sample test plan document
サンプルテスト計画を学習してダウンロードしますか？このチュートリアルは、テスト計画の例を要求した人に対応しています。
以前のチュートリアルでは、 テスト計画インデックス。 このチュートリアルでは、そのインデックスについて詳しく説明します。
テスト計画には、テストのスケジュールとアプローチ全体が反映されます。
=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください
これには、テスト計画の目的、つまり、テストアクティビティの範囲、アプローチ、リソース、およびスケジュールが含まれます。テストする項目、テストする機能、実行するテストタスク、各タスクの責任者、この計画に関連するリスクなどを特定するために。
この投稿の最後に、このテスト計画の例のPDF形式をダウンロードするためのリンクを含めました。
サンプルテスト計画
（商品名）
醸造元：
（準備した人の名前）
（日付）
目次（目次）
1.0はじめに
2.0目的とタスク
2.1目的
2.2タスク
3.0スコープ
4.0テスト戦略
4.1アルファテスト（ユニットテスト）
4.2システムと統合テスト
4.3パフォーマンスとストレステスト
4.4ユーザー受け入れテスト
4.5バッチテスト
4.6自動回帰テスト
4.7ベータテスト
5.0ハードウェア要件
c＃オブジェクト指向プログラミングの概念
6.0環境要件
6.1メインフレーム
6.2ワークステーション
7.0テストスケジュール
8.0管理手順
9.0テストする機能
10.0テストされない機能
11.0リソース/役割と責任
12.0スケジュール
13.0重大な影響を受ける部門（SID）
14.0依存関係
15.0リスク/仮定
16.0ツール
17.0承認
注意： このテスト計画はPDFとして提供されます。最大限の柔軟性を得るには、次のようなWebベースのテスト管理ツールの使用を検討してください。 TestRail テスト計画を作成します。
それぞれの分野を詳しく見ていきましょう！
1.0はじめに
これは、テストされている製品の簡単な要約です。すべての機能の概要を高レベルで説明します。
2.0目的とタスク
2.1目的
マスターテスト計画でサポートされている目的を説明し、 例えば 、タスクと責任の定義、コミュニケーションの手段、サービスレベルアグリーメントとして使用されるドキュメントなど。
2.2タスク
このテスト計画で特定されたすべてのタスク、つまり、テスト、事後テスト、問題報告などを一覧表示します。
3.0スコープ
一般： このセクションでは、特定の製品のすべての機能、その既存のインターフェイス、すべての機能の統合など、テスト対象について説明します。
戦術： 「スコープ」セクションにリストした項目をどのように達成するかについて、ここにリストしてください。
例えば 、既存のインターフェースをテストすると述べた場合、キーパーソンにそれぞれの領域を代表するように通知するために従う手順と、アクティビティの達成を支援するためのスケジュールの時間を割り当てますか？
4.0テスト戦略
テストへの全体的なアプローチを説明してください。機能または機能の組み合わせの主要なグループごとに、これらの機能グループが適切にテストされることを保証するアプローチを指定します。
指定された機能グループをテストするために使用される主要なアクティビティ、手法、およびツールを指定します。
アプローチは、主要なテストタスクの識別と各タスクの実行に必要な時間の見積もりを可能にするために十分な詳細で説明する必要があります。
4.1ユニットテスト
定義： 必要な最小限の包括性を指定します。テスト作業の包括性を判断するために使用される手法を特定します（ 例えば 、どのステートメントが少なくとも1回実行されたかを判別します）。
追加の完了基準を指定します（ 例えば 、エラー頻度）。要件を追跡するために使用する手法を指定する必要があります。
参加者： 責任を負う個人/部門の名前をリストします ユニットテスト 。
方法論： ユニットテストの実施方法を説明してください。ユニットテストのテストスクリプトは誰が作成しますか？ユニットテストのイベントのシーケンスはどのようになり、テストアクティビティはどのように実行されますか？
4.2システムと統合テスト
定義： あなたの理解をリストしてください システムテスト プロジェクトの統合テスト。
参加者： 誰がシステムを実施し、 統合テスト あなたのプロジェクトで？この活動を担当する個人をリストします。
方法論： システムと統合のテストがどのように行われるかを説明します。ユニットテストのテストスクリプトを作成するのは誰ですか。システムテストと統合テストのイベントのシーケンスはどのようになりますか。また、テストアクティビティはどのように実行されますか。
4.3パフォーマンスとストレステスト
定義： プロジェクトのストレステストについてどのように理解しているかをリストしてください。
参加者： あなたのプロジェクトで誰がストレステストを実施しますか？この活動を担当する個人をリストします。
方法論： パフォーマンスおよびストレステストの実施方法を説明してください。誰がテスト用のテストスクリプトを作成し、パフォーマンスおよびストレステストの一連のイベントはどのようになり、テストアクティビティはどのように実行されますか？
4.4ユーザー受け入れテスト
定義： 受け入れテストの目的は、システムが運用可能な状態にあることを確認することです。受け入れテスト中に、システムのエンドユーザー（顧客）はシステムを初期要件と比較します。
参加者： ユーザー受け入れテストの責任者は誰ですか？個人の名前とその責任を記載してください。
方法論： ユーザー受け入れテストの実施方法を説明してください。誰がテスト用のテストスクリプトを作成し、ユーザー受け入れテストの一連のイベントはどのようになり、テストアクティビティはどのように実行されますか？
4.5バッチテスト
4.6自動回帰テスト
定義： 回帰試験 システムまたはコンポーネントを選択的に再テストして、変更によって意図しない影響が発生していないこと、およびシステムまたはコンポーネントが要件で指定されているとおりに機能していることを確認します。
4.7ベータテスト
5.0ハードウェア要件
コンピューター
モデム
6.0環境要件
6.1メインフレーム
テスト環境の必要なプロパティと必要なプロパティの両方を指定します。
仕様には、ハードウェア、通信、システムソフトウェアなどの施設の物理的特性、使用モード（ 例えば、 スタンドアロン）、およびテストをサポートするために必要なその他のソフトウェアまたは消耗品。
また、テスト施設、システムソフトウェア、およびソフトウェア、データ、ハードウェアなどの独自のコンポーネントに提供する必要のあるセキュリティのレベルを指定します。
必要な特別なテストツールを特定します。その他のテストのニーズを特定します（ 例えば、 出版物またはオフィススペース）。現在グループで利用できないすべてのニーズの原因を特定します。
6.2ワークステーション
7.0テストスケジュール
ソフトウェアプロジェクトスケジュールで特定されたすべてのテストマイルストーンと、すべてのアイテム送信イベントを含めます。
必要な追加のテストマイルストーンを定義します。各テストタスクの実行に必要な時間を見積もります。各テストタスクとテストマイルストーンのスケジュールを指定します。各テストリソース（つまり、施設、ツール、およびスタッフ）について、その使用期間を指定します。
8.0管理手順
問題の報告
テストプロセス中にインシデントが発生した場合に従うべき手順を文書化します。標準フォームを使用する場合は、空のコピーを「付録」としてテスト計画に添付してください。
自動インシデントロギングシステムを使用している場合は、それらの手順を記述してください。
変更リクエスト
ソフトウェアの変更プロセスを文書化します。誰が変更を承認するのか、そして現在の製品への変更を含めるための基準は何かを特定します。
変更が既存のプログラムに影響を与える場合は、これらのモジュールを特定する必要があります。
9.0テストする機能
テストするすべてのソフトウェア機能とソフトウェア機能の組み合わせを特定します。
10.0テストされない機能
テストされないすべての機能と機能の重要な組み合わせを理由とともに特定します。
11.0リソース/役割と責任
テストプロジェクトに関与するスタッフとその役割を指定します（ 例えば、 Mary Brown（ユーザー）は、受け入れテスト用のテストケースをコンパイルします）。
テストアクティビティおよび関連する問題の管理、設計、準備、実行、および解決を担当するグループを特定します。
また、テスト環境の提供を担当するグループを特定します。これらのグループには、開発者、テスター、運用スタッフ、テストサービスなどが含まれる場合があります。
12.0スケジュール
主な成果物： 成果物を特定します。次のドキュメントを一覧表示できます。
- テスト計画
- テストケース
- テストインシデントレポート
- テスト概要レポート
13.0重大な影響を受ける部門（SID）
部門/ビジネスエリアバス。マネージャーテスター
14.0依存関係
テスト項目の可用性、テストリソースの可用性、期限など、テストに関する重要な制約を特定します。
15.0リスク/仮定
テスト計画のリスクの高い仮定を特定します。それぞれの緊急時対応計画を指定します（ 例えば、 テストアイテムの配信が遅れると、配信日を満たすために夜間シフトのスケジュールを増やす必要がある場合があります）。
1 6.0ツール
使用する自動化ツールを一覧表示します。また、ここにバグ追跡ツールをリストします。
17.0承認
この計画を承認する必要があるすべての人の名前と役職を指定します。署名と日付のためのスペースを提供します。
名前（大文字）署名日：
1.1。
二。
3.3。
四。
ダウンロード：このサンプルテスト計画をダウンロードすることもできます テンプレートはこちら。
本物もご用意しておりますライブプロジェクトテスト計画このサンプルから。
次のチュートリアルで確認してダウンロードできます。
=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください