テスト自動化

テスト自動化とは、テストの実行を制御し、実際の結果と予測結果を比較するために、ソフトウェア（テスト対象のソフトウェアとは別）を使用することです。 ^{[ 1 ]}テスト自動化は、手動操作なしでテスト対象システム（SUT）のテストをサポートし、テスト実行の高速化とテスト頻度の向上につながります。テスト自動化は継続的テストの重要な側面であり、継続的インテグレーションと継続的デリバリー（CI/CD）にも活用されることが多いです。^{[ 2 ]}

手動テストと比較して

自動化は手動テストに比べて多くの利点をもたらします。

APIテスト

APIテストでは、アプリケーションプログラミングインターフェース（API）を介してSUTを駆動します。手動テストと比較して、自動APIテストでは比較的短時間で比較的多くのケースを実行できる場合が多くあります。

GUIテスト

GUIテストでは、キー入力やマウスクリックなどのイベントを生成することで、グラフィカルユーザーインターフェース（GUI）を介してSUTを操作します。自動GUIテストの開発は難しい場合がありますが、人間が同様のテストを実行するよりもはるかに高速に実行できます。専門分野には以下が含まれます。

• 記録と再生テスト – 一部のGUIテストツールには、ユーザーアクションをインタラクティブに記録し、後でテストとして再生して、実際の結果と期待値を比較できる機能が備わっています。このアプローチの利点は、コーディングがほとんど、あるいは全く不要なことです。しかし、このようなテストは信頼性、保守性、精度に問題があると主張する人もいます。例えば、ボタンのラベルを変更したり、ボタンをビュー内の別の場所に移動したりすると、テストの再記録が必要になる場合があります。このようなテストは効率が悪く、重要でないアクティビティを誤って記録してしまうことがよくあります。

• ウェブサイトのテストでは、GUIはブラウザであり、インタラクションはDOMイベントとHTMLを介して行われます。通常、この目的ではヘッドレスブラウザまたはSelenium Web Driverに基づくソリューションが使用されます。^{[ 3 ] [ 4 ] [ 5 ]}

回帰テスト

自動テストを導入すれば、回帰テストは比較的迅速かつ容易に実行できます。人的時間と労力を費やす代わりに、ボタン一つで回帰テストを実行でき、実行開始さえも自動化できます。

自動化技術

以下は、テスト自動化として分類される注目すべきテスト手法です。

継続的テスト

継続的テストとは、ソフトウェア配信パイプラインの一部として自動テストを実行し、SUTのリリースによるビジネスリスクを評価するプロセスです。^{[ 6 ] [ 7 ]}テストの範囲は、ボトムアップ要件やユーザーストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価にまで及びます。^{[ 8 ]}

モデルベーステスト

モデルベーステストでは、SUTをモデル化し、そこからテストケースを生成することで、ノーコードテスト開発をサポートします。一部のツールでは、テストケースを平易な英語でエンコードし、複数のオペレーティングシステム、ブラウザ、スマートデバイスで使用できるようにしています。^{[ 9 ]}

テスト駆動開発

テスト駆動開発（TDD）は、本質的に自動テストコードの生成を含みます。ユニットテストコードは、SUTコードの作成と並行して作成されます。コードが完成すれば、テストも完了します。^{[ 10 ]}

他の

その他のテスト自動化手法には次のようなものがあります。

• データ駆動型テスト
• モジュール駆動型テスト
• キーワード駆動テスト
• ハイブリッドテスト
• 行動駆動開発

考慮事項

52人の実務家と26の学術的情報源を対象とした調査の結果、テスト自動化の決定において考慮すべき5つの主要な要素は、テスト対象システム（SUT）、テスト範囲、テストツールセット、人的および組織的課題、横断的要因であることが分かりました。最も頻繁に挙げられた要素は、回帰テストの必要性、経済的要因、そしてSUTの成熟度でした。^{[ 11 ] [ 12 ]}

自動テストの再利用性はソフトウェア開発会社によって高く評価されていますが、この特性は、同じテストを繰り返し実行するとエラーが検出されなくなるプラトー効果につながるため、欠点と見なされることもあります。

テスト ツールは、必ずしもエンドツーエンドでテストを自動 化しなくても、製品のインストール、テスト データの作成、GUI の対話、問題の検出 (テスト オラクルを備えた解析またはポーリング エージェントを検討してください)、不具合のログ記録などのタスクを自動化するのに役立ちます。

自動テストを開発する際の考慮事項は次のとおりです。

• プラットフォームとオペレーティングシステムの独立性
• データ駆動型テスト
• レポート（データベース、Crystal Reports）
• デバッグの容易さ
• ログ記録
• バージョン管理
• 拡張とカスタマイズ（例：他のツールとの統合のためのAPI）
• 開発者ツールとの統合（例：Java開発用のAntまたはMavenの使用）
• ビルドプロセスおよびバッチ実行との統合のための無人テスト実行
• 電子メール通知（バウンスメッセージなど）
• 分散テスト実行

役割

コード化された自動テストをサポートするには、テストエンジニアまたはソフトウェア品質保証担当者にソフトウェアコーディング能力が必須です。テーブル駆動型テストやノーコードテストなどのテスト手法は、プログラミングスキルの必要性を軽減、あるいは軽減します。

フレームワーク

