経営情報システム学特論2 10．テスティング（1）research.nii.ac.jp/~f-ishikawa/work/UEC-MItoku2/MItoku2-10-testing1.pdf · ソフトウェア・テストの技法第2版

SS専攻経営情報システム学講座客員石川冬樹

[email protected]

経営情報システム学特論２１０．テスティング（１）

イントロダクション数理論理学とプログラム検証形式仕様記述テスト手法事例・動向紹介

2f-ishikawa @ MI特論2

講義計画

テストの考え方について概観する様々な観点からの分類を知るテストの「良さ」に関する観点を議論するホワイトボックステストの手法を知る

本日からの「テスト」に関する参考書ソフトウェア・テストの技法第2版G. J. Myers，長尾・松尾訳，近代科学社，2006ソフトウェアのテスト技法，宗訳，日経BP社，2005


本日の内容

テスト概論（１）目標様々な観点からの分類ホワイトボックステストの手法ブラックボックステストの手法


目次

テスト：ソフトウェアを調べ，不具合，バグまたは障害（fault）を発見するために故障（Failure）を発生させる実装されたプログラムの検証，妥当性確認のために最も確かな方法すべての不具合を確実に発見することはできない


テスト

プログラム………………

………………

テスト

Observed Expectedレビュー測定 Error

Failure

Fault

Error（エラー）：理論的に正しい値や条件に対する，計算，観察，測定された値との差異Fault（障害，またはバグ，不具合）：プログラムに含まれる誤ったステップ，プロセスまたはデータ定義Failure（故障）：要求される機能が完了しない状態


用語の確認

プログラム………………

………………

テスト

Observed Expectedレビュー測定 Error

Failure

Fault

（正当性）検証：「成果物を正しく作っている？」その成果物が満たすべき性質（基準）を満たす？

妥当性確認：「妥当な成果物を作っている？」自身や顧客の本来の要求に合致している？


（再掲）用語：「正当性」・「検証」

V&V検証（Verification）

妥当性確認（Validation）

初回資料より

例：起きうるすべての実行パスを検査するためには，何回（何種類）の実行が必要？


問題：「よい」テストとは？

Repeat times<= 10

A

B C

X Y Z U

Yes

NoYes Yes

No

No

例：起きうるすべての実行パスを検査するためには，何回（何種類）の実行が必要？



Repeat times<= 10

A

B C

X Y Z U

Yes

NoYes Yes

No

No

4+42+43+…410 ≧ 106これだけのプログラムで

完璧になれないのであれば・・・最小限の労力で，「ベストな成果」を得る例：絶対値を求めるプログラム（？）

テストケースの集合として，どちらの方が，不具合を見つける能力がありそうか？



if (x>=1) return x else return –x

1. input x = 3, check the result is 32. input x = 5, check the result is 5

1. input x = 3, check the result is 32. input x = -3, check the result is -3

対象プログラム入力ダイアログから，3つの整数を読むこれらは三角形の3辺の長さを表すとし，不等辺三角形，二等辺三角形，正三角形のいずれであるかを示すメッセージを表示する

テストケースの集合を定義してみよ


クイズ

評価指標例1. 意味のある不等辺三角形を入力するテストケースを含めているか？

2. 意味のある正三角形を入力するテストケースを含めているか？

3. 意味のある二等辺三角形を入力するテストケースを含めているか？

4. 上記3において並び順の異なる，最低3つのテストケースを含めているか？

例： (3, 3, 4) (3, 4, 3) (4, 3, 3)5. 1つの辺が0となるテストケースを含めているか？6. 1つの辺が負となるテストケースを含めているか？


クイズ

評価指標例（続）7. 正の3つの値を持ち，うち2つの和がもう1つと等しいようなテストケースを含めているか？

例： (1, 2, 3 )など8. 上記7において，最も大きい値の場所が異なる，最低3つのテストケースを含めているか？

例： (1, 2, 3), (1, 3, 2), (3, 1, 2)9. 正の3つの値を持ち，うち2つの和がもう1つより小さいようなテストケースを含めているか？

10.上記9において，最も大きい値の場所が異なる，最低3つのテストケースを含めているか？


クイズ

評価指標例（続）11.すべての辺が0であるテストケースを含めているか？

12.整数でない値を持つテストケースを含めているか？13.整数の個数が間違っているようなテストケースを少なくとも1つ含めているか？

14.ここまでのテストケースにおいて，予想される出力を定義したか？


クイズ

（最後のもの以外）それぞれ異なる種類の誤りに対応している7.8/14点が専門プログラマの平均点とのこと

どのようにして，こういったテストケースを系統的に導けるのか？「頭がいい」「センスがある」「経験がある」から，だけではないようにしたい（属人性をできる限り排除したい）

次回のトピック（今回はより広い観点からの概観のみ）


クイズ

