ソフトウェア工学１第11回 テスト２

2017年7月4日

中島

1

授業内容

• テストケース設計技法

– ブラックボックス手法： 状態ベース

– ホワイトボックス手法： 命令網羅，分岐網羅

• テスト戦略と環境

• 総合テスト以降

2

テストとは （復習）

被テストプログラム

仕様 入力 出力期待値

( I1, O1 )( I2, O2 )

・・・

入力照合

出力

OK／NG

テストケース

テスト実行

不具合を検知するためにプログラムを実行すること

3

テスト仕様書／成績書

4

テスト項目 入力値 出力期待値 出力値 合否 備考

T1××テキストボックスへの正常値の入力

数値10を入力 ☆☆画面に遷移し、検索結果の文 字 列 「 豊洲」を表示

☆☆画面に遷移し、検索結果の文字列「豊洲」が表示された

○

（×であるばあい、必要に応じて状況を記述すること）

T2××テキストボックスへの予期せぬ入力値の対応

文字「あ」を入力

エ ラ ー メ ッセージ「数字を入力してください」を出力

エラーメッセージ 「 数 字 を 入力 し て く だ さい 」 が 出 力 された

○

• 単体，結合，総合，受入テストで利用• テストケースを予め書きだし(仕様），合否の記録を残す（成績）

テストとは： 何が難しいのか （復習）

• テストでは，プログラムに欠陥のないことを保証できない

テスト空間は膨大

テスト空間: すべての欠陥を発見できるテストの集合

テスト集合１

テスト集合２

テスト集合３

テスト集合４

残存欠陥

• 有限時間のテストでやり尽くすことはできない

5

1

2

N

パスの組み合わせ

2N

パスだけ考えても・・・

欠陥

テストとは： 課題と技法 （復習）

テスト戦略

テスト妥当性評価

テスト実行支援

テスト容易性の考慮

テストケース設計技法

テスト技法

課題1

課題2

システム開発計画

準備

実行

評価

計画

実施設計プロセス

テストプロセス仕様

被ﾃｽﾄﾌﾟﾛｸﾞﾗﾑ

品質目標の設定

テスト手順の計画

テスト終了判定

テスト環境の準備

テストケース設計

テスト実行と結果記録

課題1 テストを有限時間で最大効率をあげるものにする

6

課題2 テストで品質を保証したい（完了基準の設定）

テストケース設計技法 （復習）

• 少ないケース数で，漏れなく，欠陥の検出率を上げるテストケース集合を設計するやり方

7

• テストケース設計技法の種別

①ブラックボックステスト： 仕様に基づく抽出②ホワイトボックステスト： プログラムの構造に基づく抽出③ランダムテスト： ランダムな方法による抽出

ﾃｽﾄｹｰｽ設計技法 単体／結合テスト 総合テスト

ブラックボックス ○ ○

ホワイトボックス ○ ×

ランダム × ○

適用可能範囲

ブラックボックステスト

①同値分割： 入力条件のみに注目、代表値をとる

②限界値分析： 入出力条件の境界付近に注目

③状態ベース： 状態ベースの仕様より抽出

種別仕様に基づくテストケースの抽出方法

定義

8

ブラックボックステスト: 状態ベース

• 機能の網羅性を確認しやすい• 応用範囲が広い

GUI と その操作 機器制御 通信プロトコル 言語処理

状態ベースの仕様（状態遷移表）よりテストケースを直接

抽出する技法

状態ベースとは

特徴

例題： キッチンタイマーの仕様

• キッチンタイマーの液晶画面には、初めは0秒表示されており、時間設定中になっている。

• 時間設定中において： 「10秒」ボタンを押すと、現在表示されている秒

数に10足されて表示される。 「クリア」ボタンを押すと、秒数は0になる

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

例題： キッチンタイマーの仕様

• 時間設定中に「開始ストップ」ボタンを押すと表示時間が0秒より大きいならカウントダウン中になる。

• カウントダウン中は、1秒ごとに表示時間を1秒ずつ減らす（T: 表示時間）。

• カウントダウン中に「開始ストップ」ボタンを押すと、カウントダウンを中断し時間設定中に戻る。

• キッチンタイマーの液晶画面には、初めは0秒表示されており、時間設定中になっている。

• 時間設定中において： 「10秒」ボタンを押すと、現在表示されている秒

数に10足されて表示される。 「クリア」ボタンを押すと、秒数は0になる

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

例題： キッチンタイマーの仕様

• 時間設定中に「開始ストップ」ボタンを押すと表示時間が0秒より大きいならカウントダウン中になる。

• カウントダウン中は、1秒ごとに表示時間を1秒ずつ減らす（T: 表示時間）。

• カウントダウン中に「開始ストップ」ボタンを押すと、カウントダウンを中断し時間設定中に戻る。

• カウントダウン中に、表示時間が0になるとアラーム中に移り、アラームがONになる。

• アラーム中に「開始ストップ」ボタンを押すと、アラームをOFFし時間設定中に戻る。

• キッチンタイマーの液晶画面には、初めは0秒表示されており、時間設定中になっている。

• 時間設定中において： 「10秒」ボタンを押すと、現在表示されている秒

数に10足されて表示される。 「クリア」ボタンを押すと、秒数は0になる

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

after(1秒) / T=T-1

カウントダウン中

開始ストップ [T>0]

when(T=0)開始ストップ

アラーム中entry/ アラームON

開始ストップ

exit/ アラームOFF

10秒 / T=T+10 クリア/ T=0

/T=0 時間設定中

状態遷移図

ふるまいを正確にあいまいさなく 仕様記述

after(1秒) / T=T-1

カウントダウン中

開始ストップ [T>0]

when(T=0)開始ストップ

アラーム中entry/ アラームON

開始ストップ

exit/ アラームOFF

10秒 / T=T+10 クリア/ T=0

/T=0

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

時間設定中時間設定中

10秒 / T=T+10 クリア/ T=0

状態遷移図のシミュレーション

after(1秒) / T=T-1

カウントダウン中

開始ストップ[T>0]

when(T=0)開始ストップ

アラーム中entry/ アラームON

開始ストップ

exit/ アラームOFF

10秒 / T=T+10 クリア/ T=0

/T=0

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

時間設定中時間設定中

10秒 / T=T+10

開始ストップ[T>0]カウントダウン中

after(1秒) / T=T-1

開始ストップ

状態遷移図のシミュレーション

after(1秒) / T=T-1

カウントダウン中

開始ストップ[T>0]

when(T=0)開始ストップ

アラーム中entry/ アラームON

開始ストップ

exit/ アラームOFF

10秒 / T=T+10 クリア/ T=0

/T=0

10秒 ｸﾘｱ開始ｽﾄｯﾌﾟ

時間設定中時間設定中開始ストップ[T>0]

カウントダウン中

after(1秒) / T=T-1

when(T=0)

アラーム中entry/ アラームONexit/ アラームOFF

開始ストップ

状態遷移図のシミュレーション

■要求されたふるまいになっているか確認できる！！

after(1秒) / T=T-1

カウントダウン中

開始ストップ [T>0]

when(T=0)開始ストップ

アラーム中entry/ アラームON

開始ストップ

exit/ アラームOFF

10秒 / T=T+10 クリア/ T=0

/T=0 時間設定中

状態遷移図の弱点

状態遷移図では，ありえないイベント，無視するイベントを区別できない．

例： カウントダウン中に，クリアボタンを押すと？

３つの可能性あり・何もしない？・そのときクリアボタンは無効？・仕様の見逃し？

状態遷移表

18

• 状態に対して，すべてのイベントを対応づける．

• 交差したセルは，状態遷移を表す： 「ある状態のときに，あるイベントが発生すると，アクションを実行し，次の遷移先に移る．」

• 次の遷移先状態（上段）と，アクション（下段）を書く．

/ ありえない，- とどまる， nop 何も起こらない

ボタン10秒

ボタンクリア

T=0 after(1)

e1 e2 e4 e5T>0 elseS2 -

T:=T+10 T:=0 nop nop

- - S3 -

nop nop アラームON T:=T-1

- -

nop nop

S1

アラームOFF

S1

nop

S1

状態

イベント

時間設定中

カウントダウン中

アラーム中 S3

S2

ボタン開始ストップ

e3

- -

ブラックボックステスト:状態ベース

手順

セル網羅基準： 全セルを通過するようなテストケース抽出法

① 初期状態から，なるべく多くのセルをたどることができる

ようにイベント列を見いだす。

② 行き着けないセルがある場合には初期状態からたどり直

すようにする。すべてのセルを通過した時点で終わりであ

る。

ボタン10秒

ボタンクリア

T=0 after(1)

e1 e2 e4 e5T>0 elseS2 -

T:=T+10 T:=0 nop nop

- - S3 -

nop nop アラームON T:=T-1

- -

nop nop

S1

状態

イベント

S1

アラームOFF

S1

nop

時間設定中

カウントダウン中

アラーム中 S3

S2

ボタン開始ストップ

e3

- -

状態遷移表を使ったテストケースの生成

20

S1 e1 ◎10秒表示

S1 e2 ◎0秒表示

S1 e1 10秒表示

S1 e3 ◎カウントダウンスタート

S2 e3 ◎7秒でカウントダウンストップ

S2 e5(3秒) ◎7秒までカウントダウン

S1 e3 カウントダウンスタート

S2 e5(７秒) 0秒までカウントダウン

S3 e4 ◎0秒でカウントダウンストップ，アラームONS3 e3 ◎アラームOFF

入力 期待出力（◎照合すること）

テスト済の状態遷移

未テストの状態遷移

足りないテストケースを追加する

S1 e3 ◎変化なし

S2 e1 ◎カウントダウン継続

S2 e2 ◎カウントダウン継続

S3 e1 ◎アラーム継続

S3 e2 ◎アラーム継続

ホワイトボックステスト

• 命令網羅テスト： すべての命令文を実行

• 分岐網羅テスト： すべての実行パスを実行

• 条件網羅テスト： すべての条件式を評価するように実行

・・・

ホワイトボックステスト： プログラムの構造に基づく抽出

ホワイトボックステスト： 命令網羅テスト

・ダイレクトにケースを生成する方法ではない・不十分な場合が多い

プログラムに含まれるすべての実行文が実行されてるように

テストケースを選択する

命令網羅テストとは

特徴

① ある入力条件とそれに対する出力期待値を設定② プログラムを擬似実行し、実行された命令文にマーク③ マークされていない命令文を通るように、入力条件とそれに

対する出力期待値を設定④ 実行した命令文の比率が指定された値になるまで②～③を

繰り返す

手順

ホワイトボックステスト： 分岐網羅テスト

・ダイレクトにケースを生成する方法ではない・ 100% 網羅は難しい，それでも不十分な場合が多い

プログラムに含まれるすべての実行パスが実行されてるよう

にテストケースを選択する

分岐網羅テストとは

特徴

① プログラムの実行パス（分岐パス）を解析② ある入力条件とそれに対する出力期待値を設定③ プログラムを擬似実行し、実行された実行パスにマーク④ マークされていない実行パスを通るように、入力条件とそれ

に対する出力期待値を設定⑤ 実行パスが指定された割合になるまで③～④を繰り返す

手順

ホワイトボックステスト

例題

i=0

cond

i<n

array[i++]=0

開始

終了

true

false

No

Yes

void initialize (int* array, int n, bool cond){

int i = 0;if (cond == true)

while (i < n)array[i++] = 0;

} 全実行文

全実行パス

命令網羅テスト

n=1, cond=true

分岐網羅テスト

n=1, cond=truen=1, cond=false

さて実践！

25

// 年齢計算int age(int byear, int bmonth, int bday, // 生年月日

int cyear, int cmonth, int cday) // 現年月日{

