ソフトウェア・テスト入門5

第5回「モジュール・テスト」
2011年7月7日（木）
服部健太
ソフトウェア・テスト入門

モジュール・テストとは
2011/7/7ソフトウェア・テスト入門５2
 １つのプログラムのなかのサブプログラム，サブ
ルーチン，プロシージャのテスト過程のこと
 最初から全体としてテストするのではなく，まずプログ
ラムのより小さな構成要素に焦点をあててテストする
 動機：
 テストで生じる組合せの問題をのがれることができる
 エラーが見つかった時，デバッグ作業が容易になる
 複数のモジュールを同時にテストすることができる
 目的：
 あるモジュールの機能を，そのモジュールを定義してい
る機能仕様，あるいはインタフェース仕様と比較する

テスト・ケースの設計
 必要なもの
 モジュールの仕様
 入出力のパラメータ，機能など
 モジュールのソース・コード
 テスト・ケース設計の手順
 ホワイトボックス手法を２つ以上つかってモジュー
ルの論理を分析する
 それから，モジュール仕様にブラックボックス手法
を適用して，これらのテスト・ケースを補足する

例：BONUSモジュールのテスト
 機能
 最大の売り上げをもつ１あるいは複数の部門の全従業員の給与に
200ドル加える
 ただし，その資格のある従業員の現在の給与が15,000ドル以上か，
従業員がマネージャである場合には，100ドルだけの増額とする
 モジュールへの入力
 出力
 エラーコード0：モジュールが正しく機能した
 エラーコード1：どちらかのテーブルに項目が入っていない
 エラーコード2：資格のある部門に従業員がみつからない
名前仕事コード部門給与部門売上
従業員テーブル部門テーブル

BONUSモジュールのソースコー
ド
SINC = 200.00; LINC = 100.00; LSALARY = 15000.00; MGR = ‘M’
def bonus(emptab, deptab, esize, dsize):
errcode = 0; max_sales = 0
if esize <= 0 || dsize <= 0: errcode = 1
else:
for i = 1 to dsize: # 最大の売上高を求める
if deptab[i].sales >= max_sales: max_sales = deptab[i].sales
for j = 1 to dsize: # 最大売上高の部門を探す
if deptab[j].sales == max_sales:
found = False
for k = 1 to esize: # その部門の各従業員に対してボーナスを加える
if emptab[k].dept == deptab.dept(j):
found = True
if emptab[k].salary >= LSALARY || emptab[k].code == MGR:
emptab[k].salary += LINC
else: emptab[k].salary += SINC
if not found: errcode = 2
return errcode

プログラムの判定条件
 各for文は少なくとも1回は反復する
 どんなテストケースでも両方向に分岐するのでfor文は特
に注意する必要なし
 分析すべき対象：
1. if esize <= 0 || dsize <= 0
2. if deptab[i].sales >= max_sales
3. if deptab[j].sales == max_sales
4. if emptab[k].dept == deptab.dept(j)
5. if emptab[k].salary >= LSALARY
|| emptab[k].code == MGR
6. if not found

判定結果に対応する状況
判定真の出力偽の出力
1 esizeかdsizeが0以下 esizeとdsizeが1以上
2 いつも少なくとも1回はおきる低い売上の部門がより高い売上
をもつ部門のあとにでてくるよ
うにdeptabを並べる
3 いつも少なくとも1回はおきるすべての部門が同じ売上をもつ
とはかぎらない
4 資格のある部門に1人の従業員
がいる
資格のある部門に所属していな
い従業員がいる
5 資格のある従業員はマネージャ
かLSALARY以上もらっている
資格のある従業員はマネージャ
でなく，LSALARYより少ない給
与をもらっている
6 資格のある部門に従業員がいな
い
資格のある部門に少なくとも1人
の従業員がいる

