テストケースの設計ガイドライン

著者: JD Logistics 王 Yukun

ソフトウェアテストの設計は、テストプロセスにおける重要なテスト活動です. テストケースを設計する方法は、テストの効率と品質を向上させることができます. 以下の側面から簡単に説明します.

1 テストケース設計の原則

テストケース設計の基本原則には、有効性、明確性、再利用性、保守性、整合性、互換性、操作の容易さ、管理性、および評価性が含まれます。

有効性: テストケースの手順は明確に記述されている必要があり、あいまいな言葉や繰り返しの言葉は使用できません. テストケースは特定の順序で記述されている必要があるため、実行効率が比較的高くなります.
明確性: 明確な入力データと期待される出力を含め、ユースケースの操作手順を明確に記述する必要があります. 検証ポイントは明確かつ明確である必要があり, キーポイントを強調することができます. 手続き型のユースケースの場合, 使用を整理することをお勧めします.最初の検証ポイントから最後の検証ポイントまで、構成プロセスの最初から最後まで、テストの実行に便利です。テストケースに前提条件が含まれる場合、エントリポイントなどを含めて、前提条件を明確に記述する必要があります。
再利用性: 再利用可能であり、同様の機能を持つテストケースを抽象化して分類しようとします。
保守性: ビジネス要件によりテストケースが変更された場合、テストケースのリアルタイムパフォーマンスと有効性を確保するために、テストケースを適時に更新および保守する必要があります。段階的なプロセスです。
完全性: 要件を完全に理解できるように、ユースケースが完全であり、すべての要件をカバーしているかどうか。
互換性: テストケースには、新旧バージョン間の互換性、新旧データ間の互換性、ブラウザーの互換性などのテストポイントを含める必要があります。
管理性: テスターのテストの進行状況、ワークロードなどを検出する機能。
評価可能性: テストケースの合格率と欠陥の数は、ソフトウェアの品質を評価する基準です。

2 テストケースのライフサイクル

ソフトウェアテストケースの設計フェーズには、要件分析、テストケース設計、テストケース実装、テストケース実行、テストケース管理が含まれます。

2.1 需要分析

テストケースプロセスの最初のステップは、何をテストするかを決定し、テストポイントを特定して優先順位を付けることです。

2.2 テストケースの設計

テストケースの設計は、分析されたテストポイントをテストする方法を決定します。

テスト設計の主なポイントは、テストの期待される結果を決定することです。期待されるテスト結果を判断するために、テスターはテスト出力に注意を払うだけでなく、テストデータとテスト環境の前後の条件にも注意を払う必要があります。テストケースが期待するテスト結果を持たない場合、テストケースがテスト結果の正誤を判断しても意味がありません。

テストの期待される結果は、作成または出力が必要な結果、更新または変更が必要な結果、または削除が必要な結果など、さまざまです。各テストケースでは、テストの期待される結果を明確に説明する必要があります。このように、テスト担当者は、ソフトウェアシステムのテスト出力を正しく評価するために、テスト対象システムに関する豊富な知識と経験を持っている必要があります。テスト出力の評価が正しいと考えられる場合、テストケースの期待される出力として使用できます。

2.3 テストケースの実現

テストケース実現のプロセスには、テストスクリプト、テスト入力、テストデータ、および期待される結果の準備が含まれます。テストスクリプトとは、標準の構文に従ってデータまたは命令を編成することを指します。テストを実行する前に、まずテストの前提条件を満たしている必要があります。たとえば、テストケースで構成済みのデータを使用する必要がある場合は、このデータを事前に作成する必要があります。

2.4 テストケースの実行

テストケースを実行して、テスト対象のシステムをテストします。手動テストの場合、テストの実行は主にテストケースのステップを参照し、期待される結果と実際の結果を比較し、テスト中に見つかった問題を記録します。

自動化されたテストプロセスでは、実行中にテストツールを使用し、テストケーススクリプトなどを実行し、テスト結果を記録する必要があります。

実際の結果が、テストを実行したときに期待される結果と同じである場合、合格と見なされます。そうでない場合は、ユースケースの実行が失敗したか、問題があります。ユースケースの実行が失敗した場合、それがソフトウェアの問題なのか、ユースケースの予想なのかを判断するには、さらに調査が必要です。結果に問題がある場合、またはデータの問題や環境の問題が原因である場合は、さまざまな側面から分析する必要があります。

2.5 テストケース管理

1) テストケース編成

