 |
|
| 開発ライフサイクルとVisual Studio 2005という選択肢 |
第３回：Visual Studio 2005による開発とテスト環境
著者：日本ユニシス 鈴木 貴史 2005/11/15
|
|
|
| 前のページ 1 2 3 4
|
|
| テスト成果物の信頼性、充足度
|
単体・結合テストが十分でないと、後工程である統合テストやシナリオテストにおいて単体・結合テストレベルのエラーが出てしまいます。そうした場合に「開発担当者に差し戻して、バグの修正を待って・・・」となると、スケジュールに大きな影響を与えてしまいます。逆にすべてをテストコードに落とさせると、今度はそちらに工数がかかりすぎてしまいます。
つまりバランスを取る必要があります。そこでVSTE for SDの単体テストやコードカバレッジの機能が役に立ちます。
単体テストはVisual Studio 2003で皆さんが利用していたと思われるフリーソフトより、強力な機能です。自動生成されるスケルトンによって、例えば境界値チェックに関してはパラメータを変更するくらいで完成してしまいます。
コードカバレッジの機能はテストケースの充足度をざっと判断するのに有効です。こちらも今まではサードパーティーのアプリケーションを利用するしかなかったのですが、コスト面から開発者全員に配布するのは難しかったと思います。しかしコードカバレッジの機能によって一次的な判断を開発者自身に任せることが可能となり、効率的なチェックプロセスの確立が期待できます。
テストを実行可能な形で保存しておくことには、ほかにも利点があります。例えば、仕様変更などが発生し一部のロジックに変更を行った時に、「ほかの部分に影響が出ていないか」「正しく動作しているか」をテストしてみればすぐに確認が取れます。その点でも個々のテストケースを実行可能な形で管理し、必要な時に実行・確認できるということは大変有効といえます。
|
| 品質確保
|
機能要件に対する品質は単体・結合テストや統合テストなどを進めることによりおのずと修正がなされます。しかしながらテストが通ったからといって受入れの基準としては不十分です。アルゴリズム自体が非効率的であるとシステム全体のスループットに影響を与えます。また、メソッド名の命名などの整合性が取れていないと、後々の保守性を落としてしまいます（そして何よりかっこ悪い・・・）。
VSTE for SDは各種分析ツールが開発環境に統合されています。開発者自身がコーディングやパフォーマンス、およびセキュリティに関連する問題を検出することができます。特に静的コード分析は、今までソースコードレビューで行っていた多くの部分を、レビューを行う前に開発者自身によりコードの欠陥の発見・修正を可能とします。
また単体・結合テストアップの確認項目やソースコード管理のチェックインポリシーに組み込むことで、品質の確保を行うことが可能になります。開発ライフサイクルの前半に問題の修正が可能であるということは、コードの欠陥の修正にかかる全体的なコストの削減が期待できます。
|
| テスト成果物の一元管理
|
テストの種類・厳密さは、ソリューションによりそれぞれです。部門内のポータルサイトのソリューションと数十億のお金のやり取りを行う連携システムとでは要求される品質レベルが異なるのは当然でしょう。場合によっては独自のテストツールを自前で用意することもあるでしょう。
テストの種類が多様ということは、それぞれの連携・管理が難しくなります。VSTE for STでは単体テスト・Webテスト・手動テスト・負荷テストなどの様々な基本的なテストパターンが用意されています。汎用テストも用意されているので、独自のテストツールを用意した場合でも一元管理が可能です。それぞれのテストの進捗状況・バグの発生状況・収束状況をリアルタイムに把握できることは、過不足なく必要十分なテストを実行可能とします。
図8に個々の機能とプロセスの対応を示します。
図8：機能とプロセスの対応図 （画像をクリックすると別ウィンドウに拡大図を表示します）
|
| まとめ
|
VSTE for SDは開発、VSTE for STは第3者検証（確認）をターゲットとした内容になっており、チーム開発のロールを意識したエディションになっています。それではそれぞれの有効性について解説します。
|
| VSTE for SDの有効性
|
VSTE for SDはVisual Studio単体の機能アップに加え、今までフリーソフトやサードパーティ製のアプリケーションで補完していた、単体テスト・コードカバレッジ・静的コード解析・コードプロファイラの機能が加わり、使える人にとっては最強といっても過言ではない開発環境になりました。
特に静的コード解析は、既存のVisual Studio開発者が今まで通りの開発スタイルをVSTE for SDで行うだけで品質向上の恩恵を受けられる点がすばらしいと思います。
ほかの機能に関しては、明確にここが悪いといったことを指摘してくれるものではないので、プロセスエンジニアがうまく開発ライフサイクルに組み込んであげる必要があるでしょう。
例えばLUCINA for .NETではテストファーストを前提とし、単体テストコードの作成を義務づけています。その際、テストケースの充足判断が非常に難しかったのですが、開発環境にコードカバレッジの機能が提供されたことで、ある程度の目安が用意できると考えます。少なくとも事前に開発者自身に気づかせられるという意味で、論外といったレベルのチェックはなくなるでしょう。
コードプロファイラはパフォーマンスチューニングや何か問題が起こった際の原因究明に非常に有効です。しかしこれは開発者自身にゆだねるのはちょっと酷なので、アーキテクチャチームのメンバーで行うことになるでしょう。といってもやはりVSTE for SDは、簡単に効果を発揮しやすい製品だと思います。
|
| VSTE for STの有効性
|
VSTE for STは正しく使われれば非常に効果が期待できますが、むらも出やすいのです。十分な効果を発揮するためには、様々な注意が必要です。
例えば、一元管理するテストの数はそれなりの分量があります。複数の人間がアクセスする部分であり、探しやすく直感的に理解しやすい構成（フォルダ構成やファイル構成など）をとる必要があります。
またテスト担当者の「テスト → 開発者の修正 → 再テスト → ・・・」という連携を最大限に発揮するためには、すべての開発者とテスト担当者にテストプロセスを熟知してもらう必要があります。一部でも対応できなくなってしまうと進捗や収束率などのレポートも正確性を失ってしまうからです。
ここはプロセスエンジニアの腕の見せどころです。実際に作業を行う担当者の使い勝手を意識しないと現場から反発が出やすいからです。しかしVisual Studioと連携するテストツールが用意されたことにより、適切なテスティングフレームワークを用意することができ、テスト品質の平準化が期待できるでしょう。
VSTE for STはマイクロソフトの社内で使用されていた機能がベースであり、実際に実行されてきて効果があると判断されたモデルです。弊社でも効果的な使用方法を様々考えています。
|
| 次回は
|
今回はVSTE for SDおよびVSTE for STを開発ライフサイクルの観点で見てきました。次回は、チーム開発という観点でVisual Studio Team Foundation Server（図1のこれまで紹介してきた3つのVisual Studio Team Editionの土台となっている要素）を評価していきます。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
日本ユニシス株式会社 鈴木 貴史
.NETテクノロジコンサルティング所属
日本ユニシスグループの.NET技術主管のメンバーとして、Windows／.NET Framework周りの利用技術の開発から弊社受託開発案件のアーキテクト、時には営業支援、そして今回は執筆を行っています・・・
|
|
|
|
|
|
