テスト計画は、ソフトウェアのテスト領域とアクティビティを説明する詳細な文書です。テスト戦略、目的、テスト スケジュール、必要なリソース (人的リソース、ソフトウェア、ハードウェア)、テストの見積もり、テストの成果物の概要を示します。

テスト計画は、あらゆるソフトウェアのテストの基礎となります。これは、計画されたアクティビティのすべてのリストを適切な順序で確実に利用できるようにする最も重要なアクティビティです。

テスト計画は、テスト マネージャーによって完全に監視および制御される、定義されたプロセスとしてソフトウェア テスト活動を実行するためのテンプレートです。テスト計画は、テスト リーダー (60%)、テスト マネージャー (20%)、およびテスト エンジニア (20%) によって作成されます。

テスト計画の種類

テストプランは3種類あります

• マスターテスト計画
• フェーズテスト計画
• テストタイプ固有のテスト計画

マスターテスト計画

マスター テスト計画は、複数のレベルのテストを含むテスト計画の一種です。これには完全なテスト戦略が含まれています。

フェーズテスト計画

フェーズ テスト計画は、テスト戦略の任意の 1 つのフェーズに対処するテスト計画のタイプです。たとえば、ツールのリスト、テスト ケースのリストなどです。

特定のテスト計画

セキュリティ テスト、負荷テスト、パフォーマンス テストなどの主要な種類のテスト用に設計された特定のテスト計画。言い換えれば、非機能テスト用に設計された特定のテスト計画。

文字列Java

テスト計画の書き方

テスト計画の作成は、テスト管理プロセスの最も重要なタスクです。 IEEE 829 に従って、次の 7 つの手順に従ってテスト計画を準備します。

• まず、製品の構造とアーキテクチャを分析します。
• 次に、テスト戦略を設計します。
• すべてのテスト目標を定義します。
• テスト領域を定義します。
• 使用可能なすべてのリソースを定義します。
• すべてのアクティビティを適切な方法でスケジュールします。
• すべてのテスト成果物を決定します。

テスト計画のコンポーネントまたは属性

テスト計画はさまざまな部分で構成されており、テスト アクティビティ全体を導き出すのに役立ちます。

目的: これは、モジュール、機能、テストデータなどに関する情報で構成されており、アプリケーションの目的、つまりアプリケーションの動作、目標などを示します。

範囲： それぞれのアプリケーションでテストする必要がある情報が含まれています。スコープはさらに 2 つの部分に分けることができます。

• 範囲内
• 範囲外

範囲内： これらは厳密に (詳細に) テストする必要があるモジュールです。

範囲外: これらはモジュールであり、厳密にテストする必要はありません。

例えば , テストする Gmail アプリケーションがあるとします。 テストする機能 のような メールの作成、送信済みアイテム、受信トレイ、下書き そしてその テストされていない機能 のような ヘルプ など、企画段階で製品に定められた期限に基づいて、どの機能をチェックするかチェックしないかを決定します。

今 どの機能をテストしないかをどのように決定するのでしょうか?

どの機能をテストしないかを決定できる次の側面があります。

• 上記でわかるように、 ヘルプ 機能はテクニカル ライターによって作成および開発され、別のプロのライターによってレビューされるため、テストされません。
• 次のようなアプリケーションが 1 つあると仮定します。 P、Q、R、S 要件に基づいて開発する必要がある機能。しかし、ここでは、S 機能はすでに他の企業によって設計され、使用されています。そこで開発チームはその会社から S を購入し、P、Q、R などの追加機能と統合します。

S 機能はすでにリアルタイムで使用されているため、S 機能の機能テストは実行しません。ただし、以下の図に示すように、新機能は S 機能では正しく動作しない可能性があるため、P、Q、R、S 機能間の統合テストとシステム テストを実行します。

• 製品の最初のリリースで、次のような要素が開発されたとします。 P、Q、R、S、T、U、V、W…..X、Y、Z 。ここでクライアントは、第 2 リリースで製品を改善する新機能の要件を提供します。新機能は次のとおりです。 A1、B2、C3、D4、E5。

その後、テスト計画中のスコープを次のように記述します。

範囲

テストする機能

A1、B2、C3、D4、E5 (新機能)

P、Q、R、S、T

テスト対象外の機能

W…..X、Y、Z

したがって、最初に新機能をチェックし、次に古い機能を続行します。これは、新機能の追加後に影響を受ける可能性があるためです。つまり、影響を受ける領域にも影響するため、P、Q に対して 1 ラウンドの回帰テストを実行します。 、R…、Tの特徴。

