ソフトウェア・シンポジウム2017 in 宮崎

変更における状態を含むテスト網羅尺度とテストケース抽出法の提案
湯本剛
筑波大学大学院
tsuyoshi.yumoto@gmail.com

松尾谷徹
デバッグ工学研究所
matsuodani@debugeng.com

津田和彦
筑波大学
tsuda@gssm.otsuka.tsukuba.ac.jp

要旨

は，時代と共に課題を難しくしている．ソフトウェアの多様化と複雑化，再利用範囲の増大などから変更波及のソフトウェアの一部に変更を加えた場合，その変更の範囲が拡大し，かつ安易な変更による弊害など課題が山波及を探る変更波及解析（Change Impact Analysis）は積している．これらの課題に対してソフトウェア工学は実務上の大きな課題である．産業界において，変更にか十分な解を提供できていない状況にある [2]．

かる活動は新規開発よりも大きな割合を占めている．ソ

本論文では，状態遷移を持つソフトウェアにおいて，

フトウェアの多様化，複雑化，再利用範囲の増大などか変更波及がデータベースや外部変数などの保持データ

ら変更波及の範囲が拡大し，かつ安易な変更による弊害

を介して生ずる場合のテストについて考える．課題の一など課題が山積している．本論文では，変更波及のうち，つは，網羅基準である. データフローテストの全使用法

状態遷移を持つソフトウェアにおいて，変更波及がデー（AU 法）[3] を基にして, 変更波及のテスト網羅基準をタベースや外部変数などの保持データを介して生ずる場

波及全使用法（IDAU:Impact Data All Used）として提合のテストについて取り上げ，テスト網羅基準とテスト

案する．もう一つの課題は，IDAU 法を満たす具体的な設計手法を提案する．具体的な例を使って手法の適用可

変更波及のテストケースの抽出方法である. 変更波及の能性を確認し，テストケースの数を他の手法と比較し合テストの設計手法として, 順序組合せテストを提案する．

理的であることを示す．

最後に，ここで提案する IDAU 法のコストの評価、すな
わちテストケースの数を従来技法である状態遷移テストの S1 網羅基準と比較をして考察を行い, 提案する方法が

1. はじめに合理的であることを示す．

ソフトウェアの一部に変更を加えた場合，その変更の

2. 変更波及とその解析波及を探る変更波及解析（Change Impact Analysis）は，
実務上の大きな課題である．産業界において変更にかか

本節では，提案する網羅基準やテスト設計手法の前提る活動は，新規開発よりも大きな割合を占めている．ゼとなる，システムの構成と変更について定義し，変更波

ロから新規にソフトウェアを開発するケースは稀であり，及テストの課題について詳細を示す．

何らかの流用を基に変更を加える開発が主流となっている．開発方法においてもアジャイルが主流となり，変更

2.1. 対象とするアプリケーションの構成の積み重ねによって開発が行われている．
しかし，変更波及を合理的に制御する技術は，ソフト

一般的にソフトウェアは，入力 In に対して，何らか

ウェア工学とって未完成の分野である [1]．変更の背景の出力 Out を返す．ソフトウェアの機能は，何らかの入

1

SEAソフトウェア・シンポジウム2017 in 宮崎

ひとつの変更 Q について考える．変更 Q は，タスク群 T a のあるタスク T ai に対して行われたとする．変更

Q は，コードの削除や追加を含み，その結果 T ai の版
R が R + 1 に変更される．この変更の結果を T aR
i から
T aR+1とする．
i
変更 Q の波及には，３つのケースが考えられる．

1. 変更波及が無い場合．
2. 変更波及が他のタスクへ波及しない場合．
図 1: アプリケーションソフトウェアの構成

3. 変更波及が他のタスクへ波及する場合．
3. の変更波及は，タスク間の参照が図 2 に示すように力を出力に変換する処理により実現されていると考えら状態と保持データに限られるならば，該当する状態や保れる．この処理を本論文ではタスクと呼ぶ．タスクは，持データの参照を介した範囲が限られると考えられる．

該当のテストレベルからみた入力を出力に変換している

本論文では，この考え方から波及を受けるタスクを特定

１つの処理である．そのため，タスクの粒度は，テスト

し，その合理的なテスト設計について論じる．