各プロジェクトには非常に多くのテストケースがあります。テストケースをどのように整理、追跡、維持するかは非常に重要です。テストケースをどのように構成するかは、テストの成功にとって重要な要素であり、テスト効率を向上させるための重要なステップです。

テストケースの編成は、さまざまな方法で編成または分類できます。

ソフトウェア機能モジュールに従って編成する: ソフトウェアシステムは通常、ソフトウェア機能モジュールに従って作業タスクを割り当てます。そのため、ソフトウェア関数モジュールに基づいてテストケースを設計および実行する方法は非常に一般的です。モジュールに従ってテストケースを編成することで、テストケースが各システムモジュールをカバーし、より優れたモジュールテストカバレッジを達成できるようになります。
テストケースの優先度で整理: テストケースに優先順位が付けられます。どのようなソフトウェアでも、徹底的なテストを実装することは現実的ではありません。リソースと時間が限られているため、優先度の高いテストケースを最初に実行する必要があります。

機能モジュールごとに分割するのが最も一般的ですが、機能モジュールごとに分割するなど、組み合わせて使用することもできます。

2) テストケースの追跡

テストケースの追跡は、主にテスト実行過程におけるテストケースの状態に対して行われ、テスト状態の追跡と管理を通じて、テストプロセスとテストの有効性の管理と評価を実現することができます。

テストケース実行の追跡: テスト実行の過程で、テストケースの状態を追跡することで、テストプロセスを効果的に定量化できます。たとえば、一連のテストを実行する過程で、テストされたテストケースの数と、成功したテストケース、失敗したテストケース、テストされていないテストケースの割合などです。これらのデータは、ソフトウェアプロジェクトの品質と実行の進行状況を判断するための情報を提供し、テストの進行状況とステータスに関する明確なデータを提供します。これは、テストの進行状況とテストの焦点の制御に役立ちます。

3) テストケースのメンテナンス

テストケースは静的ではありません. ステージのテストプロセスが終了すると, いくつかのテストケースが不当に書かれていることや, 要件が変更されていることがわかります.テストケースには再利用性があります。

テストケース作成の3つの要素

ユースケース番号: ユースケースの一意の識別
テストモジュール: テストケースが属するモジュール
テストケースのタイトル: テストケースの簡単な説明
前提条件: ユースケース実行の前提条件
テストステップ: ユースケースステップの実行
期待される結果: 得られるべき結果
優先度: ユースケースの重要性

4 機能テストケースの設計方法

4.1 同値類の分割方法

同値類分割方法の定義

代表的なデータのサブセットを入力してください

同等クラス分類

有効な等価クラス: 要件を満たすもの
無効な等価クラス: 要件を満たしていません

適用範囲

単一入力の関数

ステップ

明確なニーズ
有効な等価クラスと無効な等価クラスの判別
テストケースを書く

例

要件: 注文が迅速に配達される場合、宅配業者はそれを変更できる必要があり、パッケージの制限数は 1 で、重量は <0.5 kg でなければなりません。

4.2 境界値分析

境界値の定義

入力等価クラスと出力等価クラスがその境界のわずかに上または下にある特定のケースについて

境界値の範囲

正確に等しい
よりもちょうど大きい
よりわずかに少ない

境界値解析の3つのポイント

上点：境界上の点
開始点: 境界に最も近い点
インライア: 範囲内のポイント

例: 1-100、上の点: 1 100 からの点: 0 99 2 101 内側の点: 50

適用範囲

入力パラメータがあり、入力タイプまたは範囲の長さに境界がある場合 (タイトル要件に長さまたは範囲がある場合に適用)
単一の関数への入力の場合に、等価クラスで使用されます

ステップ

明確なニーズ
有効な等価クラスと無効な等価クラスの判別
話題条件の境界値を明確にする
テストケースを書く

例

4.3 決定表方式

適用条件

意思決定表は、複数の入力と複数の出力があること、および入力と入力の組み合わせ関係、および入力と出力の相互制約と依存関係を示しています。

成分

条件パイル: 質問条件のすべてのテスト入力
アクションパイル: トピック条件のすべての出力
条件項目：テスト入力の値
アクションアイテム: テスト出力の値

ステップ

条件山を明確にする
アクションパイルをクリア
条件付きパイルの完全な組み合わせ
各組み合わせに対応するアクションパイルを明確化
テストケースの設計

例

4.4 因果図法

原因と結果の図の定義

理論的には、デシジョンテーブルに至る中間プロセスです。

適用範囲