判定条件（分岐）網羅基準を満たす
テスト・ケース
テスト
ケース
入力期待される出力
1 esize=0
他のすべての入力は無関係
errcode=1
esize,dsize,emptab,deptabは
変わらない
2 esize=dsize=3
emptab
deptab
errcode=2
esize,dsize,deptabは変わらな
い
emptab
JON
ES
E D4
2
21,000.00
SMIT
H
E D3
2
14,000.00
LORI
N
E D4
2
10,000.00D4
2
10,000.00
D3
2
8,000.00
D9
5
10,000.00
JON
ES
E D4
2
21,100.00
SMIT
H
E D3
2
14,000.00
LORI
N
E D4
2
10,200.00
調べていない状況の例：
エラーコードが0，従業員がマネージャ，部門テーブルが空白の状況，etc.

条件結果に対応する状況
判定条件真の出力偽の出力
1 esize <= 0 esize が0以下 esizeが0より大きい
1 dsize <= 0 dsizeが0以下 dsizeが0より大きい
2 deptab[i].sales >=
max_sales
いつも少なくとも1回はおきる低い売上の部門がより高い売
上をもつ部のんのあとにでて
くるようにdeptabを並べる
3 deptab[j].sales ==
max_sales
いつも少なくとも1回はおきるすべての部門が同じ売上をも
つとはかぎらない
4 emptab[k].dept==
deptab.dept(j)
資格のある部門に従業員がい
る
資格のある部門に所属してい
ない従業員がいる
5 emptab[k].salary >=
LSALARY
資格のある従業員はLSALARY
以上もらってる
資格のある従業員は
LSALARYより少ない給与を
もらってる
5 emptab[k].code = MGR 資格のある従業員はマネー
ジャである
資格のある従業員はマネー
ジャでない
6 not found 資格のある部門に従業員がい
ない
資格のある部門に少なくとも
1人の従業員がいる

条件網羅基準を満たす
テスト
ケース
1 esize=dsize=0
errcode=1
esize,dsize,emptab,deptabは
変わらない
2 esize=dsize=3
emptab
deptab
errcode=2
い
emptab
JON
ES
E D4
2
21,000.00
SMIT
H
E D3
2
14,000.00
LORI
N
M D4
2
10,000.00D4
2
10,000.00
D3
2
8,000.00
D9
5
10,000.00
JON
ES
E D4
2
21,100.00
SMIT
H
E D3
2
14,000.00
LORI
N
M D4
2
10,100.00
条件網羅基準は満たすが，p.8のテストケースより貧弱
たとえば，一部の命令は実行されない

判定条件／条件網羅基準の検討
 JONESをマネージャに，LORINをヒラにするこ
とで可能
 判定条件5の両方の結果を生成し，すべての命令が
実行される結果が得られる
 問題点：
 p.8のテスト・ケースより本質的によくはなってい
ない
 例：コンパイラが論理式orの解釈を短絡する場合，
emptab[k].code == MGRが真の結果になるパタンは実行さ
れないので，この論理式にあやまりがあっても，このテス
トケースでは，そのエラーを発見できない

複数条件網羅基準を満たす
テスト
ケース
1 esize=dsize=0
errcode=1となる．
esize, dsize, emptab, deptab
は変わらない
2 esize=0, dsize>0
上記と同じ
3 esize>0, dsize=0
上記と同じ
4 esize=5, dsize=4
emptab deptab
errcode=2
い
emptab
JON
ES
M D4
2
21,000.00
WAR
NS
M D9
5
12,000.00
LORI
N
E D4
2
10,000.00
TOY E D9
5
16,000.00
SMIT
H
E D3
2
14,000.00
D4
2
10,000.00
D3
2
8,000.00
D9
5
10,000.00
D4
4
10,000.00
JON
ES
M D4
2
21,100.00
WAR
NS
M D9
5
12,100.00
LORI
N
E D4
2
10,200.00
TOY E D9
5
16,100.00
SMIT E D3 14,000.00

考察
 複数条件網羅基準を満たすテストケースでも発見で
きないエラーの例：
 errcodeの初期化忘れエラーが発見できない
 errcodeが0でかえってくる状況のケースが無い
 LSALARYが15000.01に間違って設定されていた場合の
エラー
 emptab[k].salary >= LSALARYの>=が間違って>になっ
ていた場合のエラー
 そのほかの「1つ違いのエラー」
 deptabやemptabの最後の項目が正しく処理されていない場合
