BOOK Preview Microsoft Visual Studio 2005による Webアプリケーションテスト技法 第5章 テストチームによる結合機能テストの実施 マイクロソフトプレスの書籍紹介ページ 日経BPソフトプレスの書籍紹介ページ 書籍情報（書籍目次）のページ 2007/04/23

Page1 Page2 Page3

5.2.2 テスト手順書作成に関するTips & Tricks

　さてこのテスト手順書は、テストケースとしての網羅性などを意識しながら作成する必要がある。なぜなら、場当たり的で散発的なテスト（モンキーテストなど）では、製品の品質を定量的に正しく評価することができないからである。

　基本的にテスト手順書は、個別業務要件定義書（業務仕様書）に基づいて作成していけばよいが、網羅的なテストケースを作成していくために、以下のようなポイントに注意するとよい。

• エンドユーザーがよくやってしまう「ありがちな異常系シナリオ」を追加する。
• グレイボックステストの観点を入れてテストケースを追加する。
• よくある不具合やバグ一覧表を活用する。
• テスト手順書の作成方法を規定しない。

　これらについて以下に解説する。

A. ありがちな異常系シナリオの追加

　通常、業務設計担当者は「正常系にフォーカスしながら」個別業務要件定義書を書いていくことが多い。しかし実際のエンドユーザーは、「リセットボタンやウィンドウのクローズボタンを押してしまう」、「誤ってリターンキーやバックスペースを入力してしまう」、などのように、異常動作を引き起こすような操作を行うことが少なくない。想像力を発揮し、「エンドユーザーがついやってしまいそうな」異常系シナリオをたくさん追加することが望ましい。

B. グレイボックステストの考え方によるテストケースの追加

　結合機能テストはバイナリファイルを対象としてテストを実施するもの（＝ソースコードを見ないテスト）であるため、そのテストケース設計も、基本的にブラックボックステストの考え方のみに基づいて行われる。

　しかし、システムの主要コンポーネントの動作や仕組みを理解した上で、特に弱点となりそうな部分について重点的にテストケースを追加することは極めて有効である。このような、（ソースコードを直接見ることはないものの）アプリケーションアーキテクチャやシステムアーキテクチャを理解した上でテストケースを考えていく方式を、グレイボックステストの考え方と呼ぶ（図 5-6）。

図 5-6　グレイボックステストの考え方

　具体的なテストケースの追加例を挙げよう*173。

• このアプリケーションでは、データアクセス部分にテーブルアダプタを利用せず、自力でのADO.NETのコーディングを行っている。
  
  
  • この場合、パラメタライズドクエリの利用がずさんになっている可能性がある。入力値として ' （アポストロフィ）を利用し、SQL挿入脆弱性を使った不正動作を誘発できないかを確認してみるのがよさそうである。

• このアプリケーションでは、データの受け渡しに型付きデータセットを利用している。
  
  
  • データセットを利用したアプリケーションでトラブルを引き起こしやすいポイントとしては、0件データの取り扱い（中身が空のデータセットインスタンスを使うのかnullを使うのか）や、大量データの取り扱い（データセットが巨大化するとプロセス間での引渡しに時間がかかる）などが挙げられる。これらのトラブルを誘発するような入力パラメータを考えてみる。

• このアプリケーションは、ユーザーから受け付けたアップロードファイルをディスクに書き込んでいる。
  
  
  • アップロードするファイル名として不正な文字列を指定することで、不正動作を引き起こせないかを考えてみる。

• このWebアプリケーションでは、ブラウザ内からXMLHttpRequestオブジェクトを使って非同期にWebサーバーに要求を投げている。
  
  
  • サーバーからの応答を受け取れなかった場合や、二重にボタンをクリックした場合に、不正動作を引き起こせないかを考えてみる。

*173 ここに採り上げたものは結合機能テストというよりはセキュリティテストの内容に近いものであるが、分かりやすいためここで例として使うことにした。。

　このように、グレイボックステストでは、以下のような点に注意したテストケースを考えることになる。

• テストケース設計時に、コンポーネント間の連携処理や協調動作に関わる部分を意識する。
  
  
  • 信頼境界の端点となる場所や、データチェック、フォーマット変換を行っている場所などで、不正動作を誘発するような入力データを考える。

• アーキテクチャ的な観点から危険な点をテストケースとして意識する。
  
  
  • 長時間処理になりかねないバッチ処理的な業務、デッドロック発生の危険性が疑われる業務、データアクセス順序ルールにそぐわなさそうな処理、などの有無を意識する。

　グレイボックステストは定型化されたやり方ではないが、この考え方は、ブラックボックステストの考え方に基づいたテストケース設計の精度を高めるためのテクニックとして非常に役立つものである*174。

*174 実際には、ベテランテスターであれば、ブラックボックステストの考え方に基づいてテストケースを設計している場合であっても、内部設計や実装をある程度推測・理解しながらテストケースを洗い出していることが多いだろう。

C. よくある不具合やバグ一覧表の活用

