テストケースの書き方は、開発でそれほど重要だとは思えないかもしれません。しかし、テスターが最高の仕事をするには、疑問の余地のない手順とテスト対象の明確な定義が必要です。
NASAやGEからエンタープライズレベルの企業まで、チームがベストを尽くせることは、あらゆる組織にとって利益となります。すぐれたテストケースを書くのも、チームの効率と有効性を高める方法の1つであり、Parasoftはまさにそれを支援することを使命としています。
このブログ記事では、テストケースの書き方に関する以下のトピックを取り上げます。
- テストケースとは
- テストスクリプトvs.テストケース
- さまざまなテストケースのタイプ
- ソフトウェアテストケースの書き方
- 標準的なテストケースの形式
- テストケース作成のベストプラクティス
- テストスイートvs.テスト計画
- テストケース作成ツール
ソフトウェアにおけるテストケースとは
テストケースとは、その名のとおりのものです。複数のアクションまたは条件にわたる機能を測定するテストシナリオで、期待された結果かどうかを検証します。テストケースはどのようなソフトウェアアプリケーションにも適用され、手動でのテストまたは自動化されたテストを用いることができ、またテストケース管理ツールを活用することができます。
テストケースの作成に際して覚えておくべき大切なことは、テストケースは、たとえばE-コマースWebページでディスカウントコードが適切な製品に適用されているかなど、基本的な変数やタスクをテストするものだということです。そのため、どのようにコードまたは機能をテストするかに関しては、テスターに大きな自由が許されます。
テストスクリプトvs.テストケース
テストケースとテストスクリプトの違いもはっきりさせておく必要があります。テストスクリプトとは、特定の機能をテストするための短いプログラムです。テストケースとは、事前に計画したとおり完了する必要がある手順を記載したドキュメントです。
テストケースを綿密に計画された旅行であると考えると、テストスクリプトは食品雑貨店にちょっと出かけるようなものです。
さまざまなテストケースのタイプ
テストケースはコードのさまざまな側面を計測します。テストケースに含まれる手順には、ユーザーがログイン画面で間違ったパスワードを入力した場合など、正常な期待結果ではなくエラー結果を発生させるよう意図されたものもあります。
一般的なテストケースとしては以下のようなものがあります。
| タイプ | 説明 | 手順 | 期待される結果 | ステータス |
| 機能テスト | 領域には20文字まで入力できる | 20文字まで入力する | リクエストの20文字すべてが適切であること | 成功または失敗 |
| セキュリティ | パスワード ルールが機能していることを検証 | ルールに沿った新規パスワードを作成する | ユーザーのパスワードがルールに従っていれば受け入れられること | 成功または失敗 |
| ユーザビリティ | すべてのリンクが適切に動作していることを確認 | ユーザーにページのさまざまなリンクをクリックさせる | ページ上の URL に従ってリンクがユーザーを別のページに移動させること | 成功または失敗 |
テストケースは任意のソフトウェアの任意の数の機能に適用できます。一般的なテストケースのサンプルには以下のようなものがあります。
- API テスト
- UI テスト
- 負荷テストおよびパフォーマンステスト
- SQL クエリー
- Web アプリケーション
- 単体テスト
一般的なテストケースの例
テストケースはさまざまなソフトウェアシナリオに利用できます。銀行業務から個人利用のソフトウェアまで、あらゆるものにテストケースを適用する必要があります。たとえば、目的が機密データの暗号化であれば、ソフトウェアは意図の通りに動作する機能を必要とします。
しかし、機能テストはテストケース作成の1つの側面でしかありません。ソフトウェアテストはパフォーマンスから互換性やセキュリティまで、あらゆる側面を確実に検証する必要があります。これがパーソナル暗号化ソフトウェアを徹底的にテストする必要がある — 特にWeb APIなどが関わる場合には — 理由です。
ソフトウェアテストケースの書き方
ソフトウェア分野で最も理想的なテストケース作成方法を説明。サンプルのリストおよびリソースや事例への内部リンクも
テストケースの書き方は、テストケースが何をテストまたは測定するかによって異なります。また、開発チームとテストチームがテスト資産を共有することでテストを加速できることもあります。しかし、すべては効果的かつ効率的にテストケースを作成する方法を知ることから始まります。
テストケースには必ず存在しなければならない不可欠な要素がいくつかあります。すべてのテストケースは8つの基本的なステップに分解できます。
ステップ 1: テストケース ID
テストケースにはそれを表すユニークな IDが必要です。たいていの場合、ID の名前付け規則に従うことで、構成、明確さ、わかりやすさが向上します。
ステップ 2: テストの説明
どのユニット、フィーチャー、あるいは機能がテスト対象か、また何を検証するかを説明します。
ステップ 3: 仮定および事前条件
テストケースを実行する前に満たすべき条件があればここに含めます。たとえば、ログインのために有効なOutlookのアカウントが必要などです。
ステップ 4: テストデータ
これはテストケースの変数と値に関連します。E-mailログインの例では、アカウントのユーザー名とパスワードがテストデータに相当します。
ステップ 5: 実行手順
エンドユーザーの視点から実行される容易に繰り返し可能な手順であるべきです。たとえば、E-mailサーバーへのログインのテストケースであれば、以下のような手順が含まれます。
- E-mailサーバーのWebページを開く
- ユーザー名を入力する
- パスワードを入力する
- [Enter] または [Login] ボタンをクリックする
ステップ 6: 期待される結果
テストケースの手順が実行された後に期待される結果です。正しいログイン情報を入力した場合、期待される結果はログインが成功することです。
ステップ 7: 実際の結果と事後条件
期待される結果と比較して、テストケースのステータスを判断できます。E-mailログインの場合、ユーザーは正常にログインするか失敗するかです。事後条件は、たとえばE-mail受信ボックスへの遷移など、実行した手順の結果として起こることです。
ステップ 8: 成功/失敗
成功/失敗ステータスは、期待される結果と実際の結果を比較して判断します。
結果が同じ=成功
結果が異なる=失敗
単体テストの大幅な工数削減を実現できます。
標準的なテストケースの形式
適切に作成されたテストケースの標準的な形式について詳細に説明。参考となるキーワード、リスト、サンプルも
適切に作成された単体テストの各部分は、それぞれ以下のような重要な側面に対応します。
- テストが実行する機能
- テストで使用されるデータ
- テスト実行の期待される結果
- テストがコードの他の部分とは切り離して実行されたことの確認
適切に作成されたテストの標準的な形式は以下の部分で構成されることを知るのが重要です。
- 意味のあるテストメソッド名
- テストで使用されるコントロールデータまたはモック
- テスト対象メソッドまたはユニット(テストしようとしているコードの部分)
- アサーションの適用
- 分離された単体テストの実行
テストケーステンプレートはあるか
説明したように、テストケースには標準的な形式があります。しかし、テストケーステンプレートはおそらく企業によって、あるいはチームによっても異なるでしょう。テストシナリオおよびそこから発生するテストケースのリストを記載したドキュメントがテストケーステンプレートになるでしょう。
品質の高いテストケースのサンプル
テストケースはテストのタイプや全体的なテストの分野によって変わりますが、品質の高いテストケースを作成できるかは、結局のところ上で挙げたいくつかの確実な項目にかかっています。テストメソッド名にテスト対象メソッドまたはユニットの名前と、期待される結果を入れるのを忘れないでください。
各ユニットを分離してテストするべきであることにも注意します。この場合、「分離」とは、できるだけアプリケーションのテストする部分だけを実行するよう、テストの焦点を絞ることを意味します。
次のサンプルは、銀行業務関連のテストケースです。
このメソッド名から、次のような単体テストであることがわかります。
- isOverdrawn() メソッドをテストする
- コントロールデータとして使用された残高は 500 である
- 期待される結果は true である
意味のあるメソッド名を使用することで、結果をレビューする誰もが、単体テストが何をテストしているのかを理解できます。さらに、テスト対象のデータ、期待される結果、テスト対象についても情報を与えます。
テストが失敗した場合、トラブルシューティングを容易にし、レグレッションが入り込んでいないことを確認するには、期待される結果がわかることが重要です。
テストケースのデータ
使用するデータはテストを実行するのに十分なものでなければなりません。単体テストの場合、アプリケーションの最も基本的なユニットをテストできるだけのシンプルなものにします。データは値をコントロールできる String または Object 変数を作成するだけのシンプルなものかもしれません。あるいは、依存先が使用できない場合や依存先を特定の状態にしたい場合などにモックフレームワークを使用することもできます。
該当する一部分だけを作成するので十分なら、そうします。テストを実行するために、アプリケーションのあらゆる部分を設定する必要はありません。
設定されたデータを使用して単体テストが実行されるため、どのように設定するかが単体テストの動作に影響を与えます。従って、どんなデータを使用してテストするかを判断するにはテスト対象コードをある程度理解する必要があるため、単体テストで最も時間がかかるのがこの部分です。
データを簡潔にするため、テスト対象コードに必要な部分だけを使用するようにします。単体テストフェーズでは、モックが非常に便利です。モックを使用すると、テストがオブジェクトを操作したとき、どのように振る舞うかをコントロールできます。
たとえば、次のデータがあるとします。
テストを分離するため、「実際の Customer クラス」は使用せず、「Customer クラス」のモックを使用します。このテストのために別のオブジェクトを導入したり、設定するのは避けます。別のオブジェクトを導入すると、そのオブジェクトを管理するために別のレイヤーが追加されるが、テスト対象メソッドの結果には影響を与えないからです。
次に作成する変数は「初期残高」です。コードに関する知識から導かれます。次の行では、すぐ前で準備したデータを使用してメソッドをテストするため、モックと初期残高を使用して Account オブジェクトが作成されています。
つまり、このサンプルでは、Customer オブジェクトのデータは問題ではないため、モックを使用してAccount オブジェクトを設定し、テストのためにコントロールできる初期残高を渡しています。
テスト対象メソッドは数値を使用するため、次の行で入力値を定義しています。テスト対象のメソッドで使用する balance を定義しています。その後、メソッドを実行し、メソッドの結果を後で使用するために変数に格納します。
アサーションの適用
テストケースが正常に完了するように(最初から最後まで例外やエラーなしに実行されるように)なったら、単体テストにアサーションを導入します。アサーションがなければ、意図のとおりに動作しているかを確認していないため、単体テストは無意味です。
実行された行のカバレッジを収集すれば、何が実行されたかはわかりますが、それだけでは以下を判断できるだけの詳細情報を提供してくれません。
- コードは期待どおり動作しているか
- コードは品質目標を達成しているか
- 返されたデータは期待されたデータか
アサーションには以下のように単純なものもあります。
単体テストにテスト対象メソッドの結果をチェックするアサーションがあれば、それは意味のある単体テストです。
単体テストの標準的な形式を適用することで、テストのメンテナンス、読解、更新が容易になり、さらにアプリケーションのどの部分をテストすればよいかがすぐにわかります。
品質の高いテストケースのためのベストプラクティス
ベストプラクティスのリストおよび関連資料へのリンクやサンプル画像をご紹介
時間をかけて効果的なテストやテストケースの作成方法を洗練させていくことができます。ベストプラクティスの1つに、わかりやすいタイトルや説明を付け、表現を簡潔かつ明確に保つというものがあります。
事前条件や仮定、期待される結果などを含めるのもよいでしょう。これらの情報はみなテスターにとって意味があります — 特に、テストケースが「成功」か「失敗」かを判断する際には重要です。
テストケースを作成するためのチートシートは次のとおりです。
- シンプルかつ明快に保つ
- テストケースを再利用可能にする
- テストケースのIDをユニークにする
- ピアレビューは重要
- テストケースはエンドユーザーまたは定義済の要件を念頭に置く必要がある
- 期待される結果および仮定を指定する
シンプル、ユニーク、具体的、フィードバックを受け入れる、再利用性に注力する。これが優れたテストケースの在り方です。品質の高いテストケースの作り方をもっと視覚的に学びたい場合、Parasoftのウェビナーをご覧ください。
テストスイートvs.テスト計画
テストケースの別の側面として、テストスイートおよびテスト計画があります。これらには重要な違いがあり、どちらも的確なテストケースの作成に欠かせません。
テストスイートとは
テストスイートは、ソースコードや依存関係の集合、コードに対して実行するひとまとまりのテストと関連付けるのに役立ちます。テストスイートを使用すると、解析や計画のニーズに合わせてテストケースをカテゴライズできます。
つまり、ソフトウェアのコア機能用のテストスイートがあるいっぽうで、スモークテストやセキュリティテストなど、特定のテストタイプ用のテストスイートもあります。テストスイートとは、テストケースを整理する本棚のようなものだと考えてください。
テスト計画とは
いっぽう、テスト計画とは、すべてのテストスイートの上に立つ傘のようなものです。テストケースが本で、テストスイートが本棚なら、テスト計画は本棚を収めた部屋です。
一般的に、テスト計画は、手動テスト、自動テスト、テストをどのように進めるかの全般的な形式という点から組み立てられます。テスト計画は、変更を実装したり新規機能を追加したりする前に、テストスイートおよびテストケースを使用して基礎からソフトウェアをテストします。
ベストなテストケース作成ツール
Parasoft はツールを開発する際に、大まかな方針として「ジョージ・ジェットソン」理論を念頭に置いています(訳注: ジョージ・ジェットソンはTVアニメ『未来家族ジェットソン』の登場人物)。つまり、顧客が「ボタンを押す」だけで、何もかも自動で行われることを目指しています。これは完全に現実的とは言えませんが、テストケースの作成では、このような自動化を重視したツールを使用するのがベストです。
自動化を支援するだけでなく、開発の最初期から役に立ちます。結局、ささいなことや機能が足を引っ張ることはよくあります。ソフトウェアはまず機能しなければならないことは忘れられがちです。そこでJtestのようなJava単体テストツールが役に立ちます。
Parasoft Jtest によって、ビギナーもエキスパートも、よりすばやく単体テストスキルを向上させることができ、また単体テストのエクスペリエンスをより良いものにできます。基礎を確立した後に単体テストを実行し、テストが意味のあるものであるかを確認するようユーザーをガイドします。テストのどこを見ればいいのかがわかれば、テストケースの作成により自信が持てるようになります。
（この記事は、開発元Parasoft社 Blog 「How to Write Test Cases for Software: Examples & Tutorial」2021年5月27日の翻訳記事です。）
Parasoft Jtestについて
