狠狠撸

(C) Keizo Tatsumi 20081
組み合わせテストの設計
辰巳敬三 (富士通㈱)
2008年7月17日
?組み合わせテストの概要
?要因分析技法
?テスト項目設計支援システム(ATAF)
?ATAFで目指したこと
PictMaster勉強会資料

組み合わせテストの概要
? 組み合わせテストとは
? 組み合わせテスト技法の歴史
? 組み合わせテストの網羅基準

組み合わせテストとは (1/2)
?組み合わせテストの名はまだ一般的ではない
?ISTQBの用語に「組み合わせテスト(Combination Testing,
Combinatorial Testing)」はない。最新(2007年12月)の用語
集でOrthogonal Array, Pairwise Testingが追加。
?1990年中盤にpairwiseの考え方が認知され、組み合わせ
手法が発展
?組み合わせテストとは
何らかの組み合わせ手法に基づいて入力パラメタの値を
組み合わせることによりテストケースを選択する技法
[出典]“Combination Testing Strategies: A Survey”(Grindal,Offutt,Andler)

組み合わせテストとは (2/2)
?組み合わせテストの設計ステップ
1st step. 各パラメタ毎にパラメタの値を”意味のある”小さなセットに分割
2nd step. ある網羅基準に基づいて全組み合わせからサブセットを選択
[出典]“An Evaluation of Combination Strategies for Test Case Selection”(Grindal et.al)
?組み合わせテストで用いられる手法
?組み合わせ手法 [出典]“ペアワイズテスト”(土屋,菊野)
? 代数的手法 : カバリングアレー, 直交表
? 探索に基づく手法
? 逐次的な構成手法 : AETG,TCG,DDA,IPOアルゴリズムなど
? 一括的な構成手法 : ヒルクライミング、シミュレーテッドアニーリン
グ、tabuサーチ
?入力条件分析手法
Category-partition method, Classification-tree method,
要因分析技法 HAYST法のFV表,FL表はこの範疇の技術 ?

(1957: Decision table)
組み合わせテスト技法の歴史
～1967: Equivalence partitioning,
Boundary value analysis
1970: Cause Effect Graph
[Elmendorf]
1950 1980 '85 19901960 '05'951970 2000
(1983～)1985: Orthogonal Latin Squares
[R. Mandl]
(1983～)1984: 直交表/組合せ表
[佐藤,下川(富士通)]
1987: ATAF
[辰巳(富士通)]
(198x～)1992: OATS
[Brownlie, Prowse, Phadke]
(1990～)1994: CATS
[Sherwood]
(1992～)1994: AETG
[Cohen, et. al]
1998: IPO
[Lei, Tai]
2000: Covering arrays
[Williams]
2000: CTE XL
[Daimler Chrystler]
(2000～)2004: PICT
[Microsoft]
2007: FireEye
(IPOG)[Lei, Kuhn]
AT&T, Bellcore
入力条件分析手法
1988: Category-partition method
[Ostrand, Balcer]
1993: Classification-tree method
[Grochtmann, Grimm]
(1976: テスト要因分析)
[富士通]
組み合わせ手法
(199x～)2004: 直交表(HAYST法)
[富士ゼロックス]

参考文献
1) M. Grindal, J. Offutt, S. F. Andler, Combination Testing Strategies:
A Survey, GMU Technical Report ISE-TR-04-05, July 2004
2) 土屋達弘, 菊野亨, ペアワイズテスト, 電子情報通信学会論文誌 D,
Vol. J90-D, No.10, 2007
3) P. Ammann, J. Offutt, Introduction to Software Testing, Cambridge
University Press, 2008
Contents
Part 1 Overview
1 Introduction
Part 2 Coverage Criteria
2 Graph Coverage
3 Logic Coverage
4 Input Space Partitioning
5 Syntax-based Testing
Part 3 Applying Criteria in Practice
6 Practical Considerations
7 Engineering Criteria for Technologies
8 Building Testing Tools
9 Challenges in Testing Software

