テストポイント分析
5721 ワード
Test Case Point Analysis-テストポイント分析
メソッドの概要
テストポイントは、ソフトウェアテストプロセスのサイズを測定することによって、テストアクティビティの複雑さを反映し、ソフトウェアが品質目標を達成することを保証する.複雑度測定としては、テスト計画、テスト設計、テスト実行、テストレポート、欠陥追跡など、テストアクティビティの実行を反映するために最大限の努力が必要です.
テストポイント分析は、テスト用例セットを入力としてテストポイントを生成します.1つのテスト・インスタンスの複雑さには、チェックポイント(checkpoint)、プリアンブル条件(precondition)、テスト・データ(test data)、インスタンス・タイプ(types of test case)の4つの次元が含まれます.この説は有効な仮説である.これらの次元は、次の2つのタイプに分類されます.
メソッドの詳細
測定試験用例の複雑度
各試験例は、一定数の試験点として設計される.これらの試験点は、一定数のcheckpoint、前置条件の複雑さ、および使用例で用いられる試験データから構成される.
checkpointは、テスト担当者がテストで目標関数の出力が予想結果と一致するかどうかを確認する条件です.1つの例には、1つ以上のチェックポイントが含まれます.
1 ： checkpoint
Precondition. 試験例の前置条件は、試験例が実行する条件を指定します.Preconditionはtest dataと同様に、主にテスト実行のコストに影響します.テスト例では、いくつかの事前条件がテストデータ構造に関連付けられます.
表1:前提条件(Precondition)複雑度レベル説明
Complexity
Description
None
テストの実行例では、前置条件は適用されないか、重要ではありません.または、前のテスト・インスタンスを使用して、現在のテスト・インスタンスの実行を続行できます.
Low
使用例を実行する場合、いくつかの簡単な必要変動があります.あるいは、簡単な設定手順があります.
Medium
使用例を実行するとき、いくつかの明確な準備活動があります.例えば、いくつかの追加の必要な変動.または、追加の設定手順があります.
High
使用例を実行するには、大量のソフト・ハードウェア構成が必要です.
Test Data. テストデータは、テスト例を実行するために使用されます.テスト実行中に生成したり、テスト前に以前のテストで準備したり、テストスクリプトで生成したりすることができます.試験例のセットまたはシステム全体について、試験データは、通性であってもよく、特性であってもよい.汎用性のあるテストデータは、複数のテスト例のセットで繰り返し使用することができる.
表2:テストデータ(Test Data)複雑度レベル説明
Complexity
Description
None
必要なテストデータがありません
Low
テスト実行中に生成できる簡単なデータが必要です.あるいは、既存のテストデータを少し修正するだけです.
Medium
テストデータは、事前に意図的に準備し、完全性、理解性、一貫性を保証する必要があります.
High
テストデータは、その完全性、理解性、一貫性を保証するために、前期にかなりの努力を払う必要があります.ツールを使用して、生成またはデータベースの保存と管理を行います.テストデータを生成するときにスクリプトを使用することもできます.
2： 。
(unadjusted Test Case Point)
表3:先行条件のテストポイント割当
Complexity level
Number of Test Case Point
Standard deviation($\pm\sigma$)
None
0
0
Low
1
0
Medium
3
0.5
High
5
1
表4:テストデータのテストポイント割当
Complexity level
Number of Test Case Point
Standard deviation($\pm\sigma$)
None
0
0
Low
1
0
Medium
3
0.6
High
6
1.3
表3および表4の定数は、18人のテストエンジニアを調査した調査から得られた.標準差の値は、変調結果のばらつきを反映します.これらの推定定数は,プロジェクトと環境の特徴をよりよく反映することができる.
テストタイプによるテストポイントの調整
表5:各テストタイプのウエイト
Type of Test
Weight(W)
Standard deviation($\pm\sigma$)
Comments
User interface and functional testing
1.0
0
ユーザ画像インタフェースと機能テストは分析された最も透徹した基礎点である.
API
1.22
0.32
提供されるサービスでのインタフェースの精度の検証
DataBase
1.36
0.26
データベースのスクリプトの正確性、データ整合性、およびデータ移行の検証
Security
1.39
0.28
ハッカー攻撃、不正アクセス、信頼性の低いエントリのパフォーマンスをテスト
Installation
1.09
0.06
ソフトウェアプロセスの完全なインストールアンインストール、一部のインストールアンインストール、およびインストールアンインストールの更新をテストします.
Networking
1.27
0.29
エンティティとネットワーク間の通信のテスト
Algorithm and computation
1.38
0.27
検証アルゴリズムと数値計算のシステムにおける設計と応用
Usability testing
1.12
0.13
ソフトウェアの友好性、使いやすさ、システムのその他の使いやすさのプロパティをテストします.
Performance(manual)
1.33
0.27
システムがパフォーマンス要件を満たしているかどうかを確認し、パフォーマンステストが手動で実行されていると仮定します.
Recovery testing
1.07
0.14
リカバリテストソフトウェアのクラッシュおよびその他のエラーからのリカバリプロセスの正確性を検証
Compatibility testing
1.01
0.03
ブラウザ、オペレーティングシステム、ハードウェアなど、ソフトウェアとシステムの他のソフトウェアが互換性があるかどうかをテストします.
最終調整テストポイント(Adjust Test Case Point)の合計は次のとおりです.
ATCP=SUM(UTCP*W)
UTCPがUnAdjust Test Case Point WがTest Caseの重み
投入見積り
テストアクティビティは、テスト計画、テスト設計、テスト実行、欠陥レポートの4つに分類できます.この4つのアクティビティでは、テスト実行と欠陥レポートは、プロジェクトのテスト例で複数回実行されます.しかしながら、測定された試験点規模は、この4つのアクティビティに分散しており、測定の前提は、各アクティビティが1回実行されることである.各テストアクティビティの投入分布により、テスト実行と欠陥レポートの実行投入を予測するために、何度も使用できます.各テストアクティビティの投入分布は、履歴データによって生成できます.
表6:テスト投入分布
Testing Phase
Description
Percent of Effort
Standard deviation($\pm\sigma$)
Test Planning
テスト範囲、テスト方法、および関連リスクを定義します.テスト計画は、必要なテストリソースと初歩的なテストアクティビティスケジュールを定義します.
10%
3%
Test Analysis and Design
試験範囲と試験目標の詳細を処理し、試験要求を評価または明らかにし、試験用例を設計し、試験活動に必要な環境を準備する.この時期にテストの様々な組み合わせがカバーされていることを保証する必要があります.
25%
5%
Test Execution
テストの実行とテスト計画の時期に提出された目標を繰り返し処理し、テスト結果、欠陥、リスクを報告します.この時期には、実際の結果と所望の結果を検査するなどのテスト結果分析も含まれています.
47%
4%
Defect Tracking&Reporting
繰り返し処理は、テストアクティビティと欠陥の進捗状況とステータスを追跡し、現在のステータスが輸出ガイドラインと目標に達しているかどうかを評価します.
18%
3%
情報とリソースの可用性に基づいて、テストの投入は以下の簡単な方法で見積もることができます.
生産指数予測テストによる投入
Effort = TCP*Productivity Index
The Productivity Indexは履歴データで決定できます
単純な線形回帰分析によるテスト投入の見積り
E = A+B*TCP
履歴データの代入により,係数AとBの値を線形フィッティングにより求めることができる.新しいバージョンのEffortを見積もるために代入します
まとめ
ソフトウェアテストは、成功したソフトウェアの開発とメンテナンスにおいて重要な役割を果たしています.テストの投入を正確に見積もることは、目標を達成するための重要なステップです.ソフトウェアテストの見積りの空白を埋めようとするために,本論文では,ソフトウェアテスト活動の規模と投入をどのように計算するかをテストポイント分析する方法を提案した.この解析の入力はテスト用例セットであり,各用例のテストポイントとして出力される.
例は、テスト担当者の生成物として、テスト実行アクティビティに適用する必要がある.試験点解析法の有力な特性は,一例の複雑さを測定できることである.これにより、テスト担当者の活動への投資をよりよく反映することができます.もう1つの利点はcheckpointの個数を計測し,前置条件と試験データの複雑さを測定することによって,各試験例のタイプを決定した後,容易に応用できることである.
しかし、この方法にも多くの制限がある.
後日この方法で改善する際にはこれらの制限に注意する必要があります!!!
原文はTest Case Point Analysisから