テスト方法:

これには、アプリケーションでの機能テスト、統合テスト、システム テストなどのさまざまな種類のテストの実行に関する情報が含まれています。この中で、どのような種類のテストを行うかを決定します。アプリケーションの要件に基づいてさまざまな機能を実行します。また、ここでは、テスト用語が標準ではないため、経営陣、開発チーム、テストチームなど誰もが理解しやすいように、テスト方法論でどのようなテストを行うのかも定義する必要があります。

例えば、 スタンドアロン アプリケーションの場合 アドビフォトショップ では、次の種類のテストを実行します。

スモークテスト→機能テスト→統合テスト→システムテスト→アドホックテスト→互換性テスト→回帰テスト→グローバリゼーションテスト→アクセシビリティテスト→ユーザビリティテスト→信頼性テスト→リカバリテスト→インストールまたはアンインストールテスト

文字を文字列に変換する方法

そして、テストする必要があるとします。 https://www.ジーバンサティ.com/ アプリケーションをテストするため、次の種類のテストを実行します。

アプローチ

この属性は、テストの実行中および将来の参照のためにアプリケーションのフローを説明するために使用されます。

以下の観点からアプリケーションのフローを理解できます。

大まかなシナリオを書くことで フローグラフを書くことで

大まかなシナリオを書くことで

例えば をテストしているとします。 Gメール 応用：

• Gmail にログイン - 電子メールを送信し、それが [送信済みアイテム] ページにあるかどうかを確認します。
• ……にログインしてください。
• ……
• ……

これは、製品のテストに必要なアプローチを説明するために、また、高レベルのシナリオを作成する重要な機能についてのみ説明するために作成しています。どの機能をテストする必要があるかどうかは特定のテスト エンジニアが決定できるため、ここではすべてのシナリオをカバーすることに重点を置きません。

フローグラフを書くことで

以下の図に示すように、高レベルのシナリオの作成には少し時間がかかるプロセスであるため、フロー グラフが作成されます。

以下のようなメリットをもたらすフローグラフを作成しています。

• カバレッジは簡単です
• 結合は簡単です

このアプローチは、次の 2 つの部分に分類できます。

• 上から下へのアプローチ
• 下から上へのアプローチ

予測

これには、テストプロセス中に発生した可能性のある問題や問題に関する情報が含まれており、テスト計画を作成するときに、リソースやテクノロジーなどの保証された仮定が作成されます。

危険

これらは、現在のリリースでアプリケーションをテストするために直面​​する必要がある課題であり、前提が崩れる場合はリスクが伴います。

例えば、 アプリの影響により発売日が延期となります。

緩和計画または緊急時対応計画

リスクや課題を克服するために用意されたバックアッププランです。

仮定、リスク、緊急時対応計画は相互に関連しているため、一例を一緒に見てみましょう。

どのような製品においても、 予測 私たちは、3 人のテスト エンジニア全員が製品の完成までそこにいて、それぞれに P、Q、R などの異なるモジュールが割り当てられるようにします。この特定のシナリオでは、 危険 テストエンジニアがプロジェクトを途中でやめた場合はそうなる可能性があります。

したがって、 緊急時対応計画 各機能には主所有者と下位所有者が割り当てられます。そのため、1 人のテスト エンジニアが退職した場合、その下位の所有者がその特定の機能を引き継ぎ、新しいテスト エンジニアが割り当てられたモジュールを理解できるように支援します。

製品自体に関しては、前提条件、リスク、緩和策または緊急時対応計画が常に正確です。さまざまな種類のリスクは次のとおりです。

• 顧客の視点
• リソースアプローチ
• 技術的意見

役割と責任

これは、テスト チーム全体が実行する必要がある完全なタスクを定義します。大規模なプロジェクトが来ると、 テストマネージャー テスト計画を書く人です。 3 ～ 4 つの小規模プロジェクトがある場合、テスト マネージャーは各プロジェクトを各テスト リーダーに割り当てます。そして、テスト リーダーは、割り当てられたプロジェクトのテスト計画を作成します。

テスト マネージャー、テスト リーダー、テスト エンジニアの役割と責任を理解するための 1 つの例を見てみましょう。

役割: テストマネージャー

名前：ライアン

責任：

• テスト計画を準備（書いてレビュー）する
• 開発チームとのミーティングを実施する
• テストチームとのミーティングを実施する
• お客様との打ち合わせを行います
• 毎月1回スタンドアップミーティングを実施する
• リリースノートを承認する
• エスカレーションと問題の処理

