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

Page1 Page2 Page3

本コーナーは、.NET関連の新刊書籍から主要なチャプターをそのまま転載し、その内容を紹介するものです。 　今回は日経BPソフトプレス／マイクロソフトプレスより2007年4月2日発行の書籍『Microsoft Visual Studio 2005によるWebアプリケーションテスト技法−Visual Studio テスト ツールを用いた業務アプリケーションの実践的テスト手法』より、同社の許可を得てその内容を転載しています。 　本書は、大規模Webアプリケーション構築の実践的テクニックを網羅した『.NETエンタープライズWebアプリケーション 開発技術大全』シリーズ全5巻、そして、Visual Studio 2005（ASP.NET 2.0）の新機能を活用したアプリケーション設計についてまとめた『Microsoft Visual Studio 2005によるWebアプリケーション構築技法』の著者であるマイクロソフトのコンサルタント赤間氏による新刊書籍です。既刊の書籍はいずれも開発者のバイブル的な存在になっています。 　本書では、Visual Studio 2005 Team Systemに搭載されているテスト機能を活用して、単体、結合、性能テストを行うための実践的な手順について解説されています。システムが大規模／複雑になってくると、テストを漏れなく効率的に行うにはツールの活用とツボを押さえたテストが重要になってきますが、本書は.NETのアプリケーション開発において、その2点を確実にカバーするものです（テストの対象はWebアプリケーションとなっていますが、本書のテスト技法の大半は、ほかの.NETアプリケーションにもそのまま適用することができるはずです）。 また、チームによる開発／テストを前提としており、Team Systemを使って各チームが効果的に連携するためのポイントにも重点が置かれています。 　本稿は、同書の後半部分の最初である「第5章 テストチームによる結合機能テストの実施」の「5.1 テストチームによる結合機能テストの概要」および「5.2 テスト手順書の作成のポイント」の転載です。第5章では、結合機能テスト（いわゆる結合テストも含まれる）における手順書の書き方、Visual Studio 2005 Team Editionを使ったテスト項目の管理方法や、それに付属するWebテストツールによるテストの自動化方法などが解説されています。 　結合テストは、本書の前半部分で解説されている単体テストと比べて、テスト項目の洗い出しやテストの実施方法がより難しくなります。特にWebアプリケーション開発において、結合テストでの作業があいまいだったり、なかなか品質を上げることができないといった場合には、まずは本書の内容をまねてみるとよいのではないでしょうか。 　なお、書籍の詳細については書籍情報のページをご覧ください。

ご注意：本記事は、書籍の内容を改訂することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

　前章では開発チームが行うべき単体機能テストについて解説したが、開発チーム内でのアプリケーション開発とデバッグ作業がある程度進んだら、いよいよテストチームによる本格的なテスト作業を実施していくことになる（図 5-1）。

　テストチームが行うテスト作業は、結合機能テストとシステムテストに大別される。本章では、まず結合機能テストの実施方法について解説する*162。

*162 なお第3章にて解説したように、テストチームが利用するVisual Studio 2005のエディションは、Visual Studio 2005 Team Edition for Software Testers（VSTE/ST）またはVisual Studio 2005 Team Suiteである。以降の説明で特に断りのない限り、利用しているVisual Studio 2005のエディションはVSTE/STであるとお考え頂きたい（VSTE/STでは利用できず、Team Suiteでは利用できるような機能については、そのつど注記を加えてある）。

　

図 5-1　本章および次章における解説範囲

5.1 テストチームによる結合機能テストの概要

　テストチームによる結合機能テストやシステムテストを円滑に進めていくためには、開発チームとテストチームが効果的に連携できる環境を整えておくことが非常に重要になる。まずはこれについて説明しよう。

5.1.1 ビルドサーバーを介した開発チームとテストチームの連携作業

　開発チームとテストチームとの連携作業について、図 5-1から該当部分を抜き出して分かりやすく書き直したものを図 5-2に示す*163。

*163 なお、この図ではTFSを利用した場合を想定した作業フローを示したが、TFSを利用しない場合であっても、論理的にこれと等価な作業を行えるような仕組みが必要になる。

　

図 5-2　ビルドサーバーを介した開発チームとテストチームの連携作業

　具体的には、各チームは以下のような連携作業を行う。

• テストチーム
  
  
  • 開発チームが作成した特定のビルド（バイナリファイル）をドロップポイント*164から入手し、本番運用環境を模したテスト環境にインストールする。
    
    
  • テスト環境にて、テスト手順書などに基づいた計画的なテスト（結合機能テストとシステムテスト）を実施する。
    
    
  • テストの実施結果（各テストの成否）については、TFS上のテスト結果データベースにアップロードしてプロジェクトリーダーに報告する。
    
    
  • テスト環境で発見されたバグに関しては、開発チームへのフィードバックと修正依頼が必要になる。このため、テスト結果を基にバグ報告書を起票し、TFS上のバグ追跡データベースへ登録する。

• 開発チーム
  
  
  • テストチームからバグの報告を受けたら、バグ報告書に基づき修正作業を行う。
    
    
  • 修正作業を行ったコードをソースコード管理システムにチェックインしておくと、次のビルド（通常は翌日の日次ビルド）のタイミングで、バイナリファイルにその修正が取り込まれる。

*164 ビルドシステムにより作成されたバイナリファイルが、履歴と共に管理されているファイルサーバーのこと。

