【第2回】バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？

テスト設計をする際には、テスト技法を使うことで、効率的に効果的なテストケースを作ることができます。今回、本稿で紹介する技法となる「順序組み合わせテスト」と「波及全使用法：IDAU法」は、バージョンアップ開発や派生開発などで、テスト対象に変更が入ったときに役立つテスト技法です。本稿を読んだみなさんに現場で適用してもらいたいと考えているため、連載形式で具体例も織り交ぜてわかりやすく紹介していきます。連載は全部で8回を予定しています。前半の4回はこの技法の特徴や具体的な使い方を湯本から説明します。連載の後半では、後続研究として取り組んだ内容を武田から説明します。
第二回目となる今回は、順序組み合わせテストによるテスト設計の手順とルールを説明していきます。

順序組み合わせテストのテストベース
順序組み合わせテストの技法適用手順とルール
まとめ

順序組み合わせテストのテストベース

順序組み合わせテストによるテストケース抽出時の手順とルールを説明する前に、この技法の入力情報として必要になるテストベースを図1に示します。

■機能セット

テストアイテムとなる機能セット（feature set）をテスト対象全体から識別します。機能セットは複数の処理で実現しています。この処理のことは、以降、タスクと呼びます。テスト設計には、識別した機能セットに該当するDFD、ER図、CRUD図を使用します。

■DFD（データフローダイアグラム）

DFDはシステムにおけるデータの流れを表現した図です。DFDの構成要素は、図1に示す通り、源泉（Source）、タスク(Task)、データストア（DataStore）です。この技法のテストベースとして用いる場合、テストの範囲は利用するDFDで決まります。

■ER図（ERダイアグラム）

ER図はシステムにおけるエンティティ間の関係を示す図です。DFDでは表現できないエンティティの詳細化やエンティティ間の関係について示しています。技法適用手順の中ではER図は出てきませんが、実際にはDFDやCRUD図の理解を補うために重要な情報になります。

■CRUD図（CRUDダイアグラム）　

CRUD図とは，タスクからデータストアへの「生成:C」「参照:R」「更新:U」「削除:D」の操作を示した図です。CRUD図から，DFDとER図では表現されていない、タスクによるエンティティへの操作を知ることができます。ここでは、タスクがデータストアに対して行う操作を特定するためにCRUD図を用います。

順序組み合わせテストの技法適用手順とルール

順序組み合わせテストでは、テスト対象となる機能セットの外から入るデータを処理するタスクを対象にしています。対象となるタスクを「変更タスク」「波及タスク」と呼び、それらは上記したテストベースで明らかにします。そして、明らかにしたタスクの処理順序と、その時のデータの操作をCRUD図から特定して、テストが必要な順序組み合わせを見つけていきます。処理の順序は、変更タスク（テスト対象なるメインのタスク）でのデータに対する操作を最初に行い、波及タスク（同じデータを使って処理をする後続のタスク）を次に操作するという順番で組み合わせます。

変更タスクの特定

技法適用手順として最初に行うのは、変更タスクの特定です。変更タスクとは、テスト実行をする際に実際にテスト担当者が操作するタスクであるため、テスト対象となるメインのタスクと言えます。変更タスクは、以下の3つの条件を満たしているタスクです。

機能セットの外から入るデータを処理している
仕様変更や不具合修正、機能拡張といった理由でコード修正がされている
データストアにデータの書き込みをしている

変更タスクは、DFDで表すと、図2のように表現できます。機能セットの外部からの入力元（DFDにて源泉と呼んでる要素）を図2では「So1」と示しています。変更タスクは「Ta1」「Ta3」と図2で示した要素であり、複数の変更タスクをまとめた変更タスク群を「P{Ta}」と示しています。データの書き込み先を「Ds1」「Ds2」と示してあり、複数のデータの書き込み先をまとめたデータストア群を「P{Ds}」と示しています。

明らかにした変更タスクは、拡張CRUD図に記載していきます。拡張CRUD図は、この技法のために考案したCURD図で、テストベースとして与えられたDFD，ER図，CRUD図から変更タスク群とデータストア群の関係を表現できるようにしたものです。