? Ammann & Offutt 7Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com
Old : Find a Graph and Cover It
? Tailored to:
– a particular software artifact
? code, design, specifications
– a particular phase of the lifecycle
? requirements, specification, design, implementation
? This viewpoint obscures underlying similarities
? Graphs do not characterize all testing techniques well
? Four abstract models suffice
「グラフを見たら、どうすべきか。
完全に網羅せよ！」
(ボーリス?バイザー)

New : Test Coverage Criteria
? Test Requirements : Specific things that must be satisfied or
covered during testing
? Test Criterion : A collection of rules and a process that define
test requirements
A tester’s job is simple : Define a model of the
software, then find ways
to cover it
Testing researchers have defined dozens of criteria, but they
are all really just a few criteria on four types of structures …
テスターの仕事はシンプル：
ソフトウェアをモデル化し網羅する方法をみつけよ

New : Criteria Based on Structures
1. Graphs
2. Logical Expressions
3. Input Domain
Characterization
4. Syntactic Structures
(not X or not Y) and A and B
if (x > y)
z = x - y;
else
z = 2 * x;
Structures : Four ways to model software
A: {0, 1, >1}
B: {600, 700, 800}
C: {swe, cs, isa, infs}
組み合わせテスト

? Ammann & Offutt 10
Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com
Coverage Overview
Four Structures for
Modeling Software
Graphs Logic Input Space Syntax
Use cases
Specs
Design
Source
Applied
to
DNFSpecs
FSMsSource
Applied to
Input
Models
Integ
Source
Applied
to

組み合わせテストの網羅基準
基準テストケース設定方法テストケース例(*)
単純な入力空間
網羅基準
Each Choice (EC) 各因子の状態値が最低1回存在するように
テストケースを設定する。
(A,1,x)
(B,2,y)
(A,3,x)
組み合わせ網羅
基準
Pair-Wise (PW) 任意の2つの因子間で各々の状態値の組
み合わせが存在するようにテストケースを
設定する。
(A,1,x) (B,1,y)
(A,2,x) (B,2,y)
(A,3,x) (B,3,y)
(A,-,y) (B,-,x)
t-Wise (TW) t個の因子間で状態値の組み合わせが全
て存在するようにテストケースを設定する。
All Combinations
(AC)
全ての因子の状態値の組み合わせが存在
するようにテストケースを設定する。
対象ドメイン知識
を利用した基準
Base Choice (BC) 各因子の状態について基本的な値(例えば
利用者が通常使う値)を選択し、これを基
本テストケース(base choice)とする。以降、
一つの因子を除く他の因子の状態値を固
定して、対象の因子の状態値を変えてテス
トケースを設定する。
base choice : A, 1, x
(A,1,x)
(B,1,x)
(A,2,x)
(A,3,x)
(A,1,y)
Multiple Base Choice
(MBC)
base choiceを二つ以上定義し、各々base
choiceと同様にテストケースを設定する。
Ammann & Offutt による分類 (Introduction to Software Testing) (*) 各状態値は[A,B] [1,2,3] [x,y]

? Ammann & Offutt 12Introduction to Software Testing (Ch 1-5), www.introsoftwaretesting.com
ISP Coverage Criteria Subsumption
Each Choice
Coverage
EC
All Combinations
Coverage
AC
T-Wise
Coverage
TW
Multiple Base
Choice Coverage
MBC
Pair-Wise
Coverage
PW
Base Choice
Coverage
BC

要因分析技法
? テスト項目設計の流れ
? テスト分類
? 要因分析
? テスト項目設定

A B C D
テスト項目1 a1 b1 c1 d1
テスト項目2 a2 b2 c3 d2
テスト項目n a3 b1 c4 d3
因子
<テスト項目表>
A B C D
1 a1 b1 c1 d1
2 a2 b2 c2 d2
3 a3 c3 d3
4 c4
因子
<要因分析表>
状態
xxx機能
xyz???
あいう???
いろは???Step1. テスト分類
? 機能(外部仕様)の分割
Step2. 要因分析
? 入力条件の抽出(因子)
? 動作環境上の条件を抽出(因子)
? 入力／環境条件の値の分析(状態)
→ 因子と状態の二次元の表に形式化
（要因分析表の作成）
Step3. テスト項目設定
? 因子、状態の組み合わせを検討して
テスト項目を作成
Step4. テスト結果の定義
? 出力結果やプログラムの動作結果を
定義
テスト項目設計の流れ

