テスト計画テンプレート（サンプル文書例）

替え： トーマス・ハミルトン トーマス・ハミルトン
Hours 更新中

テスト計画テンプレートとは何ですか?

テスト計画テンプレート は、テスト戦略、目的、スケジュール、見積もりと成果物、およびテストに必要なリソースを説明する詳細な文書です。 テスト計画は、テスト対象のアプリケーションの品質を検証するために必要な労力を決定するのに役立ちます。 テスト計画は、ソフトウェア テスト活動を定義されたプロセスとして実行するための青写真として機能し、テスト マネージャーによって綿密に監視および制御されます。

aを作成する テスト計画 ソフトウェア テスト プロジェクトを確実に成功させるためには必須です。テスト計画を初めて使用する場合は、このチュートリアルを参照してください。 テスト計画の作成方法

サンプル テスト計画テンプレートをダウンロード

テスト計画テンプレート

以下に、テスト計画の重要な要素を示します。

1）はじめに

プロジェクトで使用されるテスト戦略、プロセス、ワークフロー、方法論の簡単な紹介

1.1）範囲

1.1.1) 範囲内

スコープは、ソフトウェアの機能要件、機能要件または非機能要件を定義します。 なります テスト

1.1.2) 範囲外

範囲外とは、ソフトウェアの機能要件、機能要件または非機能要件を定義します。 ならないだろう テスト

1.2) 品質目標

ここで、手動テストと自動テストで達成する予定の全体的な目標について言及します。

テスト プロジェクトの目的としては、次のようなものが考えられます。

  • テスト対象アプリケーションが機能要件および非機能要件に準拠していることを確認する
  • AUT がクライアントが定義した品質仕様を満たしていることを確認する
  • バグ/問題は公開前に特定され、修正されます

1.3) 役割と責任

さまざまなチームメンバーの役割と責任の詳細な説明。

  • QAアナリスト
  • テストマネージャー
  • 構成マネージャー
  • 開発者向け
  • 設置チーム

とりわけ

関連記事

2) 試験方法

2.1。概要

プロジェクトに特定のテスト方法を採用した理由について言及します。 プロジェクトに選択されたテスト方法は次のとおりです。

  • 滝
  • 繰り返し
  • アジャイル
  • エクストリームプログラミング

選択される方法論は複数の要因によって決まります。 テスト方法について読むことができます こちら

2.2) テストレベル

テスト レベルは、テスト対象アプリケーション (AUT) で実行されるテストのタイプを定義します。テスト レベルは主にプロジェクトの範囲、時間、予算の制約によって異なります。

2.3) バグのトリアージ

トリアージの目的は、

  • 各バグの解決の種類を定義するには
  • バグに優先順位を付け、すべての「修正予定のバグ」のスケジュールを決定します。

2.4) 一時停止基準と再開要件

一時停止基準はテスト手順のすべてまたは一部を一時停止するために使用する基準を定義し、再開基準は一時停止後にテストをいつ再開できるかを決定します。

2.5) テストの完全性

ここで、テストが完了したとみなす基準を定義します。

たとえば、テストの完全性をチェックするためのいくつかの基準は次のとおりです。

  • 100% のテスト カバレッジ
  • すべての手動および自動テスト ケースが実行されました
  • すべての未解決のバグは修正されているか、次のリリースで修正される予定です

3) テストの成果物

ここでは、テスト ライフサイクルのさまざまなフェーズで提供されるすべてのテスト アーティファクトについて言及します。

簡単な納品物はこちら

  • テスト計画
  • テストケース
  • 要件のトレーサビリティ マトリックス
  • バグ報告
  • テスト戦略
  • テストメトリクス
  • 顧客のサインオフ

4) 資源と環境のニーズ

4.1) テストツール

次のようなツールのリストを作成します

プロジェクトをテストするために必要です

4.2) テスト環境

最低限のことを記載しています ハードウェア アプリケーションのテストに使用される要件。

