単体テストとは？という疑問に対する回答（になっていると願いたい・・・）

目次

・前回の反省と今回記載すること
・単体テストの立ち位置・及び役割
・ホワイトボックステストとブラックボックステスト
・フローチャートを元にしたテストパターン作成
・テスト仕様書に関して
・エビデンスの重要性と残し方について
・まとめ

##前回の反省と今回記載すること
遡る事約一か月前、私はテストに関して下記のような記事を投稿した。
https://qiita.com/meitantei23/items/3db3131cbca10d6b8cd6

しかし、会社の上司からは
「末端しか書かれてないから、何のテストパターンかわからんのじゃボケ～!!」
という指摘を受けた。なので、今回は単体テストについて「単体テストの役割」「テストの視点」
「エビデンスの取り方」等を詳細に記載していこうと思う。

単体テストとは何だろう？という疑問に対して、1つの回答になっていれば
幸いである。

##単体テストの立ち位置・及び役割
そもそも、システム開発の中での「テスト」というのは
1.単体テスト→2.結合テスト→3.システムテストと、3つ存在する。
※場合によっては、受入テストと言うのがある。

システム開発をする時は、下記画像のように要件定義→基本設計→詳細設計→PG→テスト
というように、大きな所から小さくしていくのに対しテストするときは、小さな所から
大きくしていく必要がある。

個々のプログラムの品質が良いかどうかわからないまま、確認せずに結合して、そのまま結合テストとシステムテストをしてしまうと、不具合が発生する確率が高くなる+原因を特定するのが難しくなる。
　
　このような問題が発生するのを防ぐ為に、単体テストは、実装したプログラムが詳細設計書通りの動作をするかどうかを確認するために行う。
　
##ホワイトボックス視点とブラックボックス視点
単体テストのテストパターンを作成するにあたり、意識する視点が2つある。
最低限、この2つの視点を抑えた上でテストパターンを作成した方がよい。
※参考にしたのは、主に下記サイトと本
https://hnavi.co.jp/knowledge/blog/white-box-test/
　
https://www.amazon.co.jp/%E7%9F%A5%E8%AD%98%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88-%E3%80%90%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E9%AB%98%E6%A9%8B-%E5%AF%BF%E4%B8%80/dp/4798130605
　
###ホワイトボックス視点
システム内部の構造を理解して、ロジックや制御の流れが正しいかどうかを検証する
テスト技法の事をホワイトボックステストと言う。PG者目線だと、こちらの視点の方が比重が
デカくなる傾向がある。詳細設計書を確認して、「自分だったらこういう風にカスタマイズ
するかな」という視点もこのホワイトボックスに含まれる。具体的なテストは下記2つ

　・制御フロー
　　プログラムの処理が、網羅的に実行されているかどうかを確認する方法。
　　下記のように、条件判定と呼ばれる処理の分岐がある場合は、全ての処理経路が
　　通過させるようにテストする必要あり。

　　一つでも処理経路の実行が確認されないと、プログラムが正常に動作しているか
　　判断できなくなるので条件判定に合わせたテストデータを用意する必要あり。
　
　・データフロー
　　モジュール内で使用されるデータや変数処理の流れのことをデータフローと言う。
　　変数データが「定義」「使用（参照）」「消滅」するような処理を指す。
　　各変数、定義と使用のペアを少なくとも1回は網羅するテストケースを作成する。
　
###ブラックボックス視点
上記ホワイトボックス視点とは違い、システム内部の構造は一切無視!!　
仕様を満たしているかどうかだけを確認してやるぜ～!!
というテストをブラックボックステストという。画面上で、正しい出力ができているかを
確認するので**「ユーザー側のテスト」ともいえる。具体的なテストは下記2つ。
　
　・同値分割
　　詳細設計書からデータを意味のあるデータ**に分類し、各グループから代表値を選ぶ方法。
　　例えば、一年間に存在する月について、範囲の判定を行うプログラムがある場合
　　下記のグループに分類できる。

　　エラー同値クラス1：0以下の整数(正常範囲より小さい値)
　　正常同値クラス：1～12までの整数
　　エラー同値クラス2:13以上の整数(正常範囲より大きい値)

　　1～12の値が正常、0以下や13以上の値がエラーと処理されれば、そのプログラムは
　　正しく動いている事になる。
　
　・境界値分析
　　処理と処理の境界となる値を確認する方法。正常となるパターンと異常となるパターンを
　　上限下限の両境界でテストする必要あり。例えば、0～100歳までの顧客データから
　　20～29歳までをメインターゲットと判定するプログラムの場合
　　-1歳、0歳、19歳、20歳、29歳、30歳、100歳、101歳のデータを使ってテストをする。
　
　
##フローチャートを元にしたテストパターン生成
単体テストの役割、意識する視点を記載したが、ここで**「具体的にどうやってテストケースを作れ
ばいいかわからないだよ～」**という疑問が出てくると思う。そこで、テストパターンを作成する
手法の一つとして、フローチャートを元にして、テストパターンを作成してみようと思う。

