第6回 カバレージを考慮した機能試験の自動化(その1):理論的・計画的なWebアプリケーションのテストの実現(2/2 ページ)
今回からより実践的な内容に話を移し、カバレージを考慮した機能試験の自動化について解説する。機能試験の自動化を意義あるものにするにはどうすればよいのだろうか。
テストケースに優先順位と難易度を設定することで不具合の発見数を予想できるが、機能試験が100%網羅しているか、つまりカバレージはどのように測定すればいいだろうか。カバレージの測定方法には次のような方法がある。
- 仕様とテスト要件を結びつけて測定する
- テストケースをファンクション、ナビゲーション、バリデーションの3つのカテゴリーに分けて測定する
1の方法は非常に簡単な測定であるためにあまりお勧めできないが、仕様書IDとテスト要件を結びつけることで、どの仕様が検証されているかが明確になるため、最低限実装する機能が検証されているかを測定できる。しかし、よほど詳細に仕様書が作成されていない限り、ある機能とある機能の組み合わせによってしか動作しない機能などの検証が抜け落ちるなどの問題が発生することになるので注意が必要である。
2の方法はWebアプリケーションが生成するFORMを含んだページ、データ送信、各リンクのナビゲーションというカテゴリーでテストケースを分類して測定する方法である。バリデーションはクライアントバリデーションとサーバサイドバリデーションの2種類に分けた方がさらに詳細に分類できるだろう。
テンプレートエンジンを利用しているWebアプリケーションの場合では、アプリケーションの総画面数がテンプレートの数で特定できるため、非常に細かいカバレージ測定を実施できる。例えば、画面数が100であり、その100の画面の中のFORMオブジェクトの総数が明確で、各FORMオブジェクトに空白チェックのクライアントバリデーションが存在し、入力された値によるサーバサイドバリデーションがあり、1画面にはある特定の数のリンクが存在するなどをテスト要件で拾い上げ、より詳細に分類されたテストケースを作成できる。
1と2ではカバレージ測定を行うための精査基準が異なっているので、単純な比較はできないが、2のレベルまで明確にテストケースを洗い出していかない限り、本当の意味での100%カバレージは実現できないと言える。そして、100%のカバレージではないということはテストの漏れが存在しているということである。
機能試験を自動化するためには
機能試験のテストケースを作成し、テスト設計カバレージの測定が終了したら、テスト実施カバレージを考える必要がある。理想的にはすべてのテストケースを実施すべきであるが、すべてのFORMオブジェクトに文字のチェックが入っているからといっても、すべてのFORMオブジェクトで実施するのは現実的ではない。テスト実施カバレージはテスト計画作成のときに、最低限行うべきテストケースの選択方法を決めておく必要がある。例えば、優先順位AおよびBは実施するなどである。あとは実際の工数に合わせながら最大限のテストケース数を算出することになるだろう。
テスト実施カバレージも決まっており、実施するテストケースを決定したら、次はどのように機能試験を自動化していけばいいかを考えていくことになろう。個人的には最初の1サイクル目は自動化するのではなく、手動でテストを実施することをお勧めしたい。これは、自動化することに注力してしまい不具合を見落とす可能性があるためで、手動テストの後に自動化を実施する方がいいと考える。
初めてテストの自動化を行うときには、テストケースは手動で行うときのテスト手順を明確に記載しておき、自動化するときの流れを手動の流れに合わせ、1テストケースが1つのスクリプトして作成していくことをお勧めしたい。また、その際には優先順位の高いテストケースのみに絞り、スクリプトを作成するのがいいだろう。この単純な方法であれば、できあがったところから自動化スクリプトを再利用できるだけでなく、確実に自動化を進めていくことができる。
ある程度慣れてから今度は利用するテストツールに適した流れを考え、各テストケースをその流れに合わせていくのがいいだろう。イメージ的には負荷検証のときに作成するシナリオベースで機能試験を実施するといった感じで、スクリプトの再利用性とできる限り少ないステップでの実装を考慮した作り方である。
機能試験の自動化を実現するツール
Webアプリケーションの機能試験の自動化を実現するためのテストツールとしては数多くの製品が存在しているが、この連載では以下2つを使った場合を説明していきたい。1つはオープンソースの受け入れテストツールである「Jameleon」、もう1つはテストツールベンダーとして名高いマーキュリー・インタラクティブの「Quick Test Professional」である。それぞれについては関連リンクを参考にしてほしい。
次回に向けて
次回はJameleonの使い方を解説するとともに、どのように機能試験の自動化を実現していくかについてスクリプトの作り方に触れながら説明していきたい。
関連記事
- 特集第1回:テストをどう考えていますか?
- 特集第2回:テストの計画をまとめる
- 特集第3回:テストを設計するには(その1)
- 特集第4回:テストを設計するには(その2)
- 特集第5回:テストを設計するには(その3)
- QAの革新なくしては、世界水準のソフトウェアはつくれない
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.