テストの種類と V 字モデル

一口にシステムのテストといっても、「単体テスト」「結合テスト」「総合テスト」など、色々な種類がある。これらはどういう風に区別されているのか。

厳密な区別は曖昧だったりするのだが、概ね次のように、「要件定義」「設計」「実装」工程と対になる形でテスト工程が別けられていると考えて良い。

対象の工程は「要件定義」から「実装」へとトップダウンに下っていくのに対し、それらを検証するテスト工程は「単体」から「総合」へとボトムアップで上がっていくので、V 字モデルと呼ばれたりする。

単体テストの狙い

単体テストは、1画面・1機能の実装内容を確認するためのテスト工程といえる。ユニットテスト (Unit Test・UT) とか、Program Test といった呼び方がされる。

一番コードに近い部分のテストなので、境界値テストや条件網羅テストなど、多くのバリエーションを与えて意図した動作になるかを検証する。ソースコードの実装内容と照らし合わせてテストケースを組み立てることが多いので、「ホワイトボックステスト」という言い方もある。

JUnit (Java) や Jest (JavaScript) などといった世の自動テストツールは、大抵この「単体テスト」の領域をテストするために、テストコードを効率的に書き、繰り返しテストを実行しやすくしてくれる支援ツールである。

単一画面や単一機能のテストに終始するので、例えば「会員情報変更ページ」のテストケースの際には、遷移元画面となる「トップページ」がなくても良いし、「会員情報変更完了ページ」が完成していなくてもテストができるように作ることになる。当該機能の前後に、本来は必要となる画面や機能がある場合、モックを用意してテストすることがある。

• 呼び出し元の機能を再現するモノをドライバと言う。JUnit などのテストランナーは、当該機能を呼び出してテストを行っているので「ドライバ」の一種である
• 呼び出し先の機能を再現するモノをスタブと言う。「遷移先の画面」だとか、「当該画面でコールする外部 API」などは「スタブ」の一種で、呼び出す関数の内部をモック化して、ダミーのデータなどを返せるようにしておく

結合テスト・連結テスト

結合テスト、または連結テストは、機能全体が設計 (特に詳細設計書) どおりに動作するか確認するためのテスト工程といえる。Integration Test・IT とか、Joint Test、Combined Test といった呼び方がある。

例えば「トップページには常に最新のユーザ名を表示する」という設計をテストする場合、「『トップページ』からユーザが『ログイン』し、『会員情報の変更』画面でユーザ名を変更したあと、再び『トップページ』に戻った時、変更後のユーザ名が表示されるかどうか」といったテストケースを組むことになる。こうしたケースは単体テストでは確認しきれず、実際に作成した機能や画面たちを結合して動かしてみないと分からないポイントである。

結合テストをさらに分割して「内部結合テスト (内結)」「外部結合テスト (外結)」と定めたりする場合もある。1システム内で完結する内容をテストする場合は内部結合テスト、外部のシステムと通信したりするテストを行う場合は外部結合テスト、と工程を区別することがある。

• 例えば「会員 DB は別システムで既に持っていてそれを参照利用するシステムを開発している場合」などは、「会員 DB」の運用保守チームと相談のうえ、作業タイミングやテストデータの投入などを行う必要が生じる
• 内結・外結を区切る方が、スケジュールを組むうえでも他チームとの合流を管理しやすくなるし、「内結で生じたバグ」「外結で生じたバグ」を区別することで不具合の特定を容易にできる面もある

主に内部結合テスト相当の範囲で、実際に画面遷移や「モック API」を利用した自動テストを組むことがある。E2E テストと呼ばれ、Selenium 等のツールで実際にブラウザを操作し、稼動するシステムの動作をテストコードでテストする方法もある。E2E テストは実装が大変ではあるが、スクリーンショットの撮影や前回テストとの差分比較などを含めて自動化できると大変有用なので、代表的なケースだけでもテストコード化できると良いだろう。

いずれにしても、内部実装 (コードそのもの) をチェックする意図ではなく、設計書に書いたことが実現できているか、という「ガワ」を見るので、ホワイトボックステストと対比してブラックボックステストと呼ばれたりする。

• 参考 : テスト初心者が知っておくべきブラックボックステストの種類と概要 - Qiita

総合テスト

総合テストは、機能要件、および非機能要件をテストするフェーズ。System Test・ST と呼んだりする。

この辺、分け方が現場によってまちまちで、「基本設計書をテストするのが総合テスト」とする場合もあれば、「要件定義書に記載の機能要件をテストするのが総合テスト」とする現場も見たことがある。いずれにしても、エンドユーザの視点で、ユースケースを基にテストを行うのが主な方法である。

非機能要件のテストに関しては、その性質によって以下のようにテスト名称を分けることが多い。

• 運用テスト : 日付や月をまたいで使用しても問題ないかを検証する
• 性能テスト : わざと負荷をかけ、想定した負荷量に対する応答のパフォーマンスが出ることを検証する

また、これらを総称して「外部結合テスト」と呼ぶ現場もあったりするので、現場ごとにテスト工程名とテスト範囲、テスト手法などを「テスト計画書」としてまとめておくことが重要である。

ユーザ受け入れテスト

単体・結合・総合テストまでは受注開発側が行うテストだが、以上が済んだら、発注側が行う検収作業として、受け入れテストというモノを行う。User Acceptance Test・UAT と呼んだりする。

発注側が行うテストなので、その粒度は「外部結合テスト」ないしは「総合テスト」に近い粒度となることが多い。

ユーザとしてはどうしても「要件定義書に書かれたとおりの内容」というよりも「要求」をぶつけてくることが多いので、「やっぱりこの機能が欲しい」などという後出しに立ち向かう顧客折衝スキルが問われる。ｗ

事前にテストケースを用意せず、ランダムな操作を行ったり、思いついたユースケースをその場で実行したりする「モンキーテスト」「アドホックテスト」といったテストも行われることがある。これらは単体・結合・総合テストの中で開発者も行っておくと良いテスト手法だが、大抵はスケジュールに組み込まれないので、UAT 段階のモンキーテストで発覚するバグもありがちである。