目次


developerにもテストを

第2回 ツールを駆使したテスト

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: developerにもテストを

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:developerにもテストを

このシリーズの続きに乞うご期待。

はじめに – ソフトウェアテストでツールが必要な理由 -

前回は、ソフトウェアエンジニアリング基礎知識体系(Software Engineering Body of Knowledge:以下SWEBOK)をベースにソフトウェアテストの基本的な体系についてご説明しました。

第2回は「ツールを駆使したテスト」というタイトルで、ソフトウェアテストを支援するツールと、使い方のコツについて触れていきたいと思います。

ソフトウェア開発全般にツールを適用することで、効率化を図ることは、一般的なものになっており、SWEBOKでも[SOFTWARE ENGINEERING TOOLS AND METHODS]というひとつの領域として取り上げられています。今日、ソフトウェアテストの分野でも、ツールを活用することは、テストエンジニアのみならず、ソフトウェア開発に携わる技術者全てにとって必須の知識になっているといえます。それは、現代のソフトウェア開発スタイルにおける2つの大きな特徴によるものだと考えられます。

まず、いまどきの開発は、OSやミドルウェア、RDBなどはもとより、ライブラリ群や商用コンポーネントなどを利用することで、短期間での開発を可能にしています。当たり前ですが、自分たちで書くコードの量が減るので、その分工数が短縮するからです。Webサービスなどが本格的になってくるとさらにこの流れが加速するでしょう。既存のコンポーネントなどをどんどん利用し、部品の組合せのように実装が行えるようになれば、実装工数は限りなく少なくなるかもしれません。しかし、テスト量は減りません。コンポーネント同士を結合したときに矛盾無く動作することを確認しなければならないためです。既存のコンポーネントがバージョンアップされた場合も、他のコンポーネントや自分たちで開発したコンポーネントとの整合性に関して、再度テストをやり直さなければなりません。また、ソフトウェアが顧客と合意した要件(これは機能仕様だけでなく性能などの非機能要件も含みます)どおりに正しく動くかは、部品部品が正しく動くこととは別問題であるため、自分たちがコードを書いた量とは関係なくテストを行わなければなりません。

もうひとつは、反復型開発です。こちらは、顧客の要求が全てFIXしてから開発するのではなく、作れるところから小さい単位の開発を繰り返して完成させていきます。(典型的なものとして、開発ごと要件の一部を実現し、段階的にシステム全体を完成させるインクリメンタル開発や、プロダクトの洗練を繰り返し、システムを完成させるエボリューショナル開発があげられます。)この開発スタイルは、要求が変更することをある程度考慮しており、ウオーターフォール型の開発よりも仕様変更などに伴う手戻りが少なくなるとも言われています。しかし、この場合もテストは減りません。それどころか、反復のたびにテスト済みのソフトウェアに対しても、再度テストが必要になる(反復により追加になったソフトウェアと開発済みソフトウェアの整合性確認が必要なため)ので、テスト量が増加します。

両方の開発スタイルの変化に共通していえることは、「開発全体の工数が短縮できてもテスト量はそれに比例して減るわけではない」ということです。既存のコンポーネントの品質次第では、テスト量は逆に増加してしまう可能性もあります。ただ単にテスト量の増加を、工数の追加投入で対処してしまえば、開発スタイルを変更したメリットは相殺されてしまうでしょう。そこで重要になってくるのが、「ソフトウェアテストをどうおこなうか」です。

「どう行うか」には、回帰テスト(テスト済みのソフトウェアに対する再テスト)の進め方や、テスト設計技法の適用、テストプロセスの見直し(特に上流段階からのテストアクティビティを開始させること)などが考えられます。テストファースト(実装の前にテストコードを実装する)もこれらの中に含まれるでしょう。しかし、これらのアイデアを実現しようとすると、いままでのテストよりも逆にテスト工数を増やしてしまう可能性があります。これらのアイデアを現実的に現場で適用するための技術としてツールの活用があるのです。

ツールを駆使したテストのポイント

ツールを活用するといっても、ツールがあれば良いというものではありません。まず、適用できる場面も異なるため、使い方や使う場面を間違えると、効果が出ないだけでなく無駄に工数がかかってしまうことさえあります。アプリケーションドメインやプログラム言語ごとに制限があるツールもあるので、自分たちの開発に適用可能なツールかどうか事前の十分な調査/検証も必要です。しかしツール導入時に最も問題となることは、ツールを過信してしまい、なんでもツールがやってくれると思ってしまうことです。ツールは所詮「道具」です。道具はあくまで作業の一部の効率化してくれているものであることを忘れないでください。

以上を考慮し、ツールを駆使したテストを成功させるポイントをまとめると以下の3つがあげられます。

  • 得たい効果を見極める
    ツールは全てを自動化するわけではありません。適材適所で使うことが大事です。
  • ツールによるリスクをコントロールする
    ツールを使うことで、いままで一緒に出来た作業を分割するなど、テストプロセスの見直しが発生する場合もあります。開発作業をテストのために見直すことさえありえます。
  • ツールを活用できるスキルを身に付ける
    自転車より自動車のほうが、操作が難しいのと同じで、効果が高いツールほど使いこなすのは難しいといえます。使いこなすためのスキルを習得しなければなりません。

テストツールの種類

