テストの仕事を始めたばかりの友人は、私と同じようにたくさんの混乱を抱えているかもしれません。ユースケースをどのように書くか? ポイントはどこですか？プロジェクトが遅すぎてユースケースを作成できない場合はどうすればよいですか? 以下であなたの考えを共有してください。議論を歓迎します。
Q: 技術ドキュメントの入手方法とテスト ケース ツリーの構築方法。
ドキュメントを読んで製品の核心点（核となる需要は何か？競合製品と比べてどこが優位性があるのか？利益点はどこにあるのか？）を明確にします。
テスト計画/テスト概要が必要で、最初に製品のバックボーンを把握し、モジュールまたはインターフェイスごとに区別し、その後、各メインモジュールのテスト項目を完了します。
製品要件・機能のテスト項目を分解して出力する場合、プログラムロジックとビジネスシナリオの両方を考慮する必要があります。
機能的なユースケースとパフォーマンスのユースケース、自動化。区別と管理が簡単です。
プログラム内の共有モジュール (データ共有など) は、ユースケースを作成する際の統一計画のためにマークアウトする必要があります。
プログラム内の多重化モジュールは、統合計画のためにマークアウトされています。(各インターフェースのレポートなど、コードの再利用。その多くは同じコードです)
ビジネスプロセスは、統一された計画のためにマークされています。(製品に重要なビジネスがいくつ含まれているかは、製品の中核となる要件によって決まります)
Q: 良いテストケースとはどのようなものですか?
対象範囲 - すべてのコア要件がカバーされており、基本的に機能ポイントが含まれている必要があり、ビジネスに影響を与えるシナリオを可能な限り考慮する必要があります。(プロジェクトの実際のニーズによっては数値化できません)
実行が簡単 -- 1 つのテスト ポイントと 1 つのユース ケース。ユース ケースの実行手順は明確で、期待される結果も明確です。
可読性 - 標準的な文言、一貫したフォント レイアウト、明瞭かつ正確、他の人が簡単に読んで使用できることを保証します（会社のユースケースをレビューする必要があり、クロステストには他のテストが使用されます）。
再利用性 - 再利用性が高く、再利用可能なモジュールは軽微な変更のみで使用でき、使用率が高く、回帰テスト中に要件が変更されない場合は、ユースケースを軽微な変更で使用できます。
自動化 ---- ユースケースの作成は最初に考慮され、自動テストが必要なときにすぐに変更できます (自動化を減らし、石を感じながら川を渡ります)
Q: 要件/機能の分解とテストケースの作成方法は何ですか?
入力/データ - 等価クラスの分割
入力/データ - 境界値の選択方法
条件と結果 - 原因と結果の図
条件と結果 – デシジョンテーブル法
シーン -------- シーンメソッド
関数はデータに従う - 状態移行方法
豊富なデータ - 直交実験法
最後に: 熱心なファンに恩返しするために、完全なソフトウェア テスト ビデオ学習チュートリアルを作成しました。必要な場合は、無料で入手できます。【保证100%免费】
ソフトウェアテストの面接ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は次のとおりです。誰もが満足のいく仕事を見つけることができると信じています。
全部资料获取：
