今夜わかる！テストケース作成手法

「テストってなんのためにやるんだろう」「テストケースなんてテキトーに作ればいいじゃん」そんなことを考えているエンジニアの方、いませんか？テストは退屈で無駄な作業なんかではなく、本当はすごく楽しくて生産的な作業なんです。今回は、ソフトウェア開発におけるテストの重要性や、様々なテストケース作成手法をご紹介していきます。

テストってどうして必要なの？

エンジニアの皆さん、コーディングは好きですか？私は大好きです。きっと、これを読んでいるあなたもそうなのではないでしょうか。
それではテストはどうですか？この質問に対しては、先ほどよりも「Yes」と答える方の割合が少なくなりそうですね。しかし、ソフトウェア開発におけるテストは、コーディングと同じくらいに重要なものです。

リリース後に致命的なバグが見つかりサービスが継続不可となったり、ユーザに多額の損失を与えてしまう事例は後を絶ちません。テストでそれらのバグを全て潰すことは出来ません。けれど、適切にテストを実施していれば、そのうちの何割かは防ぐことが出来たのではないでしょうか。テストは、システムに障害が発生するのを防ぐ「防波堤」としての役割を担っています。

テストケース作成手法ってどうして必要なの？

それでは、テストを語る上で外すことの出来ない「テストケース作成手法」はなぜ必要なのでしょうか？
例として、あなたの上司が職場でこのような言葉をかけてきたとします。

「ユーザ登録画面のテストケースを作ったよ。入力値の組み合わせが11 × 10 × 8パターンあるんだけど、明日の朝10時までにやってもらえるかな？」

全部で何パターンあるかすぐに分かりましたか？正解は880パターンです。
あなたはきっと真面目なエンジニアなので、サボらずに全てのパターンを打鍵することでしょう。（ちなみに筆者は不真面目なエンジニアですので、途中でサボって帰ってしまいますけどね）仮に1つのテストに5分かかるとして、880パターン × 5分 ＝ 4400分！とても明日の朝10時までに終わりそうにありませんね。

これは極端な例ですが、テストケースを作るのに慣れていないエンジニアは以下のような失敗をしてしまいがちです。

1. 不必要なテストパターンが多すぎる

「全ての組み合わせを網羅しなくては」と考えてしまうあまり、意味のないテストケースをたくさん作り込んでしまうタイプです。先ほどの例で示したように、組み合わせが多くなるとあっという間に天文学的なパターン数になってしまいます。

2. 異常系テストが足りていない

「数値の項目にカタカナを入力したら」、「データベースに接続出来なくなったら」のような、異常なパターンのテストがそもそも足りていないタイプです。実際のシステム運用では、想定していない事態は頻繁に起こります。異常系テストが足りていないと、そのような時にすぐ壊れる脆弱なアプリケーションになってしまいます。

過不足なく適切なテストケースを作成するには、その手法を体系的に学ぶ必要があります。次の章からは、具体的にそれらの手法を見ていきましょう！

テストケース作成手法 – 同値分割

同値分割とは、起こりうる全ての事象をいくつかのグループに分け、各グループから代表値を選ぶ手法です。例として、以下のような仕様を持ったアプリケーションがあるとします。

・ユーザの年齢をテキストボックスに入力する。
・年齢は0～200までの数値が入力可能である。
・入力後、「チェック」ボタンを押す。
・入力された値に応じて、異なるメッセージボックスが画面上に表示される。
0～19が入力された場合：「未成年です」というメッセージボックス
20～99が入力された場合：「成人しています」というメッセージボックス
100～200が入力された場合：「とても長生きですね」というメッセージボックス

このアプリケーションにおいて、入力可能な数値の種類はたくさんありますが、実はそのグループは3つしかないことが分かります。つまり、以下の図のようなグループです。

同値分割では、これら各グループの中からそれぞれ10、80、150のように代表値を選び、テストを実施します。

テストケース作成手法 – 境界値分析

境界値分析は、同値分割によって分けられた各グループの境界値付近をテストする手法です。先ほどのアプリケーションですと、19と20、99と100がその境界値にあたります。

仕様書の「以下」と「未満」を取り違えたり、プログラムのif文中で不等号「＜」と「≦」を誤るなどして混入したバグは、この手法を用いて検出することが出来ます。

テストケース作成手法 – エラー推測

エラー推測は、エラーが発生しそうなデータパターンを推測し、テストケースを作成する手法です。このようなデータパターンというのは、ある程度形式知化されています。具体的には、以下のようなものがよく用いられます。

1. 最大値・最小値、最大値より大きい値・最小値より小さい値

言語やアプリケーションの仕様によって、入力可能な数値や文字長の最大値・最小値は決まっています。
その値を超えた場合に、どのような動作となるかを検証します。
※このパターンは、エラー推測ではなく境界値分析に分類されることもあります。

2. 小数

浮動小数点数のように、桁数が大きなデータを扱うと丸め誤差が生じてしまうものをテストします。

3. 空文字・スペース・ゼロ・NULL

プログラムは「データが存在しない場合」や「NULLを参照した場合」に誤動作が発生しやすくなります。

4. 入力されることを意図していない文字種

数値の項目に漢字を入力する、氏名の項目に記号を入力するなど、本来は入力されるべきでない文字種に対しバリデーションが機能していることを検証します。

5. うるう年、存在しない日付・時刻

日付の項目にうるう年を入力し、正しく扱えることを確認します。また、「2015/14/12」、「26:00:00」のように存在しない日付・時刻を入力してみることもあります。

おわりに

普段、あまりスポットが当たることのない「テスト」という作業。けれどそれは、より品質の高いソフトウェアを作るためになくてはならないものです。記事の中で登場した手法を使って、効率的かつ効果の高いテストケース作成を実現してみませんか？