課題

• ソースコードが複雑化しており、すべてのテストを実施することができない
• 変更点はテストしているが、影響範囲を考慮できていない
• テストでバグは検出できるが、バグのない完璧なコードは作ることはできない

解決策

Lattixのアーキテクチャメトリクスから「構造複雑度」を算出し、不具合混入リスク(バグ密度＝バグが発生しうる可能性)が高い箇所を特定します。

1. 構造的複雑度と循環的複雑度を計測する
2. リスクが高いファイルを検出するために、複雑度の分類を行う
3. バグ密度の高いファイルを可視化、テスト範囲を選定する

この構造複雑度は、アーキテクチャ(設計依存間の依存性＝結合状態)を計測し、システムの特徴を研究するグループの、Sturtevantという人物が、研究で使用したアーキテクチャ構造に対するメトリクスのことを指しています。
また、姉妹ツールのUnderstandでは「循環的複雑度」を算出し、コードの複雑度から不具合混入リスクを分析します。

アーキテクチャメトリクスの１つである「VFI/VFO」の数値をもとに、4つの領域に構造複雑度の分類分けを行います。
例）VFI/VFOの各数値で、最大値の半分を閾値として分類する

この分類方法は、Sturtevantの複雑度分類とも呼ばれます。
Sturtevantという人物が研究で使用し、アーキテクチャ構造に対するメトリクスの論文でバグとの相関があると発表しています。

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

検出されたリスクの高いファイルはレポートで確認が可能です。また、結果をHTMLでグラフとして表現するスクリプトも公開しております。

検出されたバグ混入リスクの高いファイル周辺を重点的にテストすることが望ましいです。具体的には、検出されたファイルに対して、影響範囲を見積もり、影響箇所を抜け漏れなくテスト範囲に含めることも重要です。 ＞＞影響分析ソリューションページ