フローチャートとは
プロセスの各ステップを箱で表し、流れをそれらの箱の間の矢印で表すことで、
システムの処理の流れを表現する図の事を言う。テストパターンを作成するのに
必要な図である。
　
例として、Amazon等の通販サイトの会員登録で、下記のように「生年月」を登録するとしよう。
　
・入力必須
・1～12の値はOK。それ以外はNG。NGの場合はエラーメッセージが表示される。
　フローチャートとしては、大体こんな感じ
　

このフローチャートを元にテストパターンを作成すると、下記のようになる
　

基本的にはフローチャート作成した後に、ホワイトボックス・ブラックボックス視点で
テストパターンを作成すると、無駄が少ないテストパターンを作成しやすい。
##テスト仕様書に関して
システムが詳細設計書通りに動いているかどうかを確認するため、テストするポイントをまとめた
資料の事をテスト仕様書と言う。単体テスト含め、全てのテストで作成されるものである。
よくテストケースと混在する事があると思う。
テストケースは、テスターがテストをするために「前提となる条件」「テストの具体的方法」
「そのテストの想定結果**(こういう状態になってほしい!!というもの)**」が記されている。
このテストケースは、一般的にはテスト仕様書にまとめられているもの。
つまり、テストケースはテスト仕様書の一部ともいえる。
　　
・テスト仕様書を作成するメリット
　メリットとしては、各機能が正しく動作するかどうか、誰がテストしても正しく確認する事が
　できることにある。テストの経験が多い/少ない関係なく、テストの質は高いことが望ましいので、
　基本的にはテスト仕様書は作成した方が良い。
　自分は最近、開発に入る前にテスト仕様書を作ることがあるが、
　開発の手戻りを少なくなった+テストで発見されたバグの件数が少なくなった。
　この辺りも、テスト仕様書を作成するメリットにある。
　　
・テスト仕様書を作成するデメリット
　デメリットとしては、単純に工数がかかる、ということにある。
　当たり前の話になるが、システム開発は決められた期限の中で行う必要がある。テストもしかり。
　スケジュールが厳しい場合は、テスト仕様書作成(確認含む)→テストの流れで
　テストを行うのは非常に難しい。
　　
・テスト仕様書は要るのかどうか？
　上記にも記載しているが、基本的にはテスト仕様書は作成した方が良い。
　しかし、スケジュールが厳しいとテスト仕様書自体を作成する時間はとれないかもしれない。
　また、テスト仕様書自体はお客様が必ず確認するものではなく、開発者側の人達だけが
　確認するものなので、開発チームの方針によっては、必要ないかもしれない。
　　
　なので、テスト仕様書＝基本的には作成（但し、スケジュール or チームの方針による）
　と思った方が良い。
　
##エビデンスの重要性と残し方について
「テストしましたよ」という証明書になるのがエビデンス。「やりました」と口で言っても
エビデンスがなければ話にならない。そのため、どうやってエビデンスを残すのか？
というのは大事。エビデンスの残し方を下記に紹介する。

・仕様書のシート単位でエビデンスを残す
　基本的には、エビデンスは1Excelでまとめ、詳細設計書のシート毎にエビデンスのシートを
　作成する。しかし、シートの量が多すぎると、ファイルが重くなってしまうので、その場合は
　詳細設計書の総シート数÷2(多すぎる場合は÷3)と分けて、エビデンスを残すこと。
　
・エビデンスを取るタイミング
　基本的には、下記2つのタイミングでエビデンスを取得する
　1. 確認したい機能(登録チェック・必須チェック等)を操作する前 ※ボタン押下前など
　2. 確認したい結果が表示された後
　
・必要であれば、DBの更新前・更新後のエビデンスも取得する
　DBのデータは、画面上に表示される事がほとんどなので、
　DBのエビデンスを取ることはほとんどない。しかし、画面上に表示されないカラムを確認する
　必要がある時は、そのカラムの更新前・更新後の値をエビデンスとして残すこと。
　値確認時に使用したSELECT文があると尚良い。
　
##まとめ
・単体テストとは、実装したプログラムが詳細設計書通りの動作をするかどうかを
　確認するために行うテストの事
・フローチャート作成→ホワイトボックス・ブラックボックス視点でテストパターンを
　作成すると、テストパターンが作成しやすい
・テスト仕様書は、基本的には作成しよう　※スケジュール等にもよる
・エビデンスとは、テストしたことを証明しする為に必要なもの。
　テスト結果が正しい事を証明するような取り方をする