序文
新人テスターとしてテストを始めたばかりです テストケースの書き方に頭が痛いです 要件が理解できません ユーザー視点でのテストしかできません しかし、このままではアプリをあらゆる面でテストできない、テストケースが必要だけど書き方がわからない、アドバイスをください。そして、テストで見つかったバグを追跡するにはどうすればよいでしょうか? 開発との接触は基本的に対面コミュニケーションであり、適切な基準はありません。
質問しながら学ぶのが最も効率的な学習方法です。
目次
1. テストケースとは何ですか?
2. テスト ケースを作成する理由は何ですか?
3. テストケースの書き方
したがって、テスト ケースの作成方法を紹介する前に、まずソフトウェア システムのログイン機能のテストを見てみましょう (以下のスクリーンショットを参照)。
このログイン ページのテスト ケースを作成する場合、テストではどのような側面を考慮しますか?
一見単純なページ機能のより包括的なテストを完了するには、いくつのテスト ケースを設計できますか? 10項目以内でしょうか？20項目？……
上記の答えを与える前に、まずテスト ケースとは何なのかを理解しましょう。テストケースは何をするのでしょうか? 次に、上記のケースと組み合わせて、テストケースの書き方について説明します。
以下は、この記事のディレクトリのスクリーンショットです。
1. テストケースとは何ですか?
テストケース: 特定の目的 (ソフトウェアに特定の問題が存在することを証明するため) のために設計された、テスト入力、実行条件、および期待される結果で構成される一連の文書
1. テスト ケースは、テストの実行方法をガイドする単なる文書であり、主にテスト対象のソフトウェアが要件を満たしているかどうかを確認する必要性を記録します。
2. テスト ケースの式には 2 つの一般的な形式があり、テンプレートの形式で表示できます。
1) 1 つは Excel から直接書き込む方法です。
——ほとんどのプロジェクトはこの方法で設計および作成する必要があります
2) 1 つは、xmind を通じてテスト ポイントを直接整理することです。
——時間が限られており、プロジェクトに必須の要件がない場合は、テスト ポイントを設計する形式でプロジェクトを作成できます。
——ビジネスプロセステストの場合、テストポイントにまとめてテストすることもできます。
3. 設計・実装担当者：テストエンジニア
4. ユース ケース テンプレート: ユース ケース作成の中心的な内容を説明します。一般に、プロジェクトには独自の設計ユース ケース テンプレートがあります。共通のテスト ケース テンプレートは次のように参照できます。
この業界に不慣れな友人をサポートするために、私が何年にもわたって慎重に編集した何百もの学習資料と説明ビデオもここで共有します。初心者にとって間違いなく役立ちます。それらはすべて以下にリストされています。これ以上ナンセンスです。記事の最後は無料です。Get~
2. テスト ケースを作成する理由は何ですか?
なぜテスト ケースを書くのでしょうか? 実際、製品に問題がある場合、責任者が最初に考えるのは、なぜテストで問題が検出されなかったのかということです。
製品に問題があるのに、なぜテストしなかったのですか?
もちろん、「責任転嫁」を避けることに加えて、テスト ケースを作成することのより重要な機能は次のとおりです。
- 要件を具体的で検証可能な指標に技術的に変換する
- ソフトウェアで起こり得る問題を文書化する
- テスト工程での作業漏れを防ぎ、作業効率を向上
- テスト作業負荷のデモンストレーション
3. テストケースの書き方
テスト ケースを作成することは非常に重要なので、テスト ケースをより適切に作成するにはどうすればよいでしょうか? 個人的には以下の点が満たされる必要があると考えています。 - 従来の考え方、ユーザーの立場に立つ（例：実際のユーザーはこのように使用しますか、異常な事態に遭遇するでしょうか？） - 理論的な方法のテストによるサポート（例： : ニーズに応じて テストケースを設計する際、どのような一般的なテストケース設計手法を使用できますか?) - 製品への精通と経験の蓄積 (例: すでにタイププロジェクトの経験がある、いくつかの点で問題が発生しましたが、どうでしたか) ?) 上記の設計ユース ケース プロセスには前提条件があり、包括的なユース ケースを作成できるように、テストに対する忍耐と忍耐力、さらに毎日の意識的思考トレーニングが必要です。
1. 従来の考え方
冒頭の質問に戻りますが、基本的なログイン ページの場合、従来の考え方に従えば、テスト ポイントは次のスクリーンショットのように考えられますか? 実は、これらのテストポイントはすべてユーザーの視点からのニーズに基づいた詳細設計のプロセスから導き出されたものです。実際のテストで使用されるのはこれらのテスト ポイントだけですか?
2. 学びと蓄積
上記のテストの基本的なポイントはほとんどのテストエンジニアが思いつくと思いますが、実際の業務で直面するプロジェクトは異なりますし、設計するテストケースの粒度も要件が異なります。より深いレベル？このとき、製品への精通とテスト経験のサポートが必要であり、これらの点の設計は継続的な学習、プロジェクトへの精通、テストの蓄積によって得られます。
3. 理論的裏付け
従来の考え方や経験の蓄積には理論的な裏付けも必要です。結局のところ、テスト ケースは人間の思考によって設計されており、このプロセスでの省略は避けられません。それを避けるにはどうすればよいでしょうか? 実際には、テスト理論のサポートが必要ですが、個人的には、デザインのユースケースについて深く考えることは、次の 2 つの側面にほかならないと考えています。
1) テストケースの設計方法
テスト理論の重要な部分は、要件を特定のテスト ポイントに分割し、ユース ケース設計方法に従って特定の設計を実行することです。要件を分割するための鍵は、要件を理解し、既存の記述を使用することです。ユーザーの使用シナリオに従ってドキュメントに追加し、個人的なテスト経験 (ある場合) の蓄積、コンテンツの大部分をユース ケース設計手法を直接使用できるテスト ポイントに分割し、Excel テストに直接変換できるようにするこのプロセスは一般に、特定の機能ポイントを検証するためにユース ケースを直接記述することができるようになるまで、分割および洗練するプロセスとして理解されています。
よく知られている設計ユースケースの手法には次のものがあります。
- 観察
- 同値クラス、境界値
- デシジョンテーブル、因果関係図
- フローチャート、シナリオ手法
- 間違った推測など
2) テスト設計のアイデアの開発
既存のすべての記述情報が要件に従って分割されている場合、テストに問題がないことを保証できますか?
実際にはそうではありません。上記に基づいて包括的なテストを拡張する必要がある場合は、ソフトウェア品質モデルの特性にも依存する必要があります。これらの特性に基づいて、テスト ケース設計者には、より多くの余地が与えられます。考える。この設計はより包括的で信頼性が高くなります。
一般的なソフトウェア品質モデルの特性の説明:
・機能性：機能はあるのか、使いやすいのか。
- パフォーマンス効率: システムのリソース消費と応答時間に対応
- 使いやすさ: 理解しやすく、学びやすく、使いやすい
- 互換性: さまざまなソフトウェアおよびハードウェア プラットフォームと互換性があります。
- 信頼性: 問題が発生する可能性が低く、問題が発生した場合でも簡単に回復できます。
- セキュリティ: ユーザーの安全 (外部の生命のセキュリティ、内部の情報セキュリティなど)
- 可搬性: さまざまな環境条件でも問題なく動作する能力
- メンテナンス性: 後の修理やメンテナンスに便利で迅速ですか?
したがって、上記のログイン機能では、上記の品質モデルのガイダンスに従って、次のテスト ポイントが取得されます。
4.最後に書く
この当時を振り返ってみて、試行されテストされてきた機能であるログインだけで、十数、さらには数十のテスト ケースを設計するのに十分だとまだお考えですか? もちろん、それはそれほど単純ではありません。要件を熟知したことに基づいて分割および洗練する必要があり、従来の考え方、経験の蓄積、理論的裏付けを組み合わせて使用して、最終的にテストによって検証できる結果に変換することができます。 。
最初のステップは、要件を理解し、これに基づいてテスト ポイントを分割および調整することです。より複雑な機能ポイントについては、テスト ケースの設計方法に依存する必要があります。最も一般的なアプリケーションは、ページ レベルのテスト ポイントです。 . ほぼ同値類と境界値です。
ニーズを知るだけでなく、これまでの経験の蓄積も合わせて、品質モデルの特徴からスタートして機能点の設計を総合的に考え、漏れはないか、特別な要件はないかを考える必要があります。プロジェクト。
ユースケースの設計は一朝一夕にできるものではなく、優れたユースケースを作成するには継続的な練習と修正とレビューの繰り返しが必要です。
今日の共有はこれで終わりです。まだ理解できないことがあれば、コメント欄で質問してください。私の記事が役に立った場合は、Sanlian にサポートしてもらうことができます。