フォロー ソフトウェアの クライアント固有のソフトウェアに加えて必要になります。

  • Windows 8以上
  • Office 2013以降
  • MSエクスチェンジなど

5) 用語/頭字語

プロジェクトで使用されている用語や頭字語について言及します。

用語/頭字語 定義
API アプリケーションプログラムインターフェイス
AUT テスト中のアプリケーション

上記のテスト計画テンプレート フォーマットをダウンロードします。

テスト計画のサンプル ドキュメント バンキング Web アプリケーションの例

1はじめに

テスト計画は、Guru99 Bank プロジェクトのあらゆるテスト活動の範囲、アプローチ、リソース、スケジュールを規定するように設計されています。計画では、テストする項目、テストする機能、実行するテストの種類、テストの責任者、テストを完了するために必要なリソースとスケジュール、計画に関連するリスクを特定します。

1.1 範囲

1.1.1 範囲内

ソフトウェア要件で定義されたwebsiteGuru99 Bankのすべての機能 スペック テストする必要があります
モジュール名 該当する役割 説明
バランスのお問い合わせ マネージャー顧客 Customer: 顧客は複数の銀行口座を持つことができます。自分の口座の残高のみを見ることができます。 マネージャー: マネージャーは、自分の管理下にあるすべての顧客の残高を表示できます。
口座振替え マネージャー顧客 お客様： 顧客は自分の口座から任意の送金先口座に資金を送金することができます。 マネージャー: マネージャーは、任意の送金元口座から送金先口座に資金を送金できます。
ミニステートメント マネージャー顧客 ミニ明細書には、アカウントの最後の 5 つの取引が表示されます お客様： 顧客は自分の口座のミニ明細書のみを見ることができる マネージャー： マネージャーは任意のアカウントのミニステートメントを確認できます
カスタマイズされたステートメント マネージャー顧客 カスタマイズされた明細書を使用すると、日付、取引額に基づいてアカウント内の取引をフィルタリングして表示できます。 お客様： 顧客は自分のアカウントのカスタマイズされた明細書のみを見ることができます マネージャー: マネージャーは任意のアカウントのカスタマイズされた明細書を見ることができます
パスワードの変更 マネージャー顧客 お客様： お客様は自分のアカウントのパスワードのみを変更できます。 マネージャー: 管理者は自分のアカウントのパスワードのみ変更できます。顧客のパスワードを変更することはできません。
新規のお客様 マネージャー マネージャー: マネージャーは新しい顧客を追加できます。
マネージャー マネージャー： マネージャーは顧客の住所、電子メール、電話番号などの詳細を編集できます。
新しいアカウント マネージャー 現在、システムでは 2 種類の口座が提供されています。 • 貯蓄口座 • 当座口座 顧客は複数の貯蓄口座を持つことができます (XNUMX つは自分の名義、もう XNUMX つは共同名義など)。 所有するさまざまな会社の当座口座を複数持つこともできます。 または、複数の当座口座と貯蓄口座を持つこともできます。 マネージャー： マネージャーは既存の顧客に新しいアカウントを追加できます。
アカウントの編集 マネージャー マネージャー： マネージャーは既存のアカウントのアカウント詳細を追加したり編集したりできます
アカウントを削除する マネージャー マネージャー： マネージャーは顧客のアカウントを追加、削除できます。
顧客の削除 マネージャー 顧客は、アクティブな当座口座または普通預金口座を持っていない場合にのみ削除できます。 マネージャー： マネージャーは顧客を削除できます。
保証金 マネージャー マネージャー： マネージャーはどの口座にも入金できます。通常は銀行支店に現金を入金するときに行われます。
撤退 マネージャー マネージャー： マネージャーはどの口座からでもお金を引き出すことができます。通常は銀行支店で現金を引き出すときに行われます。

1.1.2 範囲外

これらの機能はソフトウェア要件仕様に含まれていないため、テストされていません。
  • ユーザ·インタフェース
  • ハードウェアインターフェース
  • ソフトウェアインターフェース
  • データベース論理
  • 通信インターフェース
  • Web サイトのセキュリティとパフォーマンス

