ソフトウェアテストのテクニックについて紹介する本連載ですが，前回（第1回）はテストの全体像を確認しながら，さまざまなテストの種類があることをご説明しました。今回から，それらの1つ1つについて詳しく見ていきましょう。まず今回は静的テストについて紹介します。
静的テスト
ソフトウェアはテストによって品質を確保することができますが，第1回で紹介したように，テストにもさまざまな種類があります。一般的にテストと言えば，実際のテスト対象を動作させてみて，その結果を確認する動的テストのことを指します。それとは対照的に，テスト対象を動作させずに行う静的テストというものがあります。テスト対象を動作させないのであれば，一体何を検証するのでしょうか？
静的テストはドキュメントやソースコードなどを「見る」「読む」といった方法で確認し，そこにある誤りを検出します。一般的には「レビュー」と呼ばれる方法です。
静的テストの対象としては設計書やマニュアルなどのドキュメントも含まれるのですが，ここでは実際に動作するソフトウェアを構成するソースコードに対する静的テストに絞って話を進めていきます。
ソースコードに対する静的テストのメリット
ソースコードに対する静的テストの主な目的は，ソースコードの可読性の向上，そして潜在バグの可能性となるコードをツールや目視でチェックすることです。
ソースコードの可読性が高ければ，維持管理やデバッグがしやすいというメリットがあります。また，コーディング時の早い段階で潜在バグの可能性を摘み取っておけば，単体テスト以降の手戻りも少なくなります。
このような理由から，静的テストはソフトウェア開発における品質保証，工数・コスト削減のための重要なファクターとなります。
静的テストの進め方
では，静的テストはどのように行えばよいのでしょうか？品質の高いソースコードを作るためには，以下の手順を踏んで静的テストを進めていくとよいでしょう。
- コーディング規約に従ってコーディングする
- 静的解析ツールによるチェックを行う
- ソースコードレビューを行う
これらの作業はどれも大変ですが，この手順に従い，それぞれの作業を確実に行うことが成功への近道となります。それでは，それぞれの作業について詳しく説明していきます。
1．コーディング規約に従ってコーディングする
大勢のプログラマが集まったプロジェクトでソフトウェアを開発する際，プログラマが好き勝手にコーディングをすると，統一性がなく保守しづらいソースコードができあがってしまいます。これでは単体テスト以降でのバグの発見，修正や，ソフトウェアのリリース後のメンテナンスが非常に大変になります。
そこで，ソースコードの書き方に対する規則，すなわちコーディング規約を作り，すべてのプログラマがそれを守るようにします。
コーディング規約の作り方
コーディング規約を最初から作成するのは大変ですから，他のプロジェクトで作ったものや，Web上の情報など再利用できるものがあればそれを流用するのがお勧めです。たとえばJavaであれば，Sunが提供するコーディング規約を利用して，プロジェクトに合った規約にカスタマイズするのがよいでしょう。
コーディング規約に盛り込む観点としては以下のようなものが挙げられます。
- 命名規約（ex. クラス名は大文字で始める）
- コメントの記述（ex. メソッドは@paramと@returnは必須）
- コーディングスタイルに関するもの（ex. if文は一行でも必ず中括弧をつける）
- 性能低下につながるコードの禁止（ex. synchronizedの使い方）
ただし，あまり多くの規約を選ぶとプログラマが理解しきれない可能性がありますので，この後の静的解析ツールで自動チェックされるものとも組み合わせて，優先度をつけて選ぶようにしましょう。
2．静的解析ツールによるチェックを行う
コーディング規約をすべて理解して，正しくコーディングできれば問題ありませんが，実際に規約を厳密に守ってコーディングするのは，スキルの高いプログラマでも難しいことです。
そこで，コーディング規約に従っているかどうかをツールを使って自動的にチェックすることが有効になります。このツールが静的解析ツールです。
Javaの静的解析ツール
静的解析ツールとして，さまざまなプログラミング言語に対して多くのツールがありますが，ここではJava用の静的解析ツールのFindBugsとCheckstyleを紹介します。これらはオープンソースとして無償で提供されており，Javaの統合開発環境Eclipseでの導入も容易なため，多くのJavaプログラマに利用されています。
表1 Javaの静的解析ツール
| Checkstyle | FindBugs | |
|---|---|---|
| 解析対象 | ソースコード（.javaファイル） | バイトコード（.classファイル） |
| ルール数 | 約120 | 約300 |
| 用途 | コーディングスタイルのチェック | 潜在バグの検出 |
| URL | http://checkstyle.sourceforge.net/ | http://findbugs.sourceforge.net/ |
表1にも挙げたように，これら2つのツールはそれぞれ得意とするチェック観点が異なりますので，これらを合わせて利用することでコーディング規約に対応したチェックを網羅的に実施できます。
ここからは，それぞれのツールの利用方法を紹介していきます。どちらのツールも独自のGUIで利用したり，ビルドツールのAntと連携して利用することができますが，今回はEclipse上での利用方法について紹介します。
なお，ツールのインストール方法については今回は割愛させていただきますので，関連するWebや書籍を参照してください。
