Table of Contents
開発者テストの基本の基本
テストの種類
- 単体テスト
- 組み合わせテスト
- 境界値テスト
- 状態遷移テスト
- 探索的テスト
- 統合テスト
- システムテスト
単体テスト
単体テストでは下記の3つの手法を理解する
- 境界値テスト
- 状態遷移テスト
- 組み合わせテスト
コードベースの単体テスト
関数の網羅率を計測し、ロジックの確からしさを確認するホワイトボックステスト。
下記をテストする。
- プログラムを実行する中で、システム上異常な振る舞いを行わない（null pointer、0による除算など）
- 入力値とそれに対応する期待値を出力すること
- すべての分岐が正しく処理されること（境界値テスト）
命令網羅(C0カバレッジ)
あまり意味のあるテストとは言えない。
テスト基準
テスト内で少なくとも１回はプログラムのすべての命令文（ステート）を実 行する。(分岐等のロジックはテストせず、とりあえず命令が実行されればオッケーなテスト手法)
下記の様なコードでif節がtrueになり、中の処理(eatSnacks()・sleep() )が一度でも実行されれば良い。
if(isHungry || isNotFeelingGood) {
eatSnacks()
} else {
keepWorking()
}
if(isSleepy) {
sleep()
} else {
keepWorking()
}命令網羅 (C0)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
分岐網羅(C1カバレッジ)
この網羅手法で単体テストした方が良い。
テスト基準
それぞれの判定条件がTRUE、FALSEの結果を、少なくとも１回ずつ持 つようテストケースを書く。
下記の様なコードがあった場合、if節におけるtrue, falseの結果を、少なくとも１回ずつ持つようテストケースを書く。
if(isHungry || isNotFeelingGood) {
eatSnacks()
} else {
keepWorking()
}
if(isSleepy) {
sleep()
} else {
keepWorking()
}単体テストの注意点
網羅性だけ気にしてもダメ。目的は品質基準であり単体レベルの処理機能のバグをなくす事。
入力値のパターンを100%網羅するようにし、それに対する期待処理が正しいかチェックする。
単体テストのやる箇所を絞る
2:8の法則: ソフトウェアの２割の部分から８割のバグがでる。
この２割の部分に絞ってまずは始めてみる。
機能単位の単体テスト
下記の様なソート機能をテストする場合、下記をテストする。
- 単体境界値
- 組み合わせ
単体境界値
- 人間の年齢の境界値テスト: 0,-1,1000歳をエラーなく処理できるか等々
- データの件数が０の時、１の時、とても大きい時等のテスト
組み合わせ
- 同性が２人以上いた場合年齢が正しくソートされるか、入社年度とランクの組み合わせ等々
組み合わせは相当数存在する。その場合、ある程度網羅的にn個のテストをかけば問題はない。(→ 複雑な場合は自動化テストをするのがよい。ひたすら自動で流してエラーを検知する様にしておけば安心感があるう。)
統合テスト
統合テストでは、個々の機能を果たすためのプログラム部品（プログラムモジュール）を組み合わせて、データの受け渡しがうまく行われているか、コードの記述様式は揃っているか、データを授受するタイミングはずれていないか、といった点が確認される。
API テスト
APIに入力パラメータがある場合は、そのパラメータに対して境界値テストをして、できればそのAPIをさまざまな形でたたき、状態遷移まで網羅できれば完璧。