1.2 品質目標

テストの目的は次のとおりです。 確認する ウェブサイト Guru99 Bank の機能をテストすることにプロジェクトは重点を置く必要があります。 銀行業務 アカウント管理、出金、残高など。 に 保証 これらの操作はすべて機能します 通常は 実際のビジネス環境では。

1.3の役割と責任

プロジェクトで使用する必要があるのは、 アウトソーシング メンバーをテスターとしてプロジェクトのコストを節約します。
いいえ。 Director タスク
1. テストマネージャー プロジェクト全体を管理するプロジェクトの方向性を定義する適切なリソースを獲得する
2. ホイール試乗 適切なテスト手法/ツール/自動化アーキテクチャの特定と説明テストアプローチの検証と評価テストの実行、結果の記録、不具合の報告。アウトソーシングされたメンバー
3. テスト中の開発者 テストケース、テストプログラム、テストスイートなどを実装します。
4. 試験管理者 テスト環境と資産を構築し、管理および維持し、テスト実行のためにテスト環境を使用できるようにテスターをサポートします。
5. SQAメンバー 品質保証を担当し、テストプロセスが指定された要件を満たしているかどうかを確認します。

2 テスト方法

2.1概要

2.2 テストレベル

Guru99 Bank プロジェクトでは、3 種類のテストを実施する必要があります。
  • 統合 テスト（個々のソフトウェアモジュールを組み合わせてグループとしてテスト）
  • システム テスト: コンプリート, 統合された システムが指定された要件に準拠しているかを評価するシステム
  • APIテスト: テスト対象のソフトウェア用に作成されたすべての API をテストします

2.3 バグのトリアージ

2.4 一時停止の基準と再開の要件

チームメンバーが次のような報告をした場合 40％ テストケースの 失敗した、開発チームがすべての失敗したケースを修正するまでテストを一時停止します。

2.5 テストの完全性

  • を示す基準を指定します。 成功した テスト段階の完了
  • ラン レートは必須です 100％ 明確な理由が示されない限り。
  • 合格 レートは 80％、 合格率を達成するのは、 義務的な

2.6 プロジェクトのタスクと見積もりとスケジュール

仕事 加盟国 労力を見積もる
テスト仕様書を作成する テストデザイナー 170人時
テスト実行の実行 テスター、テスト管理者 80人時
試験報告書 テスター 10人時
テストの実施 20人時
トータル 280人時
これらのタスクを完了するようにスケジュールを設定する

3 テストの成果物

テスト成果物は以下のように提供されます テスト段階前
  • テスト計画の文書。
  • テストケース ドキュメント
  • テスト設計の仕様。
テスト中 – テストツールシミュレーター。 – テストデータ – テスト追跡可能性マトリックス – エラー ログと実行ログ。 テストサイクルが終了したら
  • 試験結果・報告書
  • 欠陥レポート
  • 設置/テスト手順のガイドライン
  • リリースノート

4 資源と環境のニーズ

4.1 テストツール

いいえ。 その他 Descriptイオン
1. サーバー インストールするデータベースサーバーが必要です MySQL サーバー Apache ServerをインストールするWebサーバー
2. テストツール 事前定義されたフォームにテスト結果を自動生成し、テストを自動実行できるテストツールを開発します。
3. ネットワーク LAN ギガビットと少なくとも 1 Mb/s の速度のインターネット回線を 5 本セットアップします。
4. パソコン 少なくとも 4 台のコンピュータで実行 Windows 7、RAM 2GB、CPU 3.4GHZ

4.2 テスト環境

アプリケーションのテストに使用される最小限のハードウェアおよびソフトウェア要件が記載されています。クライアント固有のソフトウェアに加えて、次のソフトウェアが必要です。
  • Windows 11以上
  • Office 2021以降
  • MSエクスチェンジなど

続きを読む readmore

よろしければ：