テスト分類
?テスト対象機能を細分化し、作業範囲を絞り込む
?外部仕様から見た機能で分類する
?機能面から見た評価がしやすくなるように分類する
?細分化することによる欠点(各機能間の関連が把握しに
くくなる)を補う
例)機能間にまたがるテスト分類を設けるなど
グループ
ウェア
削除
一覧表示
既存文書
改版
添付????
追加
ライブラリ
メール
フォーラム
ライブラリ
操作
保存文書操作新規文書
テスト
項目
要因分析、テスト項目設定の作業単位
フォルダ
操作
テスト
項目
テスト
項目
-1????+2???? +1???? 0????

要因分析～因子の抽出～
?機能の観点(マニュアルから読み取れる因子)
コマンド、オペランドの入力方法、形式、指定値など
?動作環境の観点(ソフトウェア/ハードウェアの環境)
ハード構成/種別、環境定義、サブシステム、ファイルなど
?結果の観点
帳票出力、画面表示結果、表示メッセージなど
?その他の考慮事項
?互換性/整合性の観点
プログラム、ユーザ?資産の互換／整合性など
?負荷の観点
多重度、大量データ、多端末、大規模構成など

要因分析～分析の観点～
意図的な入力監視対象の出力
利用者の
状態
(エクスペ
リエンス)
プログラムの状態
システムの状態
コンフィグレーショ
ン、システム資源
他の協働プロセス
やクライアント／
サーバから
エンティティの状態
プログラムの状態
システムの状態
接続装置、システ
ム資源への影響
他の協働プロセス
やクライアント／
サーバへ
エンティティの状態
テスト対象
ソフトウェア
(システム)
テストの
入力
テストの
結果
Testing Model

要因分析～状態の分析～
? 同値分割、限界値/境界値分析の考え方を適用して、
各因子が取りうる値(状態値)を分析
① 連続する値や個数の場合
下限値－１、下限値、標準値、上限値、上限値＋１
② 入力条件が選択形式の場合
すべての指定方法（省略を含む）、誤った指定方法
③ 列挙型の集合名や総称名形式の場合
各々の名称が意味する内容に、上記の原則を適用
④ 禁止事項、注意事項(「～ねばならない」など)の場合
その状態、そうでない状態
⑤ 出力結果の分析から入力条件を検討する
出力の境界条件の状態を引き起こす値
⑥ 上記の原則を他のケースにもあてはめる

要因分析～要因分析表の記入例～
状
態
1
2
3
4
5
A B C D E F G
指定数文字数
1個
2～9個
10個
0個
E
E
1文字
E
E
文字種別
英字
英字以外
11個以上
2～3文字
5文字
0文字
E
4文字
入力値の仕様
(1)指定数は1個以上10個以下
(2)文字数は1～4文字
(3)文字種別は英字のみ
最小値
最大値
無効同値クラス
有効同値クラス
注)実際には指定数が複数個の場合は、各々について文字数,文字種別の分析が必要

テスト項目設定
?要因分析表に記入された状態を組み合わせて
A B C D E
???-01
???
項目No
指定数文字数文字種別
???-02
???-03
???-04
1個英字2～3文字
4文字1個英字
0個 × ×
1個 5文字英字

テスト項目設定～組み合わせ基準～
?要因分析表に記入された状態を組み合わせて
? 全ての組み合わせは数が膨大で実施不可能
?テスト項目設定基準
?実験計画法の直交表の利用
任意の２つの因子間で、状態の組み合わせが
『同一回数』存在する
?更に条件を緩和し、
直交表を改造した「組み合わせ表」を適用
任意の２つの因子間で、状態の組み合わせが
『一つ以上』存在する(Pairwise)

テスト項目設定～組み合わせ表～
1 2 3 4 5 6 7 8 9
T1 1 1 1 1 1 1 1 1 1
T2 2 1 2 2 1 2 2 1 2
T3 1 2 2 1 2 2 1 2 2
T4 2 2 1 2 2 1 2 2 1
T5 1 1 2 2 2 1 1 1 2
T6 2 2 1 1 1 2 2 1 1
T7 1 2 2 2 1 2 2 1 1
T8 2 1 1 1 2 1 1 2 2
?直交表の改造
?任意の２つの因子間で、状態の組み合わせが
『一つ以上』存在する「組み合わせ表」に改造
因子番号
テスト項目番号

