テストの自動化

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェア テストではテストの自動化とは、テスト対象のソフトウェアとは別のソフトウェアを使用して 、テストの実行と、実際の結果と予測された結果との比較を制御することです。[1]テストの自動化は、すでに実施されている形式化されたテスト プロセスで反復的ではあるが必要ないくつかのタスクを自動化したり、手動で行うのが難しい追加のテストを実行したりできます。テストの自動化は、継続的デリバリー継続的テストにとって重要です。[2]

テストの自動化には多くのアプローチがありますが、広く使用されている一般的なアプローチを以下に示します。

テスト ケースを自動的に生成する 1 つの方法は、テスト ケース生成用のシステムのモデルを使用するモデルベースのテストですが、それを行うためのさまざまな代替方法について研究が続けられています。[要出典]場合によっては、モデルベースのアプローチにより、非技術系ユーザーが平易な英語で自動化されたビジネス テスト ケースを作成できるようになるため、複数のオペレーティング システム、ブラウザー、およびスマート テスト ケースを構成するために、いかなる種類のプログラミングも必要ありません。デバイス。[3]

何を自動化するか、いつ自動化するか、さらには本当に自動化が必要かどうかは、テスト (または開発) チームが行わなければならない重要な決定です。[4] 52 人の専門家と 26 人の学術情報源のマルチボーカル文献レビューでは、テスト自動化の決定で考慮すべき 5 つの主な要因は次のとおりであることがわかりました: 1) テスト中のシステム (SUT)、2) テストの種類と数、3) テスト-ツール、4) 人的および組織的トピック、および 5) 横断的要因。調査で特定された最も頻繁な個々の要因は、回帰テストの必要性、経済的要因、および SUT の成熟度でした。[5]

ソフトウェア開発で増加傾向にあるのは、 xUnitフレームワーク ( JUnitNUnitなど)などの単体テストフレームワークを使用することです。このフレームワークを使用すると、単体テストを実行して、コードのさまざまなセクションがさまざまな状況で期待どおりに動作しているかどうかを判断できます。テスト ケースでは、プログラムが期待どおりに実行されることを確認するためにプログラムで実行する必要があるテストについて説明します。

主に単体テストを使用するテストの自動化は、エクストリーム プログラミングおよびアジャイル ソフトウェア開発の重要な機能であり、テスト駆動開発(TDD) またはテスト ファースト開発として知られています。コードを記述する前に、単体テストを記述して機能を定義できます。ただし、これらの単体テストは、コーディングが進むにつれて進化し、拡張され、問題が発見され、コードがリファクタリングされます。[6]要求されたすべての機能のすべてのテストに合格した場合にのみ、コードは完成したと見なされます。支持者は、手作業による調査でテストされるコードよりも信頼性が高く、コストがかからないソフトウェアを生成すると主張しています。[引用が必要]コード カバレッジが向上し、ウォーターフォール開発サイクルの最後に 1 回ではなく、開発中に常に実行されるため、信頼性が高いと見なされます。開発者は、修正するのに最も費用がかからない変更を加えるとすぐに欠陥を発見します。最後に、単体テストを使用すると、コードのリファクタリングがより安全になります。リファクタリングされたコードが単体テストでカバーされている場合、 コードをより単純な形式に変換し、コードの重複は少なく、同等の動作を行うと、新しい欠陥が発生する可能性がはるかに低くなります。

一部のソフトウェア テストタスク (大規模な低レベル インターフェイスリグレッション テストなど) は、手動で行うには面倒で時間がかかる場合があります。さらに、手動のアプローチは、特定のクラスの欠陥を見つけるのに常に効果的であるとは限りません。テスト自動化は、これらのタイプのテストを効果的に実行する可能性を提供します。

自動化されたテストが開発されると、迅速かつ繰り返し実行できます。多くの場合、これは保守寿命が長いソフトウェア製品の回帰テストの費用対効果の高い方法です。アプリケーションの存続期間中のマイナーなパッチであっても、以前の時点では機能していた既存の機能が機能しなくなる可能性があります。

ソフトウェア開発会社は自動テストの再利用性を高く評価していますが、この特性は欠点と見なすこともできます。これはいわゆる「殺虫剤のパラドックス」につながり、繰り返し実行されるスクリプトがフレームワークを超えたエラーを検出しなくなります。このような場合は、手動テストの方が適切な投資になる可能性があります。このあいまいさは、プロジェクトの要件と特性を念頭に置いて、テストの自動化に関する決定を個別に行う必要があるという結論に再びつながります。

