ソフトウェアを開発するときは、テストケースが重要になってきます。この記事をお読みの方はまさに今、テストケースの設計にお悩みかもしれません。私はこれまでウェブエンジニアとしてソフトウェアの開発に携わってきました。この経験をもとに、テストケースとは何か、作り方や書き方、項目の洗い出しについて解説します。

この記事は、ソフトウェアのテストケースを設計する方、特にテストケースの設計経験が少ない方を対象としています。また、私はウェブエンジニアなので、その文脈でまとめています。テストケースを設計するときの参考になればうれしいです。

Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

Follow @zenizh

まず、テストケースとは何か？ということについて整理します。テストケースとは、「ソフトウェアをテストする方法を記述した手順書」のことをいいます。このテストケースをもとに、手動でテストを行ったり、あるいは自動テストを実装したりします。

まずはじめに、この記事の前提知識として「テストの種類」と「テストケースの種類」について説明します。なお、テストケースについてより詳しく学びたいときは、「ソフトウェアテスト技法練習帳」という本があります。ソフトウェアテストの知識を定着させることを目的とした本になります。あわせてご覧ください。

ソフトウェアテスト技法練習帳

技術評論社

Amazon楽天市場

ひとことでテストといっても、ソフトウェアのテストにはいろんな種類があります。例えば、代表的なものの中に次の3つがあります。

また、ソフトウェアをテストする方法を示すテストケースには、正常系と異常系という2つの種類があります。

以上をまとめると、ユニットテストなどのいろんな種類のテストについて、正常系と異常系をもとにテストの手順を書いていくのがテストケース、ということになります。

そもそも、なぜテストケースを作る必要があるのでしょうか？テストケースの設計に初めて携わる方は、その必要性が分かりづらいかもしれません。

テストケースは、「それをもとにテストを行う」という手順書になるのはもちろんそうなのですが、品質という意味でも次の3つの目的があります。

1. 必要なテストを漏れなく実施するため
2. 不要なテストを削除するため
3. 誰が行っても同じテストにするため

この3つについて説明します。

ソフトウェアが正しく動作するかどうかは、テストを通して確認します。言い換えると、テストケースが足りない場合、ソフトウェアが正しく動作しないかもしれません。例えばバグがあると、ソフトウェアは正しく動作しません。

このようなテストの漏れは、テストケースを書くことでいくらか解消できます。テストケースがあることで、いろんなメンバーからレビューを受けることができるため、必要なテストケースがあるかどうか？という確認をすることができます。

例えば、あなたが入ったばかりのプロジェクトのテストケース作成を担当することになったとします。この場合、あなたはシステムやビジネスに詳しいとは限りません。つまり、作ったテストケースに漏れがある可能性があります。

こんなときに、システムやビジネスに詳しいメンバーからのレビューを受けることで、不足したテストケースを追加することができます。

システムのすべてのバグを防ぐことは難しいですが、減らすことはできます。リリース後に見つかるバグの修正コストは大きくなりがちなので、その意味でも、テストケースをしっかりと作る必要があります。

必要なテストが漏れるのはよくないことですが、一方で漏れのないテストにしよう！と考えて、テストケースを無駄にふやしがちになる、という問題もあります。

テストケースは多すぎてもよくありません。テストを行うことはコストになりますし、テストケースを維持するのにも同じくコストがかかります。そもそも同じ目的のテストケースがいくつあっても、品質の向上にはつながりません。

テストに詳しいメンバーからのレビューを通して、不要なテストケースを削除することで、将来的なコスト削減などにつながります。

テストを手動で行う場合、テストを行う人の能力によってシステムの品質に差が出てしまってはいけません。自動テストにおいても、同じく実装者によって差が出てしまわないようにする必要があります。

テストケースを作ってレビューを行うことで、テストの品質を高い水準に保つことができるようになります。

それでは、本題であるテストケースの作り方について説明していきます。テストの種類としてはユニットテストやシステムテストなどいろいろなものがあると説明しましたが、テストケースの基本的な作り方は次のようになります。

この表だけだと分かりづらいので、具体的な例を見てみます。

例えば、分かりやすい例として「一桁の自然数同士のかけ算をする計算機能」のテストケースについて考えてみます。一桁の自然数とはつまり1〜9の値を取りうるのですが、この場合は次のようなテストケースができます。

このような表が、テストケースのひとつの例になります。

前述したテストケースの例は、必要なテストケースのひとつでしかありません。実際には、一桁の自然数同士のかけ算、つまり1〜9同士の掛け算になるので、全部で81通りの組み合わせが考えられます。

また、入力可能性という意味では無限にあり得ます。どういうことかというと、不正な入力として0や-1などが入力される可能性も考慮しなければなりません。

この組み合わせについて、すべてのケースをテストするのは大変で、コストもかかります。このようにテストケースが多いときに、品質を保ちつつケースを減らす方法として、次の4つがあります。