テスト項目設定～テスト項目の決定～
A B C
1 a1 b1 c1
2 a2 b2 c2
3
因子
<要因分析表>
A B C
項目1 a1 b1 c1
項目2 a2 b1 c2
項目3 a1 b2 c2
項目4 a2 b2 c1
因子
<テスト項目表>
組み合わせ表に従って
テスト項目を決定
1 2 3
T1 1 1 1
T2 2 1 2
T3 1 2 2
T4 2 2 1
因子
<組み合わせ表>
任意の２つの因子間で、
状態の組み合わせが
『一つ以上』存在

テスト項目設計支援システム(ATAF)
? 開発の背景
? ATAFの機能
? 要因ひな型
? 制約条件
? テスト仕様書の版数管理

開発の背景(1983年頃～)
?大規模基本ソフトウェアのテストケース設計の課題
? テスト対象ソフトウェアだけでなく、関連するソフトウェア、ハードウェア
などの広範な知識が必要
? 多くのテスト担当者の作業品質の向上が必要であるが、教育による知
識?技術の習得にも限界がある。
?解決アプローチ
? 一連のテストケース設計技法の体系化?統合化
同値分割や限界値分析、組み合わせ手法などのテスト技法の統合
? 要因分析技法
? テストケース設計に必要な技法、知識の蓄積と活用
ツール化、関連ソフト?ハードウェアの知識をテスト知識化して活用
? テスト項目設計支援システム(ATAF)

ATAFの機能
?要因分析表の作成支援
?要因分析表の作成、編集、流用
?要因ひな型を利用したテスト知識処理
?単独でエラーになる状態の指定
?テスト項目の生成
?直交表を改造した「組み合わせ表」により組み合わせを決定
?単独エラーの状態は組み合わせずにテスト項目を生成
?制約条件の指定による組み合わせの制御
?テスト仕様書の版数管理
?テスト対象機能のエンハンス時の旧テスト項目の保存

α
a1
a2
：
<要因データベース>
β
b1
b2
：
γ
c1
c2
：
関連要因
要因分析表
<要因分析表データベース>
テスト項目表
<テスト項目表データベース>
??
<テスト知識登録>
α
a1
a2
：
β
b1
b2
：
<要因分析表作成>
<制約条件の指定>
<テスト項目表作成>
a1
a2
αＸ
x1
x3
状態1
状態2
状態3
x2
β
b1
b2
x3
x1E
R制約2
a2
a2
制約1
b2
a1
a1
αＸ
x1項目1
項目2 x2
β
b1
b1
a2項目3 x1 b1
テスト項目表
編集?管理
テスト項目生成
(組み合わせ)
テスト知識蓄積
テスト知識検索
要因分析表
編集?管理
ＡＴＡＦ
[テスト担当者]
[テスト熟練者]
技法、経験則、
エラー分析
ATAFの機能～全体像～

正しく指定
不正な文字
を含む
先頭が
英字以外
装置名
の文字種
最小
(1文字)
最大
(8文字)
中間
(2～7文字)
9文字以上
装置名
の長さ
テスト要因を展開
装置名
の長さ
装置名
の文字種
装置名
因子
状
態
1
2
3
4
<要因分析画面>
A B C
要因ひな型
DEVNAME
オペランド
装置名
指定しない
因子
状
態
1
2
3
4
<要因分析画面>
A B C
DEVNAME
オペランド
装置名
指定しない
最小
(1文字)
中間
(2～7文字)
最大
(8文字)
9文字
以上
正しく指定
先頭が
英字以外
不正な文字
を含む
要因ひな型

