今回は、単体テスト仕様書に書く内容について説明していきます。この記事を読めば「単体テストとは何か？」から結合テストとの違い、そして実際の書き方まで、初心者の方でもざっくりと理解できるようになるはずです。
単体テストとは？
単体テストとは、プログラムの一番小さな部品（＝モジュール・関数・クラスなど）を1つずつテストすることなのですが、ただこれだけ聞くと少しイメージしにくいですよね。たとえば、システムを自転車にたとえる…
ブレーキ・ペダル・車輪などの部品がそれぞれ正しく動くかを確認するのが単体テストです。一方で、結合テストは「ペダルを漕ぐと車輪が回るよね？」というように、部品同士を組み合わせて、連携が正しくできているかを確認するテストになります。
また、単体テスト仕様書を書くタイミングとしては、コーディングを行なった後です。
| 工程 | 内容 | 単体テストとの関係 |
|---|---|---|
| ① 要件定義 | 何を作るかを決める（機能・条件など） | この時点ではまだテストの対象が決まらない |
| ② 基本設計書 | システム全体の設計（画面・機能・データの流れなど） | 単体テストの大まかな対象が見えてくる |
| ③ 詳細設計書 | 各機能をプログラム単位で細かく設計する | 単体テストのテストケースを考える |
| ④ 製造（コーディング） | 実際にプログラムを書く | この後に単体テストを実施！ |
| ⑤ 単体テスト | 作ったプログラム単位でテストする | コーディングの直後に行う工程 |
単体テスト仕様書の書き方
単体テスト仕様書は、基本設計書・詳細設計書の内容を確認しながら書いていきます。
単体テスト仕様書に記載する内容は開発現場によって異なると思います。私が今働いている開発現場では基本的には以下のような項目を確認します。
1.共通処理 2.基本設計書 3.詳細設計書 4.処理速度 5.+α
どんな内容を確認するのか、各項目について詳しくみていきましょう。
1. 共通処理
共通処理で確認するテストケースは以下になります。
| No | テストケース | 判定基準 |
|---|---|---|
| 1 | リサイズ | 画面レイアウトが崩れないこと（スクロール2重表示・ボタンの重なりがないこと） |
| 2 | ショートカットキー制御 | 使用不可であること Ctrl + R / Fn + 12 など |
| 3 | 右クリックメニュー | 使用不可であること |
| 4 | システムエラー | 1. 共通エラーメッセージが表示されること 2. システムが停止しないこと ※更新系の処理ではロールバックが実施されること |
| 5 | JavaScriptエラー | JavaScriptエラーが内部で発生していないこと ※開発者ツールで確認 |
| 6 | フォント | 共通のフォントが適用されていること |
| 7 | ドキュメントモード | IEで表示した場合、ドキュメントモードが「IE11（既定）」で動作していること ※開発者ツールで確認 |
2. 基本設計書
基本設計書で確認するテストケースは以下になります。
| No | テストケース | 判定基準 |
|---|---|---|
| 1 | レイアウト | 画面のレイアウトが基本設計書通りであること（配置・間隔・整列など） |
| 2 | ラベル | ラベル名・文言・位置が基本設計書通りであること |
| 3 | 全項目 | 各入力項目（種類／桁数／書式／必須項目／初期値／リスト内容など）が基本設計書通りであること |
| 4 | 一覧項目 | 一覧画面でのソート機能・表示項目・並び順が基本設計書通りであること |
3. 詳細設計書
詳細設計書で確認するテストケースは以下になります。
| No | テストケース（※） | 判定基準 |
|---|---|---|
| 1 | 初期表示 | 仕様通りであること（「イベント仕様書」シート参照） |
| 2 | 〃 | 仕様通りであること（「SQL仕様」シート参照） |
これをみただけじゃイメージ掴みにくいと思うので、以前の記事で書いてみたイベント仕様書シートとSQL仕様シートを参考に出すと…
初期表示のイベントでは、確認しなければいけないテストケースは４つ（ログ出力・一覧データ取得・画面制御・ログ出力）あり、確認しないといけないSQLは１つ（社員情報一覧取得）となります。
4. 処理速度
処理速度で確認するテストケースは以下になります。
| No | テストケース | 判定基準 |
|---|---|---|
| 1 | 検索 | 3秒以内であること（※ボタン押下～データが表示されるまで） |
| 2 | 詳細 | 3秒以内であること（※ボタン押下～データが表示されるまで） |
| 3 | DB更新 | 3秒以内であること（※ボタン押下～データが登録・更新・削除され、メッセージが表示されるまで） |
＋α
基本的な確認項目に加えて、機能によってはより細かいテストパターンを設計する必要があります。
特に検索機能のような処理では、テストデータを準備し、条件に応じて意図したデータだけが正しく表示されるかを確認することが重要です。
この説明じゃちょっとわかりにくいと思うので、実際に検索のテストパターンを出してみましょう！
(例)検索のテストパターン
最近、Greenでよく求人を見ているのですが、今回はこのGreenの検索機能をテストすると仮定してテストパターンをざっくりと出してみました。
| No | 職種 | 勤務地 | 年収 | キーワード | 判定基準 |
|---|---|---|---|---|---|
| 1 | 指定なし | 指定なし | 指定なし | 指定なし | 全求人が表示される（初期表示 or 全件検索） |
| 2 | 指定あり（例：Webエンジニア） | 指定なし | 指定なし | 指定なし | 「Webエンジニア」職種の求人が表示される |
| 3 | 指定なし | 都道府県指定（例：東京都） | 指定なし | 指定なし | 東京都に勤務地を持つ求人のみが表示される |
| 4 | 指定なし | 複数都道府県指定（例：東京都・大阪府） | 指定なし | 指定なし | 東京都または大阪府の求人が表示される |
| 5 | 指定なし | リモート可 | 指定なし | 指定なし | 「リモート勤務可」求人のみ表示される |
| 6 | 指定あり（例：Webエンジニア） | 都道府県指定（例：東京都） | 指定なし | 指定なし | 東京都 × Webエンジニア職の求人が表示される |
| 7 | 指定あり（例：営業職） | 指定なし | 下限のみ（例：500万円～） | 指定なし | 年収500万円以上の営業職求人が表示される |
| 8 | 指定あり（例：営業職） | 指定なし | 上限のみ（例：～600万円） | 指定なし | 年収600万円以下の営業職求人が表示される |
| 9 | 指定あり（例：営業職） | 指定なし | 範囲指定（例：400～700万円） | 指定なし | 年収400〜700万円の営業職求人が表示される |
| 10 | 指定なし | 指定なし | 範囲指定（例：400～700万円） | 指定なし | 年収400〜700万円の求人が表示される |
| 11 | 指定あり（例：Webエンジニア） | 都道府県指定（例：東京都） | 下限のみ（例：500万円～） | 指定なし | 東京都 × Webエンジニア × 年収500万円以上の求人 |
| 12 | 指定あり（例：Webエンジニア） | リモート可 | 指定なし | 指定なし | リモート勤務可能なWebエンジニア求人が表示される |
| 13 | 指定なし | 指定なし | 指定なし | キーワードあり（例：「React」） | キーワード「React」を含む求人が表示される |
| 14 | 指定なし | 指定なし | 指定なし | キーワードあり（例：「未経験歓迎」） | 「未経験歓迎」を含む求人が表示される（タグ・本文含む） |
| 15 | 指定あり（例：Webエンジニア） | 指定なし | 指定なし | キーワードあり（例：「フロントエンド」） | 職種とキーワード両方に合致する求人が表示される |
| 16 | 指定あり（例：Webエンジニア） | 都道府県指定（例：大阪府） | 指定なし | キーワードあり（例：「Python」） | 「大阪府 × Webエンジニア × Python」求人が表示される |
| 17 | 指定なし | リモート可 | 範囲指定（例：400～700万円） | キーワードあり（例：「バックエンド」） | 「リモート可 × 年収範囲内 × キーワード」一致求人 |
| 18 | 指定あり（例：インフラエンジニア） | 指定なし | 下限のみ（例：800万円～） | キーワードあり（例：「AWS」） | 高年収（800万以上）のAWS関連求人のみ表示される |
| 19 | 指定あり（例：デザイナー） | 都道府県指定（例：福岡県） | 指定なし | キーワードあり（例：「Photoshop」） | 福岡県のデザイナー求人で「Photoshop」を含むもの |
| 20 | 指定あり（例：エンジニア） | リモート可 | 範囲指定（例：600～900万円） | キーワードあり（例：「マネージャー」） | 条件すべてに一致する「エンジニア（リモート）×マネージャー」求人 |
| 21 | 指定あり（例：Webエンジニア） | 指定なし | 範囲指定（例：200～300万円） | 指定なし | 条件に該当する求人が存在しない場合、「該当なし」表示 |
| 22 | 指定あり（例：デザイナー） | 指定なし | 指定なし | キーワードあり（例：「フリーランス」） | 「フリーランス」関連のデザイナー求人が表示される |
| 23 | 指定あり（例：マーケティング） | 指定なし | 指定なし | キーワードあり（例：「SNS」） | 「SNSマーケティング」関連の求人が表示される |
| 24 | 指定あり（例：人事） | 指定なし | 指定なし | キーワードあり（例：「リーダー」） | 人事職のうち「リーダー」含む求人が表示される |
| 25 | 指定なし | 都道府県指定（例：北海道） | 指定なし | キーワードあり（例：「在宅」） | 北海道で「在宅」勤務可能な求人が表示される |
| 26 | 指定なし | リモート可 | 指定なし | キーワードあり（例：「スタートアップ」） | リモート可かつ「スタートアップ」関連の求人 |
| 27 | 指定あり（例：エンジニア） | 指定なし | 指定なし | キーワードあり（例：「副業可」） | 「副業可」なエンジニア求人が表示される |
| 28 | 指定なし | 指定なし | 上限のみ（例：～400万円） | キーワードあり（例：「未経験」） | 年収400万円以下で「未経験可」求人が表示される |
| 29 | 指定あり（例：営業職） | 都道府県指定（例：愛知県） | 範囲指定（例：300～500万円） | キーワードあり（例：「法人営業」） | 愛知県×営業職×法人営業×年収範囲求人 |
| 30 | 指定あり（例：プロジェクトマネージャー） | 指定なし | 指定なし | キーワードあり（例：「アジャイル」） | 「アジャイル」関連PM求人が表示される |
検索条件をマトリクス図にすることにより、確認項目に漏れがでにくいテストケースが作れるかと思います。
まとめ
いかがでしたか？現在、開発現場で単体テスト仕様書を使ったテストを黙々と行っていますが、テストデータを作成する中で結合テストを意識したり、気づくことも多く、あらためて単体テストの大切さを実感しています。単体テスト仕様書を書く時は、しっかりと設計を理解したうえで仕様の確認漏れがないようなテスト仕様書になることを意識して作成してみてください！
