ディレクトリ
ソフトウェアテストの定義
ソフトウェアのテストを手動テストシステムソフトウェアまたは静的チェックツールの下にソフトウェアによって自動的に操作され、それは検査対象物であるか、またはソフトウェア・システムが満たす検証要件を、又は所望の出力に実際の出力との差を明確にします。
ソフトウェアのテストは、常に周りの需要拡大です。
4段階のソフトウェア開発
- 定義要件（校長）
- 需要の分析（両側）
- 実装要件（開発者）
- 需要を確認してください（テスター）
一般的に、ソフトウェア開発ライフサイクル、テストでは、可能な限り早期に関与すべきです。現在普及している要件フェーズの分析に関与。
ソフトウェアテストの4つのステップ
- プラン：文書（要求仕様、予備設計文書や詳細設計ドキュメント）と事業計画に基づいて、テスト計画を策定します。
- デザイン：デザインのテストケースやテスト方法。
- 実装：テスト構成のテスト環境、デザイン主導型のモジュールによると、最終的にテストを実行し、テスト結果、欠陥を探します。
- 評価：テストしたソフトウェアシステムの品質を評価する品質評価試験の仕事。
動的試験マニュアルのための基本的な手順
- 測定対象物の提供
- 準備に関連する予想（すなわち、様々な文書）
- デザインのテストケース
- テスト環境をセットアップします
- テストケースを実行します
- テストの実行結果
- レコードの実行
- レポート発見された欠陥
- 回帰テスト
手動の静的テストの基本的な手順
- 測定対象物の提供
- 準備に関連する期待
- 確認コード、ドキュメント
- レポート発見された欠陥
私たちは、実装が簡単、より高い技術者のための静的テスト要件ルックスは、後に詳細に説明されることを以下の動的試験手順に比べて静的テストを見ることができます。
テストケース
実際のソフトウェアのテストは、3の品質、コストと時間の間でバランスされなければならないので、実際のソフトウェアのテストは、多くの場合、設計へのリスクが最も低い、最高の効率の分割統治の原理に基づいています。したがって、我々はテストケースが発生しておく必要があります。
テストを意味需要表すために小さなテストユニットをシステムの実装の実際の結果を説明する、ユーザーの期待出力を記述する。：主に3つの部分が含ま入力、出力、およびテスト環境を。
ソフトウェアテストモデル
ソフトウェアテストモデルの主ウォーターフォールモデル、Vモデル、W及びHモデルモデル4。
ウォーターフォールモデル
従来のウォーターフォールモデルは、ニーズ分析、概要設計、詳細設計以降の段階でコーディング、この部門の高い修理費用が生じた欠陥の後期発見に通常リードとしてのみテストプロセスです。
Vモデル
Vモデルは、開始するために定義されたビジネスニーズから始まる、開発段階の片側に、伝統的なウォーターフォールモデルの欠点を改善して、ソフトウェアの仕様の需要を変換した後、アウトラインの設計と詳細設計に切り替え、最終的にプログラムコードとしてエンコードされました。テスト実行フェーズの一方の側、第一ユニットテストと統合テスト、システムテスト、及び最終的に受け入れテストに形態の異なるソフトウェア・テスト（レベル）のレベル、および開発プロセスの各段階に対応していること。
Wモデル
Wモデルはオーバーラップによって形成される2つの「V」で構成されています。「V」は、ニーズ分析、一般的な設計、詳細設計、実装コーディング、モジュールの統合、システム構築、システムのインストール段階を含む開発プロセスを表します。別の「V」は、試験の概要、詳細設計、テスト、単体テスト、統合テスト、システムテストと受け入れテストやその他の活動に設計された要件を、テストを含むテストプロセスを表します。それぞれの開発プロセスのすべての段階でのソフトウェアのテストやテスト活動、。
それは、ソフトウェアのテスト要求分析段階に関与すべきであると指摘し、現在広く使用されているソフトウェアのテストモデルです。
Hモデル
Hモデルは、テストは、テストの準備とテスト実行二つの異なる段階に分かれて強調して長いため、プロセスが場所の他のテスト準備時点で進歩につながっているように、この時間は、長いテストの準備として、テスト実行活動ができるか行う必要として完成することができません間Hモデルでテスト重視が完全に独立したモデルであり、クロスや他のプロセスを実行することが可能ですが、また、私たちはできるだけ早くテストを実行することができます。
ソフトウェアのテストは完了していません
ソフトウェアのテストが完了していない、リスクがあります。ソフトウェアのテストは、ソフトウェアが欠陥のないことを保証することはできません、ソフトウェアの欠陥を識別することができます。良いテストはこれまでに見つかっていないソフトウェアの欠陥を見つけることです。
試験方法評価基準
試験方法は、少なくとも人間と最短時間で設計する必要があり、最大かつ最も深刻な欠陥の賛成で見つかりました。だから、そのための方法は、以下の5つの評価基準があります。
- 正確：強く絞ったテスト（テストケースの数より少ないです）
- 完全：完全にテストカバレッジ、バグのない（リスクをカバーするカバレッジ要件）へ
- 冗長性なし：テストケースを関連するニーズやリスクは区別されるべきではありません
- シンプル：試験方法は簡単で、実装が容易でなければなりません
- 試運転のしやすさ：小さな欠陥を見つけることの難しさ