役割: テストリーダー

名前: ハーベイ

責任：

• テスト計画を準備（書いてレビュー）する
• 毎日スタンドアップミーティングを実施する
• テストケースを確認して承認する
• RTM とレポートの準備
• モジュールの割り当て
• 取り扱いスケジュール

役割: テスト エンジニア 1、テスト エンジニア 2、およびテスト エンジニア 3

名前：ルイス、ジェシカ、ドナ

モジュールの割り当て: M1、M2、および M3

責任：

• テスト ケースとテスト シナリオで構成されるテスト ドキュメントの作成、レビュー、実行
• 要件を読み、確認し、理解し、分析する
• アプリケーションの流れを書く
• テストケースを実行する
• 各モジュールのRTM
• 欠陥追跡
• テスト実行レポートを準備し、テスト リーダーに伝えます。

スケジュール

これは、作業のタイミングを説明するために使用されます。どの作業を行う必要があるのか​​、それともこの属性は、各テスト アクティビティを正確に開始および終了する時期をカバーしますか?また、特定の日付のすべてのテスト活動についての正確なデータも記載されています。

したがって、以下の図でわかるように、特定のアクティビティには開始日と終了日が存在します。特定のビルドに対するテストごとに、指定された日付があります。

例えば

Javaのランダム値ジェネレーター

• テストケースを書く
• 実行プロセス

欠陥追跡

各バグのステータスを手動で追跡することはできないため、通常はツールを使用して行われます。また、テストプロセス中に特定されたバグをどのように伝えて開発チームに送り返すか、また開発チームがどのように返答するかについてもコメントします。ここでは、高、中、低などのバグの優先度についても言及します。

以下に、欠陥追跡のさまざまな側面を示します。

バグを追跡するテクニック
……
……
……
……バグ追跡ツール
バグの追跡に使用するツールの名前についてコメントできます。最も一般的に使用されるバグ追跡ツールには、Jira、Bugzilla、Mantis、Trac などがあります。<重大度
重大度は次のようになります。
ブロッカーまたはショーストッパー
……
….. (テスト計画の例で説明します)
例えば 、モジュールに欠陥がある可能性があります。バグがブロックされていれば、他のモジュールのチェックに進むことができるため、これ以上他のモジュールをテストすることはできません。
致命的
……
….. (テスト計画の例で説明します)
このような状況では、欠陥はビジネスに影響を及ぼします。
選考科目
…。
…。 (テスト計画の例で説明します)
マイナー
……
….. (テスト計画の例で説明します)
これらの欠陥は、アプリケーションの外観と操作性に影響を与えるものです。優先度
高P1
……
中-P2
……
低P3
……
……
P4

したがって、バグの優先度を高、中、低に基づいて、P1、P2、P3、P4 に分類します。

テスト環境

これらはアプリケーションをテストする環境です。ここでは 2 種類の環境があります。 ソフトウェア そして ハードウェア 構成。

の ソフトウェア構成 さまざまな詳細を意味します オペレーティングシステム のような Windows、Linux、UNIX、Mac そして色々な ブラウザ のように Google Chrome、Firefox、Opera、Internet Explorer 、 等々。

そしてその ハードウェア構成 のさまざまなサイズに関する情報を意味します RAM、ROM、およびプロセッサ 。

例えば

• の ソフトウェア 以下が含まれます。

サーバ

注: 上記のサーバーは、テスト チームがアプリケーションをテストするために使用するサーバーです。

クライアント

注: 上記の詳細は、テスト チームがアプリケーションをテストするさまざまなオペレーティング システムとブラウザを示しています。

• の ハードウェア 以下が含まれます。

サーバ ：サンスターキャット1500

この特定のサーバーは、テスト チームがアプリケーションをテストするために使用できます。

クライアント：

次のような構成になっています。

注: テスト チームであるテスト エンジニアのシステムの構成が提供されます。

ソフトウェアをインストールするプロセス
……
……
……

開発チームは、ソフトウェアのインストール方法の構成を提供します。開発チームがプロセスをまだ提供していない場合は、テスト計画にタスクベース開発 (TBD) として記述します。

参入基準と退出基準

これは必須条件であり、テスト プロセスを開始および停止する前に満たす必要があります。

参加基準

エントリー基準には次の条件が含まれます。

• ホワイトボックステストは終了する必要があります。
• 要件を理解して分析し、テスト文書を準備するか、テスト文書の準備ができたら。
• テストデータが準備できているはずです。
• ビルドまたはアプリケーションを準備する必要があります
• モジュールまたは機能は、さまざまなテスト エンジニアに割り当てる必要があります。
• 必要なリソースが準備できている必要があります。

