はじめに
テストケースを作ったことがない、「単体テストやった？どういう観点で？」と聞かれてハッキリ答えられない、そんな人が周りに増えてきたので覚え書き程度で書いていきます。
単体テストとは
コーディングしたプログラムが正常に動作するのかを確認するためにあるテストのことです。
実装する機能についてロジックミスがないかどうかを条件分岐ごとに調整することで、問題なく機能するかを確認します。
テストは単体テストだけではなく、他に結合テスト、総合テストがあります。
- 結合テスト:他の機能や他サービスと連携・連動が正しく出来るか
- 総合テスト:システム全体を適して想定する要件を満たしているか
これらは単体テストとは目的や観点が異なりますが、単体テスト同様サービスの開発においては非常に重要な役割を担います。
Webサイト・アプリなどの画面における単体テストの作り方
基本的にサービスに対して、画面設計書をもとにチェックすべきことを網羅しながらテストケースを作成していきます。
下図は画面設計書の例です。
私が、画面における単体テストのテストケースを作成する際に気を付けている点は主に以下のことになります。
- 画面仕様
- バリデーションチェック
- インプット・アウトプット
単体テストには上の３つの観点で考える画面上のテストとは別に
サーバサイドにおけるAPIの動作のテストも重要です。
APIのテストについては次回説明したいと思います。
1. 画面仕様
要件通りに動作・レイアウト出来ているかを確認するテストケースです。
例えば設計書通りにアイコンやテキスト、数値をはじめとする画面アイテムが配置されているか、
そのフォーマットが一致しているかなどを確認します。
画面アイテムに関しては大きく分けて、4つのチェック観点があると思います。
・レイアウト
・形式
・アクション
・エラー
-
レイアウト
設計書と見比べて、アイコン画像やヘッダ画像がレイアウトの指示通りか、ズレや不具合がないかを確認します。
また、画面アイテムの文言が一致しているか、初期値が設計書と同じになっているか確認します。
上図においてテスト結果としてはNG、修正が必要と言えます。 -
形式
使用する画面アイテムの形式が設計通りになっているかを確認します。
画面表示項目の形式(日付であればYYY/MM/DDなのか、YY年MM月DD日なのか)が設計書通りであるかを確認します。 -
アクション
画面アイテム上のボタンなどからの遷移やソート、ダイアログ・モーダル表示が正しいかを確認します。
また、Ajaxなどを利用している場合は、アクション時に動的処理を実施できているかの確認も忘れないようにしましょう。 -
エラー
エラー発生時の動作チェックに関しては、アクションでのチェック観点と類似します。
まず、エラーが発生した時の画面やモーダル、エラーコード、エラーメッセージが設計書通りになっているか。
同時に、エラーが発生した時、ユーザに次の操作の誘導や回避方法などが示されていることや、
「エラー発生時に再操作ができない」、「画面が閉じられない」などのデッドロック状態にならないことも確認してください。
2. バリデーションチェック
入力欄などに対する入力内容や記述内容が要件を満たしているか、妥当性を確認することを指します。
バリデーションチェックはアプリケーションの想定しない誤入力を避け、脆弱性を補完するために必要な要素です。
特に入力フォームなどで、悪意のある人間からの攻撃を防ぐことに大きな意味合いがあります。
バリデーションチェックにもいくつか種類があり、未入力チェック、文字列長チェック、型チェックなどがあります。
単体テストでは主に以下のバリデーションについて確認します。
1. 数値、文字列の長さが適切であるか
2. 日付や日時が想定した形式(YY/MM/DDなのか、西暦・和暦なのか等)であるか
3. 最小・最大、また想定した範囲での数値が選択されているか
4. 検索形式(前方一致、全文一致)が、設計通りになっているか
5. 入力値の過不足に対して、補完・エラーが発生する仕様になっているか
その他、サービスや要件、端末やブラウザごとにテストをする必要があります。
3. インプット・アウトプット
インプット ・アウトプットの形式が設計書の指定の形式になっているか確認します。
インプットであれば、フォームにおけるユーザ入力、選択アクション、
ファイルのインポート、カメラの起動による写真等設計書の想定通りであるかを確認します。
アウトプットであれば、画面表示・遷移・モーダル・ダイアログ表示、
データの抽出の際の形式(CSV,TSV,TXTなど)が想定通りであるかを確認します。
また、この際インプット・アウトプット両者において
ファイルの項目名や項目名の定義が一致しているかを確認することも行います。
単体テストケース作成の為のチェックシート導入
私は以上のようなことに気を付けながら、
アプリケーションやサービスをチェックする単体テストを作成しています。
単体テストを作る経験を積む中で共通する項目などをまとめ、チェックシートを作りました。
上図は私が、テストケースを作成する際に注意する点を項目ごとにまとめたチェックシートです。
このようなチェックシートがあることで、作成時見落としを減らせる上、
経験を積んでいない人にもある程度大枠でテストケースの注意点を共有できます。
おわりに
単体テストにおいてテスターが共通認識をもつことは、手動テスト・自動テストどちらでも重要です。
チェックシートの作成やテスト対象の論理的・網羅的理解はその手段と言えます。
また質の高いテストケースを作ることがテストにおいて無駄をなくすことに繋がり、
サービスの品質の担保にも繋がります。
その一方で、単体テストの実施を自動でするか手動でするかの選択については、テスト設計者や実装者が判断します。
コストや期限などの状況、リソースの状態に応じて決定されるため、
単体テストを自動化する場合は、別の注意点や観点が必要になります。。
次回はAPIのテストとともに、この自動化についても説明できればと思います。