レベルによって決まる．ソフトウェアの構成要素である

変更波及，あるいはその解析に関する研究は古くから

タスク T a の出力について考えると，T a への入力 In だ

行われている．プロダクトラインや UML 図面群を基にけでなく状態 St と保持データ（データベースや内部メ

依存関係生成モデルを用いて波及解析を行う研究がある

モリに保存されているデータ）Ds の影響を受けると考[4, 5, 6]．タスク内のデータフローを基に変更波及を詳えられる．例えば，Web アプリケーションにて予約を行細に解析した研究がある [7]．データベースなど保有デー

うタスクについて考えると，予約が可能か否かを示す状

タを基に変更波及解析を行う研究も行われている [8, 9]．

態と，予約オブジェクトの予約状況を示す保持データに一方，状態と状態遷移はマルコフ過程として実装されてよって，予約の成否が決まる．

いるので，過去の状態が未来の状態に影響しない．状態

本論文では，対象として図 1 に示すような状態と保持遷移に関する波及解析の研究は見当たらないのはそのた

データを持つアプリケーションソフトウェア (AS) につめだと推測する．

いて考える．AS の構成要素は，タスク群 T a と状態 Stと保持データ Ds とし，各タスクは外部の源泉 So から

2.3. 状態と変更波及のテストの入力 In と So への出力 Out があるとする．タスク群

T a は，その要素を T a = {T a1 , T a2 , · · · , T ai , · · · , T at }とし，変更タスクを T ai とする. 対応する入出力は Ini

変更波及は，保持データを介して変更タスクから他のタスクへ伝達する．状態や状態遷移自身は変更波及に関と Outi とする．

2.2. 変更と変更波及
AS に対して，何らかの変更を加える場合について考える．変更には，なんらかの意図がある．AS が持つ機能の変更であったり，不具合に対する変更や，性能や保守性の改善のためのリファクタリングであったりする．
本論文では，変更の意図については取り扱わず，AS の構成要素（タスク，状態，保持データ）に対する具体的な変更について考える．ただし，テスト実行をするためには，タスクを動かすことが必須となる．そのため，以
図 2: 変更タスクと変更波及降の議論はタスクに焦点を絞る．

2

SEAソフトウェア・シンポジウム2017 in 宮崎

与しないが，変更波及のテストにおいて与えるデータのントを最低限１つを含むテストケース」と定義されてい順序において状態を考慮する必要が生じる．状態 St にる [3]．この定義を変更タスクと波及タスクとの関係において, 考慮する必要がある状態を Stl とする (図 2).

置き換え「変更タスクにおいてデータの生成および更新

保持データの構成について考える．その要素を Ds ={Ds1 , Ds2 , · · · , Dsj , · · · , Dst } とし，変更波及を受けるがあるデータを使用するすべてのタスク（波及タスク）

保持データの要素を Dsj とする．保持データに対する操わらず最低限１つ含むテストケース」とし，波及全使用

作は，データのライフサイクルである「C：生成」「R：法（IDAU:Impact Data All Used）とする．

を２つのタスクを実行するまでに経由するルートにかか参照」「U：更新」「D：削除」を記した CRUD 図で定義

3. 順序組合せによるテストケース抽出法

する．Dsj を介して変更波及が生ずるのは，変更タスク

T ai において「C：生成」あるいは「U:更新」が行われ，他のタスクでその保持データを利用した場合である．こ

本節では，図２で示した変更タスクと波及タスクの組

れらのタスクを波及タスクと呼ぶ．

合せを抽出する手法として順序組合せテストを提案する．

保持データのライフサイクル上の「C：生成」「R：参

この手法で抽出するテストケースには，必ず変更タスク

照」「U：更新」「D：削除」などの操作は，無条件に行われを実行した後に波及タスクを実行する，といったようにるのではなく，操作するタスクの制御フローに沿って行

組み合わせるタスクに実行順序があるため，順序組合せ

われる．制御フローは，図 2 に示すとおり, ２階層としてと命名した．

捉えることができる．上位の制御フローはタスクの実行

3.1. 提案手法に必要となる入力情報

順序により決定する大きな制御の流れに相当する．個々のタスク内の制御フローが下位にあたる．個々のデータ
参照実行文はその制御フロー上の条件文で実行が決定さ