表1 拡張CRUD図（変更タスクに関係あるもののみ記載）

タスク	データストア			源泉
タスク	Ds1	Ds2	Ds3	So1	So2	So3
Ta1［St1］	CU			In
Ta2［St1］
Ta3［St1］		C		In
Ta4［St1］
Ta5［St1］

拡張CRUD図には，タスクの源泉からの入力(In)があることを記載します。変更が特定の状態でのみ起こり得る場合は，タスクの後に変更が起きる状態を［St］と記載します。特定した変更タスクに対する入力となる源泉にInを記入し、データストアへはCRUD図を参照して「生成:C」「更新:U」「削除:D」もしくは、その組み合わせかを記入します。この段階の拡張CRUD図として例示した表1では、2つのタスクが変更タスクで、源泉とデータストアのセルに記載があります。この段階で作成する拡張CRUD図は，作業途中のものになります。

波及タスクの特定

テスト設計の次の手順は、波及タスクの特定です。波及タスクは、以下の条件を満たしているタスクです。

図3のように、データストアに対する操作があり、源泉に出力がある
表2の基準と合致する組み合わせである

変更タスクと波及タスクを合わせて図示したものが図3になります。「Ta2」「Ta5」と書かれた要素が波及タスクであり、複数の波及タスクをまとめた変更タスク群を「S{Ta}」としています。ただし、図3のように示せるタスクが全てこの技法で網羅する変更タスクと波及タスクの組み合わせとはなりません。この技法では、「組み合わせのカバレッジ基準」をルールとして決めており、表2に示す内容で組み合わせのテストをするかどうかを決めます。

表2にて、「○」をつけた組み合わせはIDAUカバレッジを網羅するためにテストが必要な組み合わせです。「 – 」をつけた組み合わせは、データストアを介した影響が生じないため、IDAUカバレッジの対象としません。「×」をつけた組み合わせは仕様上ありえない組み合わせであり、ありえないことの確認は「順序組み合わせテスト」技法でなくともテストできるため、IDAUカバレッジの対象としません。

表2　タスク間のデータ共有組合せパターン

		変更タスク群
		C：生成	R：参照	U：更新	D：削除
波及タスク群	C：生成	×	×	×	◯
	R：参照	◯	–	◯	–
	U：更新	◯	–	◯	×
	D：削除	◯	–	◯	×

表2のパターンに該当する波及タスクに関する記述を拡張CRUD図に追記します。波及タスクにてテスト結果を確認するため、源泉への出力(Out)があると記載します。この完成した拡張CRUD図が表3になります。

表3 拡張CRUD図（波及タスクまで記載済み）

タスク	データストア			源泉
タスク	Ds1	Ds2	Ds3	So1	So2	So3
Ta1［St1］	CU			In
Ta2［St1］	R				Out
Ta3［St1］		C		In
Ta4［St1］
Ta5［St1］		RU				Out

組み合わせの特定

表3の拡張CRUD図から変更タスクと波及タスクの組み合わせを特定します。同じデータストアに対してCRUDの記載がある2つのタスクで、源泉にInと書いてあるものが変更タスク、Outと書かれているのが波及タスクになります。表3の例であれば、Ds1にCRUDの記載があるTa1とTa2、Ds2に記載があるTa3とTa5が該当する組み合わせになります。

そして、データストアに対する操作の組み合わせを特定します。表3の拡張CRUD図の例であれば、変更タスクのデータストアに対する操作であるTa1は、Ds1に対してCとUを行っています。そして、波及タスクTa2の操作はRです。データへの操作の組み合わせはC→RとU→Rとなります。表3の例における全組み合わせは表4にまとめたとおり、４パターンとなります。

表4　変更タスクと波及タスクの組み合わせ

No	変更タスク	波及タスク	テスト対象の仕様項目
1	Ta1	Ta2	Ta1でC：生成をした後、Ta2でR：参照する
2	Ta1	Ta2	Ta1でU：更新をした後、Ta2でR：参照する
3	Ta3	Ta5	Ta3でC：生成をした後、Ta5でR：参照する
4	Ta3	Ta5	Ta3でC：生成をした後、Ta5でU：更新する