単体テスト仕様書の書き方｜テスト項目の作り方とテンプレート

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

単体テスト仕様書とは？何を確かめる書類か

テストの国際的な資格の体系であるJSTQBのシラバス（Version 2023V4.0.J02）では、テストの段階の最初をコンポーネントテストと呼んでいます。ユニットテストとも呼ばれ、日本の現場では単体テストという呼び方が一般的です。

デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）でも、開発する事業者に「単体テスト、結合テスト及び総合テスト」のテスト計画書の案を求めています。単体テストは、テストの土台に当たる段階なんです。

単体テスト設計書と単体テスト仕様書は同じ？

『単体テスト設計書と書いてある所もあるけど、別の書類？』と迷いますよね。結論から言うと、現場によって呼び方が違うだけで、同じ書類を指すことがほとんどです。

チームによっては、「何を確かめるか」を決める設計書と、「どの手順で確かめるか」を書く仕様書を分けることもあります。迷ったら、先輩や現場のテンプレートで、どちらの名前で何を書いているかを確かめておきましょう。

テストの書類全体の話はテスト仕様書とは？書き方・項目とテンプレートの使い方で紹介しています。

単体テスト仕様書に書く項目

単体テスト仕様書のテンプレートは、表の形にするのが一般的です。編集部では、次の列を基本の形としておすすめしています。

期待結果は「見れば判定できる」言葉で書く

単体テスト仕様書の書き方で一番つまずきやすいのが、期待結果の欄です。「正しく計算されること」と書いてしまうと、何が正しいのかが人によって変わってしまいます。

期待結果は、返る値や画面の文言、データの状態など、見れば合否が決まる言葉で書きましょう。

テスト項目は「正常・境界・異常」の3列で作る

『正常に動く項目は書けたけど、ほかに何を書けばいいか分からない』という声はとても多いです。そこで編集部では、テスト項目を3列で作る作成表を考えました。

境界の列は「切り替わる所」を探す

境界の列を埋めるには、設計書の中から「以上」「未満」「まで」などの言葉を探してみてください。条件が切り替わる所には、書き間違いや考え違いが入りやすいんです。

例えば「一定の金額以上で送料無料」という決まりなら、その金額ちょうどと、1つ手前の値の両方を確かめます。「以上」と「より大きい」の取り違えは、こうしたテストで見つかります。

異常の列は「止まり方」を確かめる

異常の列は、エラーを起こすことが目的ではありません。おかしな値が来た時に、決めたとおりに止まり、決めたとおりの知らせを出すかを確かめます。

正常の列も、分かれ道ごとに作る

正常の列は1行で終わらせがちですが、処理の中に分かれ道があれば、その数だけ行を作ります。送料の例なら、「送料がかかる」と「無料になる」の2つの道があるので、正常の列も2行になります。

3列で作った単体テスト仕様書の記入例

編集部が作った架空の例で、送料を計算する部品のテスト項目を並べてみますね。無料になる下限の金額を「下限額」と呼ぶことにします。

こうして並べると、『境界の行が抜けていた』『異常の時の知らせを決めていなかった』といった穴に、書いている途中で気づけます。表が埋まらない所こそ、設計した人に聞くべき所なんです。

単体テスト仕様書のテンプレートの作り方と進め方

テンプレートは、現場ですでに決まっていることも多いです。新しく作る時は、先ほどの列を1行目に並べ、部品ごとにシートを分けておきましょう。

単体テストの元になる詳細設計書の書き方は、詳細設計書とは？基本設計書との違いと書き方で紹介しています。

テンプレートの表紙と履歴も忘れずに

表紙には、システム名、対象の部品、版、作成者、レビューした人を書いておきます。設計が変わってテスト項目を直した時は、変更履歴に何を直したかを残しておきましょう。

テストデータは前提の列とセットで用意する

前提の列に「会員として登録済み」と書いたなら、そのデータをどう用意するかも決めておきます。テストのたびにデータの状態が違うと、同じ項目でも結果が変わってしまうからです。

テスト用のデータを用意する手順を、別のシートに短く書いておくのがおすすめです。ほかの人が引き継いだ時も、同じ状態からテストを始められます。

単体テスト仕様書でよくある相談

知恵袋で多く読まれている相談を要約して、答えてみますね。

相談1：単体・結合・システムテストの仕様書の書き方が分からない

『単体テスト、結合テスト、システムテストの仕様書の書き方が分からない。くわしく載っている所を知りたい』という相談です。とても多くの人に読まれています。

結論から言うと、3つとも「前提・入力・期待結果」を書く点は同じです。違うのは、確かめる範囲と、元にする書類です。

単体テストは詳細設計書、結合テストは基本設計書、システムテストは要件定義書を元にすると覚えておくと、書く中身が決めやすくなります。結合テストの書き方は結合テスト・総合テスト仕様書の書き方で紹介しています。

相談2：単体テストの項目は、仕様書だけ見てソースは見ないもの？

『単体テストの項目は、仕様書だけを見て作るのが基本？ ソースの条件分岐を一つずつ追うべき？』という相談です。

考え方は2つあります。仕様書から作るテストは、決めたとおりに動くかを確かめるもの。ソースの分かれ道を通るように作るテストは、書かれた処理を漏れなく動かすものです。

どちらか一方ではなく、まず仕様書から項目を作り、足りない分かれ道をソースで補う、という順番が進めやすいですよ。

相談3：仕様書が無いまま、難しいソースから単体テストを作っている

『システムの仕様書が無く、難しいソースを読みながらテストを洗い出していて苦しい』という相談です。

そう感じるのは自然なことです。こんな時は、ソースを読んで分かった動きを「こう動くはず」と短く書き出し、詳しい人に確かめてもらいましょう。

確かめた内容は、そのまま簡単な設計メモとして残しておきます。次に同じ部品を触る人が、ずっと楽になります。ソースから設計書を起こす方法はソースコードから設計書を作る（リバース）で紹介しています。

書ける力は、次の仕事にもつながる

単体テスト仕様書を丁寧に書く経験は、設計書を読む力そのものを鍛えてくれます。今の現場で設計の担当に少しずつ近づくのも、資格を取ってから動くのも、どちらもよい道です。

今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると、どんな経験が評価されるかが見えてきます。

よくある質問

まとめ

あわせて読みたい

テスト仕様書とは？書き方・項目とテンプレートの使い方

結合テスト仕様書の書き方｜総合テスト・受入テストとシナリオの作り方

仕様書とは？意味と目的、設計書・要件定義書との違い