2016-09-29 4 views
1

私は手動テストの役割で私の会社を新しく変更しました。私のマネージャーは、要件やテストケースのトレーサビリティマトリックスを作成するよう頼まれました(わかりません)。しかし、この言葉「トレース能力マトリックス」について私が初めて聞いているのはこれです。しかし、提供された情報に基づくいくつかのブログでは、ビジネスシナリオ、テストシナリオ、テストケースを書くのと似ていると私は理解しました。私の理解は正しいのですか?手動テストでトレース機能マトリックスとは何ですか?どのように計算や見積もり?

答えて

0

トレーサビリティマトリクスとは何ですか?

要件を追跡し、現在のプロジェクト要件が満たされているかどうかを確認するために使用されます。つまり、トレーサビリティ・マトリックスは、多対多リレーションシップを必要とする2つのベースライン・ドキュメントをすべて関連付けて、リレーションシップの完全性をチェックするドキュメントです。

要件トレース・能力マトリックス

要件トレース・能力マトリックスまたはRTMは、クライアントや開発チームとライフサイクルの終了時に配信される単一ドキュメント内のトレース能力によって提案されたすべての要件をキャプチャ。

簡単に言えば、テストケースを使用してユーザーの要件をマッピングしてトレースするドキュメントです。要件トレーサビリティマトリクスの主な目的は、テスト中に機能が欠落しないようにすべてのテストケースがカバーされていることを確認することです。

RTMパラメーターが含まれています:

Requirement ID 
Risks 
Requirement Type and Description 
Trace to design specification 
Unit test cases 
Integration test cases 
System test cases 
User acceptance test cases 
Trace to test script 

私の知識フォワード

Forward traceability 
Backward or reverse traceability 
Bi-directional traceability (Forward+Backward) 

トレーサビリティあたりとしてトレーサビリティマトリックスの3つのタイプがあります:は、この行列は、プロジェクトが進むかどうかを確認するために使用されます所望の方向に、そして正しい製品のために。各要件が製品に適用され、各要件が完全にテストされていることを確認します。要件をテストケースにマッピングします。

逆追跡または逆追跡:これは、現在の製品が適切なトラックに残っているかどうかを確認するために使用されます。このタイプのトレーサビリティの目的は、要件に指定されていないコード、設計要素、テストまたはその他の作業を追加して、プロジェクトの範囲を拡大していないことを検証することです。テストケースを要件にマッピングします。

双方向トレーサビリティ(前方+後方):このトレーサビリティ測定基準は、すべての要件がテストケースによって保証されることを保証します。これは、作業成果物の欠陥によって影響を受ける要件の変化の影響を分析し、その逆も同様です。

要件トレーサビリティマトリクスの利点

It confirms 100% test coverage 
It highlights any requirements missing or document inconsistencies 
It shows the overall defects or execution status with a focus on business requirements 
It helps in analyzing or estimating the impact on the QA team's work with respect to revisiting or re-working on the test cases 
0

traceability matrixは、テスト手順によく使用されるツールです。マトリックス結果のおかげで、テスト手順に関連する非常に重要なカバレッジのメトリックを得ることができます。 2つの指標をテーブル入力(たとえばxの値とyの値)に修正し、2つの入力の関係が満たされているセルに十字を挿入する必要があります。特に、いくつかの一般的なトレーサビリティマトリクスである:

  1. test cases <--> requirements:マトリックスのこの種は、所与の結果を得るために実現テストケースのカバレッジを推定するためにテスターを助けます。この表の空のセルは、指定されたすべての要件をカバーするためにさらに多くのテストケースを作成する必要があることを意味します。
  2. requirements <--> source code:生成されたコードの一部が要件に該当しないかどうかを確認します。空のセルは、不十分な要件数または余分なコードによって引き起こされる可能性があります。
  3. test cases <--> source code:このマトリックスは、テストされたコードのパーセンテージを理解するのに便利です。複数の理由で空のセルが発生する可能性があります。
関連する問題