因果関係図とは、さまざまな入力の組み合わせをグラフィカルな手法で分析してテストケースを設計する手法で、さまざまなプログラムの入力条件の組み合わせを確認するのに適しています。

因果図の核心

いわゆる原因がインプットであり、いわゆる結果がアウトプットです。
因果図の原因入力条件
因果関係図の結果入力結果

因果関係図の基本表記

関係

恒等性: Ci が 1 の場合、ei も 1 であり、それ以外の場合は ei は 0 です。
否定: ci が 1 の場合、ei は 0、それ以外の場合、ei は 1
または: c1 または c2 または c3 が 1 の場合、ei は 1 であり、それ以外の場合は ei は 0 です。
そして、c1 と c2 が両方とも 1 の場合、ei は 1、それ以外の場合、ei は 0 です。

ステップ

インプットとアウトプットを特定する
因果図を描く
因果関係図を意思決定表に変換する
テストケースの生成

例

要件: あるソフトウェア仕様に、1 列目の文字は A または B でなければならず、2 列目の文字は数字でなければならないという要件が含まれています。この場合、ファイルを変更しますが、1 列目の文字が列が正しくない場合は出力情報 L を指定し、2 列目の文字が数字でない場合は出力情報 M を指定します。

デシジョンテーブルに変換

最後にテストケースに変わりました。

4.5 直交解析法

意味

直交法は直交テスト法とも呼ばれ、直交配列法とも呼ばれ、最小のテストプロセスセットを使用して最大のテストカバレッジ率を取得します (テストケースの数が少なく、検出されるバグの数が多くなります)。直交実験計画法は、多数の実験点から適切かつ代表的な点を選択し、ガロア理論から導出された「直交表」を使用して実験を合理的に配置する科学的な実験計画法です。

直交表の概念: 特別な表、一般的な直交表は Ln (mk) としてマークされます

n は行数、つまりテストする必要がある組み合わせの数を表します
k で表される列の数は、コントロールの数 (因子の数、または因子の数) を示します。
m は、各コントロールに含まれる値の数です (各因子のレベルの数、つまり各因子の状態の数)

例: L9 (34)
には 4 つのコントロールがあり、
各コントロールには 3 つの値があり、
9 はテストされる組み合わせの数であり、
4 つの因子と 3 つの水準と呼ばれる9 つのテストケースがあります。

ステップ

要件に従って因子状態テーブルを作成します - 因子: コントロール名状態: 各コントロールに対応する値
使用する直交表を決定する
直交表の数字を単語に置き換えます
行はテストケースです

例

知らせ

各因子の状態数が一様ではなく、状況が一様になることがほとんど不可能な場合は、因子数、状態数、および試行回数と等しいか、それよりわずかに大きい直交表を選択します。最小です

直交検定テーブルを生成するいくつかの方法
オンライン生成: https://jaccz.github.io/pairwise/tools.html

各コントロールとコントロールの値を入力します

生成されたテーブル

直交検定の表の例は、ユースケースhttp://www.york.ac.uk/depts/maths/tables/orthogonal.htmに適用できます。直交検定の表の例は、ユースケースhttp
に適用できます。://support.sas.com/techsup/technote/ts723_Designs.txt

4.6 シナリオ法-フローチャート法

意味

ユーザーの操作シーンをシミュレートし、主に複数の機能を組み合わせて使用するテストに使用

ユーザーシナリオを使用する理由

ユーザーの視点: ユーザーは通常、単一の機能を使用するのではなく、複数の機能を組み合わせて使用します。
テスターの観点から: 通常、単一の機能ポイントがテストされます. テストの網羅性を確保するために、複数の機能を組み合わせたテストのシナリオが考えられます.

シーン法の適用範囲

複数の機能間の結合テスト
スモークテストでよく使用される

シーンメソッドの 2 つの重要な概念

基本的な流れ: 正しいビジネスプロセスに従うためのパス
代替フロー：エラーが発生した場合の運用フロー

ステップ

プロジェクトの役割を特定する
ロールの共通機能を明確にする
要件に従ってテストシナリオを構築する
シーンはケース

5 セキュリティテストの設計

セキュリティテストは、ソフトウェア製品の開発が基本的に完了した時点で、製品がセキュリティ要件の定義と製品の品質基準を満たしているかどうかを検証するプロセスです。セキュリティテストとは、システムが不正な侵入や侵入を防ぐ能力をチェックすることです。

含まれるテストポイントは次のとおりです。

SQL インジェクション
平文送信
不正アクセス
SMS メール確認
認証の欠如
パスワードセキュリティ
データの堅牢性など