終了基準

終了基準には次の条件が含まれます。

• すべてのテスト ケースが実行されたとき。
• ほとんどのテスト ケースは次のようにする必要があります。 合格した 。
• バグの重大度によって異なります。つまり、障害となるバグや重大なバグがあってはなりませんが、いくつかの軽微なバグは存在します。

機能テストの実行を開始する前に、上記のすべてを行ってください。 参加基準 従うべきである。機能テストを実行した後、統合テストを実行する前に、 の終了基準 機能テストは従う必要があります。終了基準の割合は開発マネージャとテストマネージャの両方との会議によって決定され、両者の協力によりその割合を達成できるためです。しかし、機能テストの終了基準が守られていない場合、統合テストに進むことはできません。

ここ 重症度に基づいて バグの原因は、テスト チームが次のフェーズに進むことを決定したことを意味します。

C言語の文字列配列

テストの自動化

この中で、以下のことを決定します。

• 自動化する必要がある機能と自動化しない機能はどれですか?
• どの自動化フレームワークでどのテスト自動化ツールを使用するのでしょうか?

最初のリリース後にのみテスト ケースを自動化します。

ここで、何を根拠にしているのかという疑問が生じます。 私たちは 意思 どの機能をテストする必要があるかを決定しますか?

上の画像では、最も一般的に使用される機能を何度もテストする必要があることがわかります。 Gmail アプリケーションに重要な機能が含まれているかを確認する必要があるとします。 メールの作成、送信済みアイテム、受信トレイ 。手動テストを実行すると時間がかかり、単調な作業になるため、これらの機能をテストします。

今、 どの機能をテストしないのかをどのように決定するのでしょうか?

仮定する 手伝い Gmail アプリケーションの機能は定期的に使用されるものではないため、何度もテストされることはなく、頻繁にチェックする必要はありません。

しかし 一部の機能が不安定でバグが多い場合 これは、手動テストを行う際に何度もテストする必要があるため、これらの機能はテストしないことを意味します。

もし 頻繁にテストする必要がある機能があります , ただし、その機能の要件の変更が予想されるため、自動テスト スクリプトの変更と比較して手動テスト ケースの変更の方が快適であるため、チェックしません。

労力の見積もり

この中で、チームメンバー全員が適用する必要がある取り組みを計画します。

テスト成果物

これらはテスト チームからの出力であるドキュメントであり、製品とともにお客様にお渡しします。これには次のものが含まれます。

テスト計画 テストケース テストスクリプト RTM(要件トレーサビリティ・マトリックス) 欠陥報告 テスト実行レポート グラフと指標 リリースノート

グラフとメトリクス

グラフ

今回はその種類について解説していきます グラフ 各グラフのサンプルも提供します。

ご覧のとおり、テスト プロセスのさまざまな側面を示す 5 つの異なるグラフがあります。

グラフ1: ここでは、すべてのモジュールでいくつの欠陥が特定され、いくつの欠陥が修正されたかを示します。

グラフ2: 図 1 は、モジュールごとに重大な欠陥、重大な欠陥、軽微な欠陥がいくつ特定され、それぞれのモジュールで修正された欠陥がいくつあるかを示しています。

グラフ3: この特定のグラフでは、 賢明なグラフを構築する これは、すべてのビルドで、モジュールごとにいくつの欠陥が特定され、修正されたかを意味します。モジュールに基づいてバグを特定しました。追加させていただきます R P と Q の欠陥数を表示するために、さらに追加します。 S P、Q、R の欠陥を表示します。

グラフ4: テストリードは、 バグ傾向分析 毎月グラフを作成し、経営陣にも送信します。そしてそれは製品の最後に行われる予測のようなものです。ここで、次のこともできます。 バグ修正を評価する それが観察できるように アーク 持っています 上昇傾向 下の画像で。

グラフ5: の テストマネージャー がこのタイプのグラフを設計しました。このグラフは、バグの評価と実際に発生したバグのギャップを把握することを目的としており、今後のバグ評価の改善にも役立ちます。

メトリクス

上記と同様に、図 1 にあるバグ分布グラフを作成し、上記のデータを利用してメトリクスも設計します。

例えば

上の図では、特定のプロジェクトのすべてのテスト エンジニアの記録と、特定され修正された欠陥の数が保持されています。このデータは将来の分析にも使用できます。新しい要件が発生した場合、上記の指標に従って以前に発見された欠陥の数に基づいて、テストのために困難な機能を誰に提供するかを決定できます。そして、誰が問題のある機能をうまく処理し、最大数の欠陥を発見できるかを知るためのより良い状況になるでしょう。

