ソフトウェア テスト エンジニアとして、履歴書にツール fiddler が含まれている場合、面接中に次のように尋ねられることがあります。「fiddler は仕事でどのような用途に使われますか?」
fiddler は、クライアントとサーバー間のすべての通信データを記録するために使用される、非常に優れたデバッグ プロキシ ツールであることは誰もが知っています。ソフトウェアのテスト作業では、主に次のことを達成するのに役立ちます。
- フロントエンドとバックエンドのバグを特定する
- データの改ざん
- 弱いネットワークのシミュレーションテスト
- フロントエンドのパフォーマンスデータを取得する
1. フロントエンドとフロントエンドのバグを特定する
ページ側でバグを見つけた場合、業務に精通し、十分な経験を積んだテストエンジニアであれば、それがフロントエンドのバグなのかバックエンドのバグなのかを直接判断できますが、経験が浅くても慌てる必要はありません。 fiddler を使用してリクエストとレスポンスのデータをキャプチャし、フロントエンドとバックエンドのバグを分析して特定できます。
Fiddlerの設定方法やデータの取り方については本記事では割愛しますので、Baiduなどでご自身で解決していただけます。
a. リクエストの http ステータス コードが正しいかどうかを確認します。例: キャプチャされたリクエストによって返された HTTP ステータス コードが 404 の場合、フロントエンド JS が間違ったアドレスを送信したか、バックエンド サーバーにそのアドレスに対応するサービスがない可能性があることを意味します。キャプチャされたリクエストによって返されたコード。500 の場合は、バックエンド サーバーに内部エラーがあることを意味します。
b. リクエストの HTTP ステータス コード 200 を確認しますが、インターフェイスでエラーが表示されます。次に、リクエストとレスポンスの情報を分析して、フロントエンドのリクエスト パラメータが間違っているかどうかを確認します。フロントエンドの対応するリクエスト アドレスとパラメータが正しい場合は、次に、バックエンドの問題を確認します。
2. データの改ざん
2.1 ブレークポイントによるリクエストデータの改ざん
テスト中は、テスト用のページからのみリクエストを開始しますが、フロントエンドでの入力制限があるため、テストですべてのシナリオをカバーすることはできません。たとえば、WeChat によって送信される赤い封筒の金額のフロントエンド制限は 0.01 ～ 200 元ですが、パケット キャプチャを通じてテストする場合、200 を超える赤い封筒のリクエストを変更して、サーバー側で処理できるかどうかを確認する必要があります。余分なデータは通常通り削除されます。
たとえば、私たちのプロジェクトの多くには支払い機能が含まれており、商品を購入したとします。注文を送信した後、支払いウィンドウにジャンプする前に、パケット キャプチャを通じて支払い金額と数量の要求情報をキャプチャし、支払いを改ざんすることができます。金額や数量を指定して、高額商品を超低価格で大量に購入します。それは重大なバグです!
上記は、リクエスト データを変更するための fiddler ブレークポイントを通じて変更できます。
- 「設定ルール」→「自動ブレークポイント」→「リクエストの前」
- 次に、インターフェイスで [注文の送信] をクリックすると、リクエストの前に赤い禁止線マークが表示されます。これは、ブレークポイントが設定され、リクエストがインターセプトされたことを示します。
- リクエストをクリックすると、右側の Web フォーム ビューにリクエストによって送信された特定のコンテンツが表示されます。量を変更した後、[完了まで実行] ボタンをクリックします。これでデータの改ざんは完了です。
この方法は、支払いなどの重要なシナリオが関係する場合に、サーバーのセキュリティ検証を完了するために使用できます。一般的に私たちは
価格などの機密データをデータ パッケージに含めないよう開発者に依頼できます。
2.2 ブレークポイントによる応答データの改ざん
システムがサードパーティ インターフェイスを呼び出す場合、サードパーティ インターフェイスの異なる戻り結果に基づいて異なるロジック処理が実行されます。プロバイダーがテストに協力できない場合、またはデータベースから別のデータを取得して表示したい場合フロントエンドでは、fiddler を使用して、インターフェイスから返されたデータを改ざんし、必要なテスト シナリオをシミュレートできます。
- 「設定ルール」→「自動ブレークポイント」→「応答後」
- ページがリクエストを開始すると、対応するリクエスト アイコンに赤い禁止線のマークが表示され、応答プロセスにブレークポイントが設定されていることを示します。
- 応答データを変更し、「完了まで実行」ボタンをクリックします。たとえば、図に示すように、変更された州選択ボックスの州が長すぎます。フロントエンドの表示を確認してください。
上記の方法のほかに、ブレークポイントの設定方法が 2 つあります。
1) コマンドを入力してブレークポイントを作成します
- bpu：bpurlの略。コマンド入力ボックスに「 bpu requested URL 」と入力し、 Enter キーを押すと、URL 条件を満たすリクエストが中断されます。
- bpm: bpmethod と同等。コマンド入力ボックスに「 bpm request method 」と入力し、 Enter キーを押します。リクエスト メソッドに一致するリクエストは中断されます。
- bps：bpstatusの略称。コマンド入力ボックスに「bps 応答ステータス コード 」と入力し、Enter キーを押します。ステータス コードの条件を満たすリクエストは中断されます。
- bpafter: 割り込み変更応答データ。コマンド入力ボックスに「bpafter url」と入力してEnterキーを押すと、条件を満たす URL が中断されます。
2) 左下隅の小さな領域をクリックしてブレークポイントを設定します。1 回クリックしてリクエストのブレークポイントを設定し、2 回クリックしてレスポンスのブレークポイントを設定します。
2.3 AutoResponder による応答の変更
これは、ブレークポイントの外側で応答データを変更するもう 1 つの方法です。ローカル ファイルで必要な戻り結果を構成し、特定のインターフェイスを要求するときに独自に構成されたリソースを返します。たとえば、次の Web ページで要求されたロゴ画像では、改ざんによって返されたロゴ ファイルはローカルで指定されたファイルです。
次のように進めます。
再度ページをリクエストすると、指定したファイルにロゴが表示されます。
3. 弱いネットワークのシミュレーションテスト
- 「ルール」→「Fiddler でルールをカスタマイズ」で CustomRules.js ドキュメントを開き、キーワード m_SimulateModem を検索して、次のドキュメントの場所を見つけます。
- oSession[“request-trickle-lay”] = “300”; コメントを参照: 1KB をアップロードするのに 300 ミリ秒かかります; 変換されたアップロード速度: 1Kb/0.3s = 3.3(KB/s)。oSession["response-trickle-lay"] も同じです。
- 2G ネットワークなどの弱いネットワーク シナリオでは、2G アップリンク/ダウンリンク レートは約 2.7 kbps および 9.6 kbps です。1 KB のデータごとに、アップロードには約 2962 ミリ秒、ダウンロードには約 833 ミリ秒かかります。次に、2G の弱いネットワーク状況をシミュレートするために、次のように設定して保存します。
- [ルール] -> [パフォーマンス] -> [モデム速度のシミュレート] をクリックして、弱いネットワーク シミュレーションを有効にします。弱いネットワーク設定の前後の統計を比較すると、弱いネットワーク設定の後では、Web サイトへのアクセスが大幅に遅くなっていることがわかります。
もう 1 つ: 弱いネットワーク設定をキャンセルしたい場合は、[ルール] -> [パフォーマンス] を選択し、[モデム速度のシミュレート] をクリックしてチェックを外します。
4. フロントエンドのパフォーマンスデータを取得する
- 最初のリクエストと最後のリクエストをバッチで選択し、「統計」タブを使用してページ全体のロードに費やされた全体時間を取得します。円グラフにより、どのリクエストに最も時間がかかっているかが明確になります。
- タイムラインを通じてリソースの読み込みシーケンス図を分析すると、ページ上の各リソースの読み込みプロセスに必要な時間と順序を確認でき、読み込みプロセス中に時間がかかるファイル リソースを特定するのに役立ちます。
上記は、長時間かかるリクエストとファイル リソースを理解するのに役立ちます。長すぎる場合は、ターゲットのパフォーマンスを最適化するためにフロントエンド開発に送信できます。
さて、これが要約です。役立つ場合は保存しておいてください。そうすれば、次のインタビューが怖くなくなります。