あなたの作ったテストベンチのバグ検出能力を高める方法 ―― ミューテーション法を利用した検証環境の品質改善

2．機能検証環境の品質改善という考え方

●「いつ検証作業を終了するべきか」を判断できない

 　検証の進捗を管理する適当なツールや手法は，まだ十分に整備されているとは言えません．既存の技術は，設計者が実施した検証が十分であるかどうかを判断する上で有用な情報を提供しますが，これだけでは不十分です．実際，「いつ検証作業を終了するべきか」を判断することは，依然として容易ではありません．検証プロセスを構成する「活性化」，「伝播」，「検出」を意識した包括的かつ客観的な判定方法がない場合，検証チームはどのようにして検証の終了時期を決めればよいのでしょう．

　この問題に対処するためには，「機能検証環境の品質改善（Functional Qualification）」という考え方が必要になります．機能検証環境の品質改善には，ミューテーション法に基づくテスト手法が利用されます．ミューテーション法を使用することで，検証環境の「比較（Compare）」の能力を改善したり，デバッグしたりすることができ，また，検証の進捗状況を測定できます．この手法は検証環境の「伝播（Propagation）」と「検出（Detection）」の能力を解析する機能を持っており，既存のカバレッジ技術よりも優れています（図4）．

(a) 機能検証環境の品質改善

(b) バグの挿入

図4　検証環境の検証

●意図的にバグを混入させて検証環境の品質を測定

　ミューテーション法に基づくテスト技術は，既存のツールの欠点を解消し，機能検証の「品質ギャップ」の問題を是正する一つの方法です．ミューテーション法を使用したテスト技術は，1970年代初期のソフトウェア研究のなかで初めて紹介されました．この技術は，ソフトウェアのテスト工程を効率化することを目的として開発されました．

　ミューテーション法とは，テストされるプログラムに意図的にエラーを起こすような改変（ミュータント混入）を施す方法です．この改変を行うことにより，プログラムの動作が変化します．その後，この動作の変化を検出できるように，テスト環境を修正します．テスト環境がこのすべての「ミュータント」を検出した場合（学術的には「ミュータントの摘出」と呼ぶ），そのテスト環境は「ミュータントに対応した」と見なされます．

　すでにミューテーション法を使用したテストをサポートする理論的な構成概念や仮説がいくつか公開されています⁽¹⁾．

　ディジタル回路の論理検証の分野では，検証環境の特定の個所の品質を確認するために，意図的に（人手で）欠陥を混入させる方法が，検証エンジニアの間で広く知られています．テストベンチの品質が疑わしく，また適切なフィードバックを得ることができない場合，エンジニアは時折この手法を使用します．このような「人手による」ミューテーション法を使用したテストを行う場合，検証環境の中でも検証エンジニアが特に不安を抱いた個所に限定して適用されます．手作業によるこのような手法の適用範囲を拡大することは，あまり現実的ではありません．

　このミューテーション法を使用した解析・操作を自動化すれば，複雑な設計に適用する機能検証環境の品質を客観的，かつ包括的に評価・測定できます．この自動化により，機能を活性化し，バグの影響を伝播させ，バグを検出する際の詳細な情報を利用できます．そして，従来のカバレッジ解析では予見できなかった検証環境の重大な弱点や欠点を特定できます．観測ポイントへ伝播しなかったり，検出されなかったことを解析することは，スティミュラス（シミュレーション・パターン）や可観測性，チェッカの不備を解析することに相当します．

　検証環境の操作性やその利用モデルも，機能検証技術を実際に使う上では重要です．調査の結果，重要な検証環境の弱点を検出する際には，欠陥の分類が有効であることが分かっています．まず優先度の高い欠陥に対して機能検証環境の品質改善を行うことで，検証環境全体の完成度を迅速に引き上げます．

　また，検証に際しては，さまざまな解析結果に柔軟にアクセスできることが求められます．例えば，HDLコードのどの部分に欠陥が挿入されているかを表し，エラーの状態を示し，エラーに関する詳細を簡単に理解できる直観的なレポートが必要です．さらに，このような機能検証のシステムは既存のシミュレータや最先端のデバッグ・システムと緊密に連携し，制約条件付きのランダム・スティミュラス（ランダム・パターン）生成やアサーション・ベース検証のような最近の検証手法に対応していることが求められます．