ユースケース:リスク分析・テスト範囲分析
ソフトウェアのリスク分析とは、ソフトウェアに存在するリスクを特定・分析し、対応の優先順位を決めることです。
ソフトウェアの機能追加や品質を上げるためにはソースコードの変更は不可欠です。その一方で、ソースコードの変更には以下のようなリスクがともないます。
ソフトウェアの機能追加や品質を上げるためにはソースコードの変更は不可欠です。その一方で、ソースコードの変更には以下のようなリスクがともないます。
- 過去のバージョンで既に修正済の不具合の再発
- 変更・修正した箇所以外での新たな不整合・不具合の発生
- 度重なる変更によりアーキテクチャが崩れる
またテスト範囲分析とは、テスト対象のソフトウェアの機能のふるまいを調査・理解し、テストの必要性や範囲を特定する分析手法です。
ここでのテスト範囲は、バグの検出率が高く項目数が少ないテストを選択することが望ましいです。
ここでは、変更時にバグが混入しやすいリスクに着目し、メトリクス・依存関係の複雑さなどソースコードの構造から”リスク”を見抜く方法とテスト範囲への適用についてご紹介します。
課題
- ソースコードが複雑化しており、すべてのテストを実施することができない
- 変更点はテストしているが、影響範囲を考慮できていない
- テストでバグは検出できるが、バグのない完璧なコードは作ることはできない
原因
テスト範囲が曖昧で、影響範囲の考慮漏れがある
例:テスト範囲が開発者の経験や勘で決められており、属人化している。
工数的に全テストの実施が難しい
例:影響範囲が発散しており、テストが必要な範囲が膨大。重点的にテストが必要な範囲を見積もれない。
- 構造的複雑度
- 循環的複雑度
姉妹ツールのUnderstandでは、ソフトウェアの品質を定量的に評価するソースコードメトリクスの測定が可能です。その中で、「Cyclomatic複雑度」の指標では、分岐の数から関数/メソッドの複雑度を分析することが可能です。
2.リスクが高いファイルを検出するために、 複雑度の分類を行う
アーキテクチャメトリクスの1つである「VFI/VFO」の数値をもとに、4つの領域に構造複雑度の分類分けを行います。
例)VFI/VFOの各数値で、最大値の半分を閾値として分類する

この分類方法は、"Sturtevantの論文"でもバグとの相関があると発表されております。
構造複雑度が高いファイル(図のCore)は、低いファイル(図のPeripheral)と比較し、バグ密度(リスクの高さ)が3.1倍になるといわれています。
加えて、循環的複雑度の1指標でもある「Cyclomatic複雑度」と組み合わせて追加分類をすることで、バグ密度が最大8.3倍にもなるとの検証結果があります。

関連情報のご紹介
![]() >>Lattix ユースケース:影響分析ページ |
リスク分析・テスト範囲分析のユースケースについて、追加の情報をまとめております。
是非お役立てください。
関連情報:
Lattix/Understandのメトリクスをデータ分析してみた①([Lattix] Sturtevantの構造複雑度) - Understand blog (techmatrix.jp)
Lattix/Understandのメトリクスをデータ分析してみた②([Lattix] Sturtevantの構造複雑度) - Understand blog (techmatrix.jp)
Lattix/Understandのメトリクスをデータ分析してみた①([Lattix] Sturtevantの構造複雑度) - Understand blog (techmatrix.jp)
Lattix/Understandのメトリクスをデータ分析してみた②([Lattix] Sturtevantの構造複雑度) - Understand blog (techmatrix.jp)
関連資料のご案内
過去に開催したソフトウェア品質向上セミナーの講演資料をご案内します。資料は、セミナーにご登壇いただいた企業様の品質向上に関する取り組みをご紹介しています。資料をご希望の方は、申込フォームよりお申し込みください。
某医療機器メーカー様
メトリクスを活用したテスト範囲の選定
リスクが高い箇所を抽出し、テスト範囲の選定に役立てていただいております。
※こちらの資料の用意はありません。
イベント・セミナー
アーキテクチャ分析ツール Lattixに
関するお問い合わせ
テクマトリックス株式会社
東京本社ソフトウェアエンジニアリング事業部
03-4405-7853
- メールでのお問い合わせ
- lattix-info@techmatrix.co.jp