　結合機能テストのテストケース設計（テスト手順書作成）においては、ブラックボックステストやホワイトボックステストの考え方に基づいてゼロからテストケースの洗い出しを行うよりも、「よくある不具合やバグの一覧表」を作っておき、それに基づいてテストケースを設計していく方が、効率的かつ手っ取り早いこともある。

　例えば、0より大きな整数値を入力することができるとされているテキストボックスを考えてみていただきたい（図 5-7）。この場合、どのような入力値をテストケースとして使えばよいだろうか。

図 5-7　テキストボックスへの入力値

　もちろん、同値分析・限界値分析などの考えに基づいて入力値を1つずつ洗い出していくのもよいだろうが、以下のような「テキストボックスに対するよくある入力値や操作の例」を参考にしてテストケースを考えてしまった方が圧倒的にラクな場合も多いだろう。

• 空文字、文字列、2バイト文字や4バイト文字*175を含む文字列、マイナスの値、ゼロ、小数値、先頭に0をつけた値、指数表記された数値、16進数表記された数値、Int32.MaxValueより大きい数値、Int32.MinValueより小さい数値、カンマやスラッシュをつけた数値、他の国の方式で表記された数値*176など。

• テキストボックスの入力値制御、Tabキーによるフォーカス制御、Enterキー押下時の挙動、マウスのダブルクリックなど。

*175 JIS第3水準や第4水準の漢字などのこと。Windows Vistaで利用可能になったこれらの文字の中には、Unicodeの1文字をUTF-16でエンコードした際に（2バイトではなく）4バイトになるものがある。

　

*176 整数値の表記方法は国ごとに異なる。例えば日本やアメリカでは12,345,678.90123（小数点はピリオド、整数部は3桁ごとにカンマ）などのように表記されるが、カナダやフランスでは12 345 678,90123、スイスでは12'345'678.90123、イタリアでは12.345.678,90123などのように表記される。

　このような情報は、テストチームのノウハウとしてExcelシートなどにまとめておくと便利である*177。

*177 このような情報がまとめられた書籍もある。例えば、『基礎から学ぶソフトウェアテスト』付録：よくあるソフトウェア不具合、Cem Kaner, Jack Falk, Hung Quoc Nguyen著、日経BP社

D. 開発標準書におけるテスト手順書の作成方法の規約

　網羅的なテストケースを考えていく際に注意していただきたいポイントとして、開発標準書におけるテスト手順書に関する規約の問題がある。これについても解説しておこう。

　一般的に、大規模なアプリケーション開発では各種の開発標準書が作成されるが、こうしたものの中に、テスト手順書（テストケースドキュメント）の作成規約を定めているものがある。このような規約類は、協力会社などへの開発依頼では必要になるものの、作り方を誤ると大きな問題を引き起こすことがある。

　特に注意すべき点は、開発標準書の中で、テストケースの設計方法やテストに関する数値目標を具体的に定めるべきではない、ということである。例えば、以下のような規約を開発標準書の中で定めることは避けた方がよい。

• 同値分析・限界値分析によるブラックボックステストを必ず行うこと。
• C0カバレッジが90%以上になるまでテストすること。

　こうした規約を作成すると、テストチームが「定められているテスト」しか実施しなくなったり、見かけ上の数値がよくなるようにテストケースを設計したりしてしまう。その結果、テストチームの自主性や柔軟な発想力が阻害され、本来的な目標である「アプリケーションの品質確保」が達成できなくなってしま*178。

*178 そもそも「このような手順を使えばアプリケーションのバグを十二分に摘出できるようなテストケースを設計できる」といった万能な手法があるのなら、今、我々がこうしてテストケース設計に苦しんでいるようなことはないだろう。開発標準書でテストケース設計の「やり方」そのものを規定するのは、そうした「銀の弾丸」「魔法の杖」を作り出そうとするようなものである。

　テスト手順書に書くべき項目（表 5-1）や、テスト手順書の執筆例（表 5-2）を示すことは重要だが、テストケース設計の方法を定めること、すなわちテスターの創意工夫を奪うようなことは極力避けた方がよい。

　もしテストに関して何らかの規約や規定が必要であるなら、SLA（Service Level Agreement、サービス品質保証制度）的な発想で縛りをかける方がよい。例えば、過去の運用実績に基づいて、許容される残存バグ数を定義したりするとよいだろう*179。

*179 この際、過去の実績データとして、目標達成の目安となるテスト密度やカバレッジ率などを「参考データとして」提示するとよいだろう。すなわち、「過去の実績では○○ぐらいのテスト密度で○○件ぐらいのバグが残存していた」という情報を「目安」としては示すが、「○○のテスト密度でテストケースを設計する」というルールを作ることはしない。ルールとしてはあくまで「次工程での残存バグが○件以下になるようにテストを実施する」といったもののみにする。

　以上がテスト手順書作成のポイントである。引き続き、テスト実施計画の作成のポイントについて解説する。

INDEX
	Microsoft Visual Studio 2005によるWebアプリケーションテスト技法
	第5章 テストチームによる結合機能テストの実施
	1. テストチームによる結合機能テストの概要
	2. テスト手順書の作成のポイント
	3. テスト手順書作成に関するTips & Tricks

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）