Eclipseテストツール活用の基礎知識：Eclipseで使えるテストツールカタログ（1）（1/3 ページ）
Eclipseプラグインで提供されるテストツールが充実してきた。本連載では、システム開発の現場に有効なテストツールを紹介し、統合開発ツールにEclipseを選択する開発におけるテストの効率化、ソフトウェア品質の向上のヒントを提供する。（編集部）
昨今、社会問題にまで発展するシステム障害が多発し、システムの「品質」に対する意識が非常に高まっています。このような障害が起こる原因はいくつかありますが、その1つに「テスト」で問題を発見できなかったことが挙げられ、テストの重要性が再認識されています。
テストはシステム開発全体の後半で実施されるため、前半に行われる設計や製造が遅延すると、期間の短縮を余儀なくされ、十分なテストを実施できないことが多くあります。また、作業は単調であるにもかかわらず、非常に時間がかかる非効率的なものであるため、手抜きをされてしまうこともしばしばあります。
このように、システム開発の現場では、テストは重要だと分かっているにもかかわらず、軽視あるいは敬遠されがちな作業なのです。そこで本連載では、そのテストの作業を軽減するテストツールのうち、Eclipseのプラグインとして提供されているツールを紹介していきます。それぞれのツールについて、使う目的と使う場面、設定や利用の方法、利用することにより得られる効果を説明していきますので、ツールを正しく使いこなしてテストをすれば、効率よく品質の向上を実現できます。
まず今回は、テストの目的や種類などをおさらいし、その中でどのようなツールが利用できるかといった全体像を見ていきます。
テストはソフトウェアの「品質」を確認する作業
まず、テストの定義について見直してみましょう。テストの目的は「システムが要求された品質を満たすことを確認すること」です。そのために、テストでは、要求どおりに動作しないこと、すなわち「バグ」を見つけることが目標になります。逆にいうと、バグを多く見つけられたテストは「よいテスト」となります。
バグがあるのは開発スキルが低いためだと悲観的になる方もいますが、テスト本来の目的からすれば、それは悪いことではありません（もちろんバグがたくさん出過ぎるのは問題ですが）。バグが出ないのは当たり前のことしかテストしていない可能性が高く、むしろバグが潜んでいそうなところをテストすることが重要であるといえます。
すべてのケースを想定してテストするのは不可能ですので、すべてのバグを見つけるのも不可能です。また、システムに潜んでいるバグがどれだけあるかは誰にも分かりませんので、いくらテストをして数多くのバグを見つけても、「もうバグは残っていない」といい切ることはできません。しかし、可能な限り多くのバグを見つけ出すことにより、バグが残っている可能性を少しでも減らすことが必要になります。
「品質」の分類
これまでに何度か使った「品質」という言葉は非常にあいまいです。実体のあるものとは異なり、目に見えないシステムの品質をイメージするのは困難ですが、システム（正確にいうとソフトウェア）が満たすべき品質は以下の6つに分類されます。
- 機能性
要求に対する仕様の正しさ、および仕様に対するプログラムの正しさ - 信頼性
機能が正常に動作し続けられるかどうか - 使用性
システムの使いやすさ、分かりやすさ - 効率性
目標時間内で、決められたリソースを使って処理ができるか（＝性能） - 保守性
障害解析、修正、テストのしやすさ - 移植性
ほかの環境への移しやすさ
これらは「品質特性」と呼ばれ、ISO/IEC 9126（JIS X0129）で定義されています。システム開発を行ううえでは、これらの品質を意識した設計を行い、これらを満たして設計どおりに作られていることをテストで確認します。
テストの工程
「テスト」と一口にいってもさまざまな種類があります。ここでは、テストの実施工程による分類をしてみます。
システム開発の基本的な流れであるウォーターフォールモデルでは、テストは開発全体の中の後半（下流工程）で行われます。それぞれのテストは前半（上流工程）の設計に対する確認をしますので、図1のような「V字モデル」で表すことができます。
図1にも示したように、テストは段階的に行います。まず小さい単位でのテストを行い、その単位での品質を保証します。次に品質が保証されたもの同士を結合していき、最終的に全体の品質を確認していくというのがテストの過程になります。その段階は次のような工程に分けられます。
コーディング
コーディングはプログラムを書く工程ですので、一般的にはテストの工程には含まれませんが、コーディング中あるいは直後に実施するテストがあります。これは、ソースコードを実行せずに、読むことにより確認するもので、後述する「静的テスト」における「ソースコード・レビュー」と呼ばれます。このテストでは、
- 仕様に合った実装がなされているか
- コーディング規約に違反した記述がないか
- バグあるいはバグになりやすい記述がないか
といったことを中心に確認します。この時点で多くの記述違反を見つけることにより、この後の工程での手戻りを減らすことができます。例えば、性能劣化やセキュリティの脆弱性を招くような記述など、リリース直前に発見されがちな問題でも、検出可能なものもあります。
単体テスト
単体テストは、一般的には「モジュール」単位で実施するテストといわれます。Javaでいえばクラスやメソッド単位のテストとなり、単体テストツールの「JUnit」を使ってテストするのが一般的です。このテストでは、プログラムの内部設計に合っていることを確認します。
通常は、プログラマがコーディングと同一の環境で実施するものであり、コーディングとは明確に工程を区切らず、並行して実施することもあります。
結合テスト（統合テスト）
結合テストでは、単体テスト済みの複数のクラスにより構成される実行可能単位の機能について、外部仕様に合っていることを確認します。クラス間や機能間のインターフェイスなどを中心に確認します。結合テストの中でも、結合する範囲を段階的に広げていくのに合わせて、より小さな工程に分けることがよく行われます。
一般的にはテスト専任の担当者がテスト専用の環境で実施しますが、結合テストの中の初期フェーズではプログラマが実施することもあります。
システムテスト（総合テスト）
システムテストは、本番に近い環境で行い、システムが全体として要求された仕様のとおりに動作するかを確認します。機能だけでなく、性能をはじめとする非機能に対するテストや、本番での運用を意識したテストを行います。
変更部分のテスト（回帰テスト）
各テスト工程でバグが見つかった場合、それを除去するためにコードを修正し、その後には正しく修正されたことを確認するためのテストが必要になります。テストの工程ではありませんが、回帰テストと呼ばれます。
バグの修正のためにあるクラスを変更すると、そのクラスを使用しているほかのクラスの動作に影響が出て、別のバグが発生する（デグレード）可能性があります。このように、バグの修正により、ほかの個所に影響が出ていないかどうかを確認するテストを「回帰テスト」と呼びます。影響範囲を見極め、必要なテストケースを再度実行して、デグレードが起きていないことを確認します。
Copyright © ITmedia, Inc. All Rights Reserved.