7.テスト

学習目標

テストの目的と限界を説明できる
テストレベルと V 字モデルでの開発工程との対応を説明できる
同値分割・境界値分析・デシジョンテーブルでテストケースを設計できる
テストケースをテスト仕様書にまとめ、手動で実施できる

開発プロセスの最後のフェーズがテストです。本章では、Q&A サイトの「回答に投票する」を題材に、テストの目的とレベルを理解し、テストケースを設計し、テスト仕様書にまとめて手動で実施します。コードによる自動化は自動テストで扱います。

1. テストの目的と限界

1-1. テストの目的

テストには、2 つの目的があります。1 つは、作ったソフトウェアが要件どおりに動くかを確かめることです。もう 1 つは、変更による劣化を防ぐことです。

開発を続けると、ある変更が、それまで動いていた別の箇所を壊すことがあります。たとえば、投票の処理を修正したときに、無関係の検索が動かなくなります。これを デグレード（デグレ）と呼びます。変更のたびに過去のテストを繰り返し実行し、デグレが起きていないかを確かめることを 回帰テスト と呼びます。

1-2. テストの限界

テストには、2 つの限界があります。

1 つは、すべての入力を試せないことです。たとえば評価は 0 以上の無数の値を取り、そのすべてを試す 全数テスト は実行できません。もう 1 つは、テストでは「欠陥がないこと」を証明できないことです。テストに成功しても、試していない入力に欠陥が残っている可能性があります。テストは、欠陥の存在は示せても、不在は示せません。

そのため、少ないケースで多くの欠陥を見つけられるよう、試す入力を設計します。期待結果は、要件で定めた値を根拠にします。

2. テストレベル

2-1. 4 つのレベル

テストは、確かめる範囲によって 4 つの レベル に分かれます。狭い範囲を細かく確かめるレベルから、アプリ全体をまとめて確かめるレベルまであります。

レベル	確認する範囲
ユニットテスト（UT）	クラスやメソッド 1 つ
インテグレーションテスト（IT）	複数のクラスやレイヤーの連携
システムテスト（ST）	アプリ全体の動作
受け入れテスト（UAT）	利用者の要求を満たすか

投票では、ユニットテストは「評価 15 以上で投票できる」という 1 メソッドのルールを確かめます。インテグレーションテストは、投票がコントローラーからサービス・データベースまでつながることを確かめます。システムテストは、ブラウザーで投票して画面に反映されることを確かめます。受け入れテストは、利用者が企画で定めた要求を満たせるかを確かめ、開発の最後に capstone で各チームが実施します。

2-2. V 字モデル

各レベルは、開発のどの工程で決めた内容を確かめるかに対応します。この対応を表した図が V 字モデル です。

開発工程とテストレベルの対応（V 字モデル）

左に下る開発、右に上るテストで、同じ高さの工程とレベルが対応し、各テストは向かいの工程で決めた内容を確かめます。要件定義はシステムテスト（ST）、基本設計はインテグレーションテスト（IT）、詳細設計はユニットテスト（UT）に対応します。要求分析（企画で利用者の要求を定める工程）は、受け入れテスト（UAT）に対応します。

実装（コーディング）は V 字の底にあたり、詳細設計にもとづいてプログラムを作り、それをユニットテストから受け入れテストへと順に確かめます。下のレベルほど実装に近く、上のレベルほど利用者に近い確認になります。

2-3. 自動テストと手動テスト

確認の手順を人が実行するのが 手動テスト、コードに書いて自動で実行するのが 自動テスト です。レベルによって、適した方法が変わります。

ユニットテストとインテグレーションテストは、範囲が狭く、入力と結果が明確なため、コードに書いて自動で実行します。回帰テストとして何度でも繰り返せます。書き方は自動テストで扱います。一方、システムテストと受け入れテストは、アプリ全体や利用者の体験を対象にするため、画面を操作する手動テストが中心です。本章では、この手動テストに向けてテストケースを設計します。

3. テストケースの設計

何を入力し、どのような結果になれば正しいかの組を テストケース と呼びます。「回答に投票する」には、次の 2 つのビジネスルールがあります。

投票するには、評価が 15 以上であること
自分の回答には投票できないこと

これらを確かめるケースを設計します。テスト技法は決まった順で使うのではなく、入力や条件の性質に応じて選びます。

同値分割 — 入力を、同じ結果になるグループに分ける。どの入力にも使う基本の技法
境界値分析 — 順序のある入力（数値・日付など）で、グループの境目を試す。同値分割と組み合わせて使う
デシジョンテーブル — 複数の条件があるとき、その組み合わせを整理する