enum question {yes, no} afterBirthday;int result;

// 今日が誕生日前後か判定するif (cmonth > bmonth) {

afterBirthday = yes;}else if (cmonth == bmonth) {

// 日の前後で判定するif (cday >= bday)

afterBirthday = yes;else

afterBirthday = no;}else {

afterBirthday = no;}

// 年齢を決定するif (afterBirthday == yes)

result = cyear - byear;else

result = cyear - byear - 1;

return result;}

cmonth>bmonth

=bmonth

<bmonth

no

yesResult =

cyear-byearResult =

cyear-byear-1

afterBirthday

afterBirthday=yes

afterBirthday=no

afterBirthday=no

afterBirthday=yes

cday>=bday

終了

開始

左記の年齢計算の関数に対して：１．（前回P18）同値分割のテストケースを実行したら

通るパスをマークせよ２．通っていないパスを通るテストケースを追加せよ

y

n

さて実践！

26

cmonth>bmonth

=bmonth

<month

no

yesResult =

cyear-byearResult =

cyear-byear-1

afterBirthday

afterBirthday=yes

afterBirthday=no

afterBirthday=no

afterBirthday=yes

cday>=bday

終了

開始 入力 期待出力cyear cmonth cday byear bmonth bday age

C1 2015 6 23 1960 3 30 55C2 2015 6 23 1995 8 11 19C3 2012 -1 23 1940 6 7 "現在月が間違っています"C4 2020 13 5 1950 6 7 "現在月が間違っています"C5 2016 10 0 1950 6 7 "現在日が間違っています"C6 1996 4 60 1990 6 7 "現在日が間違っています"C7 2015 12 1 1700 0 20 "誕生月が間違っています"C8 2015 12 1 1800 13 20 "誕生月が間違っています"C9 2015 7 1 1900 1 -1 "誕生日が間違っています"C10 2015 7 1 200 8 40 "誕生日が間違っています"C11 1900 5 1 2000 3 30 "年齢が計算できません”

