分析と設計がなければ、テストはその魂を失います。
テスターはユースケースを作成する前に、テスト分析と設計をどのように行うべきですか? 前回「テストの根底にあるロジック」では【入出力テストモデル】と【2W+1Hテスト分析手法】についてお話しましたが、2W1H分析手法は予備的な分析手法であり、その実装方法について説明しました。テストではまだ実装する必要があります。
今回は、テスト分野の専門家であるJames Batch氏がまとめたテスト分析・設計モデルと、HTSMヒューリスティックテスト戦略モデルを紹介します。
HTSM とは何ですか?
HTSM は、テスターがテスト戦略をよりよく考えられるように設計された一連のテスト思考インスピレーション手法であり、テスト分析と設計を行う際の考え方や考慮すべきポイントについてテスターをガイドします。HTSM には、テスト。James Batch 氏は次のように提案しました。これらは自由に使用できます。これはどの種類のソフトウェアにも共通であり、適用する場合は、実際のシーンに応じてモデルの内容を調整し、独自の組織環境に適応させることをお勧めします。
James Batch訳文解释： ヒューリスティック テスト戦略モデルは、 実行するテストを設計および選択するための一連のパターンです。このモデルの直接の目的は、そのプロセス中に何を考えるべきかをテスターに思い出させることです。
以下は HTSM と 2W1H の分析手法を比較したものです 比較することで、HTSM が 2W1H に対応できることがわかります プロジェクト環境を分析することで、なぜこのプロジェクトをテストしたのか、製品要素を分析することでプロジェクトの背景を理解することができます, テスト範囲を決定し、何をテストしたいのかを明確にしてから、テスト技術と品質基準を通じてテスト方法をガイドします。
HTSM と 2W1H の比較:
HTSM モデルの概要:
HTSMモデルでは、プロジェクト環境、製品要素、品質基準、テスト技術の各項目に多くの下位項目が列挙されており、その内、[プロジェクト環境]と[製品要素]は下位項目に従って十分に分析する必要はありません。モデルが提供する項目を参照して、自分にとって有益な情報を選択して分析することができます。
また、私自身の経験に基づいた内容を追加します。[品質基準]と[試験技術]はより参考になります。原文は詳細に翻訳しました。これは単なるモデルであるため、著者がそれぞれを理解することはできません試験方法や試験規格の詳細な説明は、あくまで筆者が経験に基づいてまとめたものであり、より具体的な方法については各自の経験に基づいてまとめることができますが、試験技術や品質基準の各小項目については、以下の項目として利用することができます。テスター テスト設計の参照標準である品質標準は、ISO9126 ソフトウェア品質モデルを参照することもできます。
つまり、モデルは詳細な知識の説明ではなく、テスト分析と設計において誰もがガイドできるアイデアと方法のコレクションです。
ISO9126 ソフトウェア品質モデル
HTSM の 4 つの領域 (プロジェクト環境、製品要素、品質基準、およびテスト手法) について以下で説明します。また、HTSM をこの順序で使用し、2W1H 手法に従って分析し、HTSM が提供するサブ項目とエクスペリエンスを参照して、最終的に完全なテスト計画を作成することもできます。
テストの最初のステップ: [プロジェクト環境]、テストの前に、まずプロジェクトの背景と、なぜこのプロジェクトを行うのかを理解する必要があります。
プロジェクトの背景:なぜこのプロジェクトをやりたいと思ったのですか? プロジェクトの背景にはどのような理由があるのでしょうか？
解決された問題:このプロジェクトはどのような問題を解決しますか?
背景を理解することで、ニーズを分析し、最も本来のニーズと目的を理解するのに役立ちます。最も本来のニーズを理解した後でのみ、PRD の機能設計がユーザーの最も本来のニーズを満たすことができるかどうかを分析できます。ビジネスと要件をよりよく理解できるため、要件文書の問題や欠陥を見つけることができます。
プロジェクト レベル:それは戦略的なプロジェクトですか? それとも技術的なメンテナンスとアップグレードのプロジェクトですか? プロジェクトのレベルを理解することは重要度でもあり、品質要求がどのレベルなのか、ユーザーの品質要求が何なのかなど、投資すべきリソースも決まります。
プロジェクトの予想完了時間:完了時間を理解することで、将来どのようなテスト戦略を採用するか、どのテスト方法を採用する必要があるか、オンライン化後にどの方法を使用できるか、使用できないかなどが決まります。たとえば、時間が非常に限られているため、機能を保証することが最も重要ですが、その他のパフォーマンスは、多数のユーザーが使用するか、少数のシード ユーザーのみが使用するかなど、オンライン プランに応じて決定されます。オンライン後に互換性を実装できるかどうか、または C の互換性を保証する必要があるか、自動テストが不可能な可能性があるか、自動化テクノロジが非常に成熟しており、記録関連ツールと豊富な経験があり、その後、自動記録ツールまたは記録および再生ツールが使用されます。この時点で大きな役割を果たすことができます。
システム利用者の状況:システムの利用者は誰ですか? ユーザーは何人ですか? ユーザーの数に注意を払うには、1 つ目はシステムにパフォーマンス負荷テスト要件があるかどうかを知ること、2 つ目はシステムのユーザー数が何十人、何百人、何千人なのかを知ることです。ユーザーの数が異なると、その値も異なるはずです。
システムの顧客は誰ですか:システムの顧客は誰ですか? 顧客の最も独創的な要求は何ですか?
以下は、HTSM [プロジェクト環境] の具体的な内容であり、一部を私が補足および調整しました。
テストの 2 番目のステップ: [製品要素] はテストを計画しているものです。テスターは、目に見える部分だけでなく、すべての製品要素がカバーされていることを確認する必要があります。
最終的に、製品は顧客に提供されるエクスペリエンスまたはソリューションであり、製品には複数の側面があり、適切にテストするには、カバーする側面が包括的である必要があります。それぞれの寸法は製品の固有の側面を表します。テストが対象範囲の一部のみをカバーしている場合、重大なバグが見逃される危険があります。製品の要素を分析することは、テストの範囲と、どの側面またはコンテンツをテストする必要があるかを分析することです。ほとんどの人は、テスト範囲は要件文書からのものであると判断していますが、実際には、要件文書の外にも注意が必要でテストが必要なことがたくさんあります。以下は HTSM の [製品要素] です。
HTSM モデル [Product Elements] は多くの内容が列挙されており、比較的複雑ですが、これらの内容は参考として使用するものであり、以下の内容に従って完全にテストする必要はありません。
構造構造：製品に含まれるすべてのもの。
この部分は私たちにとって最も無視しやすい部分だと思います。私たちはソフトウェアのテストにほとんどの時間を費やしており、ハードウェア部分は無視しやすいです。さらに、ヘルプ ドキュメント、使用許諾契約書などの非実行可能ファイルも無視しやすいです。これらの多くはビジネスで提供されるものですが、会社、製品、ユーザーに対して責任を負うためには、これらの実行不可能なドキュメントも確認する必要があります。ヘルプ ドキュメントは理解しやすいか、説明はあるかなどです。エラーがあるか、システム機能に矛盾があるかにかかわらず、不足しているものはありません。なぜなら、オンラインにする前にシステムに最も精通しているのは、製品マネージャーや研究開発者ではなく、テスターだからです。
さらに、私の経験をいくつか共有したいと思います。まず、テスト範囲の決定は非常に重要ですが、ほとんどの人はこのステップを無視し、テストを見逃す可能性があります。テストの基礎が PRD であるため、このステップは無視されがちですが、テスト範囲は PRD 内にありますが、実際の状況では、テスト範囲の大部分は PRD 内にあり、一部は設計ドキュメント内またはドキュメント外にあります。 。
0 から始める新規プロジェクトの場合、テスト範囲は次の 2 つの観点から検討できます。
1.製品の観点から見ると、基本的には PRD を分析するだけで十分ですが、もちろん PRD の内容によっては無視されたり省略されたりする可能性があるため、ニーズを分析し、隠れたニーズを掘り起こす必要があります。
2. 技術的な観点から、外部から提供されるインターフェースサービスや内部で非同期に処理されるタスクなど、利用者から見て操作可能な機能以外にも、利用者が直接利用できない機能、または他のシステム技術開発者の利用者が利用する機能があります。システムの背景、スケジュールされたタスク、オンラインになる前に更新される基本データ、事前データなど。
メンテナンス項目を 1.X から 1.(X+1) または 2.0 にアップグレードします。
通常のテスト範囲の評価に加えて、最も重要で難しいのは回帰テスト範囲の評価、つまり元のシステムへの影響範囲の評価です。
回帰テストの範囲の決定は、実際にはコストと品質の間の勝負です。非常に高い品質要件を持つソフトウェアの場合、各テストには完全な回帰が必要になるため、このシナリオでは自動回帰テストが非常に重要です。時間要件は次のとおりです。許容可能または制御可能な非常に緊急の品質リスクの場合、回帰の範囲をこの変更の関連機能に狭めることができます。ただし、ほとんどのシナリオでは、所要時間は比較的厳しいですが、品質に問題が生じることはありません。現時点で範囲をどのように定めるかというと、まず第一に、この修正に関連する機能の復帰が不可欠であり、第二に、システムの最終ラインを維持すること、つまり、システムのどの機能が機能を復帰できないのかを判断する必要がある。回帰に必要な範囲。さらに、code diff の機能を使用して、変更内容と影響を受ける機能を分析できます。
アップグレードプロジェクトでは、機能回帰範囲の評価に加えて、元のデータの互換性検証にも注意を払う必要があり、次のような状況が考えられます。
1) 機能の変更が元の進行中のデータの動作に影響を与えるかどうか。
2) プロセスの変更、プロセス中のデータまたは拒否され再送信されたデータが正常に実行できるかどうか。
3) データ送信オブジェクト (PO、VO、DTO など) が変更された場合、進行中のデータまたは再編集されたデータが正常に動作できるかどうか、最も重要なことはデータの送信または保存を検証することです。
4) 基礎となるデータベース テーブルの変更は、元のデータの表示と操作、新しいフィールドを更新する必要があるかどうか、スワイプ後の機能が正常かどうかに影響します。
テストの 3 番目のステップ: [品質基準]、具体的なテスト戦略を決定し、システムがどのような種類のテストを実行するかを明確にします。
品質基準は、製品定義が満たすべき要件の一部であり、システムが検証に合格したかどうかをテスターが判断するためのルールです。さまざまな種類の基準を考慮することで、テストをより適切に計画し、重要な問題を迅速に見つけることができます。次のタイプはそれぞれ、潜在的なリスク領域とみなされる可能性があります。
能力: システムは正しく機能し、ユーザーのニーズを満たしていますか?
信頼性: どのような状況でも機能しますか?
- ロバスト性（耐障害性）：システムに障害が発生した場合、自動的に復旧できるか、障害があっても動作を継続できるか。
- エラー処理:この製品は不良データが存在する場合でも障害に強く、正常に障害が発生し、簡単に回復します。（障害発生時には、正確な情報を迅速に提供し、ユーザーに対処方法を通知することもできます）
- データの整合性:システム内のデータは保護されており、データの損失や破損は発生しません。
- 安全性:システムに障害が発生しても、多額の損失が発生することはありません。
ユーザビリティ:実際のユーザーにとって製品は使いやすいですか?
- 学習の容易さ:対象ユーザーは製品の操作をすぐに習得できます。
- 操作が簡単：製品は簡単に操作できます。
- アクセシビリティ:この製品は関連するアクセシビリティ標準に準拠しており、O/S アクセシビリティ機能と連携します。
セキュリティ:製品は不正使用や侵入からどの程度保護されていますか?
- 認証:ログインしているユーザーがシステムによって認証されているかどうか
- 認可:ユーザーの権限がさまざまな役割またはレベルに従って制御および認可されているかどうか
- プライバシー:顧客または従業員のデータは暗号化されていますか
スケーラビリティ ( Scalability ):システムの成長 (データ量、トラフィック、複雑さ) に対処するための合理的な計画があるかどうか
互換性 (互換性):外部コンポーネントや構成と互換性があり、正常に動作しますか? 異なるハードウェア プラットフォーム、異なるアプリケーション ソフトウェア間、異なるオペレーティング システム、異なるネットワーク環境で正常に実行できるかどうか。
- アプリケーションの互換性:製品が他のソフトウェア製品と連携して動作するかどうか。
- オペレーティング システムの互換性:製品がさまざまな種類のオペレーティング システムで動作できるかどうか。
- ブラウザの互換性:製品がさまざまなタイプおよびバージョンのブラウザと互換性があるかどうか。
- ハードウェアの互換性:この製品は、特定のハードウェア コンポーネントおよび構成で動作します。
- 下位互換性:製品が以前のバージョンと同時に使用できるかどうか、データや機能に互換性があるかどうか。
パフォーマンス ( Performance ):システムの応答性は十分ですか?
パフォーマンス テストは多くの場合、専用のパフォーマンス テスターによって実行されますが、機能テスターもそれに注意を払う必要があります。一般的な同時ストレス テストに加えて、実際には、システム内の大量のデータに起因するシナリオが増えており、最終的にはクエリが発生します。 、インポート、エクスポート、およびその他の関数の応答は非常に遅くなります。特に同時実行が同時に発生する場合、または複数のタスクが並列化される場合、エクスポート タスクは最終的に数日後に完了する可能性が非常に高くなります。
インストール性:システムが対応するプラットフォームに簡単にインストールできるかどうか。
- システム要件:製品は、必要なコンポーネントの一部が欠落または不足していることを認識しますか?
- 構成:インストールによってシステムのどの部分が影響を受けますか? ファイルやリソースはどこに保存されますか?
- アンインストール:製品をアンインストールするときに、クリーンアップできますか?
- アップグレード/パッチ:新しいモジュールを簡単に追加したり、新しいバージョンをアップグレードしたりできますか? 既存の構成に影響はありますか?
- 管理:インストールは専任の管理者によって処理されますか、それとも特別なスケジュールで行われますか?
メンテナンスの容易さ (開発):システムの開発、テスト、メンテナンスは簡単ですか?
-
サポート性：製品ユーザーへの支援やサポートを低コストで提供できるかどうか
-
テスト容易性:できるだけ簡単な方法で迅速なテストを実行できますか?
-
保守性:製品の構築、修正、強化はどれくらい簡単で、費用はかかりますか?
-
移植性:テクノロジーを他の場所に移植または再利用することはどの程度経済的ですか?
-
ローカライズ可能:製品を他の場所に適応させるとどれくらい経済的ですか?
テストの 4 番目のステップ: [テスト技術]。システムの品質が品質基準と要件を満たしていることを確認するために、テスト方法、テストに使用される手段と方法を決定します。
テスト技術とはテストの戦略分析のことであり、よく使われるテスト技術は以下の9つです。
機能テスト 機能テスト：製品の各機能を検証し、_機能テスト_ユースケースに応じて項目ごとにテストし、製品がユーザーの要求する機能を満たしているかどうかを確認します。
主張のテスト 制約のテスト: あらゆる主張に挑戦してください! ユーザーが閲覧する資料に記載されている機能の正確性と一貫性を保証します。
1) SLA、広告、マニュアル、ヘルプテキスト、操作マニュアルなどの関連参考資料を明確にする (_SLA_ は一般にサービス レベル契約を指します。サービス レベル契約とは、サービスを提供する企業と顧客の間のサービス契約を指します)品質、レベル、パフォーマンスなどに関して両当事者が相互に認めた合意または契約）
2) 上記の情報を参照して、製品の各ステートメントをテストします。
フローテスト フローテスト:特定の順序で実行されるテスト
-
複数の処理ステップで接続されたテストプロセス
-
関連する操作またはプロセスの間にシステムをリセットしないでください。
-
時間や順序を変更して同時実行する
ドメインテストフィールドテスト:
1) 製品の考えられる入力と出力を分析します。
2) テストに使用するテストデータを決定します。例には、境界値、典型的な値、一般的に使用される値、無効な値、および最も代表的な値が含まれます。
3) テストしたデータの組み合わせを検討します。
シナリオのテスト
1) まず、考えられるすべての実際のシナリオを検討します。
2) 製品にとって意味のある機能や複雑な相互作用シナリオを含むテスト ケースを設計する
3) 優れたシナリオ テストとは、重要な人が自分にとって重要なことをどのように行うかについての説得力のあるストーリーです。
ストレステスト ストレステスト
1) ストレス テストの範囲を決定する: このサブシステムまたは機能は、非常に大量のデータ圧力にさらされる可能性があり、またはリソースの制約により、大量の同時実行によりシステムの過負荷または「損傷」が発生する可能性があります。
2) これらのサブシステムと機能に関連するデータとリソースを特定します。
3) 限られた条件下で困難なデータやリソースを選択または生成する (たとえば、大規模または複雑なデータ構造、高負荷、長時間のテスト実行、多数のテスト ケースの実行、メモリ不足条件など)
自動チェック自動テスト
リスクテスト リスクテスト
1) 製品でどのような問題やリスクが発生する可能性があるかを考えますか?
2) どの問題が発生する可能性が最も高いですか? 発生する可能性が高い問題に焦点を当てる
3) それらが存在する場合、どのように検出して発見しますか?
4) これらの問題をリストし、それらをマイニングするために特別に使用される、対応するテスト ケースを設計します。
5) 関連する専門家に相談したり、設計文書や過去の欠陥レポートをレビューしたり、リスクヒューリスティックを適用したりすることも役立つ場合があります。
ユーザーテストユーザーテスト
1) ユーザーのカテゴリーと役割を特定する
2) 各カテゴリのユーザーが日常的にどのような操作を行うか、一般的にどのように操作するか、どの機能に重点を置くかを決定します。
3) 実際のユーザーデータを取得、または実際のユーザーを紹介し、システムを事前テストに使用する
4) 実際のユーザーの使用シナリオを体系的にシミュレートします (実際のユーザーではありませんが、ユーザーとして自分自身を想像するのは簡単です)
5) 最良のユーザー テストには、単一ユーザーまたはユーザー操作だけでなく、さまざまなユーザー ロール、マルチユーザーの並行操作およびクロス操作が含まれます。
著者: JD Retail 張強
コンテンツソース: JD Cloud 開発者コミュニティ