単体テストのテスト項目の観点

単体テストで実施する検証の内容（すなわちテスト項目）は、機能面や構造面といった観点から適切に設定され、また十分に網羅されている必要があります。
このテスト項目の網羅性（網羅率）のことをテストカバレッジ【Test Coverage】といい、カバレッジの高いテスト項目を設定できるかどうかが本工程の成果に大きく影響します。
単体テストにおいて一般的に実施されている 2 つのテスト手法を以下で説明します。

参考： 単体テスト（ユニットテスト）とは
参考： プログラムの品質保証について

ホワイトボックステスト（コードベーステスト）
ソースコードそのものに着目し、命令や条件分岐、繰り返しなどの各処理部分をテストする、いわゆる全ルート検証。
ソースコードがテストされた割合（コードカバレッジ【Code Ceverage】）を測定することによりテスト項目の網羅性を表すことができます。
コードカバレッジにはいくつかの種類があり、これがそのままホワイトボックステストにおけるテストの観点になります。

命令網羅【Statement Coverage: SC】（C0）
ソースコードの全命令文のうち、１回でも実行されたステートメントの割合。
すべての命令文を少なくとも１度は実行するようテストします。

分岐網羅【Branch Coverage: BC】（C1）
ソースコードの全分岐のうち、１回でも実行された分岐の割合。
すべての分岐処理を少なくとも１度は実行するようテストします。

条件網羅【Condition Coverage: CC】（C2）
ソースコードの分岐に設定されている１つ１つの条件について、成立・不成立の両方が１回でも実行された割合。
各条件の真偽が少なくとも１回は実行するようテストします。

複合条件網羅【Multiple Condition Coverage: MCC】
ソースコードの分岐に設定されている１つ１つの条件の真偽の組み合わせがすべて実行された割合。
各条件の組み合わせのすべてを実行するようテストします。

命令網羅 C0 は命令が実行されないパターンの考慮がないため、不完全なテストとなります。
分岐網羅 C1 は条件文と分岐処理との整合性が考慮されないため、不完全なテストとなります。
条件網羅 C2 は条件の組み合わせに抜けが生じるため、不完全なテストとなります。
複合条件網羅 MCC は完全なテストとなります。

ただし複合条件網羅 MCC は、条件の数によって組み合わせ数が膨大となるため、カバレッジを 100% に近づけようとすればするほどに、障害検出の費用対効果が低下する可能性があります 。
条件の数が少ない場合は MCC を選択し、組み合わせ数が膨大となってしまった場合は全網羅する条件をいくつかピックアップして C2 を実施する形が良いでしょう。

ブラックボックステスト
当該ユニットの外から見た機能（入出力）に着目し、コードが期待される機能（詳細設計仕様）を満たしているかどうかを検証する、いわゆる機能テストです。
ホワイトボックステストだけでは十分に検証できないユニット、例えば出力結果の生成に複雑なアルゴリズムを有するユニットなどについては、ブラックボックステストが必要となるでしょう。

単体テスト以降のテスト工程でも一般的に行われる検証方法ですが、単体テスト工程においては対象ユニットの機能、例えばメソッドの復帰値や出力データ等を確認する形となります。
テストケースの作成や結果の確認には、照合・検算するための何らかの仕様書が存在することが望ましいです。

ブラックボックステストの手法としては、入力値の同値分割に基づく境界値分析によってテスト条件を設定する方法が一般的です。

同値分割とは
とある入力値に対して、機能仕様の面から異なる出力結果（処理・振る舞い）が期待される値を分類し、グループ分けするものです。

西暦（入力）から元号（出力）を判定するプログラムを例に説明します。

出力結果ごとにグループ分けを行うと以下のようになります。

グループ	入力値	出力値
A	0 ～ 1899	（エラー）
B	1900 ～ 1911	“明治”
C	1912 ～ 1925	“大正”
D	1926 ～ 1988	“昭和”
E	1989 ～ 2018	“平成”
F	2019 ～ 2020	“令和”
G	2021 ～	（エラー）

西暦そのものは単なる数値ですが、入力値がどのグループに所属するかによって出力結果が変わってきます。
逆に同じグループに所属する値であれば同じ結果が返ってきますので、各グループに所属する値をそれぞれ１つ選択し、出力結果を確認すれば機能テストの網羅性は確保できたことになります。

上記の例のように、入力値の数値範囲がテスト項目の観点となる場合はこのような同値分割が必要ですが、もっと単純なモデル、例えば入力が０と１の値のみを取り得る場合などは、その値がそのままテスト項目の観点となります。
（０、１、それ以外、を確認すれば機能テストは網羅されたことになります）

境界値分析とは
入力値の数値範囲によって同値分割された場合、範囲の境界値はプログラムロジックと密接に関係します。
境界は「～以上、～未満」、「～から～まで」のような言葉で表現されますが、言葉で表現する設計者とプログラムを作成する実装者との間に認識のズレが生じやすく、境界付近に故障が潜む可能性が高くなる傾向があります。
境界値分析とは、境界付近を積極的にテスト条件に加えることにより不具合を検出しやすくするためのテスト手法です。

例えば図２の例では、境界値（とその付近）は以下のようになります。

グループ	条件式	境界値とその付近
A	x<1900	境界値: 1900 境界値付近: 1899
B	1900≦x<1912	境界値: 1900, 1912 境界値付近: 1899, 1911
C	1912≦x<1926	境界値: 1912, 1926 境界値付近: 1911, 1925
D	1926≦x<1989	境界値: 1926, 1989 境界値付近: 1925, 1988
E	1989≦x<2019	境界値: 1989, 2019 境界値付近: 1988, 2018
F	2019≦x<2021	境界値: 2019, 2021 境界値付近: 2018, 2020
G	2021≦x	境界値: 2021 境界値付近: 2020

境界値付近は、不等号にイコールが入る場合（以上・以下）は範囲の外、入らない場合（以降・未満）は範囲の内に設定します。
入力値として、1899, 1900, 1911, 1912, …… をすべて検証すれば、境界値分析の観点からのテストは網羅されたことになります。

テスト条件の組み合わせ
入力値は必ずしも１つではありません。
このため、テストの網羅性を確保するためには、ホワイトボックステストにおける複合条件網羅 MCC のように、それぞれの条件の組み合わせを検証する必要があります。
条件の組み合わせについては、「デシジョンテーブルとは」を参照してください。

単体テストにおけるテスト条件とテスト観点

テスト条件　　　 （入力条件）	条件項目	・メソッド引数 ・データケース（DB、ファイルなど） ・ステータス（メンバ変数値） ・グローバルステータス（グローバル領域の値）
	条件因子	・同値分割法 ・境界値分析
テスト観点 （出力結果）	確認項目	・復帰値 ・例外処理 ・出力データ（DB、ファイルなど） ・通信応答データ（html、JSONなど） ・ステータス（メンバ変数値） ・グローバルステータス（グローバル領域の値）
	確認観点	・正しい値 ・正しい画面 ・正しいエラー処理など