No

１．同値分割のテストケースをテストする

C1,C2は実行できる（左記）C3-C11は，期待出力通りにならない

２．通らないパスのために，以下のテストケースを付け足す

y

n

入力 期待出力cyear cmonth cday byear bmonth bday age

C1 2015 6 23 1960 6 23 55C2 2015 6 23 1995 6 1 19

No

前回P18再掲

cmonth>bmonth

=bmonth

<bmonth

no

yesResult =

cyear-byearResult =

cyear-byear-1

afterBirthday

afterBirthday=yes

afterBirthday=no

afterBirthday=no

afterBirthday=yes

cday>=bday

終了

開始

y

n

単体テストでのテストケース設計の推奨

27

ポイント

• 仕様（同値分割のケース）からみて，プログラムはエラー処理が抜けている場合が多い

• プログラムからみて，同値分割のケースでは実行していない部分が残ることがある（ 例： 内部的な処理方法に依存した部分／出力処理 ）

推奨手順：まず，ブラックボックス手法（同値分割・限界値分析）でテストケースをだし，足りない部分をホワイトボックス手法（分岐網羅）を実施する

結合テスト： 位置づけ

コンポーネント間を結合して行うテスト

– ソフトウェア方式設計事項を確認ソフトウェア全体

入力信号処理プログラム