では実際、ソフトウェアテストを支援するツールにはどのようなものがあるでしょうか。私たち開発者にとって身近なものとして、xUnitのようなテスト実行を支援するツールを思い浮かべるケースが多いかと思いますが、ツールはそれだけではありません。テスト準備を支援するツール、テスト設計を支援するツールなど様々なツールが存在します。今回は、「ISTQBテスト技術者資格制度Foundation Levelシラバス 日本語版」(以下ISTQBシラバス)でのテストツールの分類をベースに各ツールについて説明していきたいと思います。(参考文献[1]より引用)

ソフトウェアテスティングツールの分類

  • テストマネジメント支援ツール
  • 静的テスト支援ツール
  • テスト仕様支援ツール
  • テスト実行とロギングの支援ツール
  • 性能・モニタリング支援ツール

テストマネジメント支援ツール

テストケースを管理して、テストの進捗状況を把握したり、インシデント(不具合)を管理して、何件の不具合が見つかって未修正のものが何件かなど不具合の状態を把握したりするツールがこの分類に含まれます。テストをマネジメントするマネージャやリーダーがテストの状況を把握するために使います。IBMの製品ではRational ClearQuest and Functional Testingがあげられます。

テストマネジメントを支援するツールは、地味ですがとても重要なツールです。テスト量が増えると言うことは、テストケースの数や実行回数が増えるということです。いまどきの携帯電話の機能テストなどは、テストケースが10万項目を超えるなんてこともざらです。ツールなしでは、これらの管理が極めて困難になります。管理ができていないと、テストケースを実行するのを漏らしてしまうなど、テストを効率化する以前の問題が多数発生します。

静的テスト支援ツール

静的テストとは、レビューやコーディングルールのチェック、ソースコードのメトリクス測定などから欠陥を見つけるテストを指します(「テスト」と通常呼ばれているものは、静的テストに対しては、動的テストとよばれます)。静的テストツールで代表的なものが静的解析ツールです。IBMの製品ではRational PurifyPlus™などが該当します。

静的解析ツールは,バッファオーバフローのような、動的テストでは見つけることが困難な欠陥をコードの記述内容から見つけることができます。また、動的テスト実施前にソースコードのどのあたりに欠陥がありそうなのか当たりをつけて、テスト量の強弱をつけることで、その後のテストの効率を上げることが出来ます。

テスト仕様支援ツール

テストケース作成を支援するツールとテストデータ作成を支援するツールが該当します。

テストケース作成では、制御パステストのテストケースを生成するもの、状態遷移図からテストケースを作成するもの、All Pairテストのテストケースとなる組合せを自動的に作成するツールなどが代表的なものだといえます。ただし、テストケース作成を支援するだけなので、なんでもかんでも自動で行ってくれるわけではなく、特定のテストケースを設計する技法のルールに従ってテストケースを生成するだけです。そのため、作成するための基になる情報を適切にインプットしないと、まともなものは出てきません。

また、「何をテストするのか」「どの機能を重点的にテストしなければならないのか」「どのテスト設計技法を適用するのか」などのテストケースを設計する技法を適用する前の作業は、当然ツールではできません。

テスト実行とロギングの支援ツール

ユニットテストで使用する、xUnitや、統合テスト以降のユーザ操作をベースにしたテストの自動化で使用する、キャプチャ/リプレイツールが該当します。(キャプチャ/リプレイツールとは、PC上のマウスやキーボードの操作を記録,再生して期待結果と自動比較するツールを指します。IBMの製品では Rational Functional TesterやRationl Robotが該当します。)同じテストを繰り返し何度でも実施できるので、仕様変更に対する回帰テストの効率化に繋がります。いまどきの開発では必須のツールといえるでしょう。

ただ、前述したようにツールを使うとすべて自動でできるわけではありません。そもそも手動で行ったことがないテストは、ツールを使ってもそう簡単にはできませんし、逆にすべて手動で行っていたテストを自動化することもできません。テストプロセスを見直さないと自動化のための手間がかかりすぎてしまい効果が出ない場合もあります。

性能・モニタリング支援ツール

手動のテストでは実施が困難な大量の負荷をシステムへ与えるツール、負荷を与えたときの応答時間測定やシステムリソースのモニタリングを行うツールが該当します。IBMの製品ではRational Performance Testerなどが該当します。大量の負荷を与えるテストは、そもそもツールを使わないと実施が極めて困難な場合が多いので、ツール活用の効果はテスト実行を支援する自動テストツールと比較するととてもわかりやすいと言えるでしょう。ただこの種のツールは、機能要件ではなく非機能要件をテストしています。開発時に非機能要件が定義できているか、またどのように実装しているか(例えば、DB設計やアーキテクチャ設計でパフォーマンスを意識できているか)がわからないと、どこに集中的に負荷をかけるのか、何をモニタリングすればよいのかが分からなくなります。なぜ測定しなければならないのか、何を測定するのかなどをしっかり理解し計画的にテストをすることで、ツールの効果を十分に発揮できます。

最後に

以上、ISTQBの分類にのっとり、テストツールを上記の五つに分類して活用のポイントを説明しました。読者のみなさんがテストツールを活用する際は、本稿の「ツールを駆使するためのポイント」を考慮していただき、開発全体の効率アップのための「道具」としてテストツールを利用してもらえれば幸いです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=
ArticleID=266132
ArticleTitle=developerにもテストを: 第2回 ツールを駆使したテスト
publish-date=11092007