リリースノート: これは、製品のリリース時に作成され、テスト マネージャーによって署名された文書です。

以下の画像では、最終製品が開発され、顧客に展開されていることがわかります。最新のリリース名は次のとおりです。 ベータ 。

の リリースノート 以下で構成されます。

• ユーザーマニュアル。
• 保留中の欠陥と未解決の欠陥のリスト。
• 追加、変更、削除された機能のリスト。
• 製品がテストされるプラットフォーム (オペレーティング システム、ハードウェア、ブラウザ) のリスト。
• 製品がテストされていないプラットフォーム。
• 現在のリリースで修正されたバグのリストと、以前のリリースで修正されたバグのリスト。
• インストールプロセス
• ソフトウェアのバージョン

例えば

仮定 ベータ 最初のリリース後のアプリケーションの 2 番目のリリースです アルファ 解放されます。最初のリリースで特定された欠陥の一部は、後のリリースで修正されています。ここでは、アルファ リリースからベータ リリースまでに新たに追加、変更、削除された機能のリストも示します。

テンプレート

この部分には、製品で使用されるドキュメントのすべてのテンプレートが含まれており、製品の一貫性を維持するために、すべてのテスト エンジニアはプロジェクト内でこれらのテンプレートのみを使用します。ここでは、テスト プロセス全体で使用される、次のようなさまざまなタイプのテンプレートがあります。

• テストケースのテンプレート
• テストケースレビューテンプレート
• RTM テンプレート
• バグレポートのテンプレート
• テスト実行レポート

テスト計画書のサンプルを 1 つ見てみましょう

ページ1

3ページ目～18ページ目

ページ-20

ページ 1 では、主に バージョン、作成者、コメント、レビュー者 欄に記載し、マネージャーが承認した後、詳細を記載します。 承認者と承認日 田畑。

ほとんどのテスト計画はテスト マネージャーによって承認され、テスト エンジニアはそれをレビューするだけです。そして、新しい機能が登場したら、テスト計画を変更し、必要な変更を加えます。 バージョン その後、管理者のさらなるレビュー、更新、承認のために再度送信されます。テスト計画は、変更があった場合には常に更新する必要があります。 20 ページには、 参考文献 テスト計画文書を作成するために使用するすべての文書の詳細を指定します。

注記：

誰がテスト計画を書きますか?

• テストリード→60%
• テストマネージャー→20%
• テストエンジニア→20%

したがって、上記からわかるように、製品の 60% では、テスト計画はテスト リーダーによって作成されます。

誰がテスト計画をレビューしますか?

• テストリード
• テストマネージャー
• テストエンジニア
• お客様
• 開発チーム

テスト エンジニアはモジュールの観点からテスト計画をレビューし、テスト マネージャーは顧客の意見に基づいてテスト計画をレビューします。

誰がテスト計画を承認しますか?

• お客様
• テストマネージャー

誰がテストケースを書きますか?

• テストリード
• テストエンジニア

誰がテストケースをレビューしますか?

メソッドJavaに等しい

• テストエンジニア
• テストリード
• お客様
• 開発チーム

テストケースを承認するのは誰ですか?

• テストマネージャー
• テストリード
• お客様

テスト計画のガイドライン

• テスト計画を折りたたみます。
• 重複や冗長性を避けてください。
• すでに前述したセクションが必要ないと思われる場合は、そのセクションを削除して先に進んでください。
• 具体的にしてください。たとえば、ソフトウェア システムをテスト環境の一部として指定する場合は、名前だけではなくソフトウェア バージョンを指定します。
• 長い段落は避けてください。
• 可能な限りリストと表を使用します。
• 必要に応じて計画を更新します。
• 期限切れまたは未使用の文書は使用しないでください。

テスト計画の重要性

• テスト計画は私たちの考え方に方向性を与えます。これは従わなければならないルールブックのようなものです。
• テスト計画は、テスト対象のソフトウェア アプリケーションの品質を検証するために必要な取り組みを決定するのに役立ちます。
• テスト計画は、開発者、ビジネス マネージャー、顧客などの外部に関連する人々がテストの詳細を理解するのに役立ちます。
• テスト スケジュール、テスト戦略、テスト範囲などの重要な側面はテスト計画に文書化され、管理チームがそれらを確認して他の同様のプロジェクトに再利用できるようにします。