一般的にテストケース抽出のために必要な入力情報をれる．条件にはタスクへの入力，保持データ，状態が含テストベースと呼ぶ [10]．提案手法に必要なテストベー

まれる．

スは DFD，ER 図，CRUD 図である．以下，DFD，ER
図，CRUD 図を簡潔に説明する．

変更波及を確認するには，変更が波及した保持データを参照するデータフローに沿ってテストを設計すること• DFD（データフローダイアグラム）になる．このデータフローを決定するのは，関係するタDFD はシステムにおけるデータの流れを表現した

スクの実行順序とタスク内の制御フローであり，その制

有向グラフであり，要求分析において用いられてい御フローを決定する際に状態が影響する．よって，実際る．DFD はデータ指向設計の要として用いられ，オのテスト実行においては状態を考慮する必要が生ずる．

ブジェクト指向設計においても抽象化する前段階として実践の場で用いられている．

2.4. 変更波及テストの網羅基準
テストにおける網羅基準については，その強度を含め

DFD は，最上位のコンテキストレベルから階層として詳細化され，各階層は１枚以上の DFD から成制御フローとデータフローの観点から研究が行われ体る [11]．テストベースとして用いる場合，テストの系が作られている [3]. 最も弱い網羅基準は制御フロー

範囲は DFD で与えられるとする．DFD の階層はのみに着目した実行文網羅，次が分岐網羅であり，最もテストレベルに対応し，階層が下がると単体テスト

強い網羅基準はデータフローを含めた全パス網羅（Allとなり，上がると統合テストとなる．

Paths）である．全パステストは，すべての分岐の積でDFD はノードとエッジからなる．ノードは３種類の要素である N 個のタスク（プロセス）T a と，Mあり現実的には実現不可能のため，全使用法（All Uses）
が推奨されている [3]．

個の保持データ（データストア）Ds と，L 個の源変更波及をテストする場合，波及に関与するデータ

泉（外部エンティティ）So から構成されている．３に着目し，そのデータフローテストを行う．一般的な全種類の要素を一意に特定する際は T ai ，Dsj ，Sok

使用法は「データを定義したすべての場所から始まり，と表記する．

データを使用するすべての場所に至るまでのパスセグメ

3

SEA

ソフトウェア・シンポジウム2017 in 宮崎

エッジは，ノードからノードへのつながりを有向線

表 1: 拡張 CRUD 図

分で表記している．エッジはデータの流れを表して
おり，制御の流れは表していない．エッジの特定は，タスク

起点ノードと終点ノードを用いて行う．ある特定のデータストア

Ds1

タスクからデータストアへの入力がある場合のエッ

...

Dsj

源泉

So1

...

Sok

T a1

ジの特定は，T ai /Dsj となり，源泉から出力してタ...

スクで処理をする場合は，Sok /T ai と表す．

T ai

• ER 図ER 図はシステムにおけるエンティティ間の関係を組合せの変更タスク群 P {T a} とする．変更タスク示す図であり，UML のクラス図に対応している．

群からの出力するデータストア群を P {Ds} とする．

DFD では表現できないエンティティの詳細化やエンティティ間の関係について示しており，DFD と• ルール 2：波及タスクの特定共に用いられている．

ルール 1 で求めた P {Ds} からの入力エッジを持つ

ここでは，DFD のデータストア Dsj が持つエンタスクを波及タスク群 S{T a} として特定する．

ティティと，CRUD 図の対応から，後述する拡張• ルール 3：順序組合せテストケースの抽出

CRUD 図を作成するために用いる．よって，テス
トベースとしては，システムすべての ER 図を必要とするものではない．

拡張 CRUD 図を基に変更タスク群 P {T a} とそのデータストア群 P {Ds} を介する波及タスク群

S{T a} を組合せ，順序組合せのテストケースとする．

• CRUD 図以降からは，順序組合せを抽出してテストケースとす

CRUD 図とは，タスク T ai からデータストア Dsj
への C ：生成，U ：更新，R：参照，Ds：削除の操るまでの実施手順を詳細に説明する．

作を表した図である [12]．CRUD 図から，DFD と3.3

本論文では，タスクがデータストアに対して行う操定し，拡張 CRUD 図の変更タスク部分を作成する．

作を特定するために CRUD 図を用いる．タスク T ai

