ホワイトペーパー V2.0 2018-01
目次 1 はじめに...3 2 従来型のソフトウェア開発...3 3 テスト主導型開発...4 4...5 5 TDD を可能にするテストオートメーションツールの主要機能...5 5.1 テストケースとソースコード間のトレーサビリティー...5 5.2 テストケースと要件間のトレーサビリティー...6 6 テスト主導型開発の例...7 2
1 はじめに 本書では テストオートメーションツールと VectorCAST/C++ を併用して アジャイルプログラミング環境でテスト主導型開発 (TDD) をサポートする方法について説明します 本書は テストオートメーション製品の基礎知識があることを前提としています 2 従来型のソフトウェア開発 現在 ほとんどのプロジェクトはテストオートメーションツールを従来型の開発環境で使用しています このような環境では VectorCAST/C++ の各クラスが開発時に単体テストされます この純粋な単体テストでは あるユニットに属するローレベルの要件が正しく実装されているかどうかを確認できると同時に コードカバレッジ分析によってテストの完全性を検証できます 図 1: 従来型のソフトウェア開発 - ウォーターフォール方式 この時点でコードがすでに作成済みのため この作業方法には次のようなさまざまな問題が生じます > コードを作成してから そのコード内の潜在的欠陥が特定されるまでに ( 数週間とは言わないまでも ) 数日かかってしまう > 要件から単体テストが直接導き出されるのではなく 開発者が作成したコードに基づいて単体テストを作成してしまう > コードがオーバーエンジニアリングされ プロジェクト要件を満たすのに必要以上のコードを作成してしまう このような問題があると コードに関する潜在的問題の特定がプロジェクトライフサイクルの終盤にずれ込んでしまいます 欠陥が組み込まれてから その欠陥が最終的に検出 修正されるまでの所要時間が長いほど 欠陥の修正にかかるコストが増えることは良く知られています ( 図 2 を参照 ) 図 2: ソフトウェア開発ライフサイクルにおける欠陥の修正コスト 3
この問題の一般的な解決策は コード検査やコードの静的分析を導入することです しかしながら コード検査はコストが高く 複合アルゴリズムやシステム動作を検証する場合は検査が複雑になる可能性があります 一方 静的分析は 記述コードに曖昧さがないかどうかを検証するだけで コードが実際に正しいかどうかは検証しません さらに 検討すべき重要な点がいくつかあります 1. 大半のエラーは 範囲がかなり限られている 80% のエラーは プロジェクトの 20% のクラスまたはルーチン内で検出される (Endres 1975, Gremillion 1984, Boehm 1987b, Shull et al 2002) 2. 一般的なエラーの大半は プログラマーの間違いから起こる エラーの 95% はプログラマーが原因であり システムソフトウェア ( つまりコンパイラーや OS) によるエラーは 2% 他のソフトウェアによるエラーは 2% ハードウェアによるエラーは 1% しかない (McConnell, Steve. Code Complete. Redmond: Microsoft Press, 2004) したがって プログラマーのソフトウェアを早くテストするほど システム内のエラーの大半を早く発見できることになります 3 テスト主導型開発 テスト主導型開発 (TDD) は プロセスの序盤に行われるテストケース開発のタイミングを設計作成後 ( ただしコードの記述前 ) にずらすことによって この問題を解決します TDD は 非常に短い開発サイクルを繰り返すソフトウェア開発プロセスです これにより設計がシンプルになり ソフトウェアライフサイクルの早い段階から確信が持てるようになります TDD のコンセプトはシンプルで 次の 3 ステップのプロセスに分けることができます 1. 開発者が 必要な機能改善または新機能を検証するためのテストケースを作成する このテストケースは その機能が正しく実装されるまでは不合格になります 2. 次に このテストに合格するコードを作成する 3. コードが合格したら 受け入れ可能な規格に合わせて新しいコードをリファクタリングする 図 3: テスト主導型開発のワークフロー これらのコンセプトは テストファーストプログラミング (1992 年に生まれたエクストリームプログラミングの中核要素 ) が基になっています ただし近年では テスト主導型開発だけで一般的なトピックとして扱われるようになりました これはさらに テスト主導型開発の 3 法則にまとめることができます 1. 不合格になる単体テストを作成するまでは 本番コードを作成しないこと 2. 不合格になるために必要以上の単体テストを作成しないこと ( コンパイルをしなければ不合格になる ) 3. 現在不合格になるテストに合格させるために必要以上の本番コードを作成しないこと 4
4 VectorCAST/C++ を テスト主導型開発 モードで使用する場合と 従来型の単体テスト で使用する場合の主な違いは TDD モードではテスト環境を構築するための入力として VectorCAST/C++ ヘッダーファイル (.h ファイル ) 群を使用する点です ソースファイルに関する要件はありません テスト環境の構築時には テストケースの作成対象となる VectorCAST/C++ ヘッダーファイルを指定した後 1 つ以上のヘッダーファイルをテスト対象ユニットとして選択するだけです その後は テストオートメーションツールによってテスト環境が構築されます 最初は使用可能なソースファイルがないため テスト対象ユニット内にメソッド用の空のソースファイルが作成されます これで 実行可能なテストハーネスが完成します この時点で テストオートメーションツールの他の機能はすべて 従来型 モードとまったく同じように動作するはずです 5 TDD を可能にするテストオートメーションツールの主要機能 テストオートメーションツールには テスト主導型開発プロセスへの適応を容易にする特性がいくつかあります 5.1 テストケースとソースコード間のトレーサビリティー TDD の主なコンセプトの 1 つは 実行された正確なコード行とテストケースを相関付けられることです これにより開発者は テストケースが実行されたことの証明に関連するコードのみを検証できます これを実現する最も簡単な方法は コードカバレッジを使用することです この場合 収集されたコードカバレッジと実行されたテストケースをツールで直接リンクすることができます ( 図 4 を参照 ) 図 4: テストケースとテスト対象の基本ソースコード間のトレーサビリティー 5
5.2 テストケースと要件間のトレーサビリティー テストケースの作成は 基本コードの開発前に行う必要があります テストケースと基になる要件をリンクする機能を使用すると テストケース 要件 検証対象コードの間に直接的なトレーサビリティーが得られます これにより TDD の 3 法則を守りながら コードのリファクタリングプロセスをごく簡単にすることができます ( 図 5 を参照 ) 図 5: 要件とテストケースのリンク 6
6 テスト主導型開発の例 新しいアプリケーションを構築し モジュールの 1 つにメッセージ処理機能を付けるとします 必要となる完全な機能はまだ不確かですが メッセージの送受信は確実に必要であり さらに各メッセージを可変数の 32 ビット整数値で構成する必要があります そこで まず単純な VectorCAST/C++ ヘッダーファイルを作成し メッセージを送信するためのプロシージャーとメッセージを受信するためのプロシージャーを定義します 次に例を示します // Message.h bool Send_Message( MessageIdType Message_Id, ByteSteam &MessageData, MessageSizeType MessageSize); bool Receive_Message( MessageIdType &Message_Id, ByteSteam &MessageData, MessageSizeType &MessageSize); テスト主導型開発では 次のステップとしてこれらのプロシージャーの実装詳細に進むのではなく これら 2 つのプロシージャーのテストケースを作成する必要があります この手法を用いる利点は コードの記述を始める前に 設計の詳細と周辺条件を検討できることです 次に このモジュールに対して作成すべきテストケースの例を示します > Receive_Message を呼び出すと メッセージが送信順に返されるか それとも ID に基づくメッセージの優先順位があるか > 受信時にどうなるか 保留のメッセージはないか > 送信可能なメッセージの最大サイズ Message_Size に最適なデータ型になっているか > Message_Id 値の範囲 > 無効な Message_Id を受信するとどうなるか これらすべての質問の答えが決まったら テストオートメーションツールを使用して コードを記述する前にテストケースを作成します 最初に作成するテストケースは不合格になりますが ここには 期待される動作を正式化する各関数の入力値と出力期待値が含まれます 各関数の実装はインクリメンタルに行うことができます コードを作成すると既存のテストケースが順次合格し 最終的にコードが完成すると すべてのテストケースが合格するはずです 7
詳細情報 次の情報については 弊社ウェブサイトをご覧ください > 最新ニュース > 製品 > デモソフトウェア > サポート > トレーニング > お問い合わせ www.vector.com/jp/ja/