Estimation-techniques-testing

推定手法-テスト

テストの取り組みは、決定的な時間枠に基づいていません。 テストの完了に関係なく、事前に決められたタイムラインが設定されるまで努力が続けられます。

これは主に、従来、*テスト努力の見積もり*が*開発の見積もり*の一部であるという事実によるものです。 Wideband Delphi、3点推定、PERT、WBSなど、WBSを使用する推定手法の場合にのみ、テストアクティビティの推定値を取得できます。

推定値を関数ポイント（FP）として取得した場合、Caper Jonesに従って、

• テストケースの数=（ファンクションポイントの数）×1.2 *

テストケースの数を取得したら、組織のデータベースから生産性データを取得し、テストに必要な作業に到達できます。

開発努力方法の割合

必要なテスト作業は、開発作業の直接的な割合または割合です。 開発作業は、コード行（LOC）またはファンクションポイント（FP）を使用して推定できます。 次に、テストの労力の割合が組織データベースから取得されます。 そのようにして得られたパーセンテージは、テストの労力の見積もりに到達するために使用されます。

テストプロジェクトの見積もり

現在、いくつかの組織が独立した検証および検証サービスをクライアントに提供しています。これは、プロジェクト活動が完全にテスト活動であることを意味します。

テストプロジェクトの見積もりには、ソフトウェアテストライフサイクルのさまざまなプロジェクトの経験が必要です。 あなたがテストプロジェクトを推定しているとき、考慮してください-

• チームスキル
• 領域知識
• アプリケーションの複雑さ
• 歴史的なデータ
• プロジェクトのバグサイクル
• リソースの可用性
• 生産性のばらつき
• システム環境とダウンタイム

推定手法のテスト

次のテスト推定手法は正確であることが証明されており、広く使用されています-

• PERTソフトウェアテストの推定手法
• UCPメソッド
• WBS
• 広帯域デルファイ技術
• ファンクションポイント/テストポイント分析
• 割合分布
• 経験に基づいたテスト推定手法

PERTソフトウェアテストの推定手法

PERTソフトウェアテストの推定手法は、各テストタスクをサブタスクに分割し、各サブタスクで3種類の推定を行う統計的手法に基づいています。

この手法で使用される式は-

• テストの見積もり=（O＆plus;（4×M）＆plus; E）/6 *

どこで、

*O* =楽観的推定（何も問題がなく、すべての条件が最適であるベストケースシナリオ）。

*M* =最も可能性の高い推定値（最も可能性の高い期間であり、何らかの問題がある可能性がありますが、ほとんどの問題は解決します）。

*L* =悲観的推定値（すべてがうまくいかない最悪のシナリオ）。

テクニックの標準偏差は次のように計算されます-

• 標準偏差（SD）=（E − O）/6 *

ユースケースポイント法

UCPメソッドは、未調整のアクターの重みと未調整のユースケースの重みを計算してソフトウェアテストの見積もりを決定するユースケースに基づいています。

ユースケースは、関連するアプリケーションと対話するさまざまなユーザー、システム、またはその他の利害関係者を指定するドキュメントです。 彼らは「俳優」と名付けられています。 相互作用は、シナリオと呼ばれるさまざまな動作またはフローを通じて、すべての利害関係者の関心を保護するいくつかの定義された目標を達成します。

• ステップ1 *-番号を数える 俳優の。 アクターには、ポジティブ、ネガティブ、および例外が含まれます。

• ステップ2 *-未調整のアクターの重みを次のように計算します

未調整の俳優の重み=合計番号 俳優

• ステップ3 *-ユースケースの数を数えます。

• ステップ4 *-未調整のユースケースの重みを次のように計算します

未調整のユースケースの重量=合計 ユースケースの

• ステップ5 *-未調整のユースケースポイントを次のように計算します

未調整のユースケースポイント=（未調整のアクターウェイト＆plus;未調整のユースケースウェイト）

• ステップ6 *-技術的/環境的要因（TEF）を決定します。 利用できない場合は、0.50としてください。

• ステップ7 *-調整されたユースケースポイントを次のように計算します

• 調整済みのユースケースポイント=未調整のユースケースポイント×[0.65＆plus; （0.01×TEF] *

• ステップ8 *-合計努力量を

• 総努力=調整されたユースケースポイント×2 *

作業分解図

• ステップ1 *-テストプロジェクトを小さな断片に分解してWBSを作成します。

• ステップ2 *-モジュールをサブモジュールに分割します。

• ステップ3 *サブモジュールをさらに機能に分割します。

• ステップ4 *-機能をサブ機能に分割します。

• ステップ5 *-すべてのテスト要件を確認して、WBSに追加されていることを確認します。

• ステップ6 *-チームが完了する必要があるタスクの数を計算します。

• ステップ7 *-各タスクの労力を見積もります。

• ステップ8 *-各タスクの期間を見積もります。

広帯域デルファイ技術

Wideband Delphi Methodでは、WBSはタスクを再評価するために3〜7人のメンバーで構成されるチームに配布されます。 最終的な見積もりは、チームのコンセンサスに基づいて要約された見積もりの​​結果です。

この方法は、統計式よりも経験に基づいています。 この手法は、チームがテストの労力を見積もる際に問題のさまざまな側面を視覚化するコンセンサスに到達するために、グループの反復を強調するためにバリーベームによって普及しました。

ファンクションポイント/テストポイント分析

FPは、ユーザーの観点からソフトウェアアプリケーションの機能を示し、ソフトウェアプロジェクトのサイズを見積もる手法として使用されます。

テストでは、推定は要件仕様文書、または以前に作成されたアプリケーションのプロトタイプに基づきます。 プロジェクトのFPを計算するには、いくつかの主要なコンポーネントが必要です。 彼らは-

• 未調整のデータ関数ポイント-i）内部ファイル、ii）外部インターフェイス
• 未調整のトランザクション機能ポイント-i）ユーザー入力、ii）ユーザー出力、iii）ユーザー照会
• ケーパーズジョーンズの基本式- +テストケースの数=（関数ポイントの数）×1.2
• 総実績工数（TAE）- +（テストケースの数）×（開発努力の割合/100）

割合分布

この手法では、ソフトウェア開発ライフサイクル（SDLC）のすべての段階に％単位の作業量が割り当てられます。 これは、同様のプロジェクトからの過去のデータに基づくことができます。 たとえば-

Phase	% of Effort
Project Management	7%
Requirements	9%
Design	16%
Coding	26%
Testing (all Test Phases)	27%
Documentation	9%
Installation and Training	6%

次に、テスト（すべてのテストフェーズ）の努力の割合がすべてのテストフェーズにさらに分散されます-

All Testing Phases	% of Effort
Component Testing	16
Independent Testing	84
Total	100

Independent Testing	% of Effort
Integration Testing	24
System Testing	52
Acceptance Testing	24
Total	100

System Testing	% of Effort
Functional System Testing	65
Non-functional System Testing	35
Total	100

Test Planning and Design Architecture	50%
Review phase	50%

経験に基づいたテスト推定手法

この手法は、類推と専門家に基づいています。 この手法では、以前のプロジェクトで同様のアプリケーションを既にテストし、それらのプロジェクトからメトリックを収集したと想定しています。 また、以前のテストからメトリックを収集しました。 アプリケーション（およびテスト）を熟知している主題の専門家から情報を収集し、収集したメトリックを使用して、テスト作業に到達します。