今更ながらテストに関する初歩的な本を読んだので今後役立ちそうな知識を自分用のメモがてらまとめる。(当たり前すぎることも記載、情報が古かったり間違ってる可能性もありますm(__)m)
本はこちら：
https://www.amazon.co.jp/dp/4822282511

※ホワイトボックステストについても後日追記します。

ブラックボックステスト

同値クラステスト

• 意識しなくてもよく使っている場合が多い基本のテスト。
• 特に連続するテストデータがあるシステムの場合に、大幅にテストケースを削減できる。
• テストケースで同じ結果を返すことが期待される入力値の範囲を同値クラスという。
• 無効値に対するテストを作成するべきかについてはそのシステムの設計仕様による。
• 無効値テストがいらないものは契約による設計という事前条件(入力値)が満たされた場合のみ事後条件(特定の処理)が行われるという考えに基づいて作られたシステム。
• ただ契約による設計システムはwebなど一般的なユーザーが使用するシステムとしてはよろしくないので(無効値の入力の際に動作停止する)、普通は防御的設計という設計アプローチが用いられる。こちらは無効値に対するエラーも通知するため無効値テストが必要。
• 基本的に無効値テストは複数の入力条件がある場合はそれぞれ一つずつ無効となる値を試すテストケースが必要になる。(以下の表みたいに)

入力条件1	入力条件2	入力条件3
無効値	有効値	有効値
有効値	無効値	有効値
有効値	有効値	無効値

境界値テスト

• こちらもよく使われる。同値クラステストの派生。
• ミスが発生しやすい連続するテストデータの上端、下端に対する処理にピックアップしたもの。
• 仕様で定められている境界値(a)の すぐ上(x>a) と すぐ下(x<a) のテストケースを選択する。
• この すぐ上 と すぐ下 の幅は扱うデータの単位によって異なる。(整数値なら-1,+1、小数値なら-0.1,+0.1など)
• 入力項目が複数ある場合は境界値における有効値と無効値の組み合わせでテストケースを作成する。

デシジョンテーブルテスト

• そのシステムでのビジネスルールを可視化するテスト。
• 以下の表を元にテストケースを作成する。

	ルール1	ルール2	ルール3
条件1	true	true	false
条件2	true	false	DC
…
アクション1	true	false	false
アクション2	true	true	false
…

