ソフトウェアテストの概要

ソフトウェアテストは、ユーザーおよびシステム仕様から収集された要件に対するソフトウェアの評価です。テストは、ソフトウェア開発ライフサイクルのフェーズレベルまたはプログラムコードのモジュールレベルで実施されます。ソフトウェアテストは、妥当性確認と検証で構成されます。

ソフトウェアの妥当性確認

検証は、ソフトウェアがユーザーの要件を満たしているかどうかを調べるプロセスです。SDLCの最後に実行されます。ソフトウェアが作成された要件に一致する場合、検証されます。

検証により、開発中の製品がユーザーの要件に従っていることが確認されます。
検証は、「このソフトウェアからユーザーが必要とするすべてのことを試みる製品を開発していますか？」という質問に答えます。
検証では、ユーザーの要件に重点が置かれます。

ソフトウェア検証

検証は、ソフトウェアがビジネス要件を満たしているかどうかを確認するプロセスであり、適切な仕様と方法論に従って開発されます。

検証により、開発中の製品が設計仕様に従っていることが確認されます。
検証は、「すべての設計仕様に厳密に従ってこの製品を開発していますか？」という質問に答えます。
検証は、設計とシステム仕様に重点を置いています。

テストの対象は-

Errors-これらは、開発者が行った実際のコーディングミスです。また、ソフトウェアの出力と希望の出力に差があり、エラーとみなされます。
Fault-エラーが存在する場合、障害が発生します。バグとも呼ばれる障害は、システム障害を引き起こす可能性のあるエラーの結果です。
Failure -障害は、システムが目的のタスクを実行できないことであると言われます。システムに障害が存在すると、障害が発生します。

手動と自動テスト

テストは、手動または自動テストツールを使用して実行できます。

Manual-このテストは、自動テストツールを使用せずに実行されます。ソフトウェアテスターは、コードのさまざまなセクションとレベルのテストケースを準備し、テストを実行して、結果をマネージャーに報告します。

手動テストは時間とリソースを消費します。テスターは、適切なテストケースが使用されているかどうかを確認する必要があります。テストの大部分は手動テストを含みます。
Automatedこのテストは、自動テストツールを使用して行われるテスト手順です。手動テストの制限は、自動テストツールを使用して克服できます。

テストでは、InternetExplorerでWebページを開くことができるかどうかを確認する必要があります。これは、手動テストで簡単に実行できます。しかし、Webサーバーが100万人のユーザーの負荷に耐えられるかどうかを確認するために、手動でテストすることはまったく不可能です。

テスターが負荷テスト、ストレステスト、回帰テストを実施するのに役立つソフトウェアとハードウェアのツールがあります。

テストアプローチ

テストは、2つのアプローチに基づいて実行できます–

機能テスト
実装テスト

実際の実装を考慮せずに機能をテストする場合、それはブラックボックステストと呼ばれます。反対側はホワイトボックステストとして知られており、機能がテストされるだけでなく、その実装方法も分析されます。

徹底的なテストは、完璧なテストのために最も望ましい方法です。入力値と出力値の範囲内のすべての可能な値がテストされます。値の範囲が広い場合、実際のシナリオですべての値をテストすることはできません。

ブラックボックステスト

プログラムの機能をテストするために実行されます。「行動」テストとも呼ばれます。この場合のテスターには、一連の入力値とそれぞれの望ましい結果があります。入力を提供する際に、出力が目的の結果と一致する場合、プログラムは「OK」でテストされ、それ以外の場合は問題があります。

このテスト方法では、コードの設計と構造がテスターに知られていないため、テストエンジニアとエンドユーザーがソフトウェアでこのテストを実行します。

ブラックボックステスト手法：

Equivalence class-入力は同様のクラスに分けられます。クラスの1つの要素がテストに合格した場合、すべてのクラスに合格したと見なされます。
Boundary values-入力は上限値と下限値に分けられます。これらの値がテストに合格した場合、その間のすべての値も合格する可能性があると見なされます。
Cause-effect graphing-以前の両方の方法では、一度に1つの入力値のみがテストされます。原因（入力）–結果（出力）は、入力値の組み合わせが体系的な方法でテストされるテスト手法です。
Pair-wise Testing-ソフトウェアの動作は、複数のパラメータに依存します。ペアワイズテストでは、複数のパラメーターの値が異なるかどうかペアワイズでテストされます。
State-based testing-システムは、入力の提供時に状態を変更します。これらのシステムは、状態と入力に基づいてテストされます。

ホワイトボックステスト

コードの効率や構造を改善するために、プログラムとその実装をテストするために実施されます。「構造」テストとしても知られています。

このテスト方法では、コードの設計と構造がテスターに知られています。コードのプログラマーは、コードに対してこのテストを実行します。

以下は、いくつかのホワイトボックステスト手法です。

Control-flow testing-すべてのステートメントと分岐条件をカバーするテストケースを設定するための制御フローテストの目的。分岐条件は、trueとfalseの両方についてテストされるため、すべてのステートメントをカバーできます。
Data-flow testing-このテスト手法は、プログラムに含まれるすべてのデータ変数をカバーすることに重点を置いています。変数が宣言および定義された場所と、それらが使用または変更された場所をテストします。

テストレベル

