初めまして、ハンズラボエンジニアの @szkdskです。
前職はSIerで、ハンズラボには今年1月に入社したので今月でちょうど1年が経ちます。
テストについての記事を書きたいなーと思っていたらアドベントカレンダーやるということで、
軽い気持ちで参加しました。
これまでの経験から、フィーリングで記事を書いているので誤りなどご指摘いただけると幸いです。
テストケースの作成について感じていること
本記事では、単機能テストのケースの作り方についてを書いていきます。
前職では複数のシステムのお仕事をさせていただきましたが、
テストケースの作り方については「現場独自のノウハウ」「ベテランの経験と勘」という案件が多く、
体系的にまとまっていないと感じていました。（もちろん、きちんとノウハウ化している方々も多くいらっしゃると思います。）
そんな中で、初めてテストケースを作ることになった方や、
以前のテストをそのまま使いまわしているけれど、なんでこのケースをやっているんだ？という疑問を持った方向けに
自分が使っている手法について、まとめてみます。
ソフトウェアテストのV字モデル
ソフトウェアテストにはV字モデルというものがあり、
それぞれの段階でテストする観点などが違ってきます。
それぞれについていくつか具体例をあげると以下のようになるかと思います。
-
コーディングに対するテスト
- linter、コンパイラ
-
詳細設計に対するテスト
- 単機能テスト
- 自動テスト(単機能テストに相当するユニットテスト)
-
機能設計に対するテスト
- 結合テスト
- I/Fテスト
- シナリオテスト
-
システム設計に対するテスト
- 性能テスト
- 運用テスト
このうち案件に寄らずにテストケースを考えることができるのは、
単機能テスト（含む自動テスト）です。
私の場合、テストケースを考える際、ホワイトボックステストと、ブラックボックステストの二つに分けています。
ホワイトボックステスト
ホワイトボックステストは、ソースコードからテストケースを作成する手法です。
ソースコードを基準としてテストをするため、論理的に誤ったコードを判別することが可能ですが、機能や仕様の間違いを摘出することは不可能です。
全てのコード、条件分岐を通るようにテストケースを作成します。
テスト結果としては、カバレッジ率を指標とすることが多いです。
また、静的解析ツールをこのタイミングで実行し、テスト結果とすることもあります。
ブラックボックステスト
ブラックボックステストは、入出力仕様からテストケースを作成する手法です。
ソースコードは考えず、その機能が「何を入力するのか」「何を出力するのか」をテストするケースを作成します。
同値分割・境界値分析やデシジョンテーブルを用いてテストをするのが一般的だと思います。
同値分割・境界値分析
例えば、20才区切りで0〜100才までの年齢を入力して情報を出力するプログラムのテストをする場合、
すべてのケースをテストすると101ケース実施することになってしまいます。
そこで、同じ結果となる入力値を一つにまとめて"同値クラス"というもの作り、同じ結果になるものの中でも
代表的な値や、結果が変化する境界にある値のみをテストし、無駄なテストケースを省略します。
以下に例を挙げてみます。
この例の場合は代表値、限界値をテストすれば良いので、101ケースから、15ケースまで省略できます。
| 年齢層 | 代表値（同値クラス内の任意の値） | 下限値 | 上限値 |
|---|---|---|---|
| 0〜20 | 15 | 0 | 20 |
| 21~40 | 30 | 21 | 40 |
| 41~60 | 50 | 41 | 60 |
| 61~80 | 70 | 61 | 80 |
| 81~100 | 90 | 81 | 100 |
デシジョンテーブル
デシジョンテーブルとは、Yes/Noで判別できる条件を集めて、結果を判別する手法です。
割引の条件がサービスデー、60才以上、会員であること の3つの条件があり、
そのうち一つ満たせば20%、二つで30%、すべて満たすと40%となる仕様がある時、
どのような入力をすればすべてのパターンが作れるかを考える際に使用します。
| No. | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|---|
| 条件 | サービスデーである | Y | Y | Y | Y | N | N | N | N |
| 60才以上である | Y | N | Y | N | Y | Y | N | N | |
| 会員である | Y | N | N | Y | Y | N | Y | N | |
| 結果 | 割引率40% | Y | |||||||
| 割引率30% | Y | Y | Y | ||||||
| 割引率20% | Y | Y | Y | ||||||
| 割引なし | Y |
エラー推測
不具合が起きやすい条件でテストを実施する手法です。
言語やフレームワークによってケースとするべき内容が変わる場合がありますが、
代表的なものをいくつか挙げます。
- 小数計算時の丸め誤差
- 空文字入力、null入力
- 半角スペースや*(アスタリスク）、HTMLタグ、SQLなどの特殊な意味を持つ入力
- うるう年
- 存在しない日付、時間の入力
- データベースにデータが入っていない状態での処理実行
- etc
最後に
とりとめもなく書き連ねてしまいましたが、この記事が少しでもお役に立てれば幸いです。
明日は@Yuki_BB3さんの記事です！