⇒ブラックボックステストによってテストケースを補足
する

BONUSモジュールのI/F仕様
 emptab：（入出力）従業員テーブル
 最大売上部門にいる従業員の給与をあげる
 給与が15000.00以上かマネージャの場合100ドル増やす．そうでなけ
れば200ドル増やす
 deptab：（入力）部門テーブル
 esize：（入力）従業員テーブルの項目数
 dsize：（入力）部門テーブルの項目数
 errcode：（戻り値）エラーコード
 esizeとdsizeが0より大きくなかったら1にして実行をやめる．
それ以外なら機能は実行される
 ただし，ある最大売上部門に従業員がいないとわかったら，
処理は続行されるがエラーコード2が返される
 そうでなければ0がセットされる
 備考
 各テーブルの項目順についてはどのような仮定もない

限界値分析
【入力限界】
1. emptabは1項目をもつ
2. emptabは最大数の項目をもつ
3. emptabは空
4. deptabは1項目をもつ
5. deptabは最大数の項目をもつ
6. deptabは空
7. 最大売上部門に1人の従業員がいる
8. 最大売上部門に最大人数の従業員
9. 最大売上部門に従業員がいない
10. deptabのすべての部門は同じ売上高
11. 最大売上部門はdeptabの最初の項目
12. 最大売上部門はdeptabの最後の項目
13. 資格のある従業員はemptabの最初の
項目
14. 資格のある従業員はemptabの最後の
項目
15. 資格のある従業員はマネージャ
16. 資格のある従業員は非マネージャ
17. 管理者でない資格のある従業員が
14,999.99ドルの給与
15,000.00ドルの給与
15,000.01ドルの給与
【出力限界】
20. errcode=0
21. errcode=1
22. errcode=2
23. 資格のある従業員の増額された給与が
最大（99999.99）である
【エラー推測技法】
24. deptabで，従業員のいない最大売上部
門の直後に従業員のいる最大売上部門
がある
赤色はまだカバーされていない条件
灰色は非実際的なので除く条件

限界値分析によるテスト・ケース
テスト
ケース
5 esize = 3, dsize = 2
emptab deptab
errcode = 0
esize,dsize,deptabは変らず
emptab
emptab deptab
errcode = 0
emptab
emptab deptab
errcode = 2
emptab
ALLY E D3
6
14,999.99
BES
T
E D3
3
15,000.00
CELT
O
E D3
3
15,000.01
D3
3
55,400.01
D3
6
55,400.01
ALLY E D3
6
15,199.99
BES
T
E D3
3
15,100.00
CELT
O
E D3
3
15,100.01
CHIE
F
M D9
9
99,899.99 D9
9
99,000.00
CHIE
F
M D9
9
99,999.99
DOL
E
E D6
7
10,000.00
FOR
D
E D2
2
33,333.33
D6
6
20,000.00
D6
7
20,000.00
DOL
E
E D6
7
10,200.00
FOR
D
E D2
2
33,333.33
条件7,10,14,17,
18,19,20をカバー
条件1,4,23
をカバー
条件24
をカバー

モジュール結合の方法
 増加テスト
 テストすべき次のモジュールを，すでにテストした
モジュールのセットと結合してからテストする
 ビッグバンテスト
 各モジュールを別々にテストしてから，最後にそれ
らモジュールを結合してプログラムを形成する
A
CB D
E F
B
A
E
スタブモジュール
ドライバモジュール
テストしたい
モジュール

増加テストvsビッグバンテスト
 ビッグバンテストのほうが多くの作業を必要とする
 増加テストを使うと，モジュール間の適合しないインタ
フェースあやまりが早期に発見できる
 増加テストを使う方がエラーの位置を特定しやすいためデ
バッグが容易
 増加テストでは，最初の方に結合されたモジュールはその
後，何度もテストされることになるため，テストを進めて
いくほど効果的になる
 ビッグバンテストの方がコンピュータ使用時間が少なくて
済むが，より多くのドライバやスタブを必要とする
 ビッグバンテストをつかうと，モジュールテストの最初の