完璧たり得ないため，テストの完了基準を定めることも非常に難しい「（何となく決めた）時間または金額を使い切ったら」には，本質的な意味がない「定めたテストケースで不具合が見つからなかったこと」では，さぼればよいことになってしまう

統計・経験則に基づく判断プログラム行数などに対して，見つかると期待される不具合の数一定時間内に見つけた不具合数の変化・・・


テストの終了

心理的な側面を考慮した原則前もって予想される出力・結果を定義しておく自分自身，自分たちのグループで，自分のプログラムをテストしない誤った入力も考えてテストケースを書く意図された動きをするかどうかだけでなく，意図されなかった動きをするかどうかも調べるエラーはないだろうという想定はしないプログラムのうちエラーが多く見つかった部分においては，多くエラーがまだ残っているプログラムの書き手に対する批判をしない創造的な挑戦と見なす


心理的な側面



目次

動的テストプログラム実行

静的テストインスペクション（レビュー），ウォークスルーチェックリストに照らし合わせる，あるいは頭の中でテストケースに対するプログラム実行を再現し追ってみる※ この後者がウォークスルーであるという定義，プログラマ自身が非公式に行うのがウォークスルーという定義などが混在している模様（「立ち稽古」の意）


分類観点（１）：静的・動的

もちろん，系統的に行うべきである時間を決め，グループを構成して行う（議長，該当部分の担当プログラマ，若手，ベテランなど）照らし合わせるルールを明確にするとよい初期値未定義，配列インデックス範囲，異なる数値表現の混合演算，論理式解釈，ループ停止，パラメーターの単位，・・・

不具合の指摘は，プログラマに対する批判とならないようにする（プログラミング言語・環境が未成熟であり，誰でも当然誤りを犯す）


静的テスト

ホワイトボックステストプログラムの内部構造を踏まえてテストを設計する（例： if-else文の分岐両方を通るようにする）

ブラックボックステストプログラムの内部構造は意識せず，仕様に基づいてテストを設計する（例：状態遷移図やユースケースに基づいてテストを定める）


分類観点（２）：ホワイト・ブラック


分類観点（３）：工程

RequirementsModeling

[C. Bucanac, 1999]

ArchitecturalDesign

ComponentDesign

CodeGeneration

Executable Software

AcceptanceTesting

SystemTesting

IntegrationTesting

UnitTesting

初回資料より

Unit test（ユニットテスト・単体テスト）：メソッドなど小さい部品を対象に行うIntegration test（結合テスト・統合テスト）：個々はテスト済みである部品の組み合わせを対象に行うSystem test（システムテスト）：ネットワーク，ハードウェア，データベースなど他のシステム要素との組み合わせを対象に行うAcceptance test（受け入れテスト）：実際の利用状況としてユーザ，負荷，長期実行などを対象に行う


分類観点（３）：工程

不具合の追求を容易とするため，各テストケースでは対象部分に集中したいテストドライバー：対象プログラムを特定の入力で呼び出し，結果を観測するテストスタブ：実装またはテストが終わって居合い部品の機能を擬似的に提供する


基本概念：ドライバ・スタブ

int m1 (int x){...m1_sub(...)...

}

Target program

p = ...result = m1 (p);...

