変革の時代を迎えたソフトウェア産業
ー開発の手戻りをしないためにー

第10回
テスト環境とテストツール
日本アイ・ビー・エム株式会社
布川 薫

クライアント/サーバ・ システム開発のテスト環境

進化型のプロトタイピングやイン クリメンタル/イタラティブな方式 を用いるクライアント/サーバ・シ ステムの開発の場合、設計の早い段 階から本番と同等な開発環境下でビ ルド(リンク・エディットに相当) とテスト(動的テスト)が繰り返さ れる。

こうしたケースにおいてのマスタ ービルド(サブシステムやコンポー ネント全体のビルド)とその後のリ グレッション(回帰)テスト(統合テ ストに相当)は、テスト管理チーム の手によって、各開発チームの当回 分のローカルビルドとテスト(単体 テストに相当)が完了し、全体のバ ージョン管理環境下のデータベース へチェックインされたソースコード をマージする形で、通常、週1 回程 度のサイクルで行なわれる(図1 )。 マスタービルドの頻度は、その後 のテスト全体の進捗度合いに応じ て、3 日に一度、あるいは、隔日に 一度といった具合に増えていく。ク ライアント/サーバ開発において は、テスト環境やテスト体制につい ても、これまでからの大きな変化が 要求されてくる。

テストツールの選定

昨今においては、様々な機能を持 ったテストツールが存在している が、これらの多くのツールが他のテ ストツールや開発ツールとの連携機 能を強化している。例えば、上流 CASE ツールから設計情報を読み込 んでテストケースを生成したり、開 発ツールと連携してデバッグ機能を 提供するものなどで ある。今日、いくつ かのツールベンダか らは、“テスト管理 ツール”、“リグレッ ション・テストツー ル”、“パフォーマン ス解析ツール”など を組み合わせたテス ト・スイート(Test Suite )と呼ばれる 製品群が提供されて いる。テスト・スイ ートに含まれる各ツ ールは、互いに連携して“テスト管 理ツール”で作成したテストケース をもとに、“リグレッション・テス トツール”でテスト・スクリプトを 作成し、それを“パフォーマンス解 析ツール”から実行させるといった ことが可能になる。また、テスト・ スイートにはテスト結果の分析のた めのツールが用意され、テスト結果 をもとに、分析やレポート作成を容 易に行うことも可能である。

クライアント/サーバのシステム 開発においては、ツール選定の適否 がプロジェクトの成功のカギを握っ ているといっても過言ではない。そ のため、開発規模、要員のスキル、 アプリケーションの性質などを十分 考慮にいれて、プロジェクトの初期 段階から最適なツールを慎重に選択 することが重要となってくる。プロ ジェクトの立ち上がり時点において は、各社のナレッジベースとして提 供されるツール情報等を十分に活用 し、最適なツールの選択を行うこと に最善の努力を払わなければならな い。

テストツールの機能

クライアント/サーバ・システム の開発では、効率よく開発/テスト を実施できるツール、特に、テスト 自動化のためのツールを積極的に選 定し活用していくべきである。一口 にテストツールといっても、その目 的や使用される段階によって様々な 種類があり、実際のアプリケーショ ン開発ではそれらを適切に組み合わ せて使用する必要がある。図2 に、 機能別にカテゴリ分けをしたテスト ツールと、そのツールが主に使用さ れるテスト段階の対応を示した。

@プロトタイピング・ツール

開発の早い段階からプロトタイピ ングを行って、システムに対する要 求を確定させることで、要件の理解 の誤りや仕様の不確定に起因する手 戻りの発生を防ぎ、最初から高品質 なアプリケーションの開発を行うこ とが可能となる。現在のクライアン ト/サーバ開発では、インクリメン タルな開発や進化型のプロトタイピ ングの採用が主流となっており、そ の意味では、使いやすく拡張性に富 む適切なプロトタイピング・ツール を選定することは、品質管理の重要 なチェック・ポイントとなる。

A静的テストツール

