単体テスト

 

プラスナレッジでは2つの単体テストの手法をサポートしています。

・網羅的単体テスト

自動車業界や医療においては網羅的単体テストが要求されます。C0, C1等の基準からwinAMSを使った、MC/DC網羅率まで厳しい単体テストが要求されることがあります。その場合、多くの工数が要求され、ときとしてはソースコードと同量の単体テストケースを書かなければならないこともまれではありません。その多量の単体テストケースを社内で行うのは時間的制約や、コストの制約があり難しくはありませんか?その場合はまず弊社にご相談ください。単体テストのエキスパートが、目標の網羅率まで網羅する単体テストを作成しますし、また弊社のコンサルティングがどの程度まで単体テストをやればよいかご相談をうけます。例えばGoogleでは以下の網羅率まで単体テストを行ってます等々豊富な単体テストの経験からお客様に最適な単体テストソリューションを提供します。

・Hotspot単体テスト

ミッションクリティカルな製品でなければ品質は悪くてよいとは言いにくいですが、テストにかけられる費用はそれほど多くありません。
そうならば、すべてのコードを網羅するのではなく網羅すべき所(バグの出るところを)だけを網羅すればよいと考えるのは悪い考えでありません。昔日の日々は複雑度を計算し、プログラムの複雑な場所でバグが発生するという研究がされましたが、現代ではファイルの変更が多数発生する場所でバグが発生するとされています([KIM07]参照)。そういった場所をHotspotと呼びその場所のみテストするという会社がGoogle(http://google-engtools.blogspot.com/2011/12/bug-prediction-at-google.html)等々も含め増えてきています。例えば下図①のファイルは直近でたくさん変更されているので、バグが起こりやすく、下図②のファイルは直近ではあまり変更されていないのでバグが起こりにくくHotsport値は低くなります。
この理論を使っていけば、例えば10%のファイルだけを単体テストしただけで、80%以上のバグをつぶせるというのも夢ではなくなります!

[KIM07] S. Kim, T. Zimmermann, E. Whitehead Jr, and A. Zeller. Predicting faults from cached history. In Proceedings of the 29th international conference on Software Engineering, pages 489–498. IEEE Computer Society, 2007.