投票では、評価が順序のある数値であるため同値分割と境界値分析を、評価と関係の 2 つの条件が組み合わさるためデシジョンテーブルを使います。

3-1. 同値分割

評価がどの値であっても、結果は「投票できる」か「投票できない」のどちらかです。同じ結果になる値をまとめ、グループごとに代表を 1 つ試せば、グループ全体を確かめたことになります。

入力を、同じ結果になるグループに分ける技法を 同値分割、分けたグループを 同値クラス と呼びます。期待どおり動くものを 有効同値クラス、拒否されるものを 無効同値クラス と呼びます。評価は、次の 2 つに分かれます。

同値クラス	範囲	代表値	結果
有効	15 以上	20	投票できる
無効	15 未満	10	投票できない

代表として 20 と 10 を試せば、各グループで評価のルールが成り立つことを確かめられます。

3-2. 境界値分析

代表値だけでは、見逃す誤りがあります。不具合の多くは、グループの境目に集まるからです。

「評価が 15 以上」を、評価 >= 15 と書くべきところを、誤って 評価 > 15 と書いたとします。評価 20 では正しく動き、10 でも正しく拒否されるため、代表値では気づけません。誤りが現れるのは、境目の 15 のときだけです。

そこで、グループの境目とその前後を試します。これが 境界値分析 です。評価の境目は 15 のため、直前の 14 と境目の 15 を加えます。14 で拒否され、15 で投票できれば、境目は正しく実装されています。評価について試す値は、14・15・20 の 3 つです。

3-3. デシジョンテーブル

評価のほかに、「自分の回答には投票できない」という条件もあり、2 つが組み合わさります。条件の組み合わせと、そのときの結果を表にして整理します。この表を デシジョンテーブル と呼びます。Y は条件を満たす、N は満たさない、— はどちらでもよいことを表します。

条件	規則 1	規則 2	規則 3
評価が 15 以上	Y	Y	N
他人の回答	Y	N	—
投票できる	Y	N	N

規則 3 のとおり、評価が 15 未満なら関係を問わず投票できません。よって、本人のルール（規則 2）は、評価を満たしたうえで確かめます。これにより、試す必要のない組み合わせが分かります。

3-4. テストケースの確定

3 つの技法で絞った値を組み合わせ、テストケースを確定します。評価は 14・15・20、関係は他人・本人です。各ケースには、確かめる観点を添えます。観点には、仕様どおり成功する 正常系、誤った入力を正しく拒否する 異常系、境目を確かめる 境界値 があります。

#	投票者の評価	回答者との関係	期待結果	観点
1	20	他人	投票できる	正常系
2	15	他人	投票できる	境界値
3	14	他人	投票できない	境界値・異常系
4	20	本人	投票できない	異常系

これらは、要件定義で定めたビジネスルールから導いています。要件の各項目に対応するケースをそろえれば、要件を満たすかを漏れなく確認できます。

4. テスト仕様書と手動テスト

4-1. テスト仕様書

設計したケースは、テスト仕様書 にまとめます。テスト仕様書は、各ケースをどう確認し、どうなれば合格とするかを記した、テストフェーズの成果物です。誰が実行しても同じ手順で確認でき、確認の抜けを防げます。各ケースには、前提条件・手順・期待結果と、実施したときに記入する実施結果を書きます。

#	前提条件	手順	期待結果
1	評価 20 でログイン。他人の回答が 1 件	質問の詳細を開き、投票ボタンを押す	投票数が 1 増える
2	評価 15 でログイン。他人の回答が 1 件	同上	投票数が 1 増える
3	評価 14 でログイン。他人の回答が 1 件	同上	エラーが表示され、投票数は変わらない
4	評価 20 でログイン。自分の回答が 1 件	同上	エラーが表示され、投票数は変わらない

手順は共通のため、前提条件と期待結果がケースごとに変わります。

4-2. 手動テストの実施

テスト仕様書の手順どおりにアプリを操作し、結果が期待結果と一致するかを確かめます。一致すれば合格、しなければ不合格を実施結果に記入します。不合格のケースは、不具合（バグ）として、再現手順・期待した結果・実際の結果を記録します。再現手順がないと、現象を確認できず、修正が進みません。

システムテストで各機能を確認したら、最後に 4 つのレベルで触れた受け入れテストを行います。capstone では、各チームが要件定義書をもとに、すべての機能がそろい、受け入れ条件を満たしているかを確認します。これが、開発プロセスの最後の確認になります。