現在、会社は WeChat によって開発された Web ページを使用するプロジェクトを行っています。この Web ページには、通常のブラウザで開くことができないという問題があります (WeChat インターフェイスは、基本的なユーザー情報を取得するために使用されます)。開く必要があります。 WeChat ブラウザ経由です。OK、では、この Web ページをどのようにストレス テストしますか?
私が今考えている方法は、パケットをキャプチャして、WeChat ブラウザを模倣して http リクエストを送信できるかどうかを確認することです。 WeChat サーバーがユーザー エージェントを使用して、WeChat ブラウザーによって開かれたかどうかを判断するインターネット。
パケット キャプチャ ツール:fiddler:
スクリーンショット:
ユーザー エージェントを取得したので、このユーザー エージェントをターゲット URL のリクエスト ヘッダー フィールドに直接追加するだけです: https:open.qq.com/xxx.
しかし、最終的には次のことがわかりました。それでも失敗しました。Firefox の開発者ツールを使用して UA を追加しました: 画像:
理由が全く分かりません、私の理解が間違っているのでしょうか、それとも操作手順に問題があるのでしょうか?
ところで、ストレステストの方法について専門家の皆様にアドバイスをお願いしたいのですがお勧めのツールも教えてください。ありがとうございます~!
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
ストレステストは主にビジネスインターフェイスをテストするものであり、テストとは分離でき、ページとの関係も分離できると理解しています。通常のストレス テストでも、インターフェイスから返されるデータが最も中心となります。
WeChat ブラウザーは WeChat UA だけの問題ではなく、ブラウザーの動作環境全体の問題でもあります。
ただし、ストレス テストの場合は、Web ページにログインした後の状況をテストしてください。結局のところ、Web ページの承認に対するプレッシャーは WeChat にあります
私が取り組んでいるケースを共有しましょう。同社には WeChat の赤い封筒アクティビティがあります。基本的に、送信されるたびに何万人ものユーザーがこの問題を解決するのに役立ちました。
ストレス テストを行っていたとき、WeChat ログインをシミュレートするために、バックエンド ロジックに uid = 乱数などのパラメーターを追加しました。uid が存在する場合、WeChat ログインにはジャンプせず、データベースに移動します。ログインするための対応する偽のユーザーを見つけます。もちろん、検出できない問題もいくつかあります。たとえば、ビジネス システムは WeChat 認証ログイン後にユーザー データを保存する必要があり、これはシミュレーション テストではさらに困難であり、ランダムにしか生成できないものもあります。
この種の Web サイトの特別な点は、WeChat ブラウザーが提供するログイン機能を使用してログインすることです。
シミュレートしてログインできれば、他のテストも通常のテストと変わりません。