テスト自動化ツールは高価になる可能性があり、通常は手動テストと組み合わせて使用​​されます。特に回帰テストで繰り返し使用する場合、テストの自動化は長期的には費用対効果の高いものにすることができますアプリケーションで拡張が行われるたびに実行する必要があるため (回帰テスト)、アプリケーションの一般的なフローのテスト ケースは、テストの自動化に適しています。テストの自動化により、手動テストに伴う労力が軽減されます。自動化されたチェックを開発および維持し、テスト結果を確認するには、手作業が必要です。

自動テストでは、テスト ケースがソース コードの形式で記述され、実行時にその一部であるアサーションに従って出力が生成されるため、テスト エンジニアまたはソフトウェア品質保証担当者はソフトウェア コーディング能力を持っている必要があります。一部のテスト自動化ツールでは、プログラミングを必要としないコーディングではなく、キーワードによってテスト オーサリングを行うことができます。

API テスト

API テストは、ソフトウェア テスターに​​よって広く使用されています。これにより、GUI 実装とは独立して要件を検証できるため、通常は開発の早い段階でテストし、テスト自体がクリーン コードの原則、特に単一責任の原則に準拠していることを確認できます。統合テストの一環としてAPIを直接テストし、機能、信頼性、パフォーマンス、およびセキュリティに対する期待を満たしているかどうかを判断します。[7] API にはGUIがないため、API テストはメッセージ層で実行されます。[8] API がアプリケーション ロジックへの主要なインターフェイスとして機能する場合、API テストは重要であると見なされます[9]

継続的なテスト

継続的テストは、ソフトウェア リリース候補に関連するビジネス リスクに関するフィードバックを即座に取得するために、ソフトウェア デリバリー パイプラインの一部として自動化されたテストを実行するプロセスです。[10] [11]継続的テストの場合、テストの範囲は、ボトムアップの要件またはユーザー ストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価にまで及びます。[12]

グラフィカル ユーザー インターフェイス (GUI) のテスト

多くのテスト自動化ツールは、ユーザーが対話的にユーザー アクションを記録し、何度でも再生して、実際の結果と期待値を比較できるようにする記録および再生機能を提供します。このアプローチの利点は、ソフトウェア開発がほとんど、またはまったく必要ないことです。このアプローチは、グラフィカル ユーザー インターフェイスを持つすべてのアプリケーションに適用できますただし、これらの機能に依存すると、信頼性と保守性に大きな問題が生じます。ボタンのラベルを変更したり、ウィンドウの別の場所に移動したりすると、テストの再記録が必要になる場合があります。また、記録と再生によって、無関係なアクティビティが追加されたり、一部のアクティビティが誤って記録されたりすることもよくあります。[引用が必要]

このタイプのツールのバリエーションは、Web サイトのテスト用です。ここで、「インターフェース」は Web ページです。ただし、このようなフレームワークは、 HTMLをレンダリングし、オペレーティング システム イベントではなくDOM イベントをリッスンしているため、まったく異なる手法を使用します。通常、この目的には、 Selenium Web Driverに基づくヘッドレス ブラウザーまたはソリューションが使用されます。[13] [14] [15]

このタイプのテスト自動化ツールの別のバリエーションは、モバイル アプリケーションのテスト用です。これは、携帯電話で使用されるさまざまなサイズ、解像度、およびオペレーティング システムの数を考えると、非常に便利です。このバリエーションでは、モバイル デバイスでアクションをインスタンス化し、アクションの結果を収集するために、フレームワークが使用されます。

もう 1 つのバリエーションは、スクリプトを使用しないテスト自動化です。これは、記録と再生を使用せず、代わりにアプリケーションのモデル[説明が必要]を構築し、テスターがテスト パラメーターと条件を挿入するだけでテスト ケースを作成できるようにします。スクリプト スキルは必要ありません。 .

さまざまなレベルでのテスト

Mike Cohn が提案したテスト自動化ピラミッド[16]

自動化するテストの量を決定する戦略は、テスト自動化ピラミッドです。この戦略は、粒度の異なる 3 種類のテストを作成することを提案しています。レベルが高いほど、作成するテストの量は少なくなります。[16]