• 条件は 入力値 を、アクションは 出力値 を、ルールは 入力値の組み合わせ = テストケース を示している。
• 条件はtrue,falseのような2値だけでなく、具体的数値や範囲を示す<xなども入れられる。その場合は同値クラスや境界値テストのように具体的な値を抽出してその分テストケースを増やす必要がある。
• 出力値(アクション)に影響がない入力値(条件)は DC(Don't Care=任意) として表せる。

ペア構成テスト

• 入力項目が多くテストすべき組み合わせが膨大な場合に効果的なテスト。
• 入力項目(x個)に対してそれぞれの入力値(y個)があった場合、すべての組み合わせはyのx乗個となる。当然そんな数は現実的ではないので、そういった場合はペア構成テストが使える。
• 端的に言うと 入力項目をそれぞれのペアで見た時に、取りうる入力値の組み合わせが全て現れるテストケースだけでテストを行う という手法。
• よくわからないので下の表を例にとる。(入力項目：4個(列)、入力値：3種類(表内値))

	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

• この表の列の中で任意のペア(2列)に注目してみると、いずれのペアも1~3の値の組み合わせが全て現れていることが確認できる。そのため、実施するテストケースとしてはこの9個(行)のみで良いというのがペア構成テスト。
• しかし肝心なこの表はどこから出てきたのかというと、この表は 直行表といいある一定の大きさごとに要素のすべての組み合わせが現れる特別な表のことである(詳しくは↑のwikiで…)。つまりこの特別な性質を持つ表である直行表の大きさは 自動的に決まってくる。
• 例えば先ほどの例だと、4個の項目に対して3この値をとる場合は9*4の直行表が最適な大きさとなる。

ここからは直行表の詳しい話

• これより多い入力項目のものに関してはさらに大きな直行表が当てはまることになるが、必ずしも最適な直行表の大きさにならないこともある(直行表の大きさは一定の大きさで決まっているため)。その場合はテストで必要になる組み合わせの数を上回る大きさの直行表を探して当てはめる必要がある。
• しかし、直行表の大きさが大きい分実際の入力項目数以上の列や種類数が現れることになるので、その個所は有効値に置き換えてテストを行う必要がある。=直行表の行数分は必ずテストする必要がある。
  ※直行表は本来は水準や因子といった直行表を算出するうえで基準となる値を設定して作成するが、実際のテストケースに見合う最適な直行表を求めるのはかなり難しいと思われます、より詳細はググってみてください。
  参考：直行表を求めるサイト

• 直行表以外のアプローチとして 全ペアアルゴリズム というものがある(こちらのほうが扱いやすいと思う…)。こちらは最適なペアの組み合わせを算出するプログラムがすでにあるためそちらを用いる方法。
• 本でも紹介されていたこのプログラムは http://www.satisfice.com/tools.shtml で公開されているそうです(allpairsの方)。有志の方が実際に使用されておられました。
• またPairwiserやmicrosoftのPictという全ペア抽出ツールもあるそうです。

状態遷移テスト

• ロジックではなくシステムの状態という観点でのテスト方法。(あるいは文書化の方法)

• 状態遷移図 か 状態遷移表 を用いてテストor文書化を行う。

• 状態遷移図は以下のようなもので、主に 状態を表す円 と 遷移を表す矢印 、そして状態を遷移させる イベント(矢印のラベル) 、イベントに/を挟んで記述するイベントに伴って発生する操作である アクションなどで構成される。

• また下の図にはないが、イベントラベルに記す遷移の条件判定を表す 真偽値[] などもある。
  

• 状態遷移表は以下のような表で表され、 無効な状態遷移の組み合わせ なども表として書き起こせる点が利点。

現在の状態	イベント	アクション	次の状態
通常	アラームセット	-	アラーム状態

• 状態遷移図および表を使ったテストでは、全遷移を必ず一回は通るテストケース=矢印を全て通るテストケースを実施するのが望ましい。
• 無効な遷移であってもリスクが高いものなどは追加してテストすることも必要。

ドメイン分析テスト

• 複数の変数に相互関係(影響しあう)があり、その境界値を検証するテスト。
• 本での紹介例では一定の範囲の値をとる二つの変数(x<=36, y<-4.0など)の相互関係のテストで示されていた。
• 上記のような連続的な値をとり、境界値が存在する変数においては on(境界値)、 off(境界値のすぐ上orすぐ下)、in(任意の有効値)、 out(任意の無効値) という四つのポイントからテストケースを割り出す。
• off についてはonが有効値(<=,>=の場合)の場合は 無効値 、onが無効値(<,>の場合)の場合は 有効値 として設定する。

例：

	x<=36	x<36
on	36	36
off	37	35
in	25,30など	25,30など
out	45,50など	45,50など

• 実際にテストケースを作成する際には ドメインテストマトリックス という表を作成する。
• 例として二つの変数 x<=36, y<-4 のドメインテストマトリックスを以下に示す。
  
• この表は、片方の変数の代表値であるinの値と他方の変数のon,off値の組み合わせで構成されている(最後は互いの代表値の組み合わせ)。これは変数の数や条件が増えた場合でも同じようにテストケースを増やす。

ユースケーステスト

• アクター(ユーザーなど)の目的に観点を置いたテスト。

• アクターがシステムを使用して目的を達成するためのシナリオ(操作の流れ)を、テストケースとして定義する方法。すべてユーザー視点からテストを定義する。以下はユースケース図の例。
  

• テストケース作成の際には、 リスクが高いトランザクション(処理の塊)を外さないよう に作成する。

• 成功シナリオとそこから拡張したシナリオについて、それぞれ 最低一つずつテストケースを作成する ようにする。

• テストケースで実際に入力する値については規定していないので、同値クラステストや境界値テストを用いて入力する値を決定する。(正常系や異常系)

• また反対に必ず失敗するようなシナリオや突飛な操作を含むシナリオなども同時に検証してみることもできる。

• このテストはシナリオという観点ではある程度のカバレッジを満たすことはできるが、厳密な入力値の検証などは伴わないので他のテストと必ず併用するようにするのがよいと思う。