ご無沙汰してます、おおのんです。
今回はソフトウェアのテストに関するお話です。
ソフトウェア開発におけるテストって、自分から情報を取ろうとしない限り
体系的に理解する機会があまりないので、
知識としての理解の差に他の情報よりバラつきがありがちです。
Qiitaや書籍(※)を読んで自分なりに単語を軸に簡潔にまとめてみるので
以下のような方は目を通してみると理解の一助となるかもしれません。
※なお、読み易さを重視するためなるべく平易な言葉でまとめます。ご了承ください。
※単体テスト視点での記事です。
記事のターゲット
「ソフトウェアのテストをやったことない、これから仕事でやるんだ」
「何となくテストしたことはある」
という人。
この記事を読むメリットは？
結論：単体テストとは 【何をすべきか】【どうあるべきか】 が大体分かる。
チームによっては十分に知識または教育がなく曖昧にテストしていたりするので、テストの目的を理解することで意味のあるテストを目指すことができるようになる。
単体テストは何のために？
結論：自分で作ったものを正しく動くかどうか自分で証明すること
「仕様のとおりにアウトプットてきているか」や
「ソースコードを網羅して問題なく動作するか（カバレッジ）」という視点がある。
カバレッジとは
結論：テストをカバー（網羅）すること
命令網羅とよばれるステートメントカバレッジ(通称C0)と
分岐網羅とよばれるブランチカバレッジ(通称C1)という言葉が登場する。
※C2やMC/DCという視点もあるが、今回は割愛。
ステートメントカバレッジとは（C0）
結論：ソースコード中の命令を最低でも一度は実行すること
つまりソースコードの命令が一度でいいので実行されれば100%とみなされる。
ブランチカバレッジとは（C1）
結論：ソースコード中の全ての分岐を実行すること
例えばif文があって、それに紐づくelse分の分岐が複数ある場合、
その分岐すべてをテストコードでカバーした場合、ブランチカバレッジ100%となる。
ホワイトボックステストとは
結論：ソースコードがプログラマが意図したとおりに動くかを確認するテスト
例えると、「1という値を与えたときにif文の中で想定したelseへ分岐、通過するか」という視点。
つまり、ソース重視。
ブラックボックステストとは
結論：仕様通りに出力が得られるかどうかを確認するテスト
例えると、「1を入れると必ず2が帰ってくるね」という視点。
つまり、仕様重視。
ホワイトボックス、ブラックボックス、望ましいのはどちら？
ホワイトボックステスト（カバレッジ網羅）で100%通ったから安心！というのは危険な思想。
確かに体裁としては一見悪くないけど、仕様を確認しているわけではないのでそれだけの場合、往々にしてバグを見逃しやすい。
テストでは仕様通りに動くかを確認すべきなので、ブラックボックステストの視点が大事。
ブラックボックステストをして、網羅されていない部分をホワイトボックステストの視点で100%にする
というのがより安心で意味のあるテストと言えるのでは。
参考文献・サイト
・ソフトウェアテスト入門 押さえておきたい<<要点・重点>>
・カバレッジとは【「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典】