前に書かれています:テスト ケースは最も基本的なものですが、非常に重要であり、テスト ロードで他のテスト スキルをさらに学習するのに役立つ基本的なスキルです。オンライン ソフトウェア テスト トレーニング クラスに登録した後、クラスに登録した生徒はテスト ケースの書き方がわからず、Zhihu に助けを求めなければなりません。これは本当に心が痛むことです。研修機関の水深は非常に深いことがわかり、研修機関を選択する際には目を離さないようにする必要がありますが、どのように選択すればよいかわかりません。
テスト ケースは、テスターがテストを実行するためのガイドとなる重要なドキュメントであり、テスターの非常に中心的な仕事です。試験研修機関としてお答えさせていただきます。この主題の疑問に徹底的に答えるために、まず記事の構成を発表します。
1. 動機を明確にし、「テストケース」の重要性を理解する
2.「テストケース」形式の8つの要素を説明した明確なスタイル
3. 事前の地雷除去と「テストケース」作成時の注意事項の周知
4. ケースの統合、「テストケース」の書き方を教える
5. 視野を広げ、テストケースに関する学習リソースを共有する
1. 動機を明確にし、「テストケース」の重要性を理解する
ユースケースとは何ですか?
ユースケースは、ユーザーがソフトウェアをどのように使用するかの例です。
では、テストケースとは何でしょうか?
テストケースとは、ソフトウェアを使用するユーザーのケースを科学的に整理して導き出し、テストの実行をガイドする文書を作成することです。
したがって、テスト ケースは、特定のテスト目的のために設計されたテスト実行ドキュメントとして簡単に説明することもできます。
テストケースがいかに重要かは、「ソフトウェアのテストプロセス」をマクロな視点で見ればわかります。
完全なテストプロセス
完全なテスト プロセスには、ユース ケースに関連する 2 つのリンクがあります。したがって、テストケースの作成は非常に重要であり、核となる作業と言えます。これは重要であるため、テスターは日常業務でテスト ケースの作成に多くの時間を費やします。以下の図に示すように:
テストケースはなぜそれほど重要なのでしょうか? 理由は 3 つあります。
理由 1. テスト ケースによりテストの欠落を防ぐことができる
テストケースとは、事前にテスト作業を書いて整理しておくことです。テスト ケースが事前に文書化されていない場合、テスターはテスト シナリオを簡単に見逃してしまいます。
理由 2. テストケースはテストを実装するための標準です
テストケースには何をどのようにテストするのかが明確に書かれており、テスターはテストケースの記述に従ってテストを実行します。
理由 3. テストケースはテスト作業の評価の重要な基礎となる
テストが包括的であるかどうかは、テスト ケースを通じて直感的に反映することもできます。テスターの作業負荷の評価でもあります
2. 明確なスタイル、「テストケース」フォーマットの 8 つの要素を説明
テスト ケースは非常に重要ですが、テスト ケースはどのように作成すればよいでしょうか?
まず、全員が見られるように完全なテスト ケースの形式を示します。ユース ケースの形式からわかるように、テスト ケースには 8 つの要素が含まれています。
1. 集中するためには、まず4つの核となる要素をマスターする
まず、赤いフォントでマークされた 4 つの要素を見てみましょう。これらの 4 つの要素が核となる要素です (次の紹介文は 1 語ずつ読むことをお勧めします)。
1) ユースケースタイトル: 最も重要なテスト目的とテストポイントをユーザーが記述します。形式は「テスト目的 - テストポイント（要約、要約テキストがない場合は空白のままで構いません）」とすることをお勧めします。たとえば、図の「ログイン成功 - 正しいアカウント番号とパスワード」
2) テスト手順: テストの目的を達成するために、どの手順を実行する必要があるかについては、混乱を避けるために番号を使用して説明します。
3) テストデータ: 操作ステップに関係するデータ。さまざまなボタンのクリックなど、操作ステップにデータが必要ない場合は、空にすることができます。
4) 期待される結果: 望ましい結果。結果は私自身の主観的な想像ではなく、目に見える製品要件文書 (プロダクト マネージャー、略して PRD によって提供される) から得られたものです。
テスターは上記の 4 つの要素を習得する必要があります。
2. コア要素について話した後、コア要素以外の要素を理解する
他の 4 つは非コア要素です。見てみましょう。
1) ユースケース番号: ユースケースがソフトウェアで記述されている場合、この項目に注意する必要はありません。ただし、Excel ドキュメントを使用して自分で記述する場合は、「プロジェクト_モジュール_番号」の形式で記述する必要があり、この形式では番号を繰り返すのが困難です。
2) 前提条件: このユースケースを実行するための前提条件。
たとえば、上のスクリーンショットでは、ログインをテストするための前提条件は、最初にログイン ページに入ることであり、qq アカウントが登録されています。
3) モジュール/プロジェクト: 所属するプロジェクトまたはモジュール。スクリーンショットを例に挙げると、現在ログインモジュールをテストしているので、ここにログインを入力するだけです。
実際の業務では、製品要件書（プロダクトマネージャーが用意する、略してPRD）が明確に計画されており、要件に従って記入するだけなので特に考える必要はありません。
4) 優先度: ユースケースの重要性または影響を示します。この要素の方が重要です。原則として、ユーザーにとって重要な機能ほど優先順位が高くなります。
3. 事前の地雷除去とミスが起こりやすい要素の注意事項の周知
テストケースの8大要素の導入が完了したら、その後のプロジェクトの実践をよりスムーズにするために、まず間違いやすい6大要素を導入し、注意事項を書き、事前に地雷を除去しておきましょう。
1.「ユースケースタイトル」記載時の注意点
ユースケースのタイトルは、テーブル名のテストの目的で使用されます。
適格なユースケースのタイトルは、次の 2 つの側面から判断できます。
1) 明確にする: チームの他のメンバーは、後続のテスト手順を見なくても、ユースケースのタイトルを通じて、どのシナリオをテストするのかを明確に理解できます。
2) 面倒になりすぎないでください。明確にするために長いリストを書かないでください。実際、核心点を明確にマークするだけで十分です。
2.「テストステップ」記述時の注意点
適格なテスト ステップを作成するには、以下を把握する必要があります。
-
製品に付属の試作ページおよび試作図面を必ずご参照ください。
-
一部のステップを省略しないでください。プロトタイプ図のステップとリンクは、テスト ステップでもステップごとに明確に記述する必要があります。
-
複数のステップを混同しないでください。各ステップはアクションを表すため、読むときに明確になります。
3.「テストデータ」書き込み時の注意事項
「テストデータ」の書き込みが妥当であるかどうかはどう判断すればよいのでしょうか？
-
コンテンツの前の識別情報 (たとえば、スクリーンショットでは「QQ 番号」と「パスワード」を参照) を明確に記述する必要があります。このようにして、チーム内の他の人がユースケースを実行するときに、データの意味を理解し、明確に実行することもできます。
-
チームの他のメンバーが混乱しないように、テスト ステップに関連付けられたコア データは個別に構築する必要があります。
-
ハードコーディングされたデータにはテスト データを入力する必要はなく、「前提条件」で指定するだけで済みます。たとえば、検証コードが 8888 であれば、テスト データでそれを説明する必要はありません。
4.「期待される結果」を書く際の注意点
限定された「期待される結果」は、次の 2 つの点に注意する必要があります。
-
期待される結果を明確に書き留めます。成功と失敗についてだけ書いてはいけません。そうしないと、実行者はテスト ケースの後に製品要件文書を確認する必要があり、そうでないと何が成功で何が失敗かを判断できなくなります。
-
要件定義書で成功と失敗をどのように定義するかは、そのまま記述でき、省略することはできません。
5.「前提条件」を書く際の注意点
修飾された「前提条件」では、次の 2 つの点に注意することができます。
1) 前提条件の前提は、テスト手順が何であるかです。したがって、最初にテスト手順を記述し、次に前提条件を記述します。
2) 前提条件のほとんどを満たす必要がある条件はデフォルト条件であり、省略できます。たとえば、ネットワークは正常です (弱いネットワーク テストを実行する必要があり、ネットワークが正常でない場合を除く)。
6.「優先」記載時の注意点
優先順位、P0(最上位)だけ書かないでください、無茶です。プロジェクトの要件に応じて決定できます。
普及の優先順位に従って書かれており、一般的にP0～P3と呼ばれていますが、皆さんの理解を助けるために、「モールアプリ」の例を追加して説明します。
P0: 業務プロセスの検証が最も優先され、10 ～ 15% を占めます。
ソフトウェアを使用するユーザーの最も高い商業価値を表すビジネス プロセス。
たとえば、モール アプリでは、ユーザーのログイン -> 商品の検索 -> ショッピング カートの追加 -> 注文 -> 支払い -> 注文の表示、このコアの機能ビジネスライン、P0レベルに属します。
P1: 優先度が高く、20 ～ 30% を占めるコア機能の検証。
たとえば、モール アプリでは、注文の支払いにアカウント残高を使用すること、またはアカウントを登録することはすべて P1 レベルに属します。
P2: 中優先度、一般的な機能を検証し、50% ～ 60% を占めます。
たとえば、モール アプリでユーザーが個人のアバターを png 形式に変更した場合、それは P2 レベルに属します。
P3: 優先度は低く、特別なプリセット条件とデータ設定を確認します。10 ～ 15% を占めます。
たとえば、モール アプリで 3 分間に 10,000 回のランダム操作が行われる場合、P3 レベルに属します。
記入内容はプロジェクトの区分を参照してください。
「テスト ケース」の 8 つの主要な要素の紹介と、エラーが発生しやすい 6 つの主要な要素の注意事項を組み合わせると、要約すると、適格なテスト ケースを作成するための鍵は、次の原則を理解することです。
「あなた自身が実行できるだけでなく、チームの他のメンバーも実行できます。」
4. ケースの統合、「テストケース」の書き方を教える
上記 2 つの部分を詳しく説明した後、テスト ケースを作成するのは簡単になりましたか? 次に事例を検証してみます。
TP Mall - 製品要件ドキュメント (製品マネージャーによって提供され、PRD と呼ばれます)
上記の製品要件書 PRD にあるように、「登録の成功」と「携帯電話番号の存在」の 2 つのテスト ケースを設計する必要がありますが、どのように記述すればよいでしょうか?
「テストケース」の8大要素の紹介と、間違いやすい6大要素の注意点を組み合わせて、次のことを試してみましょう。
ステップ 1: 最初にモジュール + ユースケース番号を書き込みます
「Project_Module_Number」という形式で記述する必要がありますが、この形式では番号を繰り返すのが困難です。
プロジェクトは「TP Mall」、モジュールは「Registration」、シリアル番号は 001,002
したがって、スクリーンショットに示すように、ユースケース番号とモジュールを一緒に実行できます。
ステップ2: ユースケースのタイトル
最も重要なテスト目的とテストポイントをユーザーが記述します。形式は「テスト目的－テストポイント（概要）」です。
1) 明確にする: チームの他のメンバーは、後続のテスト手順を見なくても、ユースケースのタイトルを通じて、どのシナリオをテストするのかを明確に理解できます。2) 面倒になりすぎないでください。明確にするために長いリストを書かないでください。実際、核心点を明確にマークするだけで十分です。
テストシナリオ 1) 目的: 登録が成功する、シナリオ: 携帯電話番号が存在しない、つまり携帯電話番号が登録されていない、
テスト シナリオ 2) 目的: 登録に失敗しました。シナリオは次のとおりです: 携帯電話番号はすでに存在します。つまり、携帯電話番号は登録されています。
目的とテストポイントは「-」で区切られており、同時にわかりやすさ、煩雑ではないという要件も満たさなければならないため、ユースケースのタイトルは次のように書かれています。
ステップ3: 優先順位
優先度: 通常は P0 ～ P3 に名前を付けます。
P0: 最も高い優先度で、ビジネス プロセスを検証し、10 ～ 15% を占めます。ソフトウェアを使用するユーザーの最も高い商業価値を表す
ビジネス プロセス
。たとえば、モール アプリでは、ユーザーのログイン -> 商品の検索 -> ショッピング カートの追加 -> 注文 -> 支払い -> 注文の表示、このコアの機能ビジネスライン、P0レベルに属します。
P1: 優先度が高く、20 ～ 30% を占めるコア機能の検証。たとえば、モール アプリでは、注文の支払いにアカウント残高を使用すること、またはアカウントを登録することはすべて P1 レベルに属します。
P2: 中優先度、一般的な機能を検証し、50% ～ 60% を占めます。たとえば、モール アプリでユーザーが個人のアバターを png 形式に変更した場合、それは P2 レベルに属します。
P3: 優先度は低く、特別なプリセット条件とデータ設定を確認します。10 ～ 15% を占めます。たとえば、モール アプリで 3 分間に 10,000 回のランダム操作が行われる場合、P3 レベルに属します。
携帯電話登録機能はビジネスプロセスの機能には属さないが、コア機能に属する（登録が成功せず、ビジネス機能が実現できない）ため、P1を設定するのが適切である。
携帯電話の登録に失敗したことを通知するのはビジネスプロセスの機能ではなく、比較的一般的な機能であるため、P2 を設定するのが適切です。
よくわからない場合は、プロジェクトの要件に従って決定できます。
ステップ4: テストステップ -> 前提条件 -> テストデータ
「前提条件」の注意点2点：
1) 前提条件の前提は、テスト手順が何であるかです。したがって、最初にテスト手順を記述し、次に前提条件を記述します。
2) 前提条件のほとんどを満たす必要がある条件はデフォルト条件であり、省略できます。ネットワークなどの
「テストステップ」の3つの注意点：
-
製品に付属の試作ページおよび試作図面を必ずご参照ください。
-
一部のステップを省略しないでください。プロトタイプ図のステップとリンクは、テスト ステップでもステップごとに明確に記述する必要があります。
-
複数のステップを混同しないでください。各ステップはアクションを表すため、読むときに明確になります。
「テストデータ」の3つの注意点：
-
コンテンツの前の識別情報 (たとえば、スクリーンショットでは「QQ 番号」と「パスワード」を参照) を明確に記述する必要があります。このようにして、チーム内の他の人がユースケースを実行するときに、データの意味を理解し、明確に実行することもできます。
-
チームの他のメンバーが混乱しないように、テスト ステップに関連付けられたコア データは個別に構築する必要があります。
-
ハードコーディングされたデータにはテスト データを入力する必要はなく、「前提条件」で指定するだけで済みます。たとえば、検証コードが 8888 であれば、テスト データでそれを説明する必要はありません。
したがって、最初にテスト手順を記述し、必ず製品が提供するプロトタイプ ページとプロトタイプ図を参照して、ステップごとに明確に記述します。
プロトタイプ
プロトタイプ図を組み合わせてテスト ステップを作成します。
テスト ステップを組み合わせて前提条件を作成します。
前提条件と組み合わせたテスト ステップを作成します。
同じ 3 つの手順で、登録が失敗した場合の 3 つの要素の入力も取得します。
ステップ5: 期待される結果
-
期待される結果を明確に書き留めます。成功と失敗についてだけ書いてはいけません。
-
要件定義書で成功と失敗をどのように定義するかは、そのまま記述でき、省略することはできません。
要件定義書の成否
フォローしてください。2 つのテスト ポイントのテスト ケースを手書きで書いた後でも、まだ難しいと感じますか?
「難しいことではない」という声をお待ちしています。
特記事項:
この記事ではテストケースの書き方に重点を置いているため、比較的単純なログイン機能をケースとして選択しています。
しかし実際には、ソフトウェアを入手してテスト ケースを作成すると、1) ソフトウェア要件の分析 2) ソフトウェア ルールの整理 3) ソフトウェア テスト ポイントの分解 4) テスト ケースへの変換 の 4 つのリンクがあります。
最後に:熱心なファンに恩返しするために、完全なソフトウェア テスト ビデオ学習チュートリアルを作成しました。必要な場合は、無料で入手できます。【保证100%免费】
ソフトウェアテストの面接ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は次のとおりです。誰もが満足のいく仕事を見つけることができると信じています。