拡張 CRUD 図とは，テストベースとして与えられた
DFD，ER 図，CRUD 図から P {T a} の各 T ai と関連すルール１を用いて変更タスクとそのデータストアを特のデータストア Dsj に対する操作が U ：更新であればタスクによる操作はエッジを介した操作として

3.2

ルール 1：変更タスクの特定

ER 図では表現されていないタスクのエンティティへの操作を知ることができる．

る Sok ，そして P {Ds} となる Dsj の関係を追加して作

T ai /Dsj U と表記する．ただし，タスクが操作する
データストアが１つだけの場合は，T ai U といった成したものである．表 1 に拡張 CRUD 図の表記を示す．

省略した表記を使う．

D のいづれか，または組合せか空白である．源泉に対する情報は In か Out，または組合せか空白である．空白

拡張 CRUD 図のデータストアに対する情報は C ，U ，R，

順序組合せテストの概要

は関係が無いことを示す．

提案する手法は，2 タスク間の順序組合せを対象とす

1. 源泉からの入力エッジを持つ変更タスクの特定

る．2 タスク間の順序組合せの抽出は以下のルールを適テストケースは，外部からのテスト対象への入力か用する．

ら，外部への出力結果を確認するものであるため，
テスト入力とテスト結果のペアで構成されている．

• ルール 1：変更タスクの特定

そこで，テスト対象範囲の外からの入力，即ち Sok

対象とする DFD 内の変更タスクのうち，データス

からの入力エッジを持つ T ai を見つける必要があ

トア Ds へ出力エッジを持つタスクを選択し，順序る．この特性を持ったタスクのうち，さらに変更の

4

SEAソフトウェア・シンポジウム2017 in 宮崎

表 2: 中間の拡張 CRUD 図の例
タスク

データストアDs1
T a1 [St1 ]

Ds2

源泉

Ds3

CU

T a3 [St1 ]表 4: 完成した拡張 CRUD 図の例

C

So1

So2

タスク

So3

データストアDs1

In

T a1 [St1 ]In

T a3 [St1 ]T a2 [St1 ]あるタスク群を変更タスクの集合となる P {T a} 候

T a5 [St1 ]

Ds2

Ds3

源泉

So1

CU

So2

So3

In
C

R

In
Out

RU

Out

補とする．変更が特定の状態でのみ起こり得る場合
は，その状態を［Stl ］と記載する．

3.4

2. データストアへの出力エッジを持つタスク特定

ルール 2：波及タスクの特定

ルール 2 を用いて波及タスク群を特定し，拡張 CRUD

T ai から Dsj への出力エッジは，C か U か D の操図へ波及タスク部分を追加し図を完成させる．

作を行うことを意味する．CRUD 図から該当する出

1. データストアを介した波及タスク特定

力エッジを持つ T ai を選択する．P {T s} 候補の中から，該当する T ai を選び，変更タスク群 P {T a}

先に作成した中間の拡張図から変更タスクの操作がを確定する．

C か U か D であるデータストアに着目する．着目したデータストアに対してエッジを持つタスクが波3. 中間の拡張 CRUD 図作成

及タスクの候補となる．波及タスクとして選択する

拡張 CRUD 図には，変更タスク群 P {T a} に該当

タスクは表 3 に示す表の ○ の組合せに該当する

する Sok から T ai への入力 (In)，もしくは T ai か

タスクである．波及タスクは， C：生成，U：更新，

ら Sok への出力 (Out) の情報を付加する．特定しD：削除を選択する． - をつけた組合せは，データストアを介した影響が生じないため，組合せテスト

た T ai に対して，入力となる Sok に In を記入し，Dsj については CRUD 図を参照して C か U か D
かその組合せかを記入する．中間の拡張 CRUD 図の対象としない． × をつけた組合せは仕様上有として例示した表 2 では，3 つの源泉 {So1 ，So2

順序組合せを網羅しなくともテストできるため，組，So3 } と 3 つのデータストア {Ds1 ，Ds2 ，Ds3 } が合せテストの対象としない．

り得ない組合せであり，ありえないことの確認は，あり，2 つのタスク {T a1 [St1 ], T a3 [St1 ]} が変更タ

2. 拡張 CRUD 図の完成

