- テスト自動化と比較してください。
手動テストは、ソフトウェアの欠陥を手動でテストするプロセスです。テスターはエンド ユーザーの役割を演じ、アプリケーションのほとんどの機能を使用して正しい動作を確認する必要があります。テストの完全性を保証するために、テスターは多くの場合、一連の重要なテスト ケースをガイドする書面によるテスト プランに従います。
概要
このプロセスの重要なステップは、エンド ユーザーにリリースする前にソフトウェアの動作が正しいかどうかをテストすることです。
小規模なエンジニアリング作業 (プロトタイプを含む) では、アドホック テストで十分な場合があります。この非公式なアプローチでは、テスターは厳密なテスト手順に従わず、計画やドキュメントなしでテストを実行します。逆に、同時学習、テスト設計、テスト実行を伴う探索的テストでは、以前のテストで得られた情報を使用して直感的に追加のテストを導き出し、可能な限り多くの機能を使用してアプリケーションのユーザー インターフェイスを探索します。探索的手動テストの成功は、テスターのドメイン専門知識に大きく依存します。知識が不足しているとテストが不完全になるからです。非公式なアプローチの主な利点の 1 つは、アプリケーションの使用感を直感的に把握できることです。
手動ソフトウェアテストに依存する大規模なエンジニアリングプロジェクトでは、発見できる欠陥の数を最大化するために、より厳格な方法論に従います。体系的なアプローチは、事前に決定されたテストケースに焦点を当てており、一般的に次の手順が含まれます。[1]
- 一般的な方法論が選択され、人、コンピューター、ソフトウェア ライセンスなどのリソースが特定され、取得される高レベルのテスト プランを選択します。
- 詳細なテスト ケースを記述し、テスターが実行する明確で簡潔な手順と、期待される結果を特定します。
- テストケースをテスターに割り当て、テスターは手動で手順を実行し、結果を記録します。
- テスターの調査結果を詳細に記述したテスト レポートを作成します。このレポートは、マネージャーがソフトウェアをリリースできるかどうかを判断するために使用され、リリースできない場合は、エンジニアが問題を特定して修正するために使用されます。
ウォーターフォールモデルに従う大規模なソフトウェアエンジニアリングプロジェクトでは、厳格なテストケースベースのアプローチが伝統的であることが多い。[2]しかし、少なくとも最近の1つの研究では、探索的テストとテストケースベースのテストの間に欠陥検出効率の劇的な違いは見られなかった。[3]
テストはブラックボックステスト、ホワイトボックステスト、グレーボックステストのいずれかで行うことができます。ホワイトボックステストでは、テスト担当者はソースコードを通じてステートメントを実行することに関心があります。ブラックボックステストでは、ソフトウェアを実行して欠陥をチェックし、入力の処理方法についてはあまり関心がありません。ブラックボックステストのテスト担当者はソースコードにアクセスできません。グレーボックステストは、ソースコードとアルゴリズムを理解しながらソフトウェアを実行することに関心があります。[4]
静的および動的テストのアプローチも使用できます。動的テストではソフトウェアを実行します。静的テストには、要件、コードの構文、およびプログラムのコードを実際に実行しないその他のアクティビティの検証が含まれます。
テストは、さらに機能テストと非機能テストに分けられます。機能テストでは、テスターは計算、ページ上のリンク、または与えられた入力から出力が期待されるその他のフィールドをチェックします。非機能テストには、テスト対象システムのパフォーマンス、互換性、適合性、セキュリティ、使いやすさなどのテストが含まれます。
ステージ
いくつかの段階があります。
- ユニットテスト
- テストのこの初期段階は、通常、コードを作成した開発者によって実行されますが、ホワイト ボックス テスト手法を使用する同僚によって実行される場合もあります。
- 統合テスト
- この段階は、完全なパッケージとして、または以前のパッケージの増分として、2 つのモードで実行されます。ほとんどの場合、ブラック ボックス テスト手法が使用されます。ただし、この段階では、ブラック ボックス テストとホワイト ボックス テストの組み合わせも使用されることがあります。
- システムテスト
- この段階では、ソフトウェアはあらゆる目的とプラットフォームに対して、あらゆる角度からテストされます。この段階では通常、ブラック ボックス テスト手法が使用されます。
- ユーザー受け入れテスト
- このテスト段階は、完成品に対する顧客の承認を得るために実行されます。この段階で「合格」すると、顧客がソフトウェアを承認し、使用できる状態になったことも保証されます。
- リリースまたは展開テスト
- オンサイト チームは顧客のサイトに出向き、顧客が設定した環境にシステムをインストールし、次の点を確認します。
- SetUp.exe が実行されているかどうか。
- インストール中に簡単な画面があります
- HDD上でシステムが占めるスペースはどのくらいですか
- システムからアンインストールすることを選択した場合、システムは完全にアンインストールされます。
利点
- ソフトウェアツールを使用しないため、低コストで運用可能
- ほとんどのバグは手動テストで発見される
- 人間は自動化されたツールよりも観察力と判断力に優れている
自動テストとの比較
テスト自動化により、実際のテストにかかるコストを削減または排除できる場合があります。[5]コンピューターは、人間よりも速く手順を実行でき、夜通しテストを実行して翌朝に結果を提示できます。ただし、実際のテストで節約した労力は、テスト プログラムの作成に費やさなければなりません。テストするアプリケーションの種類や選択した自動化ツールによっては、手動のアプローチよりも多くの労力が必要になる場合があります。さらに、一部のテスト ツールは非常に大量のデータを提示するため、結果の解釈に時間がかかる可能性があります。
デバイス ドライバーやソフトウェア ライブラリなどは、テスト プログラムを使用してテストする必要があります。また、多数のユーザーを対象としたテスト (パフォーマンス テストや負荷テスト) は、実際に実行するのではなく、ソフトウェアでシミュレートするのが一般的です。
逆に、レイアウトが頻繁に変更されるグラフィカル ユーザー インターフェイスを自動的にテストするのは非常に困難です。ユーザー インターフェイスの回帰テストに使用できるテスト フレームワークがあります。これらのテスト フレームワークは、キーストロークとマウス ジェスチャのシーケンスを記録し、それを再生して、ユーザー インターフェイスが毎回同じように応答することを確認します。残念ながら、これらの記録は、後続のリリースでボタンが移動されたりラベルが変更されたりすると、正しく機能しない可能性があります。プログラム出力が大幅に変化すると、自動回帰テストが失敗することもあります。
参照
- 試験方法
- ユーザビリティテスト
- GUIテスト
- ソフトウェアテスト
- コードレステスト自動化
- 健全性テスト
参考文献
- ^ ANSI/IEEE 829-1983 ソフトウェアテストドキュメントのIEEE標準
- ^ Craig, Rick David; Stefan P. Jaskiel (2002). Systematic Software Testing . Artech House. p. 7. ISBN 1-58053-508-9。
- ^ Itkonen, Juha; Mika V. Mäntylä; Casper Lassenius (2007). 「欠陥検出効率: テストケースベースと探索的テスト」(PDF) .実証的ソフトウェアエンジニアリングと測定に関する第 1 回国際シンポジウム (ESEM 2007) . pp. 61–70. doi :10.1109/ESEM.2007.56. ISBN 978-0-7695-2886-1. S2CID 5178731. 2016年10月13日時点の オリジナル(PDF)からアーカイブ。2009年1月17日閲覧。
- ^ Hamilton, Thomas (2020年5月23日). 「グレーボックステストとは何か?テクニック、例」www.guru99.com . 2022年8月7日閲覧。
- ^ Atlassian. 「テスト自動化」. Atlassian . 2022年8月7日閲覧。