レベル

  • 強固な基盤として、単体テストはソフトウェア製品に堅牢性を提供します。コードの個々の部分をテストすると、テストの作成と実行が容易になります。開発者は、各ストーリーの一部として単体テストを作成し、CI と統合します。[17]
  • サービス層とは、アプリケーションのサービスをユーザー インターフェイスとは別にテストすることを指します。これらのサービスは、アプリケーションが何らかの入力または一連の入力に応答して行うものです。
  • 最上位にはUI テストがあり、実行がより複雑になるさまざまな属性のためにテストが少なくなります。たとえば、ユーザー インターフェイスの小さな変更が多くの​​テストを壊し、メンテナンスを追加する可能性があるテストの脆弱性です。努力。[16] [18]

自動化におけるフレームワークアプローチ

テスト自動化フレームワークは、特定の製品の自動化ルールを設定する統合システムです。このシステムは、関数ライブラリ、テスト データ ソース、オブジェクトの詳細、およびさまざまな再利用可能なモジュールを統合します。これらのコンポーネントは、ビジネス プロセスを表すために組み立てる必要がある小さなビルディング ブロックとして機能します。このフレームワークは、テスト自動化の基礎を提供し、自動化作業を簡素化します。

自動化されたソフトウェア テストをサポートする前提条件、概念、およびツールのフレームワークの主な利点は、メンテナンスコストが低いことです。いずれかのテスト ケースに変更があった場合、テスト ケース ファイルのみを更新する必要があり、ドライバー スクリプトスタートアップ スクリプトは同じままです。理想的には、アプリケーションが変更された場合にスクリプトを更新する必要はありません。

適切なフレームワーク/スクリプト手法を選択することは、低コストを維持するのに役立ちます。テスト スクリプトに関連するコストは、開発と保守の労力によるものです。テストの自動化中に使用されるスクリプト作成のアプローチは、コストに影響を与えます。

一般に、さまざまなフレームワーク/スクリプト手法が使用されます。

  1. 線形 (手続き型コード、おそらく記録と再生を使用するツールなどによって生成される)
  2. 構造化 (制御構造を使用 - 通常は「if-else」、「switch」、「for」、「while」条件/ステートメント)
  3. データ駆動型(データは、データベース、スプレッドシート、またはその他のメカニズムでテストの外部で保持されます)
  4. キーワード主導
  5. ハイブリッド (上記のパターンを 2 つ以上使用)
  6. アジャイル自動化フレームワーク

Testing フレームワークは以下の責任を負います: [19]

  1. 期待を表現する形式を定義する
  2. テスト中のアプリケーションにフックまたは駆動するメカニズムを作成する
  3. テストの実行
  4. 結果の報告

自動化インターフェースのテスト

テスト自動化インターフェイスは、テスト対象アプリケーションのシステム/統合テスト用の複数のテスト ツールとフレームワークを組み込むための単一のワークスペースを提供するプラットフォームですTest Automation Interface の目標は、コーディングを邪魔することなく、テストをビジネス基準にマッピングするプロセスを簡素化することです。テスト自動化インターフェイスは、テスト スクリプトを維持する効率と柔軟性を向上させることが期待されています。[20]

テスト自動化インターフェース モデル

テスト自動化インターフェイスは、次のコア モジュールで構成されています。

  • インターフェイス エンジン
  • インターフェイス環境
  • オブジェクト リポジトリ

インターフェースエンジン

インターフェース エンジンは、Interface Environment の上に構築されます。インターフェイス エンジンは、パーサーとテスト ランナーで構成されます。パーサーは、オブジェクト リポジトリからのオブジェクト ファイルを解析して、テスト固有のスクリプト言語に変換します。テスト ランナーは、テスト ハーネスを使用してテスト スクリプトを実行します。[20]

オブジェクトリポジトリ

オブジェクト リポジトリは、テスト対象のアプリケーションの調査中にテスト ツールによって記録された UI/アプリケーション オブジェクト データのコレクションです。[20]

自動化フレームワークとテスト ツールの間の境界を定義する

ツールは、Windows や Web 自動化ツールなど、特定のテスト環境を対象とするように特別に設計されています。ツールは、自動化プロセスの駆動エージェントとして機能します。ただし、自動化フレームワークは特定のタスクを実行するためのツールではなく、さまざまなツールが統一された方法でジョブを実行できるソリューションを提供するインフラストラクチャです。これにより、自動化エンジニアに共通のプラットフォームが提供されます。