テスト自動化フレームワークは、テストロジック、テストデータ、その他のリソースを統合するプログラミング環境を提供します。このフレームワークはテスト自動化の基盤を提供し、自動化作業を簡素化します。フレームワークを使用することで、テストの開発と保守のコストを削減できます。テストケースに変更があった場合、テストケースファイルのみを更新すればよく、ドライバースクリプトと起動スクリプトは変更されません。

フレームワークは、期待を表現するフォーマットを定義し、SUTに接続または駆動するためのメカニズムを提供し、テストを実行し、結果を報告する役割を担います。^{[ 13 ]}

さまざまなタイプのフレームワークが利用可能です。

• 線形 – 手続き型コード。記録と再生を使用するツールなどによって生成される可能性がある。
• 構造化 – 制御構造を使用します - 通常は「if-else」、「switch」、「for」、「while」条件/ステートメント
• データ駆動型- データはテスト外のデータベース、スプレッドシート、またはその他のメカニズムに保存されます
• キーワード駆動型
• ハイブリッド – 複数のタイプが使用される
• アジャイル自動化フレームワーク
• ユニットテスト – xUnit、JUnit、NUnitなどの一部のフレームワークは主にユニットテストを目的としています。

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

テスト自動化インターフェースは、システムテストや統合テストのための複数のテストツールやフレームワークを統合するためのワークスペースを提供するプラットフォームです。テスト自動化インターフェースは、コーディングなしでテストをビジネス基準にマッピングするプロセスを簡素化します。また、テストの保守の効率性と柔軟性を向上させる可能性があります。^{[ 14 ]}

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

テスト自動化インターフェースは、次の要素で構成されます。

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

パーサーとテストランナーから構成されます。パーサーは、オブジェクトリポジトリから取得したオブジェクトファイルをテスト固有のスクリプト言語に解析します。テストランナーは、テストハーネスを用いてテストスクリプトを実行します。^{[ 14 ]}

オブジェクトリポジトリ

SUTを探索中にテストツールによって記録されたUI/アプリケーションオブジェクトデータの収集。^{[ 14 ]}

参照

• GUIテストツールの比較
• ウェブテストツールのリスト
• ファジング - 自動ソフトウェアテスト手法
• バグバグ

参考文献

1. Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防：ソフトウェア管理におけるベストプラクティス. Wiley-IEEE Computer Society Press. p. 74. ISBN 978-0-470-04212-0。
2. 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。
3. ブラウザを使用したヘッドレステスト; https://docs.travis-ci.com/user/gui-and-headless-browsers/
4. PhantomJS を使用したヘッドレステスト; http://phantomjs.org/headless-testing.html
5. 自動ユーザーインターフェーステスト; https://www.devbridge.com/articles/automated-user-interface-testing/
6. パイプラインの一部：継続的テストが不可欠な理由、Adam Auerbach著、TechWell Insights 2015年8月
7. リスクと継続的テストの関係：ウェイン・アリオラ氏へのインタビュー、キャメロン・フィリップ・エドモンズ著、Stickyminds 2015年12月
8. DevOps: バグをより早くクライアントにプッシュしていますか？ ウェイン・アリオラとシンシア・ダンロップ著、PNSQC 2015年10月
9. 5回国際ソフトウェアテスト・検証会議（ICST）議事録。ソフトウェア・コンピテンス・センター・ハーゲンベルグ。「テスト設計：教訓と実践的示唆」。doi ：10.1109/IEEESTD.2008.4578383。ISBN 978-0-7381-5746-7。
10. Vodde, Bas; Koskela, Lasse (2007). 「行数カウントによるテスト駆動開発の学習」. IEEE Software . 24 (3): 74– 79. doi : 10.1109/ms.2007.80 . S2CID 30671391 . 
11. Garousi, Vahid; Mäntylä, Mika V. (2016-08-01). 「ソフトウェアテストにおいて、いつ、何を自動化すべきか？ 多角的な文献レビュー」. Information and Software Technology . 76 : 92–117 . doi : 10.1016/j.infsof.2016.04.015 .
12. Brian Marick. 「いつテストを自動化すべきか？」 StickyMinds.com . 2009年8月20日閲覧。
13. 「Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson on Robot Framework 1of2」 YouTube 2010年4月28日 . 2010年9月26日閲覧。
14. 「Conquest: テスト自動化設計のためのインターフェース」(PDF) 。 2012年4月26日時点のオリジナル(PDF)からアーカイブ。 2011年12月11日閲覧。

一般的な参考文献

• エルフリーデ・ダスティン他 (1999).自動ソフトウェアテスト. アディソン・ウェスリー. ISBN 978-0-201-43287-9。
• エルフリーデ・ダスティン他 (2009). 『自動ソフトウェアテストの実装』 . アディソン・ウェスリー. ISBN 978-0-321-58051-1。
• マーク・フュースター＆ドロシー・グラハム（1999年）『ソフトウェアテスト自動化』ACM Press/Addison-Wesley. ISBN 978-0-201-33140-0。
• ロマン・サヴェンコフ著『ソフトウェアテスターに​​なる方法』 Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
• Hong Zhu; et al. (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test . ACM Press. doi : 10.1145/1370042 . ISBN 978-1-60558-030-2。
• ダニエル・J・モズレー著、ブルース・ポージー著（2002年）『Just Enough Software Test Automation』、プレンティス・ホール・プロフェッショナル、ISBN 978-0130084682。
• Hayes, Linda G., 「自動テストハンドブック」、Software Testing Institute、第2版、2004年3月
• Kaner, Cem、「テスト自動化のアーキテクチャ」 （Wayback Machineで2021年1月26日にアーカイブ）2000年8月