インタフェースのチェック

28

論理信号処理プログラム

ｺﾝﾎﾟｰﾈﾝﾄ群

内部

外部

目的1. 外部/内部インターフェースの整合性の確認2. 機能の妥当性の確認： 結合した状態でのふるまい3. 品質要求の達成の確認 性能効率性，使用性，保守性（エラー処理やログの適切さなど）など

機能の妥当性品質要求の達成

インタフェースのテスト

• インタフェースと言っても，奥が深い．

– 呼出しシーケンス（どの順番で何を呼ぶ，異常処理の扱い）

– データの受け渡し（型，値の範囲，値の長さなど）

• コネクションのタイプ毎にインタフェースが定義される

– ストリーム（ファイル，パイプ）

– 共有メモリ，大域変数

– 通信

– 割込み29

コンポーネ

ントAコンポーネ

ントBコネクション

利用側が正しく使っているか？

30

#include <string.h>#include <stdio.h>

int main() {char str[40] = "localhost:/usr/lib/bin/ls/";const char s1[2] = ":";const char s2[2] = "/";char *token;

/* 最初のトークン（:まで）を取って捨てる */token = strtok(str, s1);

/* 無くなるまで(ヌル文字まで)トークンを取り表示 */while( token != NULL ) {printf( "%s¥n", token );token = strtok(NULL, s2);

}return(0);

}

文字列の初期化＋トークン取り出し

区切り文字の変更＋トークン取り出し