フレームワークにはさまざまな種類があります。それらは、活用する自動化コンポーネントに基づいて分類されます。これらは:

  1. データ駆動型テスト
  2. モジュール性主導のテスト
  3. キーワード駆動テスト
  4. ハイブリッド テスト
  5. モデルベースのテスト
  6. コード駆動テスト
  7. ビヘイビア駆動開発

何をテストするか

テスト ツールは、製品のインストール、テスト データの作成、GUI の操作、問題の検出 (テスト オラクルを備えた解析またはポーリング エージェントを検討してください)、欠陥のログ記録などのタスクを自動化するのに役立ちますが、必ずしもエンドツーエンドの方法でテストを自動化する必要はありません。 .

テストの自動化を考えるとき、一般的な要件を満たし続ける必要があります。

も参照

参考文献

  1. ^ コラワ、アダム。ホイジンガ、ドロタ (2007)。自動化された欠陥防止: ソフトウェア管理のベスト プラクティスWiley-IEEE コンピュータ ソサエティ プレス。p。74.ISBN _ 978-0-470-04212-0.
  2. ^ オコナー、ローリー V.; Akkaya、Mariye Umay。ケマネチ、ケレム。ユルマズ、ムラト。ポス、アレクサンダー。Messnarz、リチャード (2015-10-15)。Systems, Software and Services Process Improvement: 22nd European Conference, EuroSPI 2015, Ankara, Turkey, September 30 - October 2, 2015. Proceedings . スプリンガー。ISBN 978-3-319-24647-5.
  3. ^ ソフトウェアのテストと検証に関する第 5 回国際会議 (ICST) の議事録。ソフトウェア コンピテンス センター ハーゲンベルク。「テスト設計: 得られた教訓と実践的な意味. doi : 10.1109/IEEESTD.2008.4578383 . ISBN 978-0-7381-5746-7.
  4. ^ ブライアン・マリック. 「いつテストを自動化すべきか?」. StickyMinds.com . 2009 年 8 月20 日閲覧
  5. ^ Garousi、Vahid; Mäntylä, Mika V. (2016-08-01). 「ソフトウェア テストでいつ、何を自動化するか? マルチボーカル文献レビュー」. 情報とソフトウェア技術76 : 92–117. ドイ: 10.1016/j.infsof.2016.04.015 .
  6. ^ Vodde, Bas; コスケラ、ラッセ (2007)。「行数を数えてテスト駆動開発を学ぶ」. IEEE ソフトウェア. 24 (3): 74–79. ドイ: 10.1109/ms.2007.80 . S2CID 30671391 . 
  7. ^ API のテストはアプリケーションと評判を保護します、 Amy Reichert 著、SearchSoftwareQuality 2015 年 3 月
  8. ^ All About API Testing: An Interview with Jonathan Cooper、Cameron Philipp-Edmonds 著、Stickyminds 2014 年 8 月 19 日
  9. ^ 階層化されたテスト戦略を使用してより優れたソフトウェアを作成する[リンク切れ]、Sean Kenefick、ガートナー、2014 年 1 月 7 日
  10. ^ パイプラインの一部: 継続的なテストが不可欠な理由、Adam Auerbach、TechWell Insights 2015 年 8 月
  11. ^ The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola、Cameron Philipp-Edmonds 著、Stickyminds 2015 年 12 月
  12. ^ DevOps: Are You Pushing Bugs to Clients Faster、Wayne Ariola および Cynthia Dunlop 著、PNSQC 2015 年 10 月
  13. ^ ブラウザを使用したヘッドレス テスト。https://docs.travis-ci.com/user/gui-and-headless-browsers/
  14. ^ PhantomJS によるヘッドレス テスト; http://phantomjs.org/headless-testing.html
  15. ^ 自動化されたユーザー インターフェイス テスト。https://www.devbridge.com/articles/automated-user-interface-testing/
  16. ^ a b c マイク・コーン (2010). アジャイルで成功するライナ・クロバック。ISBN 978-0-321-57936-2.
  17. ^ 「Gayathri Mohan によるフル スタック テスト」 . www.thoughtworks.com 2022 年9 月 13 日閲覧
  18. ^ The Practical Test Pyramid、 Ham Vocke 著
  19. ^ "Selenium Meet-Up 2010 年 4 月 20 日、Robot Framework 1of2 に関する Elisabeth Hendrickson" . 2010 年9 月26 日閲覧
  20. ^ a b c 「征服: テスト自動化設計のためのインターフェース」(PDF) . 2011 年12 月 11 日閲覧

一般的な参考文献

外部リンク