スクである．この段階で作成する拡張 CRUD 図は，作業途中のものである．

波及タスク候補のうち，源泉に出力エッジを持つタ
スクを波及タスクとして特定する．波及タスクの特性を DFD より読み取り，特定する．特定した波及

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

タスクを拡張 CRUD 図に追記し完成させる．
完成させた拡張 CRUD 図の例を表 4 に示す．このP {T a}S{T a}

C

R

U

D

C
R

×

×

×

◯

◯

-

◯

-

U
D

◯

-

◯

×

◯

×

◯

例では，データストア Ds1 から源泉 So2 への流れをタスク T a2 [St1 ] が行い，データストア Ds2 から
源泉 So3 への流れをタスク T a5 [St1 ] が行っていることを示している．

3.5

ルール 3：順序組合せテストケースの抽出

拡張 CRUD 図を基に順序組合せのテストケースを抽出し，テストケース表を作成する．

5

SEA

ソフトウェア・シンポジウム2017 in 宮崎

順序組合せテストの適用評価

4

表 5: 順序組合せテストによる論理的テストケースの例

No

論理的テストケース

順序組合せ

1

概要

T a1 C → T a2 R

様を用いて，3 節で述べた実施手順を適用し，順序組合2

概要

T a1 U → T a2 R

せが抽出できることを確認する．

3

概要

T a3 C → T a2 R4

概要

T a3 C → T a2 U

本節では，旅行代理店向けフライト予約システムの仕

4.1

フライト予約システムの概要を以下に示す．