段階で並行処理をおこなう機会が多くなる
⇒ 一般的には増加テストの方がすぐれている

モジュール・プログラム例
A
CB D
F HE G I
J K L
I/O読み込み
I/O書き出し

トップダウン・テスト
 プログラムの頂上のモジュールからはじめる
 例の場合，モジュールAからテストする
 モジュールAをテストするには，B,C,Dをあらわ
すスタブモジュールを書かなければならない
 スタブは正しい値を返す必要がある
 スタブを作成するのはやさしい仕事ではない
 モジュールAのテストケースをどうやってあたえ
るか？
 1つ以上のスタブからそのモジュールにテスト・
データを与える

トップダウン・テスト（２）
 Aをテストしたあとで，スタブのうちの1つが，次に
テストするモジュールに置き変わり，そのモジュー
ルに必要なスタブを追加する
 プログラムにクリティカルな部分があるばあい，こ
れらの部分を早めに加えるように順序を設計する
 I/Oモジュールができるだけ早く加えられるように順
序を設計する
A
CB D
FE

トップダウン・テスト（３）
 利点：実際に動く骨組みが早い時点でできあがる
 欠点：この時点で，モジュールHを追加する場合，Hのテスト・ケースをカバー
するようなモジュールJへのテスト・データをしめすことは不可能かもしれない．
可能だとしても，テストデータを何にするのか決めるのは頭の痛い作業になる
ことが多い
 欠点：あるテストの表示された出力とそのモジュールで実行された内容との関
連づけがむずかしいか不可能でさえあることが多い
 欠点：他のモジュールにすすむまでは完全にそのモジュールをテストできない
ことがある
A
CB D
F HE I
J

ボトムアップ・テスト
 プログラムの末端モジュール（他のモジュールを呼ばない
モジュール）からはじめる
 ドライバモジュールが必要
 ドライバの方がスタブよりも作成しやすい
 弱点：早期の骨組みプログラムの利点は得られない
ドライバ
F
J
D
H I
K L
ドライバ

比較
トップダウン・テストボトムアップ・テスト
 長所
 おもな流れがプログラムの頂点へ
向かっているならすぐれている
 I/O機能が追加されれば，テスト・
ケースの表現がやさしくなる
 骨組みプログラムが早くデモ可能
 短所
 スタブ・モジュールの作成が必要
 スタブ・モジュールは最初に思っ
ていたより複雑なことが多い
 I/O機能が追加されるまでテスト・
ケースの表現が難しい
 テスト条件の作成が困難
 テストの出力をみるのが難しい
 あるモジュールのテスト完了が遅
れる
 長所
 おもな流れがプログラムの
底辺のほうへ向かっている
ならば，すぐれている
 テスト条件がより作成しや
すい
 テスト結果をみるのが容易
である
 短所
 ドライバ・モジュールの作
成が必要
 プログラムの本体は最後の
モジュールが加わるまで存
在しない
2011/7/724 ソフトウェア・テスト入門５

テストの実行
 モジュールの実際の結果と期待する結果が合わなかった場
合，モジュールのエラーかテストケースが正しくないかの
いずれか
 テストを行うまえにテスト・ケースのセットを検査しなけれ
ばならない
 自動テストツールを使うと，テストの単調な仕事を最小に
できる
 例：ユニットテストツール
 到達不能コード，未初期化変数の使用などはコンパイラによっては検
出可能なものもある
 モジュールをテストする人は作った人と別な方がよい（た
だしデバッグは作った本人が行う）
 モジュールの一部のサブセットで異常に多い数のエラーが
見つかった場合，そのようなモジュールはさらに詳しいテ
ストを行い，また，多くのコードのウォークスルーか検査
を追加する

次回予定
 日にち
 ２０１１年７月１５日（金）
 時間
 １０：３０～１２：００
 場所
 ＬＢ／２ＦＡ
 内容
 上級テスト

ソフトウェア・テスト入門5

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Similar a ソフトウェア・テスト入門5

Similar a ソフトウェア・テスト入門5 (20)

Más de Kenta Hattori

Más de Kenta Hattori (20)

Último

Último (20)

ソフトウェア・テスト入門5