1. 同値分割
2. 境界値分析
3. ペアワイズ法
4. エラー推測

それぞれについて説明します。

同値分割とは、入力をグループ化して、有効なものと無効なものに分けるやり方です。例えば「一桁の自然数」が入力だとすると、次の3つのグループに分けることができます。

• 1より小さい
• 1〜9
• 9より大きい

つまり入力値として、例えば0と、5、10の3つにすればよい、ということになります。これが同値分割です。

同値分割において、経験則的に「同値グループ間の境界にバグが発生しやすい」ということが分かっています。どういうことかというと、同値分割で示した例でいう0と1、9と10などの値を入力したときに、バグが発生しやすくなります。

このような境界値では、等号や不等号のミスなどでバグが起きやすくなるのですが、これを境界値分析で検出することができます。

ペアワイズ法とは、「ほとんどの不具合は1つまたは2つの要因によるものである」という経験則をもとにした方法で、たくさんある要因のうち「2つの要因の組み合わせだけは網羅する」、という観点で値を選ぶ方法です。

例えば、前述した計算機能の例では、要因は「前提条件」と「入力値」の2つですが、テストの対象によっては要因がもっと多くなることもあります。このとき、すべての要因についてテストを実施するのは大変ですが、ペアワイズ方を用いることで、テストを大きく削ることができます。

一方で、ペアワイズ法では本来検出できたはずのバグを取りこぼす可能性もあります。ペアワイズ法だけでテストせずに、組み合わせを選ぶときの参考にする程度でいいのかな、と思います。

これは上の3つの方法論とはちょっと変わっているのですが、「テストケースを作る人の経験に基づいて、エラーが起きそうな値を決めるやり方」です。例えば「一桁の自然数」という入力値に対して、負の数やヌル文字、空白、全角文字や小数などを用いてテストします。

ここまでで、テストケースの作り方と、入力値の選び方について説明しました。最後に、テストケースを作るときの観点をいくつかあげてみます。テスト対象となるシステムによって違うと思いますが、テストケースを設計するときの参考になればと思います。

• 入力に対する結果は正しいか
• 想定していない入力に対処できるか
• 入力の型や文字コードの種類は想定されているか
• 不適切な入力は想定されているか
• リクエストに対するレスポンスは正しいか

• レコードは正しく更新されているか
• トランザクションは考慮されているか

• 脆弱性は考えられないか
• 認証、認可のロジックは問題ないか
• 認証、認可失敗時の動作は問題ないか

• エラー処理はされているか
• 例外処理はされているか

• データがないときの処理・表示は問題ないか
• 文言は正しいか
• 画面の遷移先は正しいか

• 多重実行は考慮されているか
• 遅いネットワーク環境での利用は考慮されているか
• 処理がキャンセルされた場合は考慮されているか
• 同時アクセスは考慮されているか
• 同一ユーザーの複数端末からの利用は想定されているか
• 利用環境の差異（OSやブラウザなど）は想定されているか
• 利用者の役割（ゲスト、管理者など）は考慮されているか

• 実行環境の差異（開発環境、本番環境など）は想定されているか
• 時間やタイムゾーンの問題はないか

• APIなどの通信先は正しいか
• APIなど通信先のステータスは考慮されているか
• 非同期処理のタイミングによるデータの有無は考慮されているか
• 非同期処理は必要なところでされているか
• メールやチャットなどへの通知は行われているか、送り先は正しいか

ここからは余談になりますが、次にテストケースを作るタイミングについて説明します。特に決まりはないですが、テストケースは、そのテストの対象となる機能が入るタイミングで作成したりします。

例えばアジャイル開発においては、継続的にソフトウェアを変更するので、最初からすべてのテストケースを作ることはないと思います。ソフトウェアを変更するときに、変更とあわせてテストケースを追加したりします。

具体的な例として、GitHubのプルリクエストを通してソフトウェアを変更している場合は、プルリクエストの本文にテストケースを書き、ソースコードとあわせてレビューすればいいと思います。

また重要な点として、テストケースは手順書なので、読み手がいる、ということになります。作成した本人には理解できても、テストを実施したりテストコードを実装する人には分かりづらいかもしれません。

読み手が分かるような文章にすることを心がけて書いていきましょう。

この記事では、テストケースとは何か、作り方、項目の洗い出し方などについて説明しました。システムやビジネスの種類によって書くべきテストも変わってくるので、目的に合わせてテストケースを作れるようになれたらと思います。

ソフトウェアテスト技法練習帳

技術評論社

Amazon楽天市場

プロダクト開発

【2023年】エンジニアの本でおすすめの5冊を紹介します

2023-4-2

働き方

エンジニアの転職で登録したい7つの転職サイトと転職エージェント

2022-12-30

働き方

エンジニアの副業で登録したい5つのサイトやサービス【フリーランス】

2022-12-30