.NET Tools プログラムを仕上げるときの強力な助っ人DevPartner （株）ピーデー　川俣 晶 2003/12/06
Page1 Page2 Page3 Page4

テスト漏れを防止する「カバレッジ分析」

　プログラムをテストすることは、とても重要なことである。まったくテストせずにプログラムをリリースすることは自滅願望があると思われても仕方がないだろう。しかし、それが行われない状況というのも確かにある。実際に、お金を取って販売されている立派なパッケージ・ソフトであるのに、一度でも使ってみれば動作しないことが分かるバグが含まれているのに遭遇したことがある。このように、あからさまな問題を回避するのは難しくないとしても、テストの死角となって、めったに使われない特定の機能だけがテスト漏れ、という事態はなかなか回避できないだろう。

　さて、そのようなテスト漏れに対処する方法はないだろうか。1つの方法として、DevPartnerに含まれる「カバレッジ分析」を使うという選択がある。この機能は、プログラム中で、どのコードが実行され、どのコードが実行されていないかを調べることができる。この機能を利用すると、本当にすべてのコードがテストされているかを確認することができる。すべてのテストを実行してもなお、実行されていないコードが残っていれば、それはテスト漏れということになる。

　ここでは、実際にわざと実行されないコードを含むプログラムを作成して、カバレッジ分析を適用してみよう。以下のようなサンプル・コードを作成してみた。VB.NETのコンソール・アプリケーションである。

Module Module1   Function Special10(ByVal p As Integer) As Integer     Return p * 10   End Function   Function Special100(ByVal p As Integer) As Integer     Return p * 100   End Function   Sub Main()     Dim i As Integer, s As Integer     For i = 0 To 99       If i = 10 Then         s = Special10(s)       ElseIf i = 100 Then         s = Special100(s)       Else         s += i       End If     Next   End Sub End Module

「カバレッジ分析」に使用するサンプル・コード

このプログラムには、一度も実行されないコード部分が含まれている。

　このプログラムは、100回のループを繰り返し、途中で2つのメソッドを呼び出すのだが、変数iは99までしかカウントせず、永遠に100にならないため、Special100メソッドが呼び出されることはないという構造である。

　では、さっそくカバレッジ分析を行ってみよう。まず、VS.NETのメニューで、［ツール］−［DevPartner］−［カバレッジ分析］と選び、カバレッジ分析の項目を選択状態にする。そして、［デバッグ］メニューから、「開始」を選ぶ。カバレッジ分析では、「デバッグなしで開始」を選ぶ必要はない。そして、プログラムを普通に実行させてから終了させる。すると、VS.NET内に以下のように結果が表示される。

「カバレッジ分析」の実行結果

Special100メソッド（CoverageAnalysis.Module1.Special100）は、カバーされた比率（実行されたコードの比率）が0％であり、コール回数も0であり、まったく実行されていないということが分かる。Mainメソッドにも一度も実行されていない部分が存在している。

　これを見れば、実行されないコードがあることは一目瞭然だろう。Special100メソッドは、カバーされた比率0％であり、コール回数も0、未実行の行数が3行あることが分かる。未実行の行はMainメソッドにも見られる。

　［ソース］タブに切り替えると、もっと分かりやすい。

実行されていない個所を表示する［ソース］タブ

赤く表示されたコードが実行されていない部分を示している。また、画面左端には、その行が実行された回数が表示されている。

　Special100メソッドの3行には回数の数字が付かず、色も赤く表示されている。また、Mainメソッド内のSpecial100メソッドの呼び出し行も、赤く表示され、ここが実行されていないことを示している。

　このほかに、以下のようなサマリも表示できる。

カバレッジ分析の要約を表示する［セッションサマリ］タブ

品質向上のためには、客観的な数値による分析を