　上述したような、開発チーム→ビルド→テストチーム→バグ報告→開発チームによる修正→ビルド……というループをどんどん繰り返してアプリケーションのバグ出しと修正を行い、最終的に品質が安定したところで製品版として出荷する*165。製品出荷できるだけの十分な品質を持つか否かの判断は、TFS上に蓄積された以下のようなデータを「多面的に」分析することによって行う*166。

• ソースコードの総量（行数、LOC、Lines of Code）とその変化
• コードチャーン*167の変化
• テストケース密度（＝テストメソッドの総数／ソースコードの総量）
• 結合機能テストやシステムテストの実施結果
• 結合機能テストのコードカバレッジ
• 残存バグの総数やそれぞれの重大度

*165 開発チームとテストチームが、地理的にもネットワーク的にも組織的にも極端に分断してしまうような開発スタイルだと、このような頻繁なテストを実践することが難しい。特にテスト作業などで協力会社などの助力を得る場合には、どのような形態でテストを進めていくのがよいのかをよく検討することをお奨めする。

　

*166 品質評価分析では、単一の指標（メトリクス）に基づいた評価をしないことが重要である。例えば、コードカバレッジ率が高かったとしても、テストケース密度が低いようであれば十分なバグ出しが済んでいない可能性が高い。あるいはコードチャーンが減っていても、残存バグの中に重大度の高いものが多数残っているようであれば、修正難易度が高いためにコードチャーンが減っているのだと推定される。このように、複数のメトリクスを組み合わせた評価を行うことが重要である。

*167 前回のビルドから今回のビルドまでに追加／変更／削除されたソースコード行数のこと（チャーン（churn）とは「かきまぜる」の意味）。最初のうちは難易度の低い大量のバグが発見されるため、コードチャーンは大きくなる。しかしある程度難易度の低いバグ出しが終わってくると、少しずつコードチャーンは減ってくる。コードチャーンが一向に減らないようであれば、バグが大量に残留しているなど、何らかの問題がある可能性が高い。

5.1.2 テストチームによるテスト実施までの手順

　以上を基にすると、テストチームがテストを実施するまでの手順は、以下のようにまとめられる（図 5-3）。

• テスト対象となるビルドを決定する。
  
  
  • 通常は、BVT（Build Verification Test）*168の結果を基に、安定しているビルドをテスト対象として選択する。
    
    
  • より多くのバグが修正されている最新のビルドを常に利用することが望ましいが、ドロップポイントからの最新ビルドのインストール作業を頻繁に行うことは現実的には難しい。このため、テスト実施計画の中で、数日に1回、あるいは1週間に1回といった具合に、テスト期間中に最新版をインストールし直すタイミングを決めておくとよい。

• テスト環境のサーバーやクライアントに、ビルドされたアプリケーションを配置する。
  
  
  • テストチームは、アプリケーションを「エンドユーザーと同様のシナリオで利用して」その動作を検証する。このため、アプリケーションのソースコードは一切触らず、完成したバイナリファイルのみを利用する。

• テストシナリオ（テスト手順書）に基づいて、テストを実施する。
  
  
  • テスト計画とテストシナリオに基づいた、計画的なテストを実施する。

図 5-3　テストチームによるテスト実施までの手順

*168 BVTについては第2章の2.3.4 BVT（Build Verification Test）」の解説を参照のこと。

5.1.3 結合機能テスト時に利用できるVisual Studio 2005のテスト機能

　Visual Studio 2005 Team Edition for Software Testersには、結合機能テストの実施に役立つ、以下のような機能が備わっている。

• 結合機能テストを実施するための機能*169
  
  
  • 手動テスト
  • Webテスト（Webアプリケーションのテスト自動化機能）

• 結合機能テストの実施結果やバグを報告するための機能
  
  
  • テスト実施結果のアップロード機能
  • バグ報告書の起票機能

*169 なお、Windowsアプリケーションのテスト自動化機能は残念ながら備わっていない。Windowsアプリケーションのテストを自動化したい場合には、サードパーティ製ツールを活用するか、リフレクションを通した自動化などを行うとよいだろう。後者については以下の情報が参考になる。 "Test Run: Lightweight UI Test Automation with .NET", MSDN Magazine, January 2005, James McCaffrey, http://msdn.microsoft.com/msdnmag/issues/05/01/TestRun/

　これらの機能の中でも特に興味を惹かれるのは、Webアプリケーションのテスト自動化機能であるWebテスト機能であろう。しかしテストチームのゴールは、テストを自動化することやWebテストツールを利用することではない。「アプリケーションのバグを摘出し、品質評価に利用できるデータを揃えること」であり、そのためには網羅的かつ体系的にテストを実施する必要がある。そして、網羅的かつ体系的にテストを実施するためには、適切なテスト手順書の作成とテスト実施計画の作成が欠かせない。これは、結合機能テストやシステムテストを自動化するか否かによらない*170。

*170 第1章でも解説したが、例えばマイクロソフト社内でも、まず自動テストスクリプトを書く前にテストシナリオやテストケースなどのドキュメントが作成されている。

　本章では、まず本来的に重要な作業である、テスト手順書の作成やその実施計画の立て方などに焦点を当てる。そしてその後に、Webアプリケーションのテストの自動化機能について説明する、という手順で解説を進めていくことにする。

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

　

「BOOK Preview」

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