制約条件
?要因分析表に対して因子と状態の関係を指定
? 要因分析表と制約条件でテスト対象の仕様を形式化
?因子?状態の関係の指定方法
1) 状態－状態の間
2) 因子－状態の間
3) 因子－因子の間
?制約条件の種類
a) 排他の組合せ：同時に指定するとエラーになる組み合わせ
b) あり得ない組合せ：組み合わせは生成されない
c) 必要な組み合わせ：３因子以上で必要な組合せを指定
d) 状態のグループ化：出現頻度の調整(グループ単位で組み合わせ)
注)aはPICTのconstraints、cはseedに相当、dはsubmodelに近い結果が得られる機能。
PICTはbの指定ができないと思われる。
注) PICTのconstraintsの指定はvalue単位のみ
(状態-状態間)と思われる
注) PICTがIF-THEN形式のテスト項目生成ルールを表現させるのとアプローチが異なる

テスト仕様書の版数管理
?旧版のテスト項目(テスト資産)の保証
?テスト対象ソフトウェアの機能追加の際のテスト項目生成
は、既存の組み合わせ(テスト項目)を変化させず、追加
分の因子を含めて新たに必要となる組み合わせを生成し
てテスト項目を追加。
?テスト仕様書の版数管理
?旧版のテスト項目を保証するため、要因分析表の版数
アップ後は旧版で記入された因子や状態の削除は認め
ず、追加変更のみに制限。
?テスト項目設定表は要因分析表の版数に対応して生成、
管理。

ATAFの画面(PC版)

ATAFで目指したこと
? 要因分析プロセスのモデル化
? 外部仕様の解析
? 要因分析エキスパートシステム

1.入力因子の抽出
外部から陽に指定される入力因子の抽出
2.環境因子の抽出
入力因子に関連する他のプログラムやハードウェアなどの因子の抽出
3.状態の分析
a) 数値を示す因子
最大値、最小値など、同値分割、限界値分析により状態値を決定
b) 選択形式の指定の因子
すべての選択値、省略、誤った指定を状態値とする
c) 総称名形式の因子 (例えば、「Hard Disk」はいろいろな種類のHDを総称している)
一種の選択形式として総称名に含まれるものを状態値とする
4.関連する因子の類推
抽出した因子から類推して外部仕様書には陽に記述されていないような
関連因子を抽出する
要因分析プロセスのモデル化 (1/2)

要因分析プロセスのモデル化 (2/2)
一つの因子に閉じた独立因子の抽出
因子間の関連を類推した因子の抽出
装置の種類，コマンドの文法などの
既定事実の分析
同値分割?限界値分析などの論理的
なテスト技法による分析
要因分析プロセス
因子分析
状態分析
単一型因子分析
類推型因子分析
論理型状態分析
既定事実型
状態分析

BACKUPコマンド
コマンド名オペランド
BACKUP DEVNAME(装置名)
FILENAME( )
ファイル名
DUMMY
*
?終端記号
外部仕様書に記された文字列をそのままの
形で指定する。
例)DEVNAME, FILENAME, DUMMY, *, (, )
?非終端記号
入力する時に実際の値と置き換えて指定する。
例)装置名, ファイル名
?構文表記記号
終端記号や非終端記号の指定条件を表す。
-大括弧［］：大括弧内の項目は省略ある
いは一つ選択する。
-中括弧｛｝：中括弧内の項目を一つ選択
する。
-繰り返し記号???：直前の項目を繰り返す。
-省略時の標準＿(????????)：省略時の標
準値を示す。
-選択｜：選択項目の区切りを示す。
構文表記法
(1) 入力形式
(2)機能
BACKUPコマンドは?????
(3)オペランドの説明
① DEVNAME(装置名)
DEVNAMEオペランドは, バックアップ装置
の名前を指定する。指定できる装置は???
:
:
外部仕様の解析 (1/2)

外部仕様の解析 (2/2)
?構文表記法で記述された外部仕様の解析
?構文表記法から因子、状態への変換規則に従って外
部仕様から要因分析表を自動生成
?関連する因子を類推するためのキーワードとして非終
端記号を用いてテスト知識を検索(推論を実行)
?『推論』により要因分析表を生成
?非終端記号を構成する単語の識別
機能の作用主体、修飾語、助詞、形式(名、数、???)
?非終端記号が表す「概念」の推論
? 形式面：名前指定型、数値指定型、選択型
? 意味：「主体」「修飾語」をキーとして知識ベースを
検索し、環境因子を抽出