プログラムを実行せずにソースコ ードを直接解析して、文法エラーの チェックやプログラム構造の解析、 コードの複雑度の判定などを行うツ ールである。コード解析の結果をも とに、プログラム構造図や関数クロ ス・リファレンスなどのドキュメン トを生成することも可能である。ま た多くの静的ツールは、次に述べる 動的テストツールと連携して、プロ グラムの未テスト部分の検出など、 テスト・カバレッジ(テスト網羅率) の情報の取得を行うことができる。


B動的テストツール
動的テストは、プログラムを実際 に実行させて、その動作やパフォー マンスを検証するテスト方法であ る。動的テストツールのうち、“リ グレッション・テストツール”は、 ユーザの画面操作をテスト・スクリ プトの形式で記録し、それを繰り返 し実行して所定の動作が行われるか をチェックする。ユーザのインタフ ェースや機能が固まらない段階でテ スト・スクリプトを作成してしまう と、その後に追加・修正される機能 をスクリプトに反映する手間がかか り、テスト効率が上がらないのが常 であるので注意が必要である。

動的テストツールのうちの“パフ ォーマンス解析ツール”には、プロ グラムを実行して関数ごとの処理時 間を測定してプログラムのボトルネ ックを特定する“プロファイラ”や、 複数クライアントからのサーバへの アクセスを仮想的に発生させてサー バ・アプリケーションの動作やパフ ォーマンスを測定する“負荷テスト ツール”などがある。

Cテスト管理ツール

インクリメンタルやイタラティブ な方式をとるアプリケーション開発 では、複数の開発チームによって 「設計→開発(実装)→テスト」の サイクルが繰り返される。あるチー ムで発生した欠陥やその修正結果が 他の開発チームに影響を及ぼすこと を防ぐために、“バージョン(構成) 管理ツール”を用いてソースコード を管理しておく必要がある。各開発 チームは、バージョン管理データベ ースからソースコードをチェックア ウトし、必要な追加/修正を加え、 チーム内でローカルビルドと再テス トを行う。この段階で、新たな欠陥 が見つからなければ、再度バージョ ン管理データベースへチェックイン する。こうして作成されたソースコ ード全体は、マスタービルドとして マージされ、リグレッション・テス トとパフォーマンス・テストが行わ れる(図3 )。

なお、テスト管理中の問題管理や 変更管理などについては、グループ ウェアや専用の管理ツールを利用す れば、従来の紙ベースのプロセスな どと比較して、プロジェクト情報の 共有化という面で大きなメリットが でてくる。

テストツールや テスト体制への課題

現在、中小規模のシステム開発プ ロジェクトでは、まだまだテストツ ールを十分に活用しているとは言い がたい点もある。これは、導入効果 が本当にあるかどうかもはっきりし ない高価なテストツールを、最初か ら各プロジェクトごとに購入するこ とがコスト的に困難であることや、 それらのツールを有効に活用するた めのスキルを身につける時間的余裕 がないことなども大きな原因と考え られる。こうした問題を根本から解 決するためには、プロジェクトとは 独立した形でテストに高いスキルを 持つ専門的チームを組織的に育成 し、そのチームがテスト作業を専門 に請負うような体制も考慮する必要 があろう。これによって、テストツ ールを複数のプロジェクトで共用し て全体コストを抑えることができ、 同時に、スキル不足の問題も解決で きる。今後は、こうしたテストや品 質に係る専門的な組織形態の構築に ついて実践レベルで検討していくこ とも、重要な課題となってくる。

次回は最終回として、これまでに 解説してきた品質管理についてまと めてみる。

布川 薫(ぬのかわかおる)
1973 年日本アイ・ビー・エム鞄社、現在、サービス事業、コンピテンシーに所 属し、アプリケーション開発方法論やプロジェクト管理技術などを担当。副主管 IT スペシャリスト(次長)。プロジェクトマネジメント学会評議員・研究委員会 委員。
おもな著書に、『システムの開発と運用』、『アプリケーション開発技術』(いずれ も共著、リックテレコム)