プロダクト開発

テストケースの作り方。目的や観点、書き方の例

ソフトウェアを開発する上で、テストに携わることがあると思います。アジャイル開発においても、Product/Market Fitを達成した後はソフトウェアの品質がより重要になってきます。

今回は私がチームでテストの書き方について共有するために、テストケースとはなにか、作り方や観点、書き方などについての基本的な内容をまとめてみました。テストを行う際の参考になればうれしいです。

この記事の対象となる読者の方

この記事は、ソフトウェアのテストに関わる方、とくにテストの経験が長くない方を対象としています。また、筆者はWebエンジニアなので、その文脈でまとめています。

著者
ぜに/Hiroki Zenigami

Webエンジニア&プロダクトマネージャ←プログラミング教育で起業←東大院←熊本高専。 共著に「現場で使えるRuby on Rails 5」。

目次

テストケースとは

テストケースとは、『ソフトウェアのテストをどう実施するかが書かれた手順書』のことをいいます。テストケースをもとに、手動でテストを行ったり、自動テストを書いたりします。

まずはじめに、この記事の前提知識としてテストの種類テストケースの種類についてまとめます。

テストの種類

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

種類説明
ユニットテストモジュールのメソッド単体に対するテスト
インテグレーションテストモジュール間の連携に対するテスト
システムテストユーザ視点でのインタフェースをとおしたテスト

テストケースの種類

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

種類説明
正常系想定している入力に対して期待どおりの出力を行うか
異常系想定していない入力に対して問題なく対処できるか

いろんな種類のテストについて、正常系と異常系をもとにテストの手順を書いていくのがテストケース、ということになります。また、テストケースは手順書なので、つまり読み手がいることになります。読み手がわかるような文章を心がけて書くとよいですね。

ユニットテストなどいろんな種類のテストについて、正常系と異常系をもとにテストの手順を書くのがテストケースです。

なぜテストケースを作るのか

そもそもなぜテストケースを作る必要があるのでしょうか。テストケースは『それをもとにテストを行う』というのはもちろんそうですが、品質という意味でも次の3つの目的があります。

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

1. 必要なテストを漏れなく実施するため

テストケースは、ソフトウェアのあるべき姿を記述したものといえます。必要なテストがないと、提供したい機能がバグなどの理由で提供できなくなるかもしれません。とくに、異常系のテストケースは足りなくなりがちです。

こういったテストの漏れは、テストケースを書くことで解消できます。テストケースがあることでレビューができるため、レビューをとおして漏れを防ぐことができます。

テストケースを作るとき、作成者がシステムやビジネスに完全に通じているとは限りません。作成者のみでテストケースの作成を完結すると、漏れが出るかもしれません。システムやビジネスに詳しいメンバーからのレビューを行うことで、不足したテストケースを追加することができます。

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

2. 不要なテストを削除するため

必要なテストが漏れるのはよくありませんが、一方で網羅製を担保しようとしてテストケースを無駄にふやしがちになるという問題もあります。

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

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

3. 誰が行っても同じテストにするため

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

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

テストケースの作り方

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

順番項目内容
1前提条件テスト対象の前提となる値や状態はなにか
2手順どのようにテストするか
3入力値どのような値を入力するか
4期待する結果どのような結果を期待しているか

テストケースの例

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

項目内容
前提条件5が入力されている
手順かけるボタンを押す
入力値を押す
計算ボタンを押す
入力値6
期待する結果30が表示されている

テストケースの入力値

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

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

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

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

1. 同値分割

同値分割は入力をグループ化して、有効なものと無効なものに分けるやり方です。たとえば『一桁の自然数』が入力だとすると、

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

の3つのグループに分けることができます。つまり、入力値としてたとえば0、5、10の3つにすればよい、ということになります。

2. 境界値分析

同値分割において、経験則的に同値グループ間の境界にバグが発生しやすいということが分かっています。上の例でいうと、0と1、9と10などですね。このような境界値では等号や不等号のミスなどでバグが起きやすくなっていて、これを境界値分析で検出することができます。

3. ペアワイズ法

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

上の計算機能の例では要因は2つですが、テストの対象によってはもっと多くなるパターンも出てくると思います。ペアワイズ法を用いることで、組み合わせの数が多いときにテストケースを大きく削ることができます。

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

ペアワイズ法により組み合わせを選ぶやり方として、マイクロソフト社製のPICTというツールがあります。

4. エラー推測

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

テストケースの観点

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

全般

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

データ

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

セキュリティ

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

エラー

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

画面

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

アクセス

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

環境

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

通信

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

いつテストケースを作るか

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

たとえば、GitHubのプルリクエストをとおして変更を適用している場合は、プルリクエストの本文にテストケースを書き、テストコードとあわせてレビューすればよいのかな、と思います。

テストケースのスキルを身につける

テストケースの作成は、いろんな開発の現場にとって重要なスキルです。実際の現場で開発することで、より高いスキルを身につけることができます。ただ、他の現場に出会うには準備が必要になります。

少しでも他の現場が気になるなら、あらかじめ転職サイト・副業サイトに登録しておくといいです。次の記事で、登録しておくべきサイトについて説明しています。

まとめ

この記事では、テストケースとはなにか、目的や作り方についてまとめました。システムの種類やビジネス形態によって書くべきテストも変わってくるので、目的にあわせてテストケースを作れるようになりたいですね。

参考文献

著者
ぜに/Hiroki Zenigami

Webエンジニア&プロダクトマネージャ←プログラミング教育で起業←東大院←熊本高専。 共著に「現場で使えるRuby on Rails 5」。

関連記事関連書籍人気記事
applis
エンジニアとしてのんびり暮らす
お問い合わせ
ご意見・ご質問やお仕事のご依頼などは下記よりお願いいたします
お問い合わせ
© applis