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

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

第一回目から第三回目までで、順序組み合わせテストとIDAU法の概要から具体例まで説明をしました。今回はすこし話を変えて、この技法を提案するに至った背景と技法の理論について説明したいと思います。

ゆもつよメソッドの簡単な解説
論理的機能構造図
仕様項目特定パターン
「他への反映」は副作用を確認するテスト
順序組み合わせテストの理論
まとめ

ゆもつよメソッドの簡単な解説

今回、本連載で紹介している順序組み合わせテストとIDAU法は、筆者が「入出力データの順序情報に基づくブラックボックステスト手法の研究」という論文にまとめた大学院での研究成果の1つです。この論文はダウンロード可能です。

筆者は、これまで、ゆもつよメソッドという、テスト分析とテスト設計をセットにした手法をいくつものテストの現場に適用してきました。本連載で紹介している順序組み合わせテストは、ゆもつよメソッドにてテスト設計で使う1つの技法になります。

ゆもつよメソッドのことを全く知らない人もいると思うので、簡単に触れます。

ゆもつよメソッドは、テストプロセス全般に適用する手法なのですが、テスト分析のやり方に特徴があります。テスト分析には、大きく４つのポイントがあります。

論理的機能構造
テストカテゴリ
ドキュメントフォーマットと実施順序のルール化
テスト条件（仕様項目）特定パターン

ゆもつよメソッドの4つのポイントついては、私のnoteに詳しい内容が書かれていますので参照してもらえればと思います。本連載の中では、順序組み合わせテストとIDAU法の背景となる「論理的機能構造」と「テスト条件（仕様項目）特定パターン」についてもう少し詳しく説明します。

論理的機能構造図

ゆもつよメソッドでは、テスト分析をする際に、テスト対象を機能セット（feature set）に分割して整理します。例えば、デジタルカメラには、「写真を撮影する」という機能セットがあります。この機能セットは、シャッターを押したことを受け付ける処理、撮影対象をキャプチャーする処理、撮影した画像を保存する処理などが連動して、写真撮影を実現しています。このような処理が集まってテスト対象の特徴として説明できるものが機能セットだと思ってください（連載の第二回でも機能セットについて言及しているので参考にしてください）。

図1 論理的機能構造

論理的機能構造は機能セット内の構造を想定してテストするための参照モデルであり、各要素（図1の「入力調整」など）は必要な仕様項目を見つけるためのガイドになります。

仕様項目とは、機能セットに属するタスク（タスクの定義は後述します）を綿密に定義したものです。例えば、音楽プレーヤーのサウンド設定にて「ボリュームは１から10の間で設定できる。0は消音であり、10は100デシベルであり、10デシベルずつ大きくできる」と定義したものが仕様項目です。

仕様項目は、JSTQBにてテスト条件と呼ぶものとほぼ同義です。以降、テスト条件のことは仕様項目と記すことが多くなりますが、同義だと思ってもらえればと思います。

仕様項目特定パターン

図１の論理的機能構造の左側に薄い赤色のラベルで示した、「外部観察できる仕様」と「内部に関わる仕様」に分類される「入力調整」「出力調整」「変換」「貯蔵」といった要素に分類できる仕様項目は、単一の処理結果を確認するテストで確認可能になります。これは、テスト実行時のデータ入出力パターンで全て特定が可能になるという仮説を立てて、その実証を大学院での研究の1つとして行いました。この説明はここでは割愛します。具体的に知りたい方は前述した論文を参照ください。

図1の薄い赤色のラベルで「機能組み合わせ」に分類される「サポート」と「相互作用」に分類できる仕様項目に関しては、単一の処理ではなく、内部的に他の処理の呼び出しをして、他の処理の結果をテスト結果で確認しているため、呼び出しのきっかけを表1のように整理をしています。

表1 サポートと相互作用の仕様項目呼び出し方法

きっかけ	割り込み	リソース共有	他への反映	他処理連動
サポート	○			○
相互作用		○	○