1. 変更タスクと波及タスクの組合せを抽出＜フライト予約システム概要＞
・旅行代理店用に開発したフライト予約サーバにインターネット経由でアクセスできる専用のクライアントアプリケーション．
・旅行代理店の窓口での利用を想定しており，ユーザ認証されたユーザのみ利用可能である．
・旅行代理店の窓口数 (クライアント数) は 50 としており，同時に予約処理を行うことができる．
・旅行代理店にて取り扱う全ての航空会社の飛行機の予約が可能である．
・本システムは，フライト予約サーバを仲介して複数の航空会社のシス
テムと同期をする．
・チケット情報や残チケット数は同期することで最新に更新される．
・フライトの新規予約、予約内容の更新，削除が可能である．更新と削除は新規予約したユーザのみ可能である．
・以下はシステム範囲外-チケット代金の決済（別システムと連携して行うため）．
-マスタ情報設定 (他システムとの共用マスタ設定アプリケーションがあるため）．

拡張 CRUD 図から変更タスクを選ぶ．先に作成した拡張 CRUD 図の例（表 4 を参照）であれば，

T a1 [St1 ], T a3 [St1 ] である．次に変更タスクが操作しているデータストアと，それを操作している波及タ
スクを対応付ける．例では，T a1 [St1 ] −−→ T a2 [St1 ]と T a3 [St1 ] −−→ T a5 [St1 ] である．

題材の概要

Ds1

Ds2

2. データストアに対する操作の組合せ
操作の組合せとは変更タスクと波及タスクの操作の組合せである．表 4 の例であれば，変更タスクのデータストアに対する操作である T a1 は，Ds1 に対して C と U の操作を行っている．波及タスク T a2

図 3: フライト予約システムの概要の操作は R である．組合せは C → R と U → R となる．変更タスクと波及タスク間に介在するデータ

題材となるフライト予約システムの仕様は，本研究のストアが 1 つであれば −−→ を省略して → で表し一環として評価実験の際に題材として使っているものでてもよい．また変更の発生条件となる状態が 1 つである [13]．テスト対象の分析と，テストケース設計に関あれは，[St1 ] を省略してもよい．表 4 の例におけする用語は，国際標準である ISO/IEC/IEEE29119 の定る全組合せは，T a1 C → T a2 R，T a1 U → T a2 R，

義に従い，テスト対象の論理的なサブセットを機能セッT a3 C → T a2 R，T a3 C → T a2 U の４個である．

ト（Feature set）と呼ぶ [14]．本論文では，表 6 の新規

Ds1

フライト予約を変更が入った機能セットとする．(表 6 の3. テストケース表の完成

最後の列にある◯が変更を表す．
）新規フライト予約か変更タスクと波及タスクの操作の組合せをテスト

らテストケースを抽出するための前提として用意した仕ケースとしてまとめる．表 5 にその例を示す．概様は，新規フライト予約に関連する DFD（図 4），ER

要の部分は，当該組合せが持つ入力の条件や出力の図（図 5），CRUD 図（表 7）とする．DFD に含まれる特性を仕様から抜き出して記載する．

タスク数 N は 6，データストア数 M は 2，源泉数 L は4 である．

以上の手順で，順序組合せテストに必要なテストケー
スを抽出する．ここで用いたテストケースとは，ISTQB

4.2

ルール 1：変更タスクの特定の定義による論理的テストケースに相当する [10]．具体
的な値や期待結果，該当の処理までの状態を遷移させてテストベースである DFD に含まれるタスク数 N は 6

いく手順まで定義した記述を具体的テストケースと呼ぶであるが，変更が入った新規フライト予約の変更タスク

が，本論文では扱わない．

は，表 7 の CRUD 図を確認するとフライト検索 T a1 とフライト予約 T a2 であることがわかる．図 4 から，T a1と T a2 の外部入力を確認する．T a1 は，顧客 So1 から

6

SEAソフトウェア・シンポジウム2017 in 宮崎

図 4: 新規フライト予約の DFD（一部分）

表 6: フライト予約システムの機能セット一覧

テストアイテム

機能セット

フライト予約システム

メニュー

変更

ログイン
新規フライト予約◯

予約変更 &

図 5: 新規フライト予約の ER 図（一部分）

キャンセル
予約一覧

搭乗日付と渡航先を外部入力し，T a2 は，顧客 So1 から

予約グラフ

搭乗便，クラス，人数，搭乗者を外部入力している．

同期処理＆続いて，T a1 と T a2 の内部出力を確認する．T a1 はフライト情報 Ds1 に対して検索条件を与えているのみ
で内部入力はしていないため，変更タスク群 P {T a} か

4.3

ルール 2：波及タスクの特定らは除外する．T a2 がフライト情報 Ds1 で U ，予約情報 Ds2 で C を行っていることが表 7 から読み取れる．

ルール 2 にて波及タスク群 S{T a} を抽出するために，

これらから，拡張 CRUD 図（表 8）を作る．表 8 から，タスクの外部出力を図 4 の DFD から調べる．P {Ds} に

ルール１に適合する T a2 /Ds1 U ，T a2 /Ds2 C を特定で含まれる Ds1 と Ds2 にエッジを持ち，かつ So へ出力

きる．

するタスク群が S{T a} 候補である．図 4 では，全てのタスクが Ds1 および Ds2 からのエッジを持つ．しかし，So への出力に着目すると，T a4 は該当するエッジがな

7

SEAソフトウェア・シンポジウム2017 in 宮崎

表 7: 新規フライト予約の CRUD 図（一部分）
機能セット

タスク

新規フライト
予約

T a1
T a2

予約変更

T a3

キャンセル

T a4

予約リスト
予約グラフ
同期処理

T a5
T a6

フライト検
索
フライト登
録
予約情報確
認
予約情報修
正
注文状況
最新情報取
得

表 9: 新規フライト予約の拡張 CRUD 図

エンティティ
Ds1
Ds2
フライ
予約情
ト情報
報
R

RU

タスク

Ds1

C

RU

データストア

T a1

R

T a2

RU

Ds2

源泉

So1

So2

So3

So4

Out
C

T a3

R

R

T a5

R

UD

T a6

InOut
Out
Out

CU

Out

R
CU

• T a2 /Ds1 U −−→ T a6 U
Ds1

表 8: 新規フライト予約の中間拡張 CRUD 図• T a2 /Ds2 C −−→ T a3 R
Ds2

タスク

データストア

源泉

Ds1

Ds2

So1

U

C

In

So2

So3

• T a2 /Ds2 C −−→ T a5 R

So4

Ds2

T a1
T a2

これらの変更タスクと波及タスクの操作の順序組合せ
がテストケースとなる．抽出した順序組合せが持つ入力の条件や出力の特性を仕様から抜き出して論理的テスト

いため，S{T a} 候補には入らない．

ケースとしてまとめる．表 10 に論理的テストケースとS{T a} 候補のうち、表 3 の ○ がつく組合せに相してまとめた結果を示す．

当する T ai が，ルール 2 で特定したタスクとなる．本
表 10: 順序組合せテストによる論理的テストケース

節の例の場合，P {T a} での操作は，C と U であるため，

S{T a} 候補の中で C の操作をする T ai 以外は全てルー
新規フライト予約
No 論理的テストケース
1
フライト予約後の空き情
報問合せによる同一フラ
イトの参照
2
フライト予約後の再度同一フライトの予約

ル 2 で特定したタスクとなる．
これらに該当する T ai と Ds への CRUD 操作，そして So への Out を追記し，表 9 を完成させる．

4.4

ルール 3：手順 順序組合せテストケースの抽出

3

表 9 の拡張 CRUD 図から変更タスクと波及タスクの組合せを抽出する．抽出した変更タスクと波及タスクの4組合せに対して，データストアに対する操作を明記した
5

ものは以下のとおりとなる．

• T a2 /Ds1 U −−→ T a1 R

フライト予約後の同期処理によって最新のチケッ
ト残数の計算既存注文開く画面での予約したフライトの参照
注文件数グラフ・注文履
歴の一覧への新規予約フ
ライト予約の反映

順序組合せ

T a2 /Ds1 U −−−→
Ds1

T a1 RT a2 /Ds1 U −−−→
Ds1

T a2 /Ds1 U
T a2 /Ds1 U −−−→
Ds1

T a6 UT a2 /Ds2 C −−−→
Ds2

T a3 RT a2 /Ds2 C −−−→
Ds2

T a5 RDs1• T a2 /Ds1 U −−→ T a2 /Ds1 U
Ds1

8

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 11: 新規フライト予約の画面遷移表（一部分）
遷移→
前状態↓
フライト予約
画面

フライト検
索ボタン

キャン セ ル
OrOK

[出 発 日・From・To入 力 済] フライトテー
ブルフライトテーブル
注文を開く画
面

フライト予
約画面

注文を開く

グラフ

新規予約

注文を開く
画面

グラフ

[フライト便・ク ラ ス・人数・搭乗者・
入力済] フラ
イト予約画
面

履歴

XOr 終了履歴[フライト選択済] フライト予約画面[予 約 番 号]
フライト予
約画面

グラフ

フライト予
約画面

履歴

フライト予
約画面

ログイン

5

Or 終了

フライト予
約画面

考察

えられる．4 節の適用評価にて利用したテストベースは，変更が入った機能セットに焦点を絞ったものである．4

次に，提案手法で抽出したタスク間の順序組合せと，
AS のテストケースを設計する既出の手法である状態遷移テストで抽出されるテストケースの比較を行う. 状態

節では新規フライト予約が該当する。そのため，表 11

遷移テストのテストベースとなるフライト予約システム

おける波及タスクである T a6 U は，表 7 から同期処理のの画面遷移表（表 11）を使って, 順序組合せの確認が可

タスクであることがわかるが，新規フライト予約とは別

能な網羅基準である S1 網羅基準を適用する．表 11 は，の機能セットに含まれるタスクであり，フライト予約画

4 節の提案手法適用例と適用範囲を合わせるために，新規フライト予約を行うために必要な画面と隣接する画面と隣接する画面からなる画面遷移表には現れない．そでは，新規フライト予約に隣接する画面遷移を該当する
テストベースとしている．表 10 のテストケース No3 にのため，S1 網羅基準では抽出することができない．

面遷移に該当する表としている．仕様の詳細度合いは，

DFD，ER 図，CRUD 図と画面遷移表では同等にしてい

6

おわりに

る．それは，画面遷移のイベントでのガード条件に記載したデータが DFD のエッジに記載したデータ，ER 図の本論文では，状態遷移を持つソフトウェアにおいて，

エンティティの属性と一致していることから確認できる．

変更による変更波及がデータベースや外部変数などの保S1 網羅基準を適用すると 28 の状態遷移パスとなる．28の状態遷移パスのうち，対応する提案手法で抽出した順

持データを介して生ずる場合のテストに関して，その網序組合せは，表 10 で示すテストケース No.1，2，4，5 の出する手法を提案した．DFD，ER 図、CRUD 図をテス

4 つであった．これらは, 画面遷移表のフライト予約状態
での登録イベントを起点にするもののみであった．順序

トベースとして，3 つのルールを適用することでテスト組合せに該当しない状態遷移パスは，互いのタスクで同提案した手法で組合せが抽出できることを確認するため，

一のデータを介して処理をするといったことがない．例

フライト予約システムの仕様を具体例にして適用を行っ

えば，フライト検索をした後にキャンセルをするとフラた．最後に画面遷移図（画面遷移表）から従来手法であイト予約画面に遷移するパスは，前の処理の結果によっる状態遷移テストの S1 網羅基準にて抽出した状態遷移て影響を及ぼさない．

パスと提案手法を比較して，テストケース数の削減がで

S1 網羅基準では抽出できないが，本手法によって抽出できたテストケースは，No.3 の T a2 /Ds1 U −−→ T a6 U

きる効果と，S1 レベルの画面遷移の網羅では抽出でき

羅基準である IDAU 法と, 順序組合せテストケースを抽が必要となる順序組合せを抽出できることを説明した．

ないテストケースが抽出できる効果を示した．

Ds1

提案手法に対する今後の取り組みは 2 つある．1 つは,である．このテストケースは，必要なテストケースと考9

SEA

ソフトウェア・シンポジウム2017 in 宮崎

適用範囲の明確化である. 変更のパターン（タスク内の[7] J.N. Campbell, “Data-flow analysis of softwarechange,” Oregon Health & Science University,
pp.1–118, 1990.

制御ロジックの変更, 新しい要素の追加など）に対して,どこまで適用でき, どこからは適用できないかを明らかにする.
もう 1 つは，今回の提案手法のツール化である．実[8] A. Maule, W. Emmerich, and D.S. Rosenblum,“Impact analysis of database schema changes,”

際の開発プロジェクトで扱う規模の大きいデータ設計文
書に対して本手法を適用する際には，本手法のルールをProceedings of the 30th international conference
on Software engineeringACM, pp.451–460 2008.
[9] 加藤正恭，小川秀人，“CRUD マトリクスを用いたツール化するといった方法での適用が必要になる．これらの準備を行い，実践の場に本手法を適用していく．

ソフトウェア設計影響分析手法，” 情報処理学会第 73

参考文献

回全国大会講演論文集，vol.73，pp.249–250，2011．

[1] R.S. Arnold, Software change impact analysis,[10] ISTQB/FLWG, Foundation Level Syllabus, Inter-

IEEE Computer Society Press, 1996.

national Software Testing Qualifications Board,
2011.

[2] B. Li, X. Sun, H. Leung, and S. Zhang, “A survey of code-based change impact analysis techniques,” Software Testing, Verification and Reliability, vol.23, no.8, pp.613–646, 2013.

[11] T. DeMarco, “Structure analysis and system specification,” Pioneers and Their Contributions toSoftware Engineering, pp.255–288, Springer, 1979.

[3] B. Beizer, Software Testing Techniques, Van Nostrand Reinhold, 1990. (翻訳 :小野間 彰， 山浦恒
央 :ソフトウェアテスト技法, 日経 BP 出版センター[12] A.L. Politano, “Salvaging information engineering
techniques in the data warehouse environment,”(1994)).

Informing Science, vol.4, no.2, pp.35–44, 2001.

[4] H. Gomaa, “Designing software product lines withuml.,” SEW Tutorial Notes, pp.160–216, 2005.

[13] T.Yumoto， K.Uetsuki， T.Matsuodani, andK.Tsuda, “A study on the eﬃciency of a test anal-[5] L.C. Briand, Y. Labiche, and L. O’sullivan,“Impact analysis and change management of
UML models,” Software Maintenance, 2003.
ICSM 2003. Proceedings. International Confer-ysis method utilizing test-categories based on aut
and fault knowledge,” ICACTCM 2014, pp.70–
75, 2014.

ence onIEEE, pp.256–265 2003.
[6] 小谷正行，落水浩一郎，“UML 記述の変更波及解
析に利用可能な依存関係の自動生成，” 情報処理学[14] ISO/SC7/WG26,
Softwareand
Systems
Engineering-Software-Testing Part 2:Test Pro-会論文誌，vol.49，no.7，pp.2265–2291，2008．

cesses, ISO/IEC/IEEE29119 2013(E), 2013.

10

SEA