テスト自体は、SDLCのさまざまなレベルで定義できます。テストプロセスは、ソフトウェア開発と並行して実行されます。次のステージにジャンプする前に、ステージがテスト、妥当性確認、および検証されます。

個別のテストは、ソフトウェアに隠れたバグや問題が残っていないことを確認するためだけに行われます。ソフトウェアはさまざまなレベルでテストされています-

ユニットテスト

コーディング中、プログラマーはそのプログラム単位でいくつかのテストを実行して、エラーがないかどうかを確認します。テストは、ホワイトボックステストアプローチの下で実行されます。単体テストは、開発者がプログラムの個々のユニットが要件に従って機能しており、エラーがないことを確認するのに役立ちます。

統合テスト

ソフトウェアのユニットが個別に正常に動作している場合でも、ユニットを統合するとエラーなしで動作するかどうかを確認する必要があります。たとえば、引数の受け渡しやデータの更新など。

システムテスト

ソフトウェアは製品としてコンパイルされ、全体としてテストされます。これは、次の1つ以上のテストを使用して実行できます。

Functionality testing -要件に対してソフトウェアのすべての機能をテストします。
Performance testing-このテストは、ソフトウェアの効率性を証明します。ソフトウェアが目的のタスクを実行するのにかかる有効性と平均時間をテストします。パフォーマンステストは、負荷テストとストレステストによって実行されます。このテストでは、ソフトウェアがさまざまな環境条件下で高いユーザー負荷とデータ負荷にさらされます。
Security & Portability -これらのテストは、ソフトウェアがさまざまなプラットフォームで動作し、多数の人がアクセスすることを目的としている場合に実行されます。

受け入れ試験

ソフトウェアを顧客に引き渡す準備ができたら、テストの最後のフェーズを経て、ユーザーの操作と応答をテストする必要があります。ソフトウェアがすべてのユーザー要件に一致し、ユーザーがその外観や動作を気に入らない場合でも、拒否される可能性があるため、これは重要です。

Alpha testing-開発者のチーム自身が、システムを作業環境で使用されているかのように使用して、アルファテストを実行します。彼らは、ユーザーがソフトウェアのアクションにどのように反応するか、そしてシステムが入力にどのように反応するかを見つけようとします。
Beta testing-ソフトウェアが内部でテストされた後、テスト目的でのみ本番環境で使用するためにユーザーに渡されます。これはまだ納品された製品ではありません。開発者は、この段階のユーザーが、出席するためにスキップされた細かい問題をもたらすことを期待しています。

回帰試験

ソフトウェア製品が新しいコード、機能、または機能で更新されるたびに、追加されたコードの悪影響があるかどうかを検出するために徹底的にテストされます。これは回帰テストとして知られています。

ドキュメントのテスト

テストドキュメントはさまざまな段階で作成されます-

テストする前に

テストは、テストケースの生成から始まります。参照用に次のドキュメントが必要です–

SRS document -機能要件ドキュメント
Test Policy document -これは、製品をリリースする前にテストをどこまで行う必要があるかを示しています。
Test Strategy document -これは、テストチームの詳細な側面、責任マトリックス、およびテストマネージャーとテストエンジニアの権利/責任について言及しています。
Traceability Matrix document-これは、要件収集プロセスに関連するSDLCドキュメントです。新しい要件が発生すると、それらはこのマトリックスに追加されます。これらのマトリックスは、テスターが要件のソースを知るのに役立ちます。それらは前後にたどることができます。

テスト中

テストの開始時および実行中に、次のドキュメントが必要になる場合があります。

Test Case document-このドキュメントには、実行する必要のあるテストのリストが含まれています。これには、ユニットテスト計画、統合テスト計画、システムテスト計画、および受け入れテスト計画が含まれます。
Test description -このドキュメントは、すべてのテストケースとそれらを実行する手順の詳細な説明です。
Test case report -このドキュメントには、テストの結果としてのテストケースレポートが含まれています。
Test logs -このドキュメントには、すべてのテストケースレポートのテストログが含まれています。

テスト後

テスト後に次のドキュメントが生成される場合があります。

Test summary-このテストの概要は、すべてのテストレポートとログの集合的な分析です。ソフトウェアを起動する準備ができているかどうかを要約して結論付けます。ソフトウェアは、起動する準備ができている場合、バージョン管理システムの下でリリースされます。

テストと品質管理、品質保証、監査

ソフトウェアテストは、ソフトウェア品質保証、ソフトウェア品質管理、ソフトウェア監査とは異なることを理解する必要があります。

Software quality assurance-これらはソフトウェア開発プロセスの監視手段であり、組織の基準に従ってすべての措置が講じられていることが保証されます。この監視は、適切なソフトウェア開発方法に従っていることを確認するために行われます。
Software quality control-ソフトウェア製品の品質を維持するためのシステムです。これには、組織の親善を強化するソフトウェア製品の機能的側面と非機能的側面が含まれる場合があります。このシステムは、顧客が要件を満たす高品質の製品と「使用に適した」と認定された製品を確実に受け取るようにします。
Software audit-これは、ソフトウェアを開発するために組織が使用する手順のレビューです。開発チームから独立した監査人のチームが、ソフトウェアプロセス、手順、要件、およびSDLCの他の側面を調査します。ソフトウェア監査の目的は、ソフトウェアとその開発プロセスの両方が標準、規則、規制に準拠していることを確認することです。