Loading article…
ソフトウェアテストにおいて、テスト自動化とは、テストの実行と実際の結果と予測結果の比較を制御するために、テスト対象のソフトウェアとは別のソフトウェアを使用することです 。 [1]テスト自動化により、すでに導入されている形式化されたテストプロセスで、反復的だが必要なタスクの一部を自動化したり、手動では難しい追加のテストを実行したりできます。テスト自動化は、継続的デリバリーと継続的テストにとって重要です。[2]
一般的なアプローチ
テストの自動化にはさまざまなアプローチがありますが、以下は広く使用されている一般的なアプローチです。
- グラフィカル ユーザー インターフェイス テスト。キーストロークやマウス クリックなどのユーザー インターフェイスイベントを生成し、ユーザー インターフェイスで生じる変更を観察して、プログラムの観察可能な動作が正しいことを検証するテスト フレームワーク
- API 駆動型テスト。アプリケーションへのプログラミング インターフェイスを使用して、テスト対象の動作を検証するテスト フレームワーク。通常、API 駆動型テストでは、アプリケーションのユーザー インターフェイスは完全にバイパスされます。また、クラス、モジュール、またはライブラリへのパブリック インターフェイス (通常は) をさまざまな入力引数でテストし、返される結果が正しいことを検証することもできます。
その他のアプローチ
モデルベーステスト
テストケースを自動的に生成する方法の 1 つは、テストケース生成用のシステムのモデルを使用するモデルベーステストですが、そのためのさまざまな代替手法の研究が続けられています。 [要出典]場合によっては、モデルベースのアプローチにより、技術者以外のユーザーが平易な英語で自動化されたビジネステストケースを作成できるため、複数のオペレーティングシステム、ブラウザー、スマートデバイス用に構成するためにプログラミングは一切必要ありません。[3]
回帰テスト
一部のソフトウェア テストタスク (広範囲にわたる低レベル インターフェイス回帰テストなど) は、手動で行うには手間がかかり、時間がかかります。さらに、手動のアプローチは、特定の種類の欠陥を見つけるのに必ずしも効果的であるとは限りません。テスト自動化により、これらの種類のテストを効果的に実行できるようになります。
自動テストを開発したら、それを迅速かつ繰り返し何度も実行できます。これは、メンテナンス期間が長いソフトウェア製品の回帰テストを行うためのコスト効率の高い方法です。アプリケーションの存続期間中に小さなパッチを適用しただけでも、以前の時点では機能していた既存の機能が動作しなくなる可能性があります。
APIテスト
APIテストは、GUI実装とは独立して要件を検証できるため、ソフトウェアテスターにも広く使用されています。一般的には開発の早い段階でテストし、テスト自体がクリーンコードの原則、特に単一責任の原則に準拠していることを確認できます。統合テストの一環としてAPIを直接テストし、機能性、信頼性、パフォーマンス、セキュリティの期待を満たしているかどうかを判断します。[4] APIにはGUIがないため、APIテストはメッセージ層で実行されます。[5] APIがアプリケーションロジックへの主要なインターフェイスとして機能する場合、APIテストは重要であると見なされます。[6]
グラフィカル ユーザー インターフェイス (GUI) テスト
多くのテスト自動化ツールには、ユーザーが対話的にユーザー アクションを記録し、それを何度でも再生して、実際の結果と期待される結果を比較できる記録および再生機能が備わっています。このアプローチの利点は、ソフトウェア開発がほとんどまたはまったく必要ないことです。このアプローチは、グラフィカル ユーザー インターフェイスを持つすべてのアプリケーションに適用できます。ただし、これらの機能に依存すると、信頼性と保守性に大きな問題が生じます。ボタンのラベルを変更したり、ボタンをウィンドウの別の部分に移動したりすると、テストを再記録する必要がある場合があります。また、記録と再生によって、無関係なアクティビティが追加されたり、一部のアクティビティが誤って記録されたりすることもよくあります。[引用が必要]
このタイプのツールのバリエーションは、Web サイトのテスト用です。ここでの「インターフェース」は Web ページです。ただし、このようなフレームワークは、オペレーティング システム イベントではなくHTMLをレンダリングし、 DOM イベントをリッスンするため、まったく異なる手法を使用します。この目的には通常、ヘッドレス ブラウザーまたはSelenium Web Driverに基づくソリューションが使用されます。[7] [8] [9]
このタイプのテスト自動化ツールの別のバリエーションは、モバイル アプリケーションのテスト用です。これは、携帯電話で使用されるさまざまなサイズ、解像度、オペレーティング システムを考えると非常に便利です。このバリエーションでは、モバイル デバイスでアクションをインスタンス化し、アクションの結果を収集するためにフレームワークが使用されます。
もう 1 つのバリエーションは、記録と再生を使用せず、代わりにアプリケーションのモデル[明確化が必要]を構築し、テスト担当者がテスト パラメータと条件を挿入するだけでテスト ケースを作成できるようにするスクリプトレス テスト自動化です。スクリプト作成スキルは必要ありません。
方法論
テスト駆動開発
テスト自動化は、主にユニットテストを使用し、エクストリームプログラミングとアジャイルソフトウェア開発の重要な機能であり、テスト駆動開発(TDD) またはテストファースト開発として知られています。ユニットテストは、コードが記述される前に機能を定義するために記述できます。ただし、これらのユニットテストは、コーディングが進み、問題が発見され、コードがリファクタリングされるにつれて進化し、拡張されます。[10]要求されたすべての機能のすべてのテストに合格した場合にのみ、コードは完了したと見なされます。支持者は、手動の探索によってテストされたコードよりも信頼性が高く、コストのかからないソフトウェアを作成すると主張しています。[要出典]コードカバレッジがより良く、ウォーターフォール開発サイクルの最後に一度ではなく開発中に継続的に実行されるため、信頼性が高いと見なされます。開発者は、修正にかかるコストが最も少ない変更を行うとすぐに欠陥を発見します。最後に、ユニットテストを使用すると、コードリファクタリングがより安全になります。コードの重複が少なく動作が同等であるより単純な形式にコードを変換すると、リファクタリングされたコードが単体テストでカバーされている場合に、新しい欠陥が導入される可能性が大幅に低くなります。
継続的テスト
継続的テストとは、ソフトウェア配信パイプラインの一部として自動テストを実行し、ソフトウェアリリース候補に関連するビジネスリスクに関する即時のフィードバックを得るプロセスです。[11] [12]継続的テストの場合、テストの範囲は、ボトムアップの要件やユーザーストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価にまで及びます。[13]
考慮事項
テスト自動化の導入を決定する際に考慮すべき要素
何を自動化するか、いつ自動化するか、さらには自動化が本当に必要かどうかは、テスト（または開発）チームが下す必要がある重要な決定です。[14] 52 の専門家と 26 の学術ソースを対象とした多言語文献レビューでは、テスト自動化の決定で考慮すべき 5 つの主な要因が見つかりました。1) テスト対象システム (SUT)、2) テストの種類と数、3) テストツール、4) 人的および組織的トピック、5) 横断的要因です。この調査で最も頻繁に特定された個別の要因は、回帰テストの必要性、経済的要因、および SUT の成熟度でした。[15]
プラトー効果
自動テストの再利用性はソフトウェア開発会社によって高く評価されていますが、この特性は欠点とも見なされることがあります。これは、繰り返し実行されるスクリプトがフレームワークを超えたエラーを検出しなくなる、いわゆる「殺虫剤パラドックス」につながります。このような場合、手動テストの方が投資として適している可能性があります。この曖昧さから、テスト自動化に関する決定は、プロジェクトの要件と特性を考慮して個別に行う必要があるという結論に再び至ります。
テスト対象
テスト ツールは、必ずしもエンドツーエンドでテストを自動化しなくても、製品のインストール、テスト データの作成、GUI の操作、問題の検出 (テスト オラクルを備えた解析またはポーリング エージェントを検討してください)、不具合のログ記録などのタスクを自動化するのに役立ちます。
テストの自動化を考えるときは、次のような一般的な要件を満たし続ける必要があります。
- プラットフォームとOSの独立性
- データ駆動機能（入力データ、出力データ、メタデータ）
- カスタマイズレポート（DBデータベースアクセス、Crystal Reports）
- 簡単なデバッグとログ記録
- バージョン管理が容易 - バイナリファイルは最小限
- 拡張性とカスタマイズ性（他のツールと統合できるオープンAPI ）
- 共通ドライバー (たとえば、Java 開発エコシステムでは、AntまたはMavenと一般的なIDEを意味します)。これにより、テストを開発者のワークフローと統合できるようになります。
- ビルド プロセスおよびバッチ実行との統合のための無人テスト実行をサポートします。継続的インテグレーションサーバーではこれが必要です。
- バウンスメッセージなどのメール通知
- 分散実行環境（分散テストベッド）をサポート
- 分散アプリケーションサポート（分散SUT）
役割
テスト自動化ツール
テスト自動化ツールは高価になる場合があり、通常は手動テストと組み合わせて使用されます。テスト自動化は、特に回帰テストで繰り返し使用すると、長期的にはコスト効率が高くなります。テスト自動化に適した候補は、アプリケーションの共通フローのテスト ケースです。これは、アプリケーションに機能強化が行われるたびに実行 (回帰テスト) する必要があるためです。テスト自動化により、手動テストに関連する労力が削減されます。自動チェックの開発と維持、およびテスト結果の確認には、手動の労力が必要です。
テストエンジニア
自動テストでは、テスト ケースがソース コードの形式で記述され、実行されると、その一部であるアサーションに従って出力が生成されるため、テスト エンジニアまたはソフトウェア品質保証担当者はソフトウェア コーディング能力を持っている必要があります。一部のテスト自動化ツールでは、コーディングではなくキーワードでテストを作成できるため、プログラミングは必要ありません。
さまざまなレベルでのテスト
自動化するテストの量を決定する戦略は、テスト自動化ピラミッドです。この戦略では、粒度の異なる3種類のテストを書くことを提案しています。レベルが高くなるほど、書くテストの量は少なくなります。[16]
ユニット、サービス、ユーザーインターフェースレベル
- ユニットテストは強固な基盤としてソフトウェア製品の堅牢性を実現します。コードの個々の部分をテストすることで、テストの作成と実行が容易になります。開発者は各ストーリーの一部としてユニットテストを作成し、CIと統合します。[17]
- サービス レイヤーとは、アプリケーションのサービスをユーザー インターフェイスとは別にテストすることを指します。これらのサービスとは、アプリケーションが何らかの入力または入力セットに応じて実行するすべてのことです。
- 最上位レベルではUIテストがありますが、これはさまざまな属性によって実行が複雑になるためテストが少なくなります。たとえば、テストの脆弱性により、ユーザーインターフェイスの小さな変更が多くのテストを中断させ、メンテナンスの手間を増やす可能性があります。[16] [18]
ユニット、統合、エンドツーエンドレベル
テストピラミッドの1つの概念には、ユニットテスト、統合テスト、エンドツーエンドのユニットテストが含まれます。Googleのテストブログによると、ユニットテストがテスト戦略の大部分を占め、統合テストは少なく、エンドツーエンドテストはごくわずかであるべきです。[19]
- ユニット テスト: 個々のコンポーネントまたはコード ユニットを個別にテストするテストです。高速で信頼性が高く、障害を小さなコード ユニットに分離します。
- 統合テスト: これらのテストでは、異なるコード ユニットがどのように連携して動作するかを確認します。個々のユニットは単独でも適切に機能しますが、統合テストではそれらが一貫して連携して動作することを確認します。
- エンドツーエンド テスト: システム全体をテストし、実際の使用シナリオをシミュレートします。これは最も時間がかかり、最も複雑なテストです。
自動化におけるフレームワークアプローチ
テスト自動化フレームワークは、特定の製品の自動化のルールを設定する統合システムです。このシステムは、関数ライブラリ、テスト データ ソース、オブジェクトの詳細、およびさまざまな再利用可能なモジュールを統合します。これらのコンポーネントは、ビジネス プロセスを表すために組み立てる必要のある小さな構成要素として機能します。フレームワークは、テスト自動化の基盤を提供し、自動化作業を簡素化します。
自動ソフトウェア テストをサポートする前提、概念、ツールのフレームワークの主な利点は、メンテナンスコストが低いことです。テスト ケースに変更があった場合、テスト ケース ファイルのみを更新すればよく、ドライバー スクリプトと起動スクリプトはそのまま残ります。理想的には、アプリケーションに変更があった場合でもスクリプトを更新する必要はありません。
適切なフレームワーク/スクリプト手法を選択すると、コストを低く抑えることができます。テスト スクリプトに関連するコストは、開発と保守の作業に起因します。テスト自動化中に使用されるスクリプトのアプローチは、コストに影響を与えます。
一般的に、さまざまなフレームワーク/スクリプト手法が使用されます。
- 線形（手続き型コード、記録と再生を使用するツールなどによって生成される可能性がある）
- 構造化（制御構造を使用 - 通常は「if-else」、「switch」、「for」、「while」条件/ステートメント）
- データ駆動型（データはテスト外のデータベース、スプレッドシート、またはその他のメカニズムに保存されます）
- キーワード駆動
- ハイブリッド（上記のパターンの2つ以上が使用される）
- アジャイル自動化フレームワーク
テストフレームワークは以下の責任を負います: [20]
- 期待を表現する形式を定義する
- テスト対象のアプリケーションに接続したり駆動したりするメカニズムを作成する
- テストを実行する
- 結果報告
ユニットテストフレームワーク
ソフトウェア開発では、 xUnitフレームワーク ( JUnitやNUnitなど)などの単体テストフレームワークの使用がますます増えています。これらのフレームワークでは単体テストを実行して、さまざまな状況下でコードのさまざまなセクションが期待どおりに動作しているかどうかを判断できます。テスト ケースは、プログラムが期待どおりに動作することを確認するためにプログラムで実行する必要があるテストを記述します。
テスト自動化インターフェース
テスト自動化インターフェースは、テスト対象アプリケーションのシステム/統合テスト用の複数のテストツールとフレームワークを組み込むための単一のワークスペースを提供するプラットフォームです。テスト自動化インターフェースの目標は、コーディングをプロセスの邪魔にすることなく、テストをビジネス基準にマッピングするプロセスを簡素化することです。テスト自動化インターフェースは、テストスクリプトの保守の効率と柔軟性を向上させることが期待されています。[21]
テスト自動化インターフェースは、次のコア モジュールで構成されています。
- インターフェースエンジン
- インターフェース環境
- オブジェクトリポジトリ
インターフェースエンジン
インターフェースエンジンはインターフェース環境の上に構築されます。インターフェースエンジンはパーサーとテストランナーで構成されています。パーサーはオブジェクトリポジトリから取得したオブジェクトファイルをテスト固有のスクリプト言語に解析するために存在します。テストランナーはテストハーネスを使用してテストスクリプトを実行します。[21]
オブジェクトリポジトリ
オブジェクトリポジトリは、テスト対象アプリケーションを探索中にテストツールによって記録されたUI /アプリケーションオブジェクトデータのコレクションです。[21]
自動化フレームワークとテストツールの境界を定義する
ツールは、Windows や Web 自動化ツールなどの特定のテスト環境を対象に特別に設計されています。ツールは自動化プロセスの駆動エージェントとして機能します。ただし、自動化フレームワークは特定のタスクを実行するツールではなく、さまざまなツールが統一された方法でジョブを実行できるソリューションを提供するインフラストラクチャです。これにより、自動化エンジニアに共通のプラットフォームが提供されます。
フレームワークにはさまざまな種類があります。これらは、活用する自動化コンポーネントに基づいて分類されます。次のとおりです。
- データ駆動型テスト
- モジュール駆動型テスト
- キーワード駆動型テスト
- ハイブリッドテスト
- モデルベーステスト
- コード駆動型テスト
- 行動主導型開発
データ駆動型テスト
データ駆動型テスト(DDT) は、テーブル駆動型テストまたはパラメータ化テストとも呼ばれ、コンピュータソフトウェアのテストで使用されるソフトウェア テスト方法論です。テスト入力と検証可能な出力として条件テーブルを直接使用して実行されるテスト、およびテスト環境の設定と制御がハードコードされていないプロセスについて説明します。[22] [23]最も単純な形式では、テスターはテーブルの行から入力を提供し、同じ行に発生する出力を期待します。テーブルには通常、境界またはパーティション入力スペースに対応する値が含まれています。制御方法論では、テスト構成はデータベースから「読み取られます」。
モジュール駆動型テスト
モジュール駆動型テストは、ソフトウェアのテストで使用される用語です。テストスクリプトのモジュール化フレームワークでは、テスト対象アプリケーションのモジュール、セクション、機能を表す小さな独立したスクリプトを作成する必要があります。これらの小さなスクリプトは、階層的に使用され、より大きなテストを構築し、特定のテストケースを実現します。[24]
キーワード駆動型テスト
キーワード駆動テストは、アクション ワード ベース テストとも呼ばれ、手動テストと自動テストの両方に適したソフトウェア テスト手法です (アクション駆動テストと混同しないでください)。この方法では、テスト ケースのドキュメント (使用するデータと機能の両方を含む) と、テスト ケースの実行方法の規定を分離します。その結果、テスト作成プロセスが、設計および開発段階と実行段階の 2 つの異なる段階に分割されます。設計サブステージでは、要件分析と評価、およびデータの分析、定義、および入力がカバーされます。
ハイブリッドテスト
ハイブリッド テストは、ほとんどのフレームワークが時間の経過と複数のプロジェクトを経て進化/発展していくものです。最も成功している自動化フレームワークは、通常、文法とスペル、および情報入力の両方に対応しています。これにより、提供された情報を既存の確認済みの情報と照合できます。これにより、誤った情報や誤解を招く情報が投稿されるのを防ぐことができます。ただし、既存の投稿に新しい関連情報を投稿することはできます。そのため、サイトの有用性と関連性が高まります。とはいえ、完璧なシステムはなく、常にすべての主題でこの基準を満たすとは限りませんが、入力と使用が増えるにつれて改善されます。
モデルベーステスト
行動主導型開発
参照
参考文献
- ^ Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防: ソフトウェア管理のベストプラクティス. Wiley-IEEE Computer Society Press. p. 74. ISBN 978-0-470-04212-0。
- ^ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (2015-10-15). システム、ソフトウェア、およびサービス プロセス改善: 第 22 回ヨーロッパ会議、EuroSPI 2015 、トルコ、アンカラ、2015 年 9 月 30 日 - 10 月 2 日。議事録。Springer。ISBN 978-3-319-24647-5。
- ^ 第 5 回国際ソフトウェアテストおよび検証会議 (ICST) の議事録。ソフトウェア コンピテンス センター ハーゲンベルグ。「テスト設計: 学んだ教訓と実践的影響」。doi :10.1109 / IEEESTD.2008.4578383。ISBN 978-0-7381-5746-7。
- ^ API のテストはアプリケーションと評判を守る、Amy Reichert 著、SearchSoftwareQuality 2015 年 3 月
- ^ API テストのすべて: Jonathan Cooper とのインタビュー、Cameron Philipp-Edmonds 著、Stickyminds、2014 年 8 月 19 日
- ^ 階層化テスト戦略を使用してソフトウェアの品質を向上させる、ショーン・ケネフィック著、ガートナー、 2014 年 1 月 7 日
- ^ ブラウザを使用したヘッドレステスト; https://docs.travis-ci.com/user/gui-and-headless-browsers/
- ^ PhantomJS を使用したヘッドレステスト;http://phantomjs.org/headless-testing.html
- ^ 自動ユーザーインターフェーステスト; https://www.devbridge.com/articles/automated-user-interface-testing/
- ^ Vodde, Bas; Koskela, Lasse (2007). 「行数を数えてテスト駆動開発を学ぶ」. IEEE ソフトウェア. 24 (3): 74– 79. doi :10.1109/ms.2007.80. S2CID 30671391.
- ^ パイプラインの一部: 継続的テストが不可欠な理由、Adam Auerbach 著、TechWell Insights 2015 年 8 月
- ^ リスクと継続的テストの関係: Wayne Ariola 氏へのインタビュー、Cameron Philipp-Edmonds 著、Stickyminds 2015 年 12 月
- ^ DevOps: バグをより早くクライアントにプッシュしていますか、Wayne Ariola と Cynthia Dunlop 著、PNSQC 2015 年 10 月
- ^ Brian Marick. 「いつテストを自動化すべきか?」 StickyMinds.com . 2009 年 8 月 20 日閲覧。
- ^ Garousi, Vahid; Mäntylä, Mika V. (2016-08-01). 「ソフトウェアテストでいつ何を自動化するか? 多言語文献レビュー」.情報およびソフトウェア技術. 76 : 92–117 . doi :10.1016/j.infsof.2016.04.015.
- ^ abc Mike Cohn (2010).アジャイルで成功する。Raina Chrobak. ISBN 978-0-321-57936-2。
- ^ 「Full Stack Testing by Gayathri Mohan」。www.thoughtworks.com 。 2022年9月13日閲覧。
- ^ 実技試験ピラミッド、ハム・ヴォッケ著
- ^ ab 「エンドツーエンドテストを増やすのはやめましょう」。Google Testing Blog 。2023 年 2 月 11 日閲覧。
- ^ 「Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson による Robot Framework 1/2」。YouTube。2010年4 月 28 日。2010年 9 月 26 日閲覧。
- ^ abc 「Conquest: テスト自動化設計のためのインターフェース」(PDF) 。 2012年4月26日時点のオリジナル(PDF)からアーカイブ。2011年12月11日閲覧。
- ^ 「golang/go TableDrivenTests」。GitHub。
- ^ 「JUnit 5 ユーザーガイド」. junit.org .
- ^ DESAI, SANDEEP; SRIVASTAVA, ABHISHEK (2016-01-30). ソフトウェアテスト: 実践的アプローチ (アラビア語). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1。
一般的な参考文献
- Elfriede Dustin 他 (1999)。自動ソフトウェアテスト。Addison Wesley。ISBN 978-0-201-43287-9。
- Elfriede Dustin 他 (2009)。自動ソフトウェアテストの実装。Addison Wesley。ISBN 978-0-321-58051-1。
- Mark Fewster & Dorothy Graham (1999)。ソフトウェアテスト自動化。ACM Press/Addison- Wesley。ISBN 978-0-201-33140-0。
- Roman Savenkov:ソフトウェアテスターになる方法。Roman Savenkov Consulting、2008 年、ISBN 978-0-615-23372-7
- Hong Zhu 他 (2008)。AST '08: ソフトウェアテストの自動化に関する第 3 回国際ワークショップの議事録。ACM Press。doi : 10.1145 /1370042。ISBN 978-1-60558-030-2。
- Mosley, Daniel J.; Posey, Bruce (2002)。Just Enough Software Test Automation。Prentice Hall Professional。ISBN 978-0130084682。
- Hayes, Linda G.、「自動テスト ハンドブック」、Software Testing Institute、第 2 版、2004 年 3 月
- Kaner, Cem、「テスト自動化のアーキテクチャ」、2000 年 8 月、Wayback Machineで 2021-01-26 にアーカイブ