Software-engineering-software-testing-overview
ソフトウェアテストの概要
ソフトウェアテストは、ユーザーとシステム仕様から収集した要件に対するソフトウェアの評価です。 テストは、ソフトウェア開発ライフサイクルのフェーズレベルまたはプログラムコードのモジュールレベルで実行されます。 ソフトウェアテストは、検証と検証で構成されます。
ソフトウェア検証
検証とは、ソフトウェアがユーザーの要件を満たしているかどうかを調べるプロセスです。 SDLCの最後に実行されます。 ソフトウェアが作成された要件に一致する場合、検証されます。
- 検証により、開発中の製品がユーザーの要件に従っていることを確認します。
- 検証は、「ユーザーがこのソフトウェアから必要とするすべてを試行する製品を開発していますか？」という質問に答えます。
- 検証では、ユーザーの要件に重点が置かれます。
ソフトウェア検証
検証は、ソフトウェアがビジネス要件を満たしているかどうかを確認するプロセスであり、適切な仕様と方法論に従って開発されます。
- 検証により、開発中の製品が設計仕様に従っていることを確認します。
- 検証は、「すべての設計仕様をしっかりと守ってこの製品を開発しているのですか？」
- 検証は、設計とシステムの仕様に集中します。
テストの対象は-
- エラー-これらは開発者が実際にコーディングした間違いです。 また、ソフトウェアの出力と目的の出力に違いがあり、エラーと見なされます。
- 障害-エラーが存在する場合、障害が発生します。 バグとも呼ばれる障害は、システムの障害を引き起こす可能性のあるエラーの結果です。
- 障害-障害とは、システムが目的のタスクを実行できないことです。 システムに障害が存在する場合、障害が発生します。
手動テストと自動テスト
テストは手動または自動テストツールを使用して実行できます。
- 手動-このテストは、自動テストツールを使用せずに実行されます。 ソフトウェアテスターは、コードのさまざまなセクションとレベルのテストケースを準備し、テストを実行して結果をマネージャーに報告します。 +手動テストは時間とリソースを消費します。 テスターは、正しいテストケースが使用されているかどうかを確認する必要があります。 テストの大部分には手動テストが含まれます。
- *自動化*このテストは、自動化されたテストツールを使用して実行されるテスト手順です。 手動テストの制限は、自動テストツールを使用して克服できます。
テストでは、Internet ExplorerでWebページを開くことができるかどうかを確認する必要があります。 これは手動テストで簡単に実行できます。 しかし、Webサーバーが100万人のユーザーの負荷を処理できるかどうかを確認するために、手動でテストすることはまったく不可能です。
テスターが負荷テスト、ストレステスト、リグレッションテストを実施するのに役立つソフトウェアおよびハードウェアツールがあります。
テストアプローチ
テストは、次の2つのアプローチに基づいて実施できます。
- 機能テスト
- 実装テスト
実際の実装を考慮せずに機能をテストする場合、ブラックボックステストと呼ばれます。 反対側はホワイトボックステストと呼ばれ、機能がテストされるだけでなく、実装方法も分析されます。
徹底的なテストは、完全なテストに最も望ましい方法です。 入力値と出力値の範囲内のすべての可能な値がテストされます。 値の範囲が大きい場合、現実世界のシナリオですべての値をテストすることはできません。
ブラックボックステスト
プログラムの機能をテストするために実行されます。 「行動」テストとも呼ばれます。 この場合のテスターには、一連の入力値とそれぞれの望ましい結果があります。 入力の提供時に、出力が目的の結果と一致する場合、プログラムは「OK」でテストされ、それ以外の場合は問題があります。
このテスト方法では、コードの設計と構造はテスターに知られておらず、テストエンジニアとエンドユーザーはソフトウェアでこのテストを行います。
ブラックボックスのテスト手法：
- 等価クラス-入力は同様のクラスに分割されます。 クラスの1つの要素がテストに合格すると、すべてのクラスが合格したと見なされます。
- 境界値-入力は上限値と下限値に分割されます。 これらの値がテストに合格した場合、その間のすべての値も合格すると想定されます。
- 原因効果グラフ-以前の方法では、一度に1つの入力値のみがテストされます。 原因（入力）–効果（出力）は、入力値の組み合わせを体系的にテストするテスト手法です。
- ペアワイズテスト-ソフトウェアの動作は複数のパラメーターに依存します。 ペアワイズテストでは、複数のパラメーターが異なる値に対してペアワイズでテストされます。
- 状態ベースのテスト-システムは入力の提供時に状態を変更します。 これらのシステムは、その状態と入力に基づいてテストされます。
ホワイトボックステスト
コードの効率または構造を改善するために、プログラムとその実装をテストするために実施されます。 「構造」テストとも呼ばれます。
このテスト方法では、コードの設計と構造がテスターに知られています。 コードのプログラマは、コードに対してこのテストを実施します。
以下は、ホワイトボックステストのテクニックです。
- 制御フローテスト-すべてのステートメントと分岐条件をカバーするテストケースを設定するための制御フローテストの目的。 分岐条件は、trueとfalseの両方についてテストされるため、すべてのステートメントをカバーできます。
- データフローテスト-このテスト手法は、プログラムに含まれるすべてのデータ変数をカバーすることを重視しています。 変数が宣言および定義された場所と、変数が使用または変更された場所をテストします。
テストレベル
テスト自体は、SDLCのさまざまなレベルで定義できます。 テストプロセスは、ソフトウェア開発と並行して実行されます。 次のステージにジャンプする前に、ステージはテスト、検証、および検証されます。
ソフトウェアに隠れたバグや問題が残っていないことを確認するために、個別にテストが行われます。 ソフトウェアはさまざまなレベルでテストされています-
単体テスト
コーディング中に、プログラマはそのプログラム単位でいくつかのテストを実行し、エラーがないかどうかを確認します。 テストはホワイトボックステストアプローチで実行されます。 ユニットテストは、開発者がプログラムの個々のユニットが要件に従って機能しており、エラーがないことを判断するのに役立ちます。
統合テスト
ソフトウェアのユニットが個別に正常に機能していても、ユニットが統合されていればエラーなく機能するかどうかを確認する必要があります。 たとえば、引数の受け渡しやデータの更新など。
システムテスト
ソフトウェアは製品としてコンパイルされ、全体としてテストされます。 これは、次のテストの1つ以上を使用して実現できます。
- 機能テスト-要件に対してソフトウェアのすべての機能をテストします。
- パフォーマンステスト-このテストは、ソフトウェアの効率を証明します。 ソフトウェアが目的のタスクを実行するのにかかる有効性と平均時間をテストします。 パフォーマンステストは、さまざまな環境条件下でソフトウェアが高いユーザー負荷とデータ負荷を受ける負荷テストとストレステストによって行われます。
- セキュリティと移植性-これらのテストは、ソフトウェアがさまざまなプラットフォームで動作することを意図しており、多くの人がアクセスするときに行われます。
受け入れ試験
ソフトウェアを顧客に引き渡す準備ができたら、最後のテスト段階を経て、ユーザーとのやり取りと応答をテストする必要があります。 これは、ソフトウェアがすべてのユーザー要件に一致し、ユーザーがその表示や動作を好まない場合でも拒否される可能性があるため、重要です。
- アルファテスト-開発者自身のチームが、まるで作業環境で使用されているかのようにシステムを使用してアルファテストを実行します。 彼らは、ユーザーがソフトウェアのアクションにどのように反応するか、システムが入力にどのように応答するかを見つけようとします。
- ベータテスト-ソフトウェアが内部でテストされた後、テスト目的でのみ本番環境で使用するためにユーザーに引き渡されます。 これはまだ提供されている製品ではありません。 開発者は、この段階のユーザーがわずかな問題をもたらすことを期待していますが、それらは出席するためにスキップされました。
回帰試験
ソフトウェア製品が新しいコード、機能、または機能で更新されるたびに、追加されたコードに悪影響があるかどうかを検出するために徹底的にテストされます。 これは回帰テストとして知られています。
テストドキュメント
テストドキュメントはさまざまな段階で準備されます-
テスト前
テストはテストケースの生成から始まります。 参考のために次の書類が必要です–
- * SRSドキュメント*-機能要件ドキュメント
- テストポリシードキュメント-これは、製品をリリースする前にテストをどこまで行う必要があるかを説明しています。
- テスト戦略ドキュメント-テストチーム、責任マトリックス、およびテストマネージャーとテストエンジニアの権利/責任の詳細な側面に言及しています。
- トレーサビリティマトリックスドキュメント-これはSDLCドキュメントであり、要件収集プロセスに関連しています。 新しい要件が来ると、このマトリックスに追加されます。 これらのマトリックスは、テスターが要件の原因を知るのに役立ちます。 それらは前後にトレースできます。
テスト中
テストの開始中および実行中には、次のドキュメントが必要になる場合があります。
- テストケースドキュメント-このドキュメントには、実施が必要なテストのリストが含まれています。 ユニットテスト計画、統合テスト計画、システムテスト計画、受け入れテスト計画が含まれます。
- テストの説明-このドキュメントは、すべてのテストケースとそれらを実行する手順の詳細な説明です。
- テストケースレポート-このドキュメントには、テストの結果としてのテストケースレポートが含まれています。
- テストログ-このドキュメントには、すべてのテストケースレポートのテストログが含まれています。
テスト後
テスト後に次のドキュメントが生成される場合があります。
- テスト概要-このテスト概要は、すべてのテストレポートとログの集合分析です。 ソフトウェアを起動する準備ができているかどうかをまとめてまとめています。 ソフトウェアは、起動準備ができている場合、バージョン管理システムの下でリリースされます。
テストvs. 品質管理、品質保証および監査
ソフトウェアテストは、ソフトウェア品質保証、ソフトウェア品質管理、ソフトウェア監査とは異なることを理解する必要があります。
- ソフトウェア品質保証-これらはソフトウェア開発プロセスの監視手段であり、それによってすべての対策が組織の基準に従って行われることが保証されます。 この監視は、適切なソフトウェア開発方法に従っていることを確認するために行われます。
- ソフトウェア品質管理-これは、ソフトウェア製品の品質を維持するためのシステムです。 ソフトウェア製品の機能的側面と非機能的側面が含まれることがあり、組織の善意を高めます。 このシステムにより、顧客は要件に合った高品質の製品を受け取り、「使用に適した」製品として認定されます。
- ソフトウェア監査-これは、組織がソフトウェアを開発するために使用した手順のレビューです。 開発チームから独立した監査チームが、SDLCのソフトウェアプロセス、手順、要件、およびその他の側面を調査します。 ソフトウェア監査の目的は、そのソフトウェアとその開発プロセスが標準、規則、規制に準拠していることを確認することです。