要因分析エキスパートシステム
状
態
因子
A B C D E
1
2
3
4
DEVNAME
オペランド
装置名
指定しない
装置名
の長さ
最小
(1文字)
最大
(8文字)
中間
(2～7文字)
9文字以上
装置名
の文字種
正しく指定
先頭が
英字以外
不正な文字
を含む
FILENAME
オペランド
*
ファイル名
省略
その他
DUMMY
オペランド
指定する
省略
誤った指定
DEVNAME(装置名)
FILENAME( )
ファイル名
DUMMY
*
フレーム型知識
?テスト対象ソフトウェアの既定事実型知識
?要因分析のためのソフトウェアの一般的知識
IF 因子展開型＝数値指定型
THEN 状態値＝ "最小値より小/E"、"最小値"、
"中間値"、"最大値"、
“最大値より大/E”、“指定誤り”
IF ????
ファイル?フレーム
????1：装置 Disk｜Tape｜FPD｜他
????2：入出力入力｜出力｜入出力
ファイル名?フレーム
????1：対象ファイル
????2：形式名
????3：因子展開型名前指定
????4：開始文字ルール起動
????5：使用可能文字ルール起動
????6：単純名けた数８
????7：禁止指定ルール起動
ファイル名スロット決定ルール
開始文字
IF 装置＝ Disk
THEN 開始文字＝ (英字、各国用文字)
IF 装置＝ Tape
THEN 開始文字＝英字
IF 装置＝ FPD
THEN 開始文字＝英字
????
要因分析
エキスパート
システム
ルール型知識(プロダクションルール)
?推論全体を制御するメタルール
?因子／状態生成ルール(論理型、経験的知識)
?フレーム型知識の未確定事項決定ルール

α
a1
a2
：
β
b1
b2
：
γ
c1
c2
：
関連要因
要因分析表
<要因分析表データベース>
テスト項目表
<テスト項目表データベース>
??
<テスト知識登録>
<要因分析表作成>
<制約条件の指定>
<テスト項目表作成>
a1
a2
αＸ
x1
x3
状態1
状態2
状態3
x2
β
b1
b2
x3
x1E
R制約2
a2
a2
制約1
b2
a1
a1
αＸ
x1項目1
項目2 x2
β
b1
b1
a2項目3 x1 b1
テスト項目表
編集?管理
テスト項目生成
(組み合わせ)
テスト知識蓄積
テスト知識検索
要因分析表
編集?管理
ＡＴＡＦ
[テスト担当者]
[テスト熟練者]
技法、経験則、
エラー分析
テスト項目設計支援システム
α
a1
a2
：
β
b1
b2
：
ルール
フレーム
ルールフレーム
<知識ベース>
<外部仕様入力>
DEVNAME(装置名)
FILENAME( )
DUMMY
*
????名
外部仕様解析

おわりに
?「はじめて学ぶソフトウェアのテスト技法」(コープランド)
Pairwiseテストが有効であることを保証する「ソフトウェア欠陥物理学」
はありません。効果を知るには試してみるしかありません。
?"Pairwise Testing - A Best Practice That Isn't"(Bach,Shroeder)
Pairwise testing fails
? when you don't select the right values to test with.
? when you don't have a good enough oracle.
? when highly probable combinations get too little attention.
? when you don't know how the variables interact.
Develop Skill, Take Ownership, but Do Not Trust "Best Practice."
PictMaster/PICTやHAYST法を活用した結果を共有して
よりよいテスト技法に育てていきましょう。
ご静聴ありがとうございました。
(正しい値を選んでいないとき)
(テスト結果判定が不十分なとき)
(よくある組み合わせ
に注意しないとき)
(パラメタ間の関係を知らないとき)
(Pairwiseテストが失敗するのは、)

狠狠撸

組み合わせテストの設計(PictMaster勉強会) 2008年7月17日

Recommended

More Related Content

What's hot (20)

Similar to 組み合わせテストの設計(PictMaster勉強会) 2008年7月17日 (20)

More from Keizo Tatsumi (20)

組み合わせテストの設計(PictMaster勉強会) 2008年7月17日