テスト戦略と環境

単体・結合テストは、以下のようなテスト環境の準備を必要とする。

31

ドライバ

被テストモジュール

入力 出力

スタブA

引数

テスト済モジュール

引数戻り値（ダミー）

戻り値

引数 戻り値、副作用

結果照合

テスト結果（良／否）

期待出力

目視／自動

ボトムアップ

トップダウン

呼ばれる側のモジュールから先にテスト呼ぶ側のモジュールから先にテスト

① 下位ﾓｼﾞｭｰﾙを独立してテストできるため並行したテスト作業が可能

② スタブを作る必要がないが，ドライバを作る必要がある

③ アーキテクチャやインタフェースに関す

る重大なエラーがテストの最終段階近くにならないと見つからない

① 上位ﾓｼﾞｭｰﾙにありがちな重大な欠陥が先に発見できる

② ドライバを作る必要がないが，スタブを作る必要がある

③ 当初からプログラムの統合状態でテスト

環境を構成するので，下位モジュールを並行的にテストすることが難しい

テスト戦略と環境： 結合順序

32

機能仕様記述対応関係

テストケース設計（機能テスト）

テスト用のインタフェースが明確ならば、テスト自動化がしやすい

テスト環境

機能仕様と主処理との対応関係がとれていれば、仕様記述からテストケースを作りやすい！

入力 主処理 出力

テスト入力 結果出力

テスト戦略と環境：テスト容易性

テストケース

アーキテクチャとテスト容易性：

入力デバイス入力ファイル

出力デバイス出力ファイル

よいアーキテクチャは、テストもしやすい

テスト用インタフェース

33※ Model-View-Controller も同じ

Controller Model View

テスト戦略と環境：テスト容易性

主処理

通信ＤＢｱｸｾｽ

ｺﾝｿｰﾙ入出力ﾌｧｲﾙ入出力

ＤＢＭＳ 通信ﾌﾟﾛｸﾞﾗﾑ

アーキテクチャ設計： ・システムと外界とやりとりを受け持つモジュール群

は主処理から分離

インタフェース設計： ・明確かつ簡単なプロトコルを定義 （テスト入力を

与えやすく、出力を取り出しやすい）・インタフェースが確認しやすいテキスト形式を選択

（入出力ﾓｼﾞｭｰﾙ群のテスト）＜（主処理のテスト）

⇒ 主処理テストが容易になる

34

テスト容易性の設計

総合テスト以降

ソフトウェア総合テスト

• ソフトウェアが，ソフトウェア要求仕様通りか，実際の運用環境に近い状態で，使用目的・環境に適合するかどうかを確認する．

システムテスト• ハードウェアと組合せて，そのインタフェースをチェック• 製品に組み上げた状態で，システム要求仕様通りか，実

際の運用環境に近い状態で，使用目的・環境に適合するかどうかを確認する．

受入テスト• システムが，合意した仕様通りに動作するかどうかを発注

元の顧客が検証するテスト．実運用環境において検査されることが多い．

35

妥当性確認

テスト仕様書・成績書

36

項目 内容

1 テスト目的 テストのレベル，テストで確認したいこと

2 テスト内容確認事項を達成するために，テストケースを作る方法テスト戦略（組み立て方と確認方法）

3 入力仕様 テストケースを作る上でのインプットドキュメント

4 テスト対象 テストの対象となるソフトウェアの名称，バーション

5 テスト環境 （テストの妥当性確認と再現性確保のための情報）

(1) システム構成テストを実施するシステム構成（ハードウェア，ネットワーク，OSなどバージョンも含めて）

(2) 仕様ツール テストを実施する上で利用するツール（デバッガを含む）

6 テスト仕様と結果 個別のテストケースの記述と，実施結果

テスト仕様と結果

• 個別のテストケースと，実施結果を記載

37

No テスト項目入力

