量は異常で、00 年以降のテスト ケースは私よりも優れており、恥ずかしいです...

職場に入ったばかりの新人でも、ある程度働いているおじさんでも、テストケースを書くのに悩んでいるのをよく見かけませんか？例えば：

 テストケースはどのように書くのでしょうか?

テスト初心者でテストに触れ始めたばかり テストケースの書き方に頭が痛い 要件が掴めない ユーザー視点でのテストしかできないが、この状況では、APP を総合的にテストできなくなります...

効率的なソフトウェア テスト ケースを作成するにはどうすればよいですか?

私は半年以上ソフトウェアテストに携わっていますが、基本的にソフトウェア製品についての一般的な理解に頼ってテスト作業を行っており、製品の網羅的かつ詳細なテストを行うことは困難です。テスト計画とテスト ケースの書き方を学びたいのですが、どのような関連書籍を参照できますか?

もちろん、良いテスト ケースを作成するには、十分な需要分析能力 + 理論と経験の恩恵が必要です。ただし、これは、テストの経験と弱い分析能力がなければ、優れたユースケースを作成できないという意味ではありません。テスト現場で 9 年間働いてきたおっさんとして、ユースケースを書く際の経験をいくつか共有したいと思います。次に、次の点から始めます。

1. テストケースの概念、機能、内容などの紹介
2. テストケースはどのように書くのでしょうか?
3. Wechat でモーメントのケース共有を送信

1. テストケースの紹介

テストケースとは、プログラムが顧客の要件を満たしているかどうかをテストするために、テストの入力、実行条件、期待される結果など、プロジェクトの要件に合わせて作成された一連の文書です。

1. なぜテストケースを書くのでしょうか?

1. これはテスト作業の指針であり、ソフトウェア テストの品質の安定性の基本的な保証であり、テスト結果を評価するためのベンチマークです。
2. テスト実行をガイドするユースケースがあると、テスターが疲れたときに牽引力として機能します。
3. ユースケースを作成する過程で、要件を理解することでシステム アーキテクチャまたはビジネスについての理解を深めます。
4. 責任を試すことを避けることができる

2. テストケースのテンプレート: 各社のテンプレートは異なる場合がありますが、一般的に次の内容が含まれます。

• ユースケース番号: 一意性、一般ルール: 製品名_テストフェーズ(開始)_テスト項目_番号
• テスト項目: 機能またはサブ機能モジュールに対応
• テストのタイトル: 現在のテストの意図と目的を 1 文で要約したもの
• 重大度レベル: 高/中/低
• 前提条件: いくつかの前提条件が満たされる必要があります。満たされていない場合、ユースケースは実行できません。
• テスト入力: 処理する必要がある入力情報は、手順と組み合わせると有益なものでなければなりません。
• 作業手順: 各手順を明確に説明し、幹部は手順に従って実行作業を完了できます。
• 期待される結果: 期待される出力と実際の結果を比較して、テストされたオブジェクトが要件を満たしているかどうかを判断します。
• 実際の結果: テスト実行に合格した後の実際の結果。ユースケースを作成するときは空です。

3. テストケースの記述形式

1. 上記のテンプレートは Excel で作成されたこのフォームです。プロジェクトの開発時間が比較的十分な場合に適しています。
2. 緊急のプロジェクト開発時間に適した、Xmind によるテスト ポイントの分類
3. ZenTao などのプロジェクト管理プラットフォームで書かれていますが、一般的には使用されていません

2. テストケースの書き方

一般的なアイデアは 3 つのステップに分かれています。

ステップ1：要件に応じた機能と機能ポイントの整理

ステップ2：テストの理論・手法・経験からテストポイントを整理する

ステップ 3: 隠れた要件をマイニングし、非機能テスト レベルをカバーする

例: WeChat モーメントの動的送信

ステップ1、要件に応じて機能と機能ポイントを整理する

一言で言えば、目に見える機能や機能点を整理することです。通常、企業には要求仕様書やプロトタイプ図面、UI設計図などの製品要件資料が用意されており、要件情報がない場合には、ソフトウェアを利用することで業務に慣れることができます。モーメントの送信と同様に、機能モジュールを整理し、次にサブ機能を分類し、その後機能要件の詳細に進むことができますが、要件の詳細が不明瞭な場合は、製品に時間内に確認する必要があることに注意してください。ざっくり整理すると以下のようになります。

ステップ2：テストの理論・手法・経験からテストポイントを整理する

このステップは非常に重要で、要件に応じて機能ポイントを整理した後、機能ポイントごとに具体的なテスト ポイントを分割して整理する必要がありますが、このとき、ユーザーの正常な動作と異常な動作を含むあらゆる状況を想定する必要があります。シナリオ。

包括的で信頼性の高いテスト ケースをより適切に設計するには、テスト理論とテスト経験の両方が必要です。一般的なテストケースの設計手法には、同値クラス分割、境界値分析、デシジョンテーブル、因果関係図、エラー推定法、シナリオ法、直交実験法、状態遷移法などが含まれます。テストの経験には、複数のプロジェクトのテストの蓄積と沈殿が必要です。新しいテスターの場合、テスト経験がゼロになる傾向がありますが、この時点では、以前の経験から学ぶことができます。そのためのドキュメントを作成したことがありますが、このドキュメントを使用した後、多くの新人テスターは、突然テスト ケースの感覚が得られ、ユース ケースの書き方がわかったと感じます。

この情報は次のように共有されます。

注: この情報は、あらゆるソフトウェア製品の分析に使用できますが、基本的にユーザーの視点で操作されるソフトウェア製品は、その操作機能がデータの追加、削除、変更、確認にすぎないため、必要に応じて分析や分析を行うときに使用できます。ソフトウェア製品のテスト ケースを作成する場合、上で整理したテスト ポイントを使用して、現在の機能が追加、削除、変更、確認する操作に応じてテスト ケースを適用および作成できます。追加、削除、変更、確認の操作に応じて、次のように分類されます。

1. フォームテスト: データページの追加または削除を含む、データ送信に関連するページ
2. 検索テスト: データのクエリが行われたページ
3. 削除テスト: データのために削除されたページ
4. Cookie、セッション等のテスト：ユーザー操作視点、補足テスト
5. データベースのテスト: ページ上のビジネス関連の操作の追加、変更、削除、およびクエリは、データベース データの追加、変更、削除、およびチェックです。

理論的な方法とテスト経験を通じて、WeChat モーメントのテスト ポイントを取得できます。

Excel ドキュメントのユースケースとして記述すると、次のようになります。

728×291 1254×502

ステップ 3: 隠れた要件をマイニングし、非機能テスト レベルをカバーする

WeChat モバイル製品については、上記の機能レベルに加えて、次のような非機能テスト レベルを含むいくつかの機能テストも考慮する必要があります。

3. まとめ

ユースケースを書くのはそれほど簡単ではありませんが、上記を通して、従うべき方法がまだあることがわかりましたか? 書き方が分からない人は、まずは見よう見まねで書いてみましょう 長期にわたるプロジェクト内でのテスト思考のトレーニングや、業務上のバグの経験まとめを経て、いつかは見つかると思いますテスト ケースを書くのはそれほど難しいことではありません。

『テストケーステンプレート事典』

 

 学習リソースの配置について:

 

  これらの資料は、[ソフトウェア テスト] の友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト。お役に立てれば幸いです。エンジニア