明日からできるプロジェクト管理（4）
単体テストの品質をチェックするには
1page｜2page｜3page

高野敦
2006/1/12

実装・単体テストの品質をうまくチェックするにはどうすればいいのだろうか。本稿ではまず品質の考え方を概観し、その後、チェックを現実化するツールを紹介していく（＠IT編集部）

---

　プロジェクトマネージャ（＝PM）の石出さんは今日も悩んでいます。

　石出さん談――。

　今度のプロジェクトは実装・単体テストを一括発注することになった。でも一括発注だとどのように品質をチェックしたらいいのだろう。いつものように目の前で作業をしてくれれば分かるんだけれど……。

　なるほど、石出さんは実装・単体テストの品質に関して悩んでいるようです。

◆ 品質の考え方

　 品質には大きく分けて2つの考え方があります。製品（システム）そのものの品質と製品を作成するプロセス（作り方）の品質です。前者は、対象物そのものがどの程度の品質を保っているかを評価することであり、後者はプロセスがどれくらい欠陥を作らないようにしているか、また除去できるかを評価しそのプロセスから作られた製品はどの程度の品質なのかを評価する方法です。

　一般的にプロセスの品質の方が複数の製品を対象にできるため着目されています。例えばCMMIに代表されるようなプロセス改善の仕組みはこのプロセスの品質の考え方によって実現されています。

　プロセス品質が重要なことは分かりますが、一括発注先にプロセスを強制することは難しい場合があります。そのようなときにどのように品質を確保するかが問題となります。発注先のプロセスがしっかりしたところに発注すればいいわけですが、それだけでよいのでしょうか。いろいろな状況が考えられます。今回はプロセス品質にはこだわらず、製品品質を評価する方法を考えてみましょう。

● 製品品質

　実装単体テスト工程における製品品質を評価するためには、以下の表のような評価をするとよいでしょう。

製品品質（実装・単体テスト工程）
評価方法	説明
コードレビュー	ソースコードを対象としてフォーマットの適切さ、コーディング規約の遵守、バグになりやすいコードの有無などを評価する
単体テスト（BlackBox）	ソースコードが仕様のとおりかを確認するテストの実施結果を基に評価する
単体テスト（WhiteBox）	単体テストがすべてのソースコードに対して行われているかを評価する

　ここでは単体テストをBlackBoxテストとWhiteBoxテストの2種類に分類しています。BlackBoxテストはソースコードをBlackBox化して、仕様どおりかをテストする方法で、WhiteBoxテストはソースコードの詳細に沿った形でテストする方法です。BlackBoxテストが仕様と合致しているかという正確性の品質を評価し、WhiteBoxテストではテスト実施済みコードの点から信頼性を評価しています。

● 製品品質の評価

　製品品質、つまりソースコードの品質を評価するためにコードレビュー（インスペクション）や単体テスト（BlackBox、WhiteBox）を行います。それぞれの手法について簡単に説明します。

・コードレビュー

　コードレビューは、コーディング規約違反やバグになりやすいコードの有無、仕様との差異を人間の目で確認し、ソースコードの品質を評価するタスクです。このレビュー方法には、Checklist-Based Reading（CBR）、Perspective-based　Reading（PBR）といった手法があります。CBRはチェックリストを基にコードをレビューする方法で、PBRはプログラムの視点（規約を守っているか、保守しやすいかなど）を絞り、その観点ごとにシナリオ化して、そのシナリオを基にコードをレビューする方法です。優秀なプログラマーなどによって属人的にコードレビューする方法もありますが、それは手法ではありません。

　レビューで大事なことは、どの範囲のソースコードを誰がレビューアでどれくらいの時間をかけてレビューしているかということと、レビューの指摘事項の記録を取るということです。この2つの情報によってソースコードの品質を測ることができます。

コードレビューのメトリクス*

レビュー時間（延べ時間）

レビューアレベル

レビュー指摘数（パッケージ別、チーム別、個人別、指摘分類［仕様勘違い、コーディング規約不適合など］）

［*］ メトリクスについては「初めてのソフトウェアメトリクス（前編） ソフトウェアの品質を数値化して確かめる」を参照してください。

　最初の2つのメトリクスはこのレビューが適切なものだったかという判定に利用され、その判定により妥当だと判断された場合にレビュー指摘数が多い・少ないといった定量的にソースコードの品質を測ることができます。ただし、単一のプロジェクトの指摘数だけを確認することは相対的な品質しか分かりません。言語を限定しいくつかのプロジェクトのレビュー指摘数を統計的に処理することで、ライン数当たりのレビュー指摘数の標準値を定義することができます。こうすることで相対的ではなくソースコードの品質を定量的に評価できるようになります。

　最初のうちは相対的な評価をするとともにどの指摘を修正するかということを考える方が適切だと思います。相対的であっても、チームや個人の品質の課題などを洗い出すことができ、製品品質を高めるのに役立ちます。

・単体テスト（BlackBox）

　単体テスト（BlackBox）は、仕様どおりにソースコードが作成されているかどうかを確認しソースコードの品質を評価するタスクです。単体テストという言葉はあいまいな言葉で、結合テスト前のテストを指し、統合後（ビルド後）の疎通テストやスモークテストを指す人もいるようです。ここでは単一のモジュール（Javaのクラス）のロジックをテストすることを単体テストと呼びます。

　つまり、メソッドの仕様に沿ってテストケースを作成し、単体テストを実施することになります。単体テストを実施するためにテストドライバと呼ばれるテスト対象のクラス（メソッド）を呼び出すモジュールを作成する必要があります。近年、このテストドライバはxUnitと呼ばれるテストのフレームワークによって形式的に作成できるようになっています。テストドライバとテストケースを組み合わせてテストを実施していきます。テストケース数、テスト実施数とテストの成功数でソースコードの仕様書の適合性という観点での品質を測ることができます。

　テストケースの粒度と重複度によってテスト実施数の精度が変わるので、この品質評価を相対的ではない評価に用いるためには、コードレビューの定量評価と同様に複数のプロジェクトのテストケース数を統計的に処理する必要があります。

単体テスト（BlackBox）のメトリクス

テストケース数

テスト実施数

テストの成功数

・単体テスト（WhiteBox）

　テストされていないコードは品質が評価されていないコードであり、それらのコードが残っていることは好ましくありません。そのため単体テスト（BlackBox）と同様に単体テストを行います。単体テスト（BlackBox）との違いは、仕様書に沿ってテストケースを作成するのではなく、ソースコードの構造に沿ってテストケースを作成する点です。本来的に意味のあるテストケースを作成した方がよいですが、テストされていないコードをなくすことを目的にしているので意味のないテストケースでもテスト可能です。

　このテストの目標はソースコードのテスト網羅度なのでカバレッジ（テストをしているかどうかの全体に対する割合）を計測して、ソースコードの信頼度を評価します。カバレッジの詳細についてはここを参照してください。

単体テスト（WhiteBox）のメトリクス

ステートメントレベルのカバレッジ

分岐レベルのカバレッジ

　カバレッジの目安は、難しく議論の分かれるところです。そのため環境（Web、Javaなど）によってコストメリットの高い数値を設定するとよいでしょう。筆者の経験的には85％くらいがバランスの良い数値かと思います。

1/3

INDEX
明日からできるプロジェクト管理（4） 単体テストの品質をチェックするには
	Page1 ◆ 品質の考え方
	Page2 ◆ メトリクスを計測するためのツール
	Page3 ● 単体テスト（BlackBox）におけるツール

IT Architect 連載記事一覧