Jingdong は仕事をしています | 説明: ブラック ボックス テストの根底にあるロジック

ブラックボックステストとは?

プログラムをブラックボックスと見なし、プログラムの機能が PRD 規定に従って正常に使用されているか、プログラムが入力データを正しく受け取り、プログラムの内部構造を考慮せずに正しい出力を生成できるかをチェックします。

これは、実際にはブラックボックス テストの定義であり、ブラック ボックス テストの根底にあるロジックです。ほとんどの人は定義に注意を払いませんが、定義はしばしば真実を教えてくれます。

職場の多くの人は、1 つのタイプのシステム テストに慣れていて、新しいビジネス タイプに切り替えると、突然開始方法がわかりません。

新しいものに適応する時は常にあるかもしれませんが、実際にはすべて同じです. ブラックボックステストの根底にあるロジックを習得している限り、適応したり調整したりせずにすぐに始めることができます.

ほとんどがブラックボックステストなので、どのようなシステムであっても「PRDの規定に従ってプログラムの機能が正常に使えるか、プログラムが入力データを正しく受け取って正しく生成できるか」をテストプランとしています。出力」 .

私たちのテストは PRD に基づいています. まず第一に, あなたは PRD をよく知っている必要があります. 次に、その入力と出力を分析します. これらはすべてカバーされています. 基本的に 80 点を達成できます, つまり、このプロジェクトに勝つことは問題ありません. . .

最後に、もう一度強調したいのは、私が言ったことを誰もが理解していないのではないかと心配しているためです. 初日のテストを理解すれば、いつブラックボックステストが発生するかがわかります.インプットとアウトプットとは何か。しかし、多くの場合、真実は平凡に隠されています。彼の定義を思い出してください!

プロジェクトに遭遇し、テストの開始方法がわからない場合は、定義を取り出して 3 回注意深く読んでください。そうすれば、必ず答えが見つかります。

強調

実際、純粋なブラックボックスはあまりなく、入力と出力を理解するだけでなく、中間の処理ロジックも明確にする必要があり、テストに役立ちます。

さらに重要なことは、PRD に精通していること、PRD の内容を徹底的に分析すること、段落や単語を手放さないことです.実際、PRD と設計ドキュメントには多くの抜け穴があります。あなたが発見するのを待っています。

ブラックボックステストの根底にあるロジックの詳細な説明

つまり、入力および出力テスト モデルです。ここでの入力は単純なインターフェイス入力ボックスではありませんが、システムの実行をトリガーできるものはすべて入力です。コード構造の階層化に従って、入力は次のように分類することもできます。

1. インターフェース操作の入力

  • フォワード操作

    単一操作

    通常の操作:入力ボックス、ボタン、ラジオチェックボックス、ボタン、ドロップダウンボックスなどの特定の操作異常な操作:入力ボックスの異常な値、長い入力など、ボタンの複数回のクリック、高速および連続のクリック(非常に簡単です。データが繰り返し送信されるか、システムの応答が遅くなるなどの問題が発生し、システムがクラッシュする可能性があります)。

    複雑な操作

    組み合わせ操作: 一般的なシステム機能はさまざまな操作の組み合わせであり、もう 1 つはビジネス シナリオに関連しています。つまり、さまざまなビジネス シナリオを組み合わせて同時に操作します。

    並列操作: 複数の人が同じファンクション ポイントを同時に操作するか、2 人が同時に単価を変更または削除するなど、複数の人が同じデータを操作します。

  • 逆操作

    逆操作

    ロールバック操作: ブラウザーまたは APP を介して実行されるロールバック操作。

    キャンセル操作: 通常の操作が突然キャンセルされます。たとえば、ユーザーが大量のフォームに入力して突然キャンセルした場合、保存またはプロンプトが必要ですか?

    削除操作: システムが提供する機能を介してデータを削除します。

2. サービス層の入力

インターフェイス サービス: 外部に提供されるインターフェイスも、システムにとって非常に一般的な入力であり、このタイプの入力も最も問題が発生しやすいものです。

ファイルのアップロード: 一部のシステム関数は、ftp サーバー上の Excel や xml などのファイルを取得することによってシステムが実行されるため、このときの入力はファイルになります。

MQ メッセージ: JD の最も一般的な入力形式でもあります.MQ にはファイルアドレスなども含まれる場合があります.この種の入力はより柔軟です.

強調: インターフェイスのアップストリーム入力については、フォームに関係なく、アップストリーム データの各フィールドを分析して、さまざまなアップストリーム入力の可能性を理解する必要があります。

一部のフィールドは、このフィールドの意味、可能な列挙値、可能な結果などをビジネスから学習する必要もあります[ソース]。

また、歴史的な理由により、ソースデータには想像を絶するさまざまなデータが含まれている可能性があります。

入力の分析は非常に重要です。この時点で、分析に [equivalent class] メソッドを使用できます。

3. データ層の入力

データの変更: 新しいデータが挿入または削除されたかどうかを監視するバックグラウンド処理タスクが多数あります。

データ フィールドの変更: バックグラウンド処理タスクは、データ ステータスの変更、または結合されたフィールドの変更などを監視します。

キャッシュされたデータの変更: データベースの変更に加えて、キャッシュされたデータの変更もあります。

時間の変化: 入力としてのデータに加えて、時間も時限タスクの入力です。

出力は、可視出力と不可視出力に分けられます。

  • 目に見える出力: これは、私たちの共通のシステム操作のフィードバック、ユーザーが直接見ることができる変更です; 箇条書きボックス、プロンプト、ジャンプ、データの追加、変更、および削除後の変更、操作の変更後の写真、ビデオなど。

  • 目に見えない出力: 目に見えない出力は無視するのが最も簡単で、最も問題があります; [見えない出力] には、データベースの変更、キャッシュの変更、システム ファイルの変更、ダウンストリーム インターフェイスに送信されたデータなどが含まれます。

[目に見える出力] 機能の 90% 以上を検証するのに役立ちますが、インターフェイスを介して表示されるデータは、追加または変更されたデータが、追加が成功したか、正しい変更が行われたかを確認することもできます。

しかし、表示されているのはほんの一部であり、表示されていないフィールドが多数あります。その中には、下流のシステムや他のシステムでのみ使用されるものや、将来の使用のために予約されているものもあります。これらの目に見えない部分は、システムの異常を引き起こすことが多く、システムに隠された最大の穴でもあります。

したがって、テストはユーザーの視点からシステムをテストするだけでなく、設計者の視点からもテストする必要があり、製品全体の視点からも検討する必要があります。

最終学習教材の共有

この情報は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備情報である必要があります. 各モジュールをよりよく整理するために、インターネット上の多くの高品質のブログ投稿やプロジェクトも参照し、すべてを見逃さないようにしています. 知識ポイント、これらの資料は、自己学習のあらゆる瞬間にも同行します。

ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/weixin_54696666/article/details/130160788