　最近、プログラミングに関して筆者が感じていることが1つある。それは、「定性的」と「定量的」という言葉で表現してもよいように思う。大ざっぱにいえば、定性的とは性質に着目することであり、定量的とは量に着目することをいう。例えば、雨が降る日は傘が売れる、というのは定性的な話題である。それに対して、雨が降る日は晴天の日よりも平均5倍の傘が売れる、というのは定量的な話といえる。この2つの差はとても大きい。その理由は傘屋になった気持ちで、この2つの情報の有用度を比較すれば分かるだろう。例えば、明日は雨になりそうだと思ったとき、いつもより多くの傘を仕入れれば利益を拡大するチャンスになる。そのことは、定性的な話題でも、定量的な話題でも、どちらからも分かる。問題はその先である。傘をいったい何本仕入れれば利益が最大になるのだろうか。もし、売れる数よりも仕入れが少なければ、得られるはずの利益が減ってしまうことになる。かといって、売れる数よりも多く仕入れれば、売れない傘の仕入れに使った分だけ無駄が発生する。これに対する答えは、「定性的な話題」からは得られない。しかし、「定量的な話題」からは、晴天時に売れる数の5倍を仕入れればよい、と結論を出すことができる。もちろん、その数字が正しいかどうかは神のみぞ知るということになるが、少なくとも、何かを決断する根拠にはなる。

　同じような話は、プログラミングの世界にもあるような気がする。例えば、プログラミングにも、さまざまな「良くないこと」がある。しかし、良くないからといって宗教的な情熱を持ってすべて追放すれば万事良くなるかといえば、そういうわけでもない。例えば、配列などに含まれている一連のデータを検索する際、最初から順番に1つずつ調べていく方法（リニアサーチ）は効率が悪い。しかし、データ量が少ない場合は、ほとんどプログラムの性能に影響しないのも事実である。そのような性能に影響しない部分に時間を使うことは、プログラマーの能力の無駄遣いとなって、それも「良くないこと」に分類できる。この場合、「リニアサーチは効率が悪い」という定性的な知識だけでは、書き換えるべきか、書き換えるべきではないのか、適切な答えを得ることはできない。どの程度全体の性能に影響しているかを示す、具体的な数値が必要である。つまり、定量的な知識が必要である。

　別の例を挙げてみよう。プログラムの品質を上げるためにいつもより多くのテストを作成しよう、と考えることは簡単である。しかし、増やしたテストが、まんべんなくプログラム全体に適用されなければ、全体の品質は上がらない。例えば、クラスAとクラスBを含むプログラムがあるとき、100本のテストを200本に増やしたとしよう。そのとき、増えた100本のテストがすべてクラスAをテストするものであり、クラスBを呼び出すテストの数が増えないとすれば、クラスBの品質向上には何の寄与もしないことになる。この場合、どのテストが、プログラムのどの部分をどの程度テストしているかという定量的な数値が重要な意味を持つことになる。ここで注意すべきことは、テストの数を100本から200本に増やしました、といえば定量的な話であるかのように思えてしまう点である。しかし、この話には、プログラムのどの部分にどの程度のテストが増えているかという具体性がない。ただ単に数値があればよいというわけではなく、目的を達成するために必要な詳細な数値が必要だということである。その数値が本当に意味のある数値か、ということもよく吟味する必要がある。

　これらの状況を考えると、具体的な数値を結果として出してくれる分析の重要性が分かるだろう。困難な目標を達成するために、本当に何かを行おうとするなら、実際のプログラムに関する定量的なデータ収集は不可欠である。そして、ただ数字を出すだけでは意味がないことにも注意しなければならない。よく吟味し、目的を達成するために本当に必要な詳細な数値を得なければならない。そして、それを達成するために、DevPartnerのような強力かつ詳細な解析ツールが、有益な手助けになるのではないかと思う。例えば、リニアサーチをより効率の良い形に書き換えるか否かはパフォーマンス分析が役に立ち、追加したテストがまんべんなく全体をテストしているかを調べるにはカバレッジ分析が役に立つだろう。

INDEX
	［.NET Tools］
	プログラムを仕上げるときの強力な助っ人DevPartner
	1．分析を支援するDevPartner
	2．ソース・コードの弱点を検出する「静的ソース・コード解析」
	3．処理にかかった時間を計測する「パフォーマンス分析」
	4．テスト漏れを防止する「カバレッジ分析」

　

「.NET Tools」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）