(操作とデータ）出力期待値 合否

確認済事項及び不具合状況

理由と対応

1 ××値の入力 ××TextBoxへ数

値10を入力、OK

ボタンを押す

○○画面に遷移し、検索結果 の文 字列「豊洲」を表示

×

○

○○画面に遷移を確認したが、検索結果の文字列は「大宮」が表示された

仕様誤解

7/20確認完了

×の場合・不具合原因を記載・修正後の確認では○と

日付を記載

×の場合・不具合原因を記載・修正後の確認では○と

日付を記載

再現できるように 照合できるように

妥当性確認（で確認したい品質）とシステムテスト

38

確認したい品質

テストの種類 実施内容と確認事項

機能の目的に対

する適合度

業務動作確認テ

スト代表的な業務処理を実施し、業務への適合性を確認

有用度テスト

人間的要因（障害者対応、利用者能力レベルに応じた操作性、

利用者嗜好）に関する妥当性の確認。運用操作が概念的な統

一性を持っていることを確認

マニュアル確認テ

スト

マニュアルに基づきシステムを操作し、その記述の正確性と明

瞭性を確認

疎通テスト実外部システムと接続し、現行データの入力や他システムとの

通信等のデータの受け渡しが適切にできることを確認

構成テストプラットホーム／ミドルウェアのバージョンとの組み合わせ等、

種々のシステム構成下において要求を満足することを確認

共存性テスト他のシステムと共存させ実行し、相互に悪影響を与えないことを

確認

信頼性テスト

長時間運用状態に置き、要求MTBFの満足を確認。運用時にお

ける入力・操作状態を模擬するため、想定利用者のテスタへの

割当て、実際のデータの利用、運用時の頻度と順序関係で入

力・操作を発生できる確率モデルの作成、などを計画・準備

障害時動作確認

テスト

想定されるすべての障害を発生させシステム動作を確認し、運

用上支障が生じないどうかを確認

障害復旧手順確

認テスト

想定されるすべての障害について障害からの復旧手順を実施

し、要求時間内に意図した復旧ができることを確認

信頼性

互換性

使いやすさ

妥当性確認（で確認したい品質）とシステムテスト（続き）

39

確認したい品質

テストの種類 実施内容と確認事項

セキュリティ 脆弱性テスト種々のセキュリティアタックをかけ、システムのセキュリティ強度

が想定内であることを確認

性能テスト主要機能を種々の条件で性能（応答時間やスループット）を測

定し、要求性能を満足していることを確認

容量テスト

通常業務／過負荷状態など種々の条件で、CPUやメモリなどの

リソース消費状況を測定し、要求機能・性能が満足できることを

確認

負荷（ストレス）テ

スト

システムに想定限度あるいはそれ以上の負荷をかけ、要求機

能・性能が満足できることを確認

移植性設置手順確認テ

スト

システム設置の手続きを実施し、要求どおりに実施できることを

確認

保守のしやすさ保守手順確認テ

スト

保守手順を実施し、問題が生じた時の解析のしやすさ、対処の

しやすさなどに問題がないことを確認

運用テストシステム利用者が試運用し、業務上の期待効果を得ることがで

きるか，問題は起きないかなどを確認

環境要因確認テ

スト

運用環境がシステムの動作に必要な環境／リソースの要件を

満たしていることを確認

運用時の品質

性能

システムテストのステージ

40

単機能テスト

機能組合せテスト

性能テスト

境界テスト

異常処理テスト

代表業務動作テスト

脆弱性テスト

保守手順確認テスト

障害復旧手順確認

テスト

負荷テスト

運用テスト

環境要因確認テスト

信頼性テスト

設置手順確認テスト

疎通テスト

有用度テスト

開発元工場内

現地

STAGE1 機能・性能の確認

STAGE2 業務への適合確認

STAGE3 実環境への適合確認

評価ポイントSTAGE0 開始条件

の確認

STAGE1確認

STAGE2確認

最終確認

システムテストは，例えば以下のように，組み立てる．システムによって，省かれるテストもある．

まとめ

• 状態ベースのテスト

– 状態遷移表に基づくテスト

– 状態遷移を網羅する

– 応用が広い

• ホワイトボックステスト

– プログラムの構造に基づくテスト

– ブラックボックステストを補完する

• テスト戦略： ボトムアップ，トップダウン，テスト容易性

• 総合テスト以降：

– 要求を確認するテスト

– 実際の運用環境に近い状態で，使用目的・環境に適合していることをみるテスト

41