テスト ケースはテスターにとって最も基本的なスキルですが、非常に重要です。テスト ケースは、テスト ロードで他のテスト スキルをさらに学習するのに役立つ基本的なスキルです。
テスト ケースの作成方法には、完全に 2 つの部分が含まれている必要があります。
内容 1: テスト ケースの作成 (8 つの要素に従って)、
内容 2: テスト ケース (テスト ポイント) の分析 (テスト ケースをより包括的にし、テスト シナリオの欠落を少なくするように努めます)。
したがって、この記事ではテスト ケースの作成を省略することについて説明し、主な目的は「テスト ケース分析の実施方法」を説明することです。
学生にこの記事の全体的な状況を理解してもらうために、まず記事の構成を次のように紹介します。
1. ソフトウェア入手後のテストケース分析方法;
2. Douyinケース_ビジネスシナリオを通じたテストケース分析方法;
3. Douyinケース_単一機能モジュールのテストケースを徹底的に分析する方法;
4. まとめ+テストケースシリーズ学習 情報共有
じゃあ始めよう。
1. ソフトウェアを入手した後、テスト ケースをどのように分析しますか?
答えを直接教えてください。つまり、テストケースを「グローバル -> ローカル」で分析する必要があります。
ソフトウェアを入手するのは、迷路の入り口まで歩くようなものです。迷路から抜け出して迷路ゲームをクリアするためには、まず迷路全体を分析するのではなく、迷路の一部に直接入って理解を深めなければ、最適なゲーム経路を見つけることは困難になります。したがって、迷路ゲームをプレイするには、グローバルからローカルに移動する必要があります。
下の写真のTPモール（Webモールは本質的にはソフトウェアです）のようなプロジェクトではメニューが多く、パスワード付きの機能項目も多いのですが、ソフトウェアの品質を確保するためのテストはどのように始めればよいのでしょうか？そうすると、先ほどの迷路と同じで、まず全体からソフトウェアをしっかり理解してから、局所的に深く入っていく必要があります。つまり、グローバルからローカルへ。
TPモールの背景
ソフトウェアの場合、グローバルとはビジネス プロセスを指し、ローカルとは機能モジュールを指します。
ユーザーがソフトウェアを使用する際の最大の商業的価値を表すビジネス プロセス (詳細は後述)
ソフトウェアの全体的な状況（ビジネスプロセス）をどのように理解するかというと、このとき重要な中核となる参考資料、つまりプロダクトマネージャーが作成する製品要件文書（PRD）を使用する必要があります。
PRD ドキュメントの役割は次のとおりです。
1) ソフトウェア要件を計画、定義、記述、表示するためのツール
2) 設計/開発/テスト プロセスの指針となる原則
制作・研究チーム協力フォーム
2. ビジネスシナリオを通じたテストケースの分析方法
前節でも述べたように、テストケース分析には「グローバルからローカルへ」という考え方が必要です。
では全体の状況からどうやってスタートするかというと、「ビジネスシナリオ」からスタートする必要があります。
1. ビジネスシナリオとは
ユーザーがソフトウェアを使用する際の最大の商業的価値を表すビジネス シナリオ
わかりにくい場合は、例を挙げて説明しましょう。
タオバオ モールを例にとると、その商業的価値の実現は、ユーザーをタオバオで商品を購入するように引き付けることです。この目標を達成するために、タオバオは以下の一連の機能を提供する必要があります。
上記のスクリーンショットに示されている一連の機能は、淘宝網ストアのビジネス シナリオです。
したがって、ビジネス シナリオは次のように理解することもできます。
1) ビジネス シナリオ。ユーザーがソフトウェアを使用することで最も高い商業的価値が得られます。
2) ビジネスシナリオは複数の機能の組み合わせです。
ビジネス シナリオを要約すると、特定のソフトウェアの最高の商品価値を実現するためにユーザーが生み出す一連のアクティビティです。
したがって、ソフトウェア製品を入手するときは、まずビジネス シナリオを分析し、ビジネス シナリオをテストし、ソフトウェアのグローバル機能をユーザーが確実に使用できることを優先する必要があります。
ソフトウェアの目標を達成してください。したがって、ビジネス シナリオ テストは総合テストの基礎となります。
では、ビジネスシナリオを通じてテストケースをどのように記述すべきでしょうか? フローチャート方式とスイムレーンダイアグラム方式の2つの方式があります。
以下でそれについて話しましょう。
2. ビジネスシナリオのテストケースを作成_フローチャートメソッド
まず、この方法の 4 つのステップを次のように紹介します。
1. 製品要件ドキュメントに従ってフローチャートを取得 (または描画)
2. フローチャートのパスを分析
3. テスト シナリオとテスト ポイントを作成
4. テスト ケースの設計
手順が完了したら、誰もがよく知っている Douyin プロジェクトによってリリースされたビデオを例として、別のケースを実行してみましょう。
ビジネス シナリオ: ユーザーが Douyin を使用してビデオを投稿する
1) 製品要件ドキュメントに従って、 Douyin プロジェクトのリリースビデオを入手 (または自分で描画)
PRD 文書、このビジネス シナリオのテキスト説明は次のとおりです。
① 入り口: ホームページの + 記号をクリックしてビデオ撮影に入ります。
② ビデオの種類: 日常ビデオは 1 日だけ見ることができます/仕事ビデオは永続的に見ることができます
次のように PRD ドキュメントのフローチャートのスクリーンショットを撮ります。
2) フローチャートのパス分析
①最初から最後までがパス、
②スキルシェア:パス数=判定ポイント数(ダイヤ)+1
したがって、Douyin プロジェクトによってリリースされたビデオ パスの総数 = 判定数 + 1 = 4
3) 4つのパスの「テストシナリオ～テストポイント」を作成
①シナリオ１：ログインせずに動画を投稿する
②シナリオ２：日常動画を投稿する
③シナリオ３：下書き動画を投稿する
④シナリオ４：作品の動画を公開する
4) テストケースの設計
ボタンクリック操作なのでテストデータは空です
3. ビジネスシナリオのテストケースの作成_スイムレーンダイアグラム手法
上記の「ユーザーがDouyinを通じてビデオを公開する」の場合、ビジネスシナリオでは役割は1人だけであるため、フローチャートを使用できます。
しかし、ビジネス シナリオに複数の役割が関与する場合、フローチャートでは表現できず、スイム レーン図が必要になります。
ただし、スイムレーン図のテストパスの解析方法はフローチャートと同様で、以下の4ステップとなります。
1) 製品要件ドキュメントに従ってフローチャートを取得 (または作成)
2) フローチャートのパスを分析
3) テスト シナリオとテスト ポイントを作成する
4) テスト ケースの設計
次に、Douyin Mall の返金などのケースを実行してみましょう。
ビジネスシナリオ: ユーザーはDouyin Mallを使用して返金します
1) 製品要件文書に従ってフローチャートを入手 (または作成)
PRD 文書では、ビジネス シナリオのテキスト説明は次のとおりです。
①一般ユーザーが返金申請を開始
②加盟店は監査を実施し、監査に合格した場合は返金され、監査が不合格の場合は返金を拒否され、返金が成功した場合はユーザーアカウントに返金アイテムが提供され、アフターサービスが行われます。
詳細を見ると返金されたことがわかります
③販売者が返金を拒否した後、ユーザーはアフターサービスの結果を確認し、返金プロセスは終了し、アフターサービスの詳細には返金処理が終了したことが表示されます。
④ 加盟店が返金を拒否した後、ユーザーはプラットフォームに異議を申し立てることができ、プラットフォームは審査後、実情に応じて全額返金/一部返金/返金拒否を決定でき、プラットフォームの結果が最終審査結果となります。
PRD ドキュメントのフローチャートのスクリーンショットは次のとおりです。
Douyinモール返金遊泳レーンの地図
2) フローチャートのパス分析
①最初から最後までがパス、
②スキルシェア:パス数=判定ポイント数(ダイヤ)+1
したがって、Douyin Mall返金ビジネスのパスの総数 = 判定数 + 1 = 5
3) 「TikTokモール返金事業」、「テストシナリオ～テストポイント」の5つのパスを書く
① シナリオ 1: 加盟店審査不合格
② シナリオ 2: 加盟店審査合格
③ シナリオ 3: プラットフォーム審査不合格
④ シナリオ 4: プラットフォーム審査後に全額返金
⑤ シナリオ 5: プラットフォーム審査後に一部返金
ここでは詳細には触れませんが、テスト ケース テーブルを直接置きます。
ボタンクリック操作なのでテストデータは空です
概要: グローバルからローカルの観点からテスト ケースを設計します。全体の状況をビジネスシナリオの観点から表現します。フローチャート（スイムレーン図）から分析し、最終的にテストケースに変換してテストを実行します。
全体的な主要業務の導入後、特定の機能モジュールのテスト ケースをどのように設計するか? 以下でそれについて話しましょう。
3. 単機能モジュールのテストケースを詳細に分析する方法
ローカル関数の詳細なテストを実行します。これは一般にモジュール テストとも呼ばれます。
モジュールの機能テストにもテストの考え方があり、それを 3 つのステップに分けて説明します。
1. 製品要件文書 (PRD 文書とも呼ばれます) に従ってモジュールの紹介を取得します。
① 機能の説明
② ページのプロトタイプ
③ 要件の説明
2. PRD 文書に従って、機能要件
と設計アイデアを整理します。
① ビジネス ルール:ユーザーにとって最も価値のあるルールであり、優先度が最も高いルールです。 最上位
② 要素ルール：要素の長さ・種類・操作を考慮します。
③ ページレイアウトのデフォルト値：要素の組版＋デフォルト値の表示
④ データロジック：データソース、データ加工、出力（この点はデータベースの知識が必要なので、最初はスキップしてください)
3. テスト ポイント
の設計アイデアのテスト ポイント
① ビジネス ルール: 順方向 (要件に適合) + 逆方向 (要件を満たさない)
② 要素ルール: 順方向 + 逆方向
③ デフォルトのページ レイアウト
4 . テストポイントの改善
① できるだけ多くのユースケースをカバーする フォワードテストポイントをカバーする
② 各リバーステストポイントはユースケースを使用してカバーする
5. テストポイントをテストケースに変換する
上記の考え方が理解できなくても問題ありません。事例を考えてみましょう。そうすれば生徒は認識を得ることができます。
ビジネス シナリオの最初のモジュールであるログイン モジュールを例に挙げてみましょう。
ステップ 1: 製品要件ドキュメント (PRD ドキュメントとも呼ばれます) に従って、「Douyin ログイン モジュール」の導入を取得します。
①機能説明 ②ページプロトタイプ ③要件説明
1) 機能説明
ユーザーログイン方法: 携帯電話番号と認証コード / 携帯電話番号とパスワード / サードパーティログイン
2) ページのプロトタイプ
3) 要件の説明
ステップ 2: PRD ドキュメントに従って機能要件を整理します (整理には xmind を使用します)
① ビジネスルール：ユーザーにとって最も価値のあるルールであり、最優先のルールです。
② 要素ルール：要素の長さ・種類・操作を考慮します。
③ ページレイアウトのデフォルト値：要素組版＋デフォルト値表示
1) ビジネスルールを整理する: このルールはユーザーにとって最大の価値があり、最優先されます。
業務ルール：携帯電話番号が未登録の場合は自動登録・ログイン
2) 要素のルール: 要素の長さ/種類/操作を考慮する
要素ルールは、製品内のすべての要素を検索し、これらの要素の長さ、種類、時間、動作要件を分類することです。
PRD ドキュメントのページ プロトタイプと要件の説明によると、概要は次のとおりです。
3) ページレイアウトデフォルト値：要素レイアウト＋デフォルト値表示
ステップ 3: テスト ポイントを書き込む
① ビジネスルール：順方向（要件を満たす）+逆方向（要件を満たさない）
②要素ルール：順方向+逆方向
③デフォルトのページレイアウト
1) ビジネスルール記述テストのポイント（順方向と逆方向）
2) 要素ルール: 順方向 + 逆方向
「60秒以上経ってクリック可能な状態に戻る」は順方向と逆方向に分類できますが、核心は「60秒以上」という状況にあり、テストポイントとして見逃さないようにしてください。ここでまず逆に戻ります。
プロトコル選択のラジオボタンやログインボタンの操作では、順方向、逆方向の書き込みはできません。
3) ページレイアウトのデフォルト
「ページレイアウトデフォルト値」なので、順送り・逆送りがないので、書く必要がありません。飛び越える。
ステップ 4: テスト ポイントを改善する
① ユースケースはできるだけ多くのフォワードテストポイントをカバーします。
② 各リバーステストポイントはユースケースによってカバーされます。
1) ユースケースは可能な限り多くのフォワードテストポイントをカバーします
ユース ケースは、できる限り多くの肯定的なテスト ポイントをカバーします。つまり、分類されたすべての肯定的なテスト ポイントがユース ケースに書き込まれ、テストが正常に実行できるかどうかがテストされます。
case01: 携帯電話番号が登録されログイン成功
2) 各リバース テスト ポイントはユース ケースでカバーされます。
case02: 携帯電話番号が登録されていないので、自動登録してログイン
case03: 携帯電話番号が 11 桁ではない
case04: 携帯電話番号が数字ではない
case05: 認証コードが 4 桁ではない
case06: 認証コードが数字ではありません
case07: 認証コードは 3 分以上有効です
case08: 検証「60 秒以上後に認証コード ボタンがクリック可能な状態に戻るかどうかを取得する」
3) 「アクションボタン」+「ページレイアウトのデフォルト」を追加
case09: 「プロトコル ラジオ ボタンをクリックして選択状態を切り替える」を確認します
case10: 「携帯電話番号/認証コード/プロトコル ラジオ ボタンのいずれかが欠落しており、グレー表示されクリックできません」を確認します case11: のデフォルト値を確認し
ますページレイアウト
注: 上記のテスト ポイントには問題が見つかります。つまり、テスト ポイントの記述が十分に厳密ではありません。たとえば、携帯電話番号が 11 桁でない場合、携帯電話番号が 11 ではないことを意味します。数字です。テストする必要がありますか? こうやってみると、テストデータは「網羅的ではない」ことになるので、これは厄介です。このとき、夜間に点をテストするには等価クラス分割法を使用する必要があります。
4）「等価クラス分割法」を活用して試験の点数を向上させる
等価クラス分割法：テストデータをある共通の特徴に従って「いくつかの部分集合」に分割し、これらの部分集合を「等価クラス」と呼びます。
アプリケーションシナリオ: テストデータは網羅的ではない
テスト ポイントを改善するには、次の図に示すように、「等価クラス テーブル」を使用する必要があります。
同値クラス表
ps: 上の表のフィールドにある「実効等価クラス」は、要件を満たすデータセットを指します。「無効な同値クラス」とは、「要件を満たさないデータの集合」を指します。
等価リストを使用するには、次の 3 つの手順があります。
step1. 要件から入力条件を見つけます。「
step2. ケースにおける入力条件の同値クラス（同値クラステーブル）を分割する。
step3. テストケースを設計する」
ログインの場合の要素ルールと組み合わせると、次の完成したフォームを取得できます。
したがって、上記の簡単なテスト ポイントは次のように最適化されます。case01: 携帯電話番号が登録され、ログインに成功しました。
case02: 手机号未注册，自动注册并登录case03: 手机号非11位case03-1: 手机号大于11位case03-2: 手机号小于11位case03-3: 手机号为空case03-4: 11位数字非手机号case04: 手机号非数字case05: 验证码非4位case05-1: 验证码大于4位数字case05-2: 验证码小于4位数字case05-3: 验证码为空case05-4: 错误的4位验证码case06: 验证码非数字case07: 验证码有效期大于3分钟case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”case09: 验证“协议单选按钮点击切换选中状态”case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”case11: 验证页面布局默认值
PS: これを見て、まだ疑問を抱いている学生もいると思います。つまり、等価性表に記入されたテストデータです。たとえば、「11 より大きい数字」ですが、なぜ表に 15 桁、13 桁、12 桁ではなく 14 桁があるのでしょうか...?
これには別の質問が含まれます。どうすれば同値クラスはより代表的な値を取ることができるでしょうか?
次に、別の知識ポイントである境界値法を導入する必要があります。
5) 「境界値法」を使用して同値類の値をより代表的にする
境界値法：テストデータを選択する際、間隔がある場合は臨界点の両側のデータを選択します。
使用方法: 境界と完全に等しい、境界よりわずかに大きい、または境界よりわずかに小さい値をテスト データとして選択します。
理由: 境界線上の値はエラーが発生しやすくなります。
したがって、グラフ内のデータについては、以下のスクリーンショットに示すように、境界値の考え方に従って、下限値を最適化しましょう。
テスト ポイントがより詳細になり、値がより代表的なものになりましたが、テスト ポイントに他に問題はありますか?
もつ。
例10：「携帯電話番号/認証コード/プロトコルのラジオボタン、条件が欠けている場合はグレーアウトしてクリックできません。」を確認します。ここでは、1つの条件のみがグレーアウトされていると見なされます。
2つの条件が同時に欠けているテストポイントや3つの条件が同時に欠けているテストポイントも考慮する必要がありますか? したがって、現在のテスト ポイントは単一の入力条件のテスト ポイントにのみ焦点を当てており、複数の入力条件の組み合わせ関係は考慮されていません。
解決策: 「デシジョンテーブル分析手法」を導入する必要があります。
6) 「デシジョンテーブル分析手法」を活用してテストポイントをさらに最適化
判定テーブル：「複数の条件の組み合わせ」で異なる結果を表形式で表現する分析ツールです。
デシジョンテーブル分析
デシジョンテーブルの作成は主に次の 3 つのステップを経ます。
1) アクションを列挙する
2) 条件項目を入力し、条件を組み合わせる
3) 条件項目の組み合わせに従ってアクションを決定する 条件は
n 個あり、各条件項目は 2 つの値を持ちます。条件項目の最大の組み合わせは 2 です。 n 乗
4) 簡略化されたマージ類似性ルール
ログインケースを見てみましょう。
① アクション項目は 2 つあります: ログイン ボタンをクリックできるか、ログイン ボタンがグレーアウトされています
② 条件項目は 3 つあります: 携帯電話番号が空、確認コードが空、プロトコル ラジオ ボタンが空です。
③ 決定された条件項目の最大の組み合わせは、2 の 3 乗 = 8 であり、テーブル用に 8 列を予約する必要があります。
次のようにフォームを取得します。
④ 簡略化されたマージ類似性ルール
アクションがまったく同じ列を 2 つ以上出力する場合、アクションの出力が条件と無関係であれば、次の図に示すようにそれらを結合できます。
すると、上記の判定テーブルは以下のように最適化され、8 つのテスト ポイントから 5 つのテスト ポイントに変更されます。
そして、最終的なテスト ポイントは次のように記述されます。
case01: 手机号已注册，登录成功case02: 手机号未注册，自动注册并登录case03: 手机号非11位case03-1: 手机号大于11位case03-2: 手机号小于11位case03-3: 手机号为空case03-4: 11位数字非手机号case04: 手机号非数字case05: 验证码非4位case05-1: 验证码大于4位数字case05-2: 验证码小于4位数字case05-3: 验证码为空case05-4: 错误的4位验证码case06: 验证码非数字case07: 验证码有效期大于3分钟case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”case09: 验证“协议单选按钮点击切换选中状态”case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”case10-1: 验证“手机号为空+验证码为空，登录按钮置灰不可点击”case10-2: 验证“手机号为空+验证码不为空，登录按钮置灰不可点击”case10-3: 验证“手机号不为空+验证码为空，登录按钮置灰不可点击”case10-4: 验证“手机号不为空+验证码不为空+协议选择按钮为空，登录按钮置灰不可点击”case10-5: 验证“手机号不为空+验证码不为空+协议选择按钮不为空，登录按钮可点击” case11: 验证页面布局默认值
ステップ 5: テスト ポイントをテスト ケースに変換する
次のように、テスト ケースのスクリーンショットを直接取得します。
4. 最終的なまとめ:
製品を入手したら、テスト ケースをどのように作成すればよいでしょうか?
一般的には、1) 要件を分析する、2) ルールを整理する、3) テストポイントを分解する、4) テストケースに変換する、という手順を考える必要があります。
製品自体のニーズに焦点を当て、問題をより包括的に検討する方法はないかも考えなければなりません。
今回紹介した3つの知識ポイント、同値クラス分割法、境界値法、デシジョンテーブル分析法を活用して検討してみてはいかがでしょうか。
最後に:以下の完全なソフトウェア テスト ビデオ チュートリアルが整理されてアップロードされており、必要な友人は自分で入手できます[100% 無料保証]
ソフトウェアテストの面接ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は誰もが満足のいく仕事を見つけることができると信じています。
完全な情報の取得
