知識ベース

手動テスト

テスト自動化と比較してください

手動テストは、ソフトウェアの欠陥を手動でテストするプロセスです。テスターがエンドユーザーの役割を果たし、アプリケーションのほとんどの機能を使用して正しい動作を保証する必要があります。テストの完全性を保証するために、テスターは多くの場合、一連の重要なテストケースを導くテスト計画書に従います。

概要

プロセスの重要なステップは、エンドユーザーにリリースする前に、ソフトウェアの正しい動作をテストすることです。

小規模なエンジニアリング作業(プロトタイプを含む)の場合、探索的テストで十分な場合があります。この非公式のアプローチでは、テスターは厳密なテスト手順に従いませんが、以前のテストで得られた情報を使用して追加のテストを直感的に導き出し、可能な限り多くの機能を使用してアプリケーションのユーザーインターフェイスを探索します。探索的手動テストの成功は、テスターの専門知識に大きく依存しています。これは、知識が不足するとテストが不完全になるためです。非公式のアプローチの主な利点の1つは、アプリケーションを使用する気持ちを直感的に把握できることです。

手動のソフトウェアテストに依存する大規模なエンジニアリングプロジェクトは、発見できる欠陥の数を最大化するために、より厳密な方法論に従います。体系的なアプローチは、事前に決定されたテストケースに焦点を当てており、一般に次の手順を含みます。

  1. 一般的な方法論を選択し、人、コンピューター、ソフトウェアライセンスなどのリソースを特定して取得する、高レベルのテスト計画を選択します。
  2. 詳細なテストケースを記述し、テスターが行うべき明確で簡潔な手順を、期待される結果とともに特定します。
  3. テストケースをテスターに​​割り当てます。テスターは手動で手順に従い、結果を記録します。
  4. テストレポートを作成し、テスターの調査結果を詳述します。このレポートは、マネージャーがソフトウェアをリリースできるかどうかを判断するために使用され、そうでない場合は、エンジニアが問題を特定して修正するために使用します。

ウォーターフォールモデルに従う大規模なソフトウェアエンジニアリングプロジェクトでは、厳密なテストケースベースのアプローチが多くの場合伝統的です。ただし、少なくとも1つの最近の研究では、探索的テストとテストケースベースのテストとの間で、欠陥検出効率の劇的な違いは示されませんでした。

テストは、ブラックボックス、ホワイトボックス、またはグレーボックスのテストで行うことができます。ホワイトボックステストでは、テスターはソースコードを介したステートメントの実行に関心があります。ブラックボックステストでは、ソフトウェアが実行されて欠陥をチェックし、入力の処理がどのように行われるかについてあまり気にしません。ブラックボックステスターは、ソースコードにアクセスできません。グレーボックステストは、ソースコードとアルゴリズムを理解しながら、ソフトウェアを実行することに関するものです。

静的および動的テストのアプローチも使用できます。動的テストには、ソフトウェアの実行が含まれます。静的テストには、要件、コードの構文、およびプログラムのコードの実際の実行を含まないその他のアクティビティの検証が含まれます。

テストは、機能テストと非機能テストにさらに分けることができます。機能テストでは、テスターは計算、ページ上のリンク、または特定の入力で出力が予想されるその他のフィールドをチェックします。非機能テストには、テスト対象システムのパフォーマンス、互換性、適合性、セキュリティ、使いやすさなどが含まれます。

ステージ

いくつかの段階があります。彼らです:

単体テストテストのこの初期段階は、通常、コードを記述した開発者によって、時にはホワイトボックステスト手法を使用してピアによって実行されます。統合テストこの段階は、完全なパッケージとして、または以前のパッケージの増分として、2つのモードで実行されます。ほとんどの場合、ブラックボックステスト手法が使用されます。ただし、この段階では、ブラックボックステストとホワイトボックステストの組み合わせも使用される場合があります。システムのテストこの段階では、意図するすべての目的とプラットフォームについて、考えられるすべての次元からソフトウェアをテストします。この段階では、通常、ブラックボックステスト手法が使用されます。ユーザー受け入れテストこのテスト段階は、最終製品の顧客の承認を得るために実施されました。また、この段階で「合格」することで、顧客がソフトウェアを受け入れ、使用する準備ができたことを確認できます。リリースまたは展開テストオンサイトチームは、お客様のサイトにアクセスして、お客様が構成した環境にシステムをインストールし、次の点を確認します。
  1. SetUp.exeが実行中かどうか。
  2. インストール中に簡単な画面があります
  3. HDD上のシステムが占めるスペース
  4. システムからのアンインストールを選択したときに、システムは完全にアンインストールされていますか。

自動テストとの比較

テストの自動化により、実際のテストのコストを削減または排除できる場合があります。コンピューターは、人よりも迅速に一連の手順をたどることができ、朝に結果を表示するために一晩テストを実行できます。ただし、実際のテストで節約される労力は、代わりにテストプログラムの作成に費やさなければなりません。テストするアプリケーションの種類、および選択した自動化ツールによっては、手動のアプローチよりも多くの労力が必要になる場合があります。さらに、一部のテストツールは非常に大量のデータを提示するため、結果の解釈に時間がかかる可能性があります。

デバイスドライバーやソフトウェアライブラリなどは、テストプログラムを使用してテストする必要があります。さらに、多数のユーザーのテスト(パフォーマンステストと負荷テスト)は、実際に実行されるのではなく、通常ソフトウェアでシミュレートされます。

逆に、レイアウトが頻繁に変更されるグラフィカルユーザーインターフェイスは、自動的にテストするのが非常に困難です。ユーザーインターフェイスの回帰テストに使用できるテストフレームワークがあります。キーストロークとマウスジェスチャのシーケンスを記録し、それらを再生して、ユーザーインターフェイスが毎回同じように応答することを観察します。残念ながら、これらの記録は、その後のリリースでボタンを移動したり、ラベルを付け直したりすると、正しく機能しない場合があります。プログラムの出力が大きく異なる場合、自動回帰テストもだまされる可能性があります。