ソフトウェアテストのテクニックについて紹介する本連載ですが、前回（第1回）はテストの全体像を確認しながら、さまざまなテストの種類があることをご説明しました。今回から、それらの1つ1つについて詳しく見ていきましょう。まず今回は静的テストについて紹介します。

静的テスト

ソフトウェアはテストによって品質を確保することができますが、第1回で紹介したように、テストにもさまざまな種類があります。一般的にテストと言えば、実際のテスト対象を動作させてみて、その結果を確認する動的テストのことを指します。それとは対照的に、テスト対象を動作させずに行う静的テストというものがあります。テスト対象を動作させないのであれば、一体何を検証するのでしょうか？

静的テストはドキュメントやソースコードなどを「見る」「⁠読む」といった方法で確認し、そこにある誤りを検出します。一般的には「レビュー」と呼ばれる方法です。

静的テストの対象としては設計書やマニュアルなどのドキュメントも含まれるのですが、ここでは実際に動作するソフトウェアを構成するソースコードに対する静的テストに絞って話を進めていきます。

ソースコードに対する静的テストのメリット

ソースコードに対する静的テストの主な目的は、ソースコードの可読性の向上、そして潜在バグの可能性となるコードをツールや目視でチェックすることです。

ソースコードの可読性が高ければ、維持管理やデバッグがしやすいというメリットがあります。また、コーディング時の早い段階で潜在バグの可能性を摘み取っておけば、単体テスト以降の手戻りも少なくなります。

このような理由から、静的テストはソフトウェア開発における品質保証、工数・コスト削減のための重要なファクターとなります。

静的テストの進め方

では、静的テストはどのように行えばよいのでしょうか？品質の高いソースコードを作るためには、以下の手順を踏んで静的テストを進めていくとよいでしょう。

1. コーディング規約に従ってコーディングする
2. 静的解析ツールによるチェックを行う
3. ソースコードレビューを行う

これらの作業はどれも大変ですが、この手順に従い、それぞれの作業を確実に行うことが成功への近道となります。それでは、それぞれの作業について詳しく説明していきます。

1．コーディング規約に従ってコーディングする

大勢のプログラマが集まったプロジェクトでソフトウェアを開発する際、プログラマが好き勝手にコーディングをすると、統一性がなく保守しづらいソースコードができあがってしまいます。これでは単体テスト以降でのバグの発見、修正や、ソフトウェアのリリース後のメンテナンスが非常に大変になります。

そこで、ソースコードの書き方に対する規則、すなわちコーディング規約を作り、すべてのプログラマがそれを守るようにします。

コーディング規約の作り方

コーディング規約を最初から作成するのは大変ですから、他のプロジェクトで作ったものや、Web上の情報など再利用できるものがあればそれを流用するのがお勧めです。たとえばJavaであれば、Sunが提供するコーディング規約を利用して、プロジェクトに合った規約にカスタマイズするのがよいでしょう。

• Sun コーディング規約
• Sun コーディング規約日本語版

コーディング規約に盛り込む観点としては以下のようなものが挙げられます。

• 命名規約（ex. クラス名は大文字で始める）
• コメントの記述（ex. メソッドは@paramと@returnは必須）
• コーディングスタイルに関するもの（ex. if文は一行でも必ず中括弧をつける）
• 性能低下につながるコードの禁止（ex. synchronizedの使い方）

ただし、あまり多くの規約を選ぶとプログラマが理解しきれない可能性がありますので、この後の静的解析ツールで自動チェックされるものとも組み合わせて、優先度をつけて選ぶようにしましょう。

2．静的解析ツールによるチェックを行う

コーディング規約をすべて理解して、正しくコーディングできれば問題ありませんが、実際に規約を厳密に守ってコーディングするのは、スキルの高いプログラマでも難しいことです。

そこで、コーディング規約に従っているかどうかをツールを使って自動的にチェックすることが有効になります。このツールが静的解析ツールです。

Javaの静的解析ツール

静的解析ツールとして、さまざまなプログラミング言語に対して多くのツールがありますが、ここではJava用の静的解析ツールのFindBugsとCheckstyleを紹介します。これらはオープンソースとして無償で提供されており、Javaの統合開発環境Eclipseでの導入も容易なため、多くのJavaプログラマに利用されています。

表1にも挙げたように、これら2つのツールはそれぞれ得意とするチェック観点が異なりますので、これらを合わせて利用することでコーディング規約に対応したチェックを網羅的に実施できます。

ここからは、それぞれのツールの利用方法を紹介していきます。どちらのツールも独自のGUIで利用したり、ビルドツールのAntと連携して利用することができますが、今回はEclipse上での利用方法について紹介します。

なお、ツールのインストール方法については今回は割愛させていただきますので、関連するWebや書籍を参照してください。

FindBugsの利用方法

（1）チェックルールの選択

まずFindBugsでチェックするルールを選択します。ルールの選択はEclipseのプロジェクトのプロパティ画面でチェックボックスのオン／オフにより設定できます（図1⁠）⁠。

このルールの設定を「ルールフィルタファイル」と呼ばれるファイルに記述することができます。これをプログラマに配布して、設定を読み込ませるようにすることで、ルールの設定を容易に統一できます。

（2）チェックの実行

FindBugsは、Eclipse上で実行対象を右クリックして、[FindBugs]→[FindBugs]を選択するだけで実行できます※1（図2⁠）⁠。

（3）チェック結果の確認と修正

FindBugsが実行されると、チェックされた箇所や内容といった情報がEclipse上に表示されます。最新版のFindBugsでは、図3のようにFingBugsの専用画面（パースペクティブ）を使って詳細な結果を確認できます。「⁠Bug Details」ビューにはバグの詳しい説明が表示されますので、それを参考に該当箇所を修正していきます。

Checkstyleの利用方法

（1）チェックルールの選択

Checkstyleについても、ルールの設定をXML形式でエクスポートすることができますので、それを配布し、インポートすることでルールの統一が容易にできます。

（2）チェックの実行

Checkstyleは、Eclipse上で実行対象を右クリックして、[Checkstyle]→[Check Code with Checkstyle]を選択するだけで実行できます※3（図6⁠）⁠。

（3）チェック結果の確認と修正

このように、静的解析ツールを使うと規約に違反したソースコードの記述が容易かつ瞬時に検出できますので、ツールをうまく活用することで、可読性が高く、バグが潜在しない高品質なソースコードを作成できます。また、次に行うソースコードレビューで、チェックする項目を大幅に削減できるという効果もあります。

3．ソースコードレビューを行う

ソースコードレビューは、プログラマ自身あるいは第三者（できればプログラミング言語に精通した有識者）がソースコードを目で見て確認することで、記述上のミスを見つける技法です。静的解析ツールを使うことによって、レビューでチェックすべき項目を削減できますので、たとえば処理フローの危険性、マルチスレッド環境ならデットロックになるようなところはないかなど、人にしか判断できない観点に絞ってチェックしていきましょう。

以上、静的テストについてご紹介しましたが、ソースコードに潜むバグの大部分は静的テストで検出することができます。面倒だから、時間がないからといって静的テストをしないと、後々の手戻りが増えて余計に時間がかかりますので、今回ご紹介した進め方に従って、早期にバグを検出し修正するよう心がけましょう。