本連載で紹介している技法である順序組み合わせテストは、表1の「他への反映」に分類される仕様項目に対するテスト設計に使う技法として提案したものになります。図2では、図1の論理的機能構造の機能組み合わせと表1の呼び出し方法の他への反映が対象である、「データベースを内部に持つことが多い業務系の情報システム（前回のまとめで言及）」に適したテスト技法であることを図示しています。

図2 論理的機能構造と順序組み合わせテスト技法の関係

「他への反映」は副作用を確認するテスト

「他への反映」へ分類した仕様項目を確認するテストは、連載の初回で示した図3で説明できます。この図では、上部に「入力→処理1→出力1」と記載されています。これは、単一の処理結果を確認するテストをイメージしたものになります。図3では、単一処理に対するデータの入出力の副作用として内部のデータ1がデータ2になっていることを表現しています。例えば、処理1のテストをするために、入力1を与えて、出力1を確認するとします。ただし、この確認だけでは、データ1からデータ2へ変化しているかといった副作用は確認できません。この確認をする際には、副作用によって変更されたデータ2を事前条件とする処理2を動作させて、出力2が期待通りになることで確認が可能になります。

図3 順序組み合わせテストで確認していること

このような確認が「他への反映」に分類されるテストになります。そして、他への反映に分類されるテストを設計する技法として、順序組み合わせテストという技法を提案しました。

順序組み合わせテストの理論

それでは、順序組み合わせテストの理論を説明していきます。順序組み合わせテストは、「副作用を理解することが変更波及を確認するテストに使える」という考え方に基づいています。説明の前提として、理解しておいてほしい用語を表2にまとめました。

表2 　順序組み合わせテスト技法のために理解しておいてほしい用語

日本語名	英語名	略称	変数	概要
タスク	Task	Ta	i	入力から出力への処理　ie.変更タスクと波及タスクを含む
源泉	Source	So	k	テスト対象の外部にある、テスト対象とのデータ入出力もと
データストア	DataStore	Ds	j	テスト対象の内部に持っているデータ　ie.保持データを含む
状態	State	St	l	タスクの実行を制御するデータ変数の集合、または外部制約
変更タスク	–	P{Ta}	–	順序組み合わせテストにて最初に動作させるタスクの集合
保持データ	–	P{Ds}	–	変更タスクで操作され、波及タスクで使われるデータの集合
波及タスク	–	S{Ta}	–	順序組み合わせテストにて２番目に動作させるタスクの集合

図4は、変更：Qが入ることにより、変更タスクのリビジョン：Rが一つ繰り上がってR+1となり、波及タスクのリビジョン:Rと変わっていることを表しています。

変更波及は、図4で示すように、変更タスクによる処理が内部に持っている保持データを介して波及タスクへ影響を与えます。保持データに対する操作は、「生成:C」「参照:R」「更新:U」「削除:D」の4つです。保持データを介して変更波及が発生するのは、例えば、変更タスクにおいて「生成:C」あるいは「更新:U」が行われ、変更が入った保持データに対して波及タスクによる「参照:R」が行われたときです。

保持データのライフサイクルで「生成:C」「参照:R」「更新:U」「削除:D」を行う操作は，無条件に行われるのではなく、データを操作するタスクの制御フローに沿って行われます。制御フローは、図4で示すように２階層として捉えることができます。上位の制御フローはタスクの実行順序により決定される大きな制御の流れに相当します。個々のタスク内の制御フローが下位にあたります。

図4 順序組み合わせテストの考え方

変更波及を確認するには、上位の制御フローで、波及した保持データを参照するデータフローに沿ってテストケースを抽出することになります。このテストケースの抽出方法を順序組み合わせテストと呼びます。

順序組み合わせテストでのデータフローを決定するのは、関係するタスクの実行順序とタスク内の制御フローであり、その制御フローを決定する際に状態が影響します。状態による制御が想定通りに行われない欠陥がテストで見つからない原因は、タスクの実行順序により決定される大きな制御の流れの判断のための状態の確認をするテストをタスク実行のあるタイミングでのみ行っている場合が考えられます。