#ソフトウェアテストとは？
・意図した通りにプログラムが動くのか？を検証する
・期待通りにいかない箇所（バグ）を減らすことで品質を保証する
##ソフトウェアテストの種類
-
単体テスト
ひとつひとつのモジュール（プログラムの部品）をしっかりとテストしておくこと -
統合テスト
結合テストではモジュール単体でのテストをクリアしたモジュールと、
その他外部モジュールを結合した状態でテストを行う。 -
UI、システムテスト
-
ブラックボックステスト
ソフトウェアのコード内部のロジックを考慮せず、 外部から見たときの仕様のみからテストケースを作成する プログラミングの知識よりも業務に関する知識が必要 -
ホワイトボックステスト
コード内部のロジックを考慮してテストケースを作成する ロジックなどを読み取れる必要があるので、ある程度プログラミングの知識が必要
##ソフトウェアテスト技法
###テストケースを設計する際に目指すべきこと
現実的に実行できるレベルの量までテストケースを削減しつつ、
少ないテストケースでも品質を保証できる
###テスト設計アプローチには以下の2つがある
- 契約によるテスト
- 与えられた条件の範囲内だけでテストを行うアプローチ
1~10の整数しか渡されない条件の場合、その範囲でしかテストを行わない
文字列や浮動小数、11以上の整数はテストしない - 防御的テスト
- 与えられた条件の範囲外もテストを行うアプローチ
1~10までの整数しか渡されない条件の場合の場合、
文字列や浮動小数、11以上の整数などのテストを行い、 例外やエラーが出ることを確認する
どちらのアプローチが正解ということはない
大事なのは、どちらのアプローチでテストをするのか?を明確にした上で、 テストを実行すること
##網羅性 と ピンポイント
ソフトウェアテストで重要な2つの概念は「網羅性」と「ピンポイント」
網羅性 ➡︎ テストの抜け漏れをなるべくなくす
ピンポイント ➡︎ 怪しいところを入念に調べる
怪しいところを発見するには、テストの観点を広げることが重要
以下3つの方法で観点を広げて怪しいところを見つけ出す
①具体的な例を考え、その例の「間」「逆」「類推」「外側」を考える
②意地悪な条件を考える
③自分が「知っている」「当たり前」と思っていることこそ疑う
確認するテスト項目は一つずつ行う
複数の条件を同時にテストを行うとどこに欠陥があるかわからない
#テスト技法
##単純な条件のテスト##
###同値クラステスト###
テスト的に同じ意味になる値のこと
if(a <= 10){}
であるならば
a=3 と a=7は同じ意味となる
つまり、同値テストは１つあれば良い
###境界値テスト
if(a <= 10){}
であるならば
a=９ と a=１０が境界値となる
この付近を調べれば効率的にバグを見つけられる
##複数の条件のテスト
条件が増えて論理が複雑になると、テストケースの抜け漏れが発生しやすい
それを防ぐための2つの技法が、ドメイン分析テストとデシジョンテーブル
###ドメイン分析テスト
条件同士が相互作用を持つような場合
複数の条件が数式で結ばれているような場合に有効
//a、bの範囲は共に０~100の整数とする
if(a + b >= 60）{
OK
}else{
NG
}
この場合、aの値とbの値は相互作用を持つと言える（aの値によってbの値が変化する）
- a+bの境界値は60
- 確認するテスト項目は一つずつ行う
これらを踏まえてテストケースを考えると
a=0、b=59 ⇨ NG
a=0、b=60 ⇨ OK
a=59、b=0 ⇨ NG
a=60、b=0 ⇨ OK
の４パターンとなる
###デシジョンテーブルテスト
条件同士は独立している、論理関係を整理する場合
複数の条件が論理式で結ばれている場合に有効
//a、bの範囲は共に０~100の整数とする
if( (a >= 40) && (b >= 40) ){
OK
}else{
NG
}
こういう場合に有効となる
デシジョンテーブルを作成し条件と結果を整理する
この４パターンがテストケースとなる
ただし、if文では条件は左から順に処理される。
そのため、a>=40が偽なら全体の結果はNGになる。
つまり右端のテストは省略することができる。
##もっと複雑な条件のテスト
より複雑な組み合わせを網羅しようとするとテストケースが膨大になる
⇒ すべてを網羅するのは難しい、方針の切り替えが必要
###ペア構成テスト
すべての組み合わせをテストするのではなく、条件のすべてのペアをテストする技法
条件A,B,Cがそれぞれ「１」または「０」の値をとる場合
全ての組み合わせは８通り
そのうち、すべてのペアの君合わせは４通り
####すべてのペアをテストすることである程度の網羅性が確保できる理由は?
ほとんどの欠陥はシングルモード欠陥とダブルモード欠陥のどちらか
シングルモード欠陥 → モジュールが正しく動かない欠陥
ダブルモード欠陥 → 2つのモジュールが組み合わさったときに生じる欠陥
すべてのペアを調べれば、シングルモード欠陥とダブルモード欠陥については網羅できることになるため、ある程度の網羅性を確保できる。
ペア構成テストによって70~85%程度のバグを発見することが期待できる。
ただし、これだけで完璧なテストにはならないことには注意が必要
###状態遷移テスト
現在の状態とその遷移によって振る舞いが変わるようなソフトウェアをテスト
####状態遷移図
簡単に全体を確認する
状態遷移は大きく「状態」「遷移」「イベント」の3つからなる
「イベント」は状態を遷移させるもののこと
簡易的なストップウォッチを考えるとこんな感じ
####状態遷移表
上記の状態遷移図を表形式に置き換えたもの
####Nスイッチカバレッジ
連続して遷移が発生した時に正しく動作するかを確認する
２回連続で遷移が発生したとすると
状態遷移図・状態遷移表・Nスイッチカバレッジのテスト、
それぞれの利用目的を理解した上で、求められる品質に応じて使い分ける必要がある
##データフローテスト
それぞれの変数において「生成→使用→廃棄」というサイクルを確認するテスト
変数を生成していないのに使用しようとしていないか?
生成しているのに使用していない変数はないか?
など、変数ごとに「生成→使用→廃棄」の順番が守られているか?を確認する
##制御フローテスト
コード中の処理がどれだけ実行されたか?を基準に行うテスト。
###制御フローテストの考え方
####ステートメントカバレッジ（命令網羅）
実行可能な行のうち何行を実行したか
if(a > 0 && b == 1){
x = 1
}
この場合、実行可能行数「2」のうち何行を実行したか？というものが該当する
####デシジョンカバレッジ（判定網羅）
判定の分岐をどれだけ網羅したか
if(a > 0 && b == 1){
x = 1
}
(a > 0 && b == 1)の判定が真か偽
の１パターンのうち、どれだけ網羅したか？というものが該当する
####コンディションカバレッジ（条件網羅）
判定の中の条件式の真偽をどれだけ網羅したか
if(a > 0 && b == 1){
x = 1
}
「a > 0」が真
「a > 0」が偽
「b == 1」が真
「b == 1」が偽
の４パターンのうち、どれだけ網羅したか？というものが該当する
####複合コンディションカバレッジ（複合条件網羅）
条件式の真偽の組み合わせをどれだけ網羅したか
if(a > 0 && b == 1){
x = 1
}
この場合
「a > 0」が真、かつ「b == 1」が真
「a > 0」が真、かつ「b == 1」が偽
「a > 0」が偽、かつ「b == 1」が真
「a > 0」が偽、かつ「b == 1」が偽
の４パターンのうち、どれだけ網羅したか？というものが該当する
####MC/DCカバレッジ
複合コンディションカバレッジの改良版
条件
①判断文がすべての結果を実行する
②条件式がすべてのパターンを実行する
③条件式の各条件が、単独で結果に影響する
if(a > 0 && b == 1){
x = 1
}
この場合
「a > 0」が真、かつ「b == 1」が真
「a > 0」が真、かつ「b == 1」が偽
「a > 0」が偽、かつ「b == 1」が真
の３パターンのうち、どれだけ網羅したか？というものが該当する
なぜ３つになるのか？
「条件式の各条件が、単独で結果に影響する」この条件が関係している
今回の条件式
(a > 0 && b == 1)
では、「a > 0」と「b == 1」が＆＆で結ばれている
つまり、「a > 0」と「b == 1」のどちらかが偽なら全体としての判定は偽になるということ
簡単にしてみると
①偽 && ②偽 ⇨ 偽
の場合、②を固定して①だけを真に書き換えてみる
①真 && ②偽 ⇨ 偽
結果は偽のままである
対して
①真 && ②真 ⇨ 真
の場合、②を固定して①だけを偽に書き換えてみる
①偽 && ②真 ⇨ 偽
結果が真に変わった
つまり「片方だけを変化させた場合、全体の結果が変化するものである必要がある」ということである
よって
「a > 0」が偽、かつ「b == 1」が偽はその条件を満たしていないため、テストケースから除外される。ということである