まず、定義およびソフトウェアテストの目的
1.1の定義
古典的な定義：ソフトウェアテスト（ソフトウェアテスト）、動作するようにバグを発見するために、ソフトウェアの品質を測定し、そしてそれは、設計プロセスの要件を満たすことができるかどうかを評価するプログラムで指定された条件の下で。
標準的な定義：ソフトウェアのテストを実行したり、システムをテストするために、手動または自動手段の使用で、その目的は、指定された要件を満たしているかどうかを調べたり、期待される結果と実際の結果との違いを明らかにすることでした。
これは、（全体的にまたは部分的に）ソフトウェア・プロセスの正確性、完全性および品質コンピュータソフトウェアの（中間又は最終バージョン）を特定するために開発されました。
1.2コンテンツ
主なタスクをテストソフトウェアは、（検証）と確認（検証）を確認することです。
検証は、そのソフトウェアが正しくあなたが期待することを行うためのソフトウェアを確保することである一連の活動、いくつかの特定の機能を実装して確保することです。（正しいことを行います）
確認が目的が与えられた外部環境のソフトウェアロジックの正しさを確認することで、活動や一連の処理です。どのソフトウェアにこのイベントを行うための正しい方法を確保することである（右のそれを実行してください）
ソフトウェアのテストは、このような要求仕様、予備設計文書、詳細な設計文書はもちろん、メインターゲットやソフトウェアテストのソースとして、生成されたQの全ての段階でのドキュメントが含まれている必要があり、単にオブジェクトプログラムのテスト、ソフトウェアの開発を通して、ソフトウェアのテストではありません。
1.3目的
目的は、原因によって引き起こされる可能性のあるソフトウェアの不具合やエラーへのソフトウェアリリースでリスクを回避するために、潜在的なソフトウェアのエラーや欠陥のすべての種類を見つけると、エラーや欠陥を補正することにより、ソフトウェアの品質を向上させるために、最小限の人員、材料資源と時間を使用してソフトウェアをテストすることですビジネスリスクへ。
ソフトウェアテストの目的は、問題を見つけることです、問題を特定し、見つかっていません。システムが要件を満たしているか確認してください。
Grenford J.Myersビュー：
（1）プログラムの実行がテストされ、エラーを発見することを目的は、
（2）これまでに見つけることができ、良好なテストがエラーを発見した;
（3）成功した試験は、試験中にエラーが発見され見つかりませんでした。
第二に、テストプロセス
試験要件は、分析フェーズ：読書ニーズは、主にビジネスを学ぶ、ニーズを理解し、需要のポイントを分析し、ニーズ調査会に関与し
たテスト計画段階：主なタスクは、テストを含むソフトウェア要求仕様書、プロジェクトのマスタープラン、を参照して、テストプログラムを書くことです（要件文書から）の範囲、スケジュール、人的・物的資源の配分、全体的なテスト戦略の開発。リスク評価と意思を避けるための措置。
テスト設計段階：メインの要件文書（プロトタイプ図面）、概要設計、詳細設計文書への参照を行います、テストケースを書くことで、ユースケースは、準備が完了した後に審査されます。
テスト実行フェーズ：、環境を構築する（事前テスト）スモークテストを実行する-し、テストの終了時まで、正式なテスト、バグ管理に
試験評価段階：上のオンラインかどうかを確認するためのテストレポート
ソフトウェアテストの第三に、原則
3.1試験規格は、ユーザーのニーズである
テスターは常に、ユーザーの視点から問題を見なければならないソフトウェアの欠陥の影響を判断するために、すべてのソフトウェアテストのは、ユーザーのニーズにさかのぼるされなければならない、プログラムを引き起こし、システムの最も重大なエラーがものであり、欠陥は、ユーザーのニーズを満たすことができません。
3.2、事前定義された標準の良い品質の製品
品質規格、製品の品質試験結果に基づいて分析し、評価を補正するためには、例えば、予備性能試験、良好なパフォーマンスの関連指標の定義すべきです。試験結果が検証できない場合同様、期待される出力を決定すべきであるテストケースは、それが決定することができません。
3.3、「できるだけ早くとソフトウェアテストを実行し続ける」ことのテスターのモットーとしてすべき
ソフトウェア開発ライフサイクル会計ソフトウェアプロセスの間違った早期導入で60％〜50％の量（最終欠陥を含む）すべてのエラー。、欠陥増幅傾向。要件の位相誤差がNの設計ミスにつながる可能性があるとして、そのため、後者の試験より、より大きな欠陥を修復するために支払った価格です。
恣意除く3.4、テスト計画、
前実際のテストに、テスト戦略及びテストの目的を決定するために、特に、音声、試験計画の実用的かつ厳格な実施を確立します。試験計画が含まれるべきである：測定ソフトウェア、入力と出力、試験、試験プロセス制御方法及びリソース要件、テストデータ、テストツール、テストケースの選択、テスト、システムの構成スケジューリング機能をトラックなど回帰テストや評価基準などのルール、デバッグルール、および要件。
3.5と完全テストは、テストを脇に置くことができない
テストの効率を向上させるために、設計に対応する試験方法を用いて、目的に応じてテストのために、より多くのエラーは、プログラムの信頼性を向上することが見出されています。行う手順が行われるべきかどうかをチェックすることに加えて、手順が完了したか否かに依存すべきではない、合理的な入力データが不正な入力のために使用されなければならないだけでなく、テストのためのテストケースを設計しなければなりません。
クラスター現象があることを十分に認識し3.6、
80/20原則をつかむには、テストを最適化することを目標と最短時間でより多くの問題を発見したが、また、テスターにテストプロセスの全体的な把握を確実にするためにすることができます。特にプロジェクトタイトな、複雑性の高い、あなたは時間、相を分けることができ、モジュールが問題を解決するとき、それは問題を解決するための効果的な方法の一つです。
3.7は、自分の手順をテスト避ける
ため、心理的要因に、人は無意識のうちに自分のミスを見つけることしたくありません。この考え方に基づいて、自分のミスを見つけることは困難です。そのため、ソフトウェア開発者が自社製品のテストを避けるために試してみてください、第三者がテストする必要があり、もちろん、開発者は、配信前に自己テストに関連する必要があります。独立したテスト（開発者が独自のコードを避けることを好む）のある程度は、あなたがソフトウェア障害やソフトウェアのバグが存在し、より効率的に見つけることができます。開発者が効率的に自分のコードには多くの欠陥を見つけることができますので、しかし、独立したテストでは、完全な代用品ではありません。スタッフの開発の責任の一つであるソフトウェア開発の初期の開発者に深刻なテストのための彼らの作品製品。
3.8、それはテストを終了する必要があり、完全にテストすることは不可能である
、ことはできませんテストは、特定のテスト終了基準を満たして終了しなければならないときに、現在の状況と組み合わせる必要が徹底的なテストを。
3.9は、回帰テスト
修正後のプログラム、エラーを発生させるために他のコードを新しいバグを導入または発生しない変更を確認するために再テストする必要があります。
3.10、すべてのテストドキュメントの適切な保全