温め続けているアイデア～テスト要因分析エキスパートシステム

Software Testing ManiaX vol.3
温め続けているアイデア～テスト要因分析エキスパートシステム～
An idea waiting to hatch: Test factor analysis expert system
辰巳敬三
はじめに
巳年生まれは執念深いといわれる。私の場合、名字に「巳」がつくので、さらに執念深
いかもしれない。
このアイデアを考えたのは 25 年ほど前、AI(Artificial Intelligence)技術を応用したエキ
スパートシステム、あるいはその構築ツールが盛んに研究、開発されていた時代である。
当時、協力会社の人達と一緒に ATAF という名前のテスト設計支援システムをメインフレ
ーム上で開発しており、その拡張機能として開発を進めた。ある程度までは開発できたが、
私の仕事上の環境変化があり完成するには至らなかった。
これまで、ずっと考え続けていたわけではないが、まだ当時の資料は持っている。あき
らめてはいない。このエキスパートシステムのことは 4 年ほど前に TEF で紹介したり、2
年前の PICT 勉強会で紹介したりしたので記憶にある方もいるかもしれない。古いアイデア
であるがしつこく温め続けているマニアックさ(?)に免じて、“Software Testing Maniax”で
改めてこのアイデアを紹介することをお許しいただきたい。
1. テスト要因分析エキスパートシステムの位置付け
私が所属していた部門では外部仕様に基づくテスト設計は以下のステップを踏むが、一
般的にも同様の流れでテスト設計は進められるはずである。テスト要因分析エキスパート
システムは、ステップ２を支援するものである。
・ステップ１：テスト分類
ABC製品
xxx機能
xyz・・・
X機能
あいう・・・
いろは・・・
xxx機能
テスト対象の機能を細分化し、ツリー状のテス
トの分類体系を作成する。ソフトウェア開発フェ
ーズにおけるアーキテクチャ設計やモジュール分
割に相等するステップである。
zzz機能
Y機能
<テスト要因分析表>
因子
状態
A
B
C
D
1
a1
b1
c1
d1
細分化された機能ごとに、外部仕様から入力条
2
a2
b2
c2
d2
件，及びその機能の動作に影響を与える環境条件
3
a3
c3
d3
を抽出する。本稿では入力条件や環境条件を指す
4
・ステップ２：テスト要因分析
c4
名称を「因子」、それら条件が取り得る値や状態を
「状態」と呼び，因子と状態を合わせて「テスト
要因」と呼ぶ。外部仕様から抽出したテスト要因
を記述するドキュメントを「テスト要因分析表」
と呼ぶ。
・ステップ３：テストケース設定
テスト要因分析表に記入された各因子の状態を
<テストケース表>
因子
A
B
C
D
テスト項目1
a1
b1
c1
d1
テスト項目2
a2
b2
c3
d2
テスト項目n
a3
b1
c4
d3
図－１テスト設計の流れ
組み合せることによりテストケースを設定する。テストケースを記述するドキュメント
を「テストケース表」と呼ぶ。状態の組み合わせを検討する際に、直交表や Pairwise 法
などの技法が適用できる。
・ステップ４：テスト結果の定義
設定したテストケースごとに、予想される結果を定義する。
これらのうち、特にステップ２の作業が不十分な場合、設定されたテストケースで条件
漏れや考慮漏れといった問題を引き起こすため、このステップでテスト設計の熟練者（エ
キスパート）がもつ知識を活用できるようにしたいというのが、このテスト要因分析エキ
スパートシステムを発案した動機である。
2. テスト要因分析の思考プロセス
テスト要因分析を行うときに、熟練のテスト設計者はどのような思考プロセスを経て必
要なテスト要因を導き出しているのかを整理してみる。
2.1 テスト設計で考慮すべき事項
ソフトウェアのテストを設計する場合、図－２に示すように明確な入力や出力以外に考
慮すべき条件（破線の部分、いわゆる環境条件）は多い。この環境条件の考慮が漏れると、
「テスト漏れ」につながってしまう。このような環境条件は、通常はソフトウェアの利用
者が意識するものではなく、ソフトウェア内部の処理で対応されるため、外部仕様書に書
かれていないことが多い。
システムの状態
システムの状態
エンティティの状態
エンティティの状態
明示的な入力
テスト対象
ソフトウェア
(システム)
テストの結果
プログラムの状態
テストの入力
プログラムの状態
監視対象の出力
コンフィグレーショ
ン、システム資源
接続装置、システ
ム資源への影響
他の協働プロセス
やクライアント／
サーバから
他の協働プロセス
やクライアント／
サーバへ
図－２テスト設計の考慮点
2.2 テスト要因分析のプロセス
テスト要因分析では、以下のような思考により因子の分析、因子が取り得る状態の分析
が行われている。
1) 因子の分析
1-1) 入力因子の抽出
一般にソフトウェアは、コマンド／制御文／文･･･のような形式で外部から陽に
指定された入力に基づいて動作する。例えばコマンドの場合、コマンド自身やオペ
ランドとして与える情報がそれに当り、これらの情報から入力因子が抽出される。
コマンドのような形式ではなく、何らかのトリガーに基づいて起動され、その時
のパラメタ情報に応じて動作するようなソフトウェアの機能も、擬似的にコマンド
形式で表現することは可能であり、同じ思考方法により入力因子が分析できる。
1-2) 環境因子の抽出
ソフトウェアの動作は、動作の対象となる資源の状態や関連するソフトウェア・
ハードウェアの動作状況により変化することがある。これらの資源や関連ソフトウ
ェア・ハードウェアに関する因子を環境因子として抽出する。
1-3) 関連する因子の類推
因子の分析過程では、
「ファイル名」という因子を抽出すると、それに関連して「フ
ァイル編成」、「ブロック長」などの‘ファイル’という名前から類推される因子を
思い浮かべて、テスト要因として考慮するか否か取捨選択していく作業が行われて
いる。すなわち、あるキーワード（因子）から次のキーワードをたぐるという作業
（思考）が行われている。
2) 状態の分析
状態の分析では、因子の属性に応じて、以下のように状態値が決定される。
2-1) 数値を示す因子
「下限値－１、下限値、標準値、上限値、上限値＋１、･･･」というように同値
分割、限界値分析をした値を状態値とする。
2-2) 選択形式の指定の因子
アクセス名＝［装置名｜機種名｜ＤＡ］というようにオペランドの選択肢
が提示されている外部仕様では、アクセス名という因子に対して「装置名、機種名、
ＤＡ、省略、誤った指定」というように, すべての指定方法を状態値とする。
2-3) 総称名形式の因子
「装置」、
「Hard Disk」、
「用紙サイズ」という概念はいろいろな種類の装置、Hard
Disk、用紙サイズを総称するものである。総称名形式も選択形式の一種であるが、
選択可能なもの(状態)は既知という前提で、テスト対象ソフトウェアの外部仕様書に
は書かれていないことが多い。このためテスト担当者がこのような事実(既定の事実)
を知っているか否かによりテスト要因分析の質が左右されることになる。
2.3 テスト要因分析のモデル化
以上に述べたテスト要因分析の思考プロセスは図－３のようにモデル化できる。単一型
因子分析や論理型状態分析はテスト技法の適用により一定の質の確保が可能である。熟練
者と経験の浅い担当者との差は、関連する因子が類推できるか(類推型因子分析)、多くの事
実の知識をもっているか(既定事実型状態分析)という点にあると考えられる。
要因分析
因子分析
状態分析
単一型因子分析
入力条件や環境条件から陽に認識で
きる因子をひとつずつ抽出
類推型因子分析
ある因子から類推される他の因子の
抽出
論理型状態分析
同値分割・限界値分析などの論理的
なテスト技法による分析
既定事実型
状態分析
装置の種類，コマンドの文法などの
既定の事実の分析
図－３テスト要因分析モデル
3. テスト要因分析に必要な知識
前章で整理したモデルに沿ってテスト要因分析で必要となる知識を整理すると、外部仕
様から因子や状態を識別するための知識（単一型因子分析）
、関連する因子を類推するため
の知識（類推型因子分析）
、因子の属性に応じた状態を展開するための知識（論理型状態分
析、既定事実型状態分析）に分けることができる。
3.1 外部仕様からテスト要因へ展開する知識
外部仕様のうち、コマンドや制御文については、図－４に示す終端記号、非終端記号、
構文表記記号からなる構文表記法や同種の表記法に基づいて、それらの指定方法が外部仕
様書に記述されている。入力因子の抽出はこの構文の解析を行うことが出発点となる。構
文表記法と抽出すべきテスト要因との間につぎのような変換規則を設ければ、外部仕様か
らテスト要因分析表を自動的に生成できる。この変換規則が、外部仕様から因子や状態を
識別するための知識ということになる。
- オペランド名の終端記号は因子とする
- 構文表記記号の種類に応じて状態値を決定する
例) 大括弧の場合は、選択可能なものを状態として列挙し、省略も状態値とする
- 非終端記号は、その文字列をそのまま展開して、つぎの段階のキーワードとする。
外部仕様の解析過程で、コマンドや制御文の構文は、終端記号と非終端記号に分解され、
非終端記号が関連する因子を類推するためのキーワードとなる。
構文表記法
BACKUPコマンド
(1) 入力形式
コマンド名
BACKUP
終端記号
外部仕様書に記された文字列をそのままの
形で指定する。
例) DEVNAME, FILENAME, DUMMY, *, (, )
オペランド
DEVNAME(装置名)
FILENAME(
*
)
ファイル名
DUMMY
(2)機能
BACKUPコマンドは・・・・・
(3)オペランドの説明
① DEVNAME(装置名)
DEVNAMEオペランドは, バックアップ装置
の名前を指定する。指定できる装置は・・・
:
:
非終端記号
入力する時に実際の値と置き換えて指定する。
例) 装置名, ファイル名
構文表記記号
終端記号や非終端記号の指定条件を表す。
- 大括弧［］：大括弧内の項目は省略ある
いは一つ選択する。
- 中括弧｛｝：中括弧内の項目を一つ選択
する。
- 繰り返し記号・・・：直前の項目を繰り返す。
- 省略時の標準＿(ｱﾝﾀﾞｰﾗｲﾝ)：省略時の
標準値を示す。
- 選択｜：選択項目の区切りを示す。
図－４構文表記法に基づく外部仕様の表現
3.2 ひな型タイプの知識
テスト要因分析における基本的な知識単位は、テスト要因分析表の縦の列、すなわち因
子とその因子に対する状態値の組である。典型的な因子＋状態を「ひな型」として登録し
ておき、テスト要因分析を行う際に必要な「ひな型」知識を検索して利用する。
1) 単純型知識
論理型分析、既定事実型分析を行なうことにより得られる状態を、因子の名前をキ
ーとして要因データベースに蓄積しておく。因子名には外部仕様に記述されている用
語を用いることにより、同名異物／異名同物の要因が蓄積されないようにしておく。
2) 連想型知識
連想型知識は、単純型知識及び連想型知識の集合である。その集合の定義は、関連
する因子群に対して上位の名前（因子グループ名）を付けることにより行う。この情
報も要因データベース上に蓄積する。
連想型知識の検索も、単純型知識と同様の形で検索され、関連を持つすべての要因
を表示する。図－５にその様子を示す。
<要因分析画面>
A
因子
1
状 2
B
<要因分析画面>
C
因子
DEVNAME
オペランド
テスト要因を展開
装置名
1
状 2
指定しない
態 3
<要因データベース>
4
A
B
C
DEVNAME
オペランド
装置名
の長さ
装置名
の文字種
装置名
最小
(1文字)
正しく指定
指定しない
態 3
4
先頭が
中間
(2～7文字) 英字以外
最大
(8文字)
不正な文字
を含む
9文字以上
要因ひな型装置名
装置名
の長さ
最小
(1文字)
中間
(2～7文字)
最大
(8文字)
9文字
以上
装置名
の文字種
正しく指定
先頭が
英字以外
不正な文字
を含む
図－５ひな型知識の利用
3.3 知識ベースタイプの知識
ひな型タイプの知識は固定的な知識であるため、柔軟性に欠け、知識量が爆発しやすい
という問題がある。このため、動的に知識活用の判定や新たな知識獲得を行う仕組みとし
て AI の技術を応用することにし、要因分析を行うための知識の内、手続き的な知識をルー
ル型知識、既定事実や宣言的知識をフレーム型知識として知識ベースに登録し、活用する。
1) ルール型知識(プロダクションルール)
IF THEN の形式で知識を表現する。以下の知識をルール型知識として登録する。
・推論全体を制御するメタルール(ルールを適用するためのルール)
・因子、状態を生成するためのルール(論理的知識、経験的知識)
・フレーム型知識において不確実な事実を決定するためのルール
2) フレーム型知識
概念を複数のスロットから構成されるフレームとして表現する。以下の知識をフレ
ーム型知識として登録する。
・テスト対象ソフトウェアの既定事実型知識
・テスト要因分析を行うためのソフトウェアの一般的知識(例えば、使用可能な文字
種別、文字数など、標準や OS の仕様で決まっている事項)
図－６に知識ベースを用いた要因分析エキスパートシステムを示す。
ルール型知識(プロダクションルール)
・推論全体を制御するメタルール
・因子／状態生成ルール(論理型、経験的知識)
・フレーム型知識の未確定事項決定ルール
DEVNAME(装置名)
FILENAME(
*
)
ファイル名
DUMMY
A
因子 DEVNAME
オペランド
1
状
装置名
要因分析
エキスパート
システム
B
C
D
装置名
の長さ
装置名 FILENAME DUMMY
の文字種オペランドオペランド
最小
(1文字)
正しく指定
*
4
最大
(8文字)
不正な文字
を含む
9文字以上
省略
フレーム型知識
・テスト対象ソフトウェアの既定事実型知識
・要因分析のためのソフトウェアの一般的知識
ファイル・フレーム
ｽﾛｯﾄ1：装置
Disk｜Tape｜FPD｜他
ｽﾛｯﾄ2：入出力
入力｜出力｜入出力
ファイル名・フレーム
ｽﾛｯﾄ1：対象
ファイル
ｽﾛｯﾄ2：形式
名
ｽﾛｯﾄ3：因子展開型名前指定
ｽﾛｯﾄ4：開始文字
ルール起動
ｽﾛｯﾄ5：使用可能文字ルール起動
ｽﾛｯﾄ6：単純名けた数８
ｽﾛｯﾄ7：禁止指定
ルール起動
ファイル名スロット決定ルール
開始文字
IF 装置＝ Disk
THEN 開始文字＝ (英字、各国用文字)
IF 装置＝ Tape
THEN 開始文字＝英字
IF 装置＝ FPD
THEN 開始文字＝英字
・・・・
E
指定する
中間
先頭が
2 指定しない (2～7文字)
ファイル名
英字以外
態 3
IF 因子展開型＝数値指定型
THEN 状態値＝ "最小値より小/E"、"最小値"、
"中間値"、"最大値"、
“最大値より大/E”、“指定誤り”
IF ・・・・
省略
誤った指定
その他
図－６知識ベースの利用
4. テスト要因分析エキスパートシステムの処理の流れ
1) 機能定義表の解析
1-1) オペランドの指定方法に関する要因の抽出
テスト対象の外部仕様を構文表記法で記述した「機能定義表」を入力とし、構文
表記法と抽出すべきテスト要因の間の変換規則に従って因子－状態値群を生成する。
1-2) 非終端記号の抽出と推論機能の起動
非終端記号を識別し、関連因子の類推のキーワードとして推論機能に渡す。
2) 推論機能による非終端記号の意味理解とテスト要因の生成
2-1) 非終端記号を構成する単語の識別
機能の作用主体、修飾語、助詞、形式(名、数、・・・)を識別して抽出する。
2-2) 非終端記号の形式面に応じたテスト要因の生成
・因子展開型(状態値生成のタイプ)を以下の３つに大別
- 名前指定型：名前の命名規則を元に因子や状態値を生成
- 数値指定型：指定可能な数値範囲を限界値分析・同値分割
- 選択型：各選択可能値、省略、誤った指定を状態値として生成
・非終端記号の最後の語句をキーに因子展開型を識別
ｘｘ名、ｘｘＩＤ、ｘｘ識別名など
→
名前指定型
ｘｘ長、ｘｘ量、ｘｘ数、ｘｘサイズなど → 数値指定型
ｘｘ形式、ｘｘタイプ、ｘｘ属性など
→
選択型
2-3) 非終端記号がどのような概念を表すのかの推論(意味的なものの因子抽出と展開)
・非終端記号で表された「主体」(ｘｘの部分で、ソフトウェアの機能の作用対象)
をキーとして知識ベースを検索し、登録されている知識を抽出
・主体に対する「修飾語」や「はたらき(動詞)」があれば、その内容により推論を制
御(展開、絞り込み)
・解決できない知識があれば、使用者に問い合わせて推論を続行
3) 推論結果をテスト要因分析表として出力
図－７にエキスパートシステムを組み込んだテスト設計支援システムを示す。
テスト設計支援システム
<要因データベース>
関連要因
・・
γ
β
α
c1
c2
：
b1
b2
：
a1
a2
：
テスト知識蓄積
技法、経験則、
エラー分析
<テスト知識登録>
α
β
a1
a2
：
b1
b2
：
[テスト熟練者]
ルール
フレーム
<外部仕様入力>
外部仕様解析
*
FILENAME(
<知識ベース>
[テスト担当者]
DEVNAME(装置名)
)
ﾌｧｲﾙ名
DUMMY
フレーム
ルール
テスト知識検索
<要因分析表データベース>
テスト要因分析表
編集・管理
要因分析表
<テストｹｰｽ表データベース>
テストケース設定
(組み合わせ)
<要因分析表作成>
Ｘ α β
状態1 x1 a1 b1
状態2 x2 a2 b2
状態3 x3
<制約条件の指定>
制約1
制約2
E x1 a2
R x3 a2 b2
<テストケース表作成>
ﾃｽﾄｹｰｽ表
テストケース表
編集・管理
Ｘ α β
項目1 x1 a1 b1
項目2 x2 a1 b1
項目3 x1 a2 b1
図－７テスト設計支援システム
おわりに
このシステムでは、テスト設計技法やノウハウを IF-THEN ルールとフレームで書き表せ
るようにすることを目指した。完成させることはできなかったが、アイデアを具体化する
過程で、一部ではあるがテスト設計の思考プロセスを明確にできたように思う。
半年ほど前に CLIPS(C Language Integrated Production System)というエキスパート
システム構築ツールがあることを知った( http://clipsrules.sourceforge.net/ )。日本語が扱
えないという問題はあるが、1985 年から開発が続けられており完成度は高い。今後、CLIPS
で試行してみたい。そして、さらにしつこくアイデアを温め、いつの日か孵したい。
ところで、一緒にしつこく考えてくれる方はいらっしゃいませんか？
以
上

Download Report