Test driverm1_sub(int n){

switch (n){case 0:return 2;case 1:return 3;...

Test stub

ドライバー・スタブを用いて特定の小さな部品に集中するXUnitフレームワークを活用することが多い（Junit，CppUnit，PHPUnit，…）アサーション（表明）を用いて個々のテストケースを分離して定義するそれらを登録し，まとめて実行，記録する


ユニットテスト

public class TestCase1extends TestCase{

public void testFun1(){...assertEqual( x, 3 );

}}

suite.addTest(new TestCase1());suite.addTest(new TestCase2());...suite.run(result);...

部品の組み合わせは段階的に行うそうでない場合，不具合の同定が難しくなる（ビッグバンテストという用語まである）トップダウンまたはボトムアップに増加テスト

Bottom-upの方がは後から大きな変更が発生しやすいTop-downの方が実装と並行に行いづらい


結合テスト

A

CB

FED

Top-down1. A and B(with C stub)

2. A, B, and C(with D, E, F stubs)

3. A. B, C, and D(with E, F stubs)

4. …

Bottom-up1. C and D(with E, F stubs)

2. C, D, and E(with F stub)

3. C, D, E, and F4. …

システムとしての仕様・設計に基づき様々なテストを行う（ブラックボックス）高負荷（stress testing）性能（performance testing）大容量（volume testing）使いやすさ（usability testing）セキュリティ，記憶域，構成，互換性，設置容易性，信頼性，回復，保守性，人手での手続き，ドキュメント，・・・

受け入れテストはユーザー側の承認・確認作業実際のユーザー，実際のデータ，・・・


システムテスト・受け入れテスト

回帰テスト（regression test）以前のバージョンより悪くなっていないかを調べるプログラムのある箇所の修正により，別の機能に不具合が出ることは多々あるRegression（回帰，退行）やdegrade（退化する）といった言葉で説明される


回帰テスト



目次

論理網羅（Coverage）：「構成要素」が検査されているかにより，テストケースの集合を評価


カバレッジ

基準名対象要素命令網羅・C0 (Statement Coverage) 命令判定条件網羅・分岐網羅・C1(Decision Coverage, Branch Coverage)

分岐判定の取り得る結果

条件網羅 (Condition Coverage) 分岐判定の個別条件が取り得る結果

判定条件／条件網羅・分岐／条件網羅(Decision/Condition Coverage,Branch/Condition Coverage)

上記2つ

複数条件網羅(Multiple-condition coverage)

分岐判定の個別条件が取り得る結果の組合せ

命令網羅・C0 (Statement Coverage)各命令が少なくとも1回実行されるか？例：右のプログラムに対してa = 2, b = 0, x = 3


命令網羅

a > 1 AND b = 0

x=x/a

x=x++

a = 2 OR x > 1

判定条件網羅・分岐網羅・C1(Decision Coverage, Branch Coverage)各分岐判定の取り得る結果が少なくとも1回実行されるか？（if文，switch文など）例：右のプログラムに対してa = 3, b = 0, x = 3a = 2, b = 1, x = 1


判定条件網羅

a > 1 AND b = 0

x=x/a

x=x++

a = 2 OR x > 1

判定条件網羅を満たすテストケースの集合が，命令網羅も満たさない例外もある到達しない命令がある場合（という不具合がある）対象プログラム実行の入り口が複数ある場合（それらも網羅する必要がある）

通常命令網羅は必須とするため，判定条件網羅も命令網羅を含むとすることが多い判定条件網羅を満たしても漏れる場合がある後述


判定条件網羅

条件網羅(Condition Coverage)各分岐判定の個別条件が取り得る結果が少なくとも1回実行されるか？例：右のプログラムに対してa = 1, b = 0, x = 3a = 2, b = 1, x = 1（a > 1, a <= 0, b = 0, b != 0,a = 2, a != 2, x > 1, x <=1をすべて試している）


条件網羅

a > 1 AND b = 0

x=x/a

x=x++

a = 2 OR x > 1

条件網羅を満たしても，判定条件網羅を満たさない場合はありうる例： if P AND Qに対して

P = true, Q = falseP = false, Q = true


条件網羅

判定条件／条件網羅・分岐／条件網羅(Decision/Condition Coverage, Branch/Condition Coverage)判定条件網羅と条件網羅をともに満たすか？例：右のプログラムに対してa = 2, b = 0, x = 4a = 1, b = 1, x = 1


判定条件／条件網羅

a > 1 AND b = 0

x=x/a

x=x++

a = 2 OR x > 1

判定条件網羅や条件網羅，それらの両方を満たしても漏れる場合がある判定条件内の誤り（例：P AND QでPが偽であった場合にQに関する設定は使われない）次で対応特定のパス（例： 2つの分岐がともに偽）これは困難なので，テスト基準としてはあまり考えない（モデル検査ツールはこれを扱う）


判定条件／条件網羅

複数条件網羅(Multiple-condition Coverage)各分岐判定の個別条件が取り得る結果の組み合わせすべてが少なくとも1回実行されるか？例：右のプログラムに対してa = 2, b = 0, x = 4 (T-T, T-T)a = 2, b = 1, x = 1 (T-F, T-F)a = 1, b = 0, x = 2 (F-T, F-T)a = 1, b = 1, x = 1 (F-F, F-F)


複数条件網羅

a > 1 AND b = 0

x=x/a

x=x++

a = 2 OR x > 1

以上は「可能であれば」であるともに真にはなり得ない組み合わせ，などもある

テストケース生成やカバレッジ測定のための，多くのツールが利用可能である満足or 不満足ではなく割合で考えることも多い非常に希な状況などもあり，コストの兼ね合いから，「90%検査すればよし」などと決めることも多い

判定条件網羅（C1）を必須とすることが多いそれより厳しい条件では，テストケースの数が膨大となり，個々のテストケースを決めるのも難しい


カバレッジ

テスト（１）正しさの定義（期待される結果）に対する検証，本来の要求に対する妥当性確認を行う完璧にあらゆる不具合を見つけることはできず，費用対効果を追求する工程・目的に応じて様々なアプローチがある潜在的な不具合を効率よく顕在化させるような，テストケースの設計を目指すホワイトボックステストでは，構成要素に対するカバレッジを指標として，それを高めるようテスト設計を行う

次回：引き続きテスト技法を扱う40f-ishikawa @ MI特論2

今回のまとめ

Documents

経営情報システム学特論2 10．テスティング（1）research.nii.ac.jp/~f-ishikawa/work/UEC-MItoku2/MItoku2-10-testing1.pdf · ソフトウェア・テストの技法第2版