ストレス テストは多くのプロジェクトで使用されており、テスト パートナーが備えなければならない基本的なスキルです。最近、私は小さなゲームのストレス テストの仕事を引き継ぎました。一連のストレス テストを終えた後、非常にやりがいがありました。すぐに記録しました。みんなでシェアして、みんなで落とし穴を避けられることを願っています。
1. ストレステストのタイミング
ストレス テストのタイミングは非常に重要です。タイミングが間違っていると、役に立たない可能性があります。一般的なストレス テストの 5 つのシナリオを次に示します。
1. イベントがライブになる前のストレステスト
イベント型プロジェクトの場合、イベント開催前にシステムの高電圧テストを実施し、イベント中にシステムが正常に動作できるように、推定トラフィックに応じてシステム構成を最適化および調整するのが日常業務です。
今回のミニゲームプロジェクトはアクティビティカテゴリーに属しており、オンライン化前にストレステストが実施されました。
2. プロジェクトが開始され、安定した後、システムを評価します
システム稼働後もユーザー数の増加に伴ってシステムにかかる負荷は増大し、将来的にシステムを安定稼働させるためには、ストレステストによるシステム評価を行って構成を調整したり、システムを調整したりする必要があります。ユーザー数の増加に完全に対応するためにインターフェースを最適化します。
3. プロジェクト開発の後期段階でのシステムの検査
プロジェクトの後半段階では、リーダーやチームの要件により、トラフィックが短期間に急激に増加した場合にシステムが安定して動作できることを確認するために、システムの安定性を検証する必要があります。システム導入の参考になります。
4. オンラインのパフォーマンスの問題
市場を掌握し、時間を節約するために、ストレステストを行わずに基本的な機能を完了してからオンライン化するプロジェクトもありますが、ユーザーが急増してオンラインパフォーマンスに問題が発生した場合、代わりにストレステストを実行することになりますが、この状況は非常に危険です。お勧めしません。
5. パートナー要件
パートナーによっては、性能に関する明確な要件を契約書に記載している場合があり、その場合は圧力テストを実施する必要があります。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
2. 圧力測定プロセス
ストレス テスト用のツールは数多くありますが、その中でも Jmeter が業界で広く使用されています。今日は、Jmeter を例として、ストレス テストの 6 つのステップを共有します。
1. ストレス テスト スクリプトを作成する
1) HTTPリクエストを追加する
リクエストメソッド、パス、リクエストパラメータを入力します。
2) HTTPヘッダーマネージャーを追加する
一部のリクエストは追加する必要がなく、デフォルト値を使用します。一部のリクエストは追加する必要があります。開発クラスメートに確認してください。リクエスト本文が Body Data の場合、ほとんどの場合、リクエスト ヘッダー Content-Type を追加する必要があることに注意してください。 : アプリケーション/json
3) 応答アサーションを追加する
4) アサート期間を追加する
プロジェクトの状況に応じて決定、通常は60秒に設定
5) スループットを制限する必要があるかどうかを評価します (一定スループット タイマーを追加します)。
場合によっては、実際の使用シナリオをシミュレートするために、スレッド グループによって設定された同時実行数が集計レポートのスループット レートと一致していることを確認してください。
6) 結果ツリーを表示する
圧力テストを開始するときは、エラー ログのみをチェックしてエラー情報を確認します。デバッグするときは、すべてのログを確認して、インターフェイス スクリプトが正常に調整できることを確認する必要があります。
7) 集計レポート
2. ストレステストサーバー（テストサーバー/オンラインサーバー）の準備
一部のプロジェクトはテスト サーバーで実行する必要がありますが、その他のプロジェクトはオンライン サーバーで直接実行できます。たとえば、まだ開始されていないイベント プロジェクトをオンラインで直接テストできます。サーバー構成が異なると結果も異なります。
3. 圧力テストを開始します
事前に開発担当者と製品担当者に同時実行性を確認してください。プロジェクトのユーザー数が 500 人など明確な場合は、500 同時実行数または 500 より少し多い同時実行数をそのまま使用します。明確な同時実行数がないプロジェクトの場合は、同時実行数を使用します。現在のプロジェクトの状況に応じて実装できます。
圧力テスト中は、サーバーの Nginx ログだけでなく、CPU、メモリ、ディスク、ネットワークなどのサーバー リソースの消費量を観察することに注意してください。
サーバーへの負荷を観察します。テスト環境の場合は、サーバーに nmon ツールをインストールして、サーバーのリソース消費をリアルタイムで表示できます。オンライン環境の場合は、通常、サーバーを直接リモートにリモートすることはできません。今回のように運用保守のクラスメートにリンクしてもらうことができます 運用保守の学生が直接ナイチンゲール(Nightingale)のリンクアドレスを教えてくれて、ログインしてサーバーのリソース消費量を直接確認することができます。
サーバーの Nginx を確認します。主に、エラー メッセージがあるかどうか、およびリクエストがテスト サーバーにヒットしたかどうかを確認します。
4. 結果を記録する
これには主に、サーバー構成、圧力テストシナリオ、Jmeter 集計レポート、インターフェースエラーレポート、サーバーリソース監視などが含まれます。
1) サーバー構成
テスト環境のマシン構成: 6 コアと 6G メモリを備えた単一マシン
オンライン環境のマシン構成: それぞれ 6 コアと 6G メモリで構成された 2 台の Web アプリケーション サーバー、1 台のデータベース サーバーの負荷分散
2) 圧力試験シナリオ
赤いパケットを開く + 赤いパケットのサイズを推測する + 赤いパケットのステータスのインターフェイスを取得する (インターフェイスの URI を書き込む)
/v1/API/レッド
3) 集計レポート
1秒から開始する1000スレッド、500サイクル、圧力測定時間：2023/01/17 15:00~15:05 (圧力測定時間はナイチンゲール上の期間中のリソース消費グラフを表示するために記録されます)
主に平均応答時間、平均、エラー%、スループットに焦点を当てます。
4) 試験結果
結果ツリーを表示し、報告されたすべての種類のエラーをリストします。たとえば、接続タイムアウト エラーがあります: 接続タイムアウト
5) リソース監視
CPU 使用率、メモリ使用率、ネットワーク トラフィックを監視する
5. パフォーマンスのバグと検証のバグを改善する
一部のインターフェイスにパフォーマンスのバグがある場合は、そのバグを開発に提出し、開発が修正した後、再度ストレス テストを実行し、回帰テストを実行してバグが修正されたことを確認します。
6. 圧力テストレポートの送信
簡単なテキスト分析とステップ 4 の結果の要約を実行し、ストレス テスト レポートを送信します。
以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
