背景
引用: 2008 年の Aberdeen Group の調査レポートによると、Web サイトの場合、ページ読み込みの 1 秒の遅延は PV (ページビュー) の 11% の減少に相当し、これは顧客満足度の 16% の減少に相当します。金銭的な観点から見ると、Web サイトが 1 日に 10 万元稼いでいた場合、ページの読み込み速度が競合他社より 1 秒遅いため、1 年で合計 25 万元の売上が失われる可能性があることを意味します。
コンピュウェアは、150 以上の Web サイトと閲覧された 150 万ページを分析し、ページの応答時間が 2 秒から 10 秒に増加すると、ページ ビューの放棄率が 38% に達することを発見しました。Web サイトのパフォーマンスはビジネス目標と直接的な関係があることがわかり、Web サイトのパフォーマンス テストを実行することが非常に重要です。
パフォーマンス テストを行う学生は、パフォーマンスの実行には多くのシナリオがあることを知っています。各企業は、ここにはリストされていない独自に定義されたシナリオ名詞を持っています。私は通常、パフォーマンスに 4 つのシナリオを使用します (ベースライン シナリオ、キャパシティ シナリオ、安定性シナリオ、例外シナリオ) ) パフォーマンス要件をカバーします。これら 4 つのシナリオがどのように実装されるか、およびパフォーマンス要件をどのようにカバーするかについて説明します。
実際の着陸
4 つのシナリオについて話す前に、パフォーマンス テストの一般的なプロセスについて話しましょう。このプロセスがルールです。孟子の「李楼章と文」では、「李楼志明、大衆の偶然が息子を失い、もしルールに従わないと正方形を作ることはできません。」このプロセスを実行すると、パフォーマンス テストに遭遇したときに混乱することがなくなり、このプロセスに従って作業できるようになります。
それぞれのアクションで何をする必要があるかについては、パフォーマンステストを行う人が一目見てわかるので、ここでは具体的な内容については説明しません。前提条件を完了したら、シーンの設計と実行を実行できます。パフォーマンス分析については、このレッスンでは説明しません。ここでは、Jmeter 圧力ツールが使用されます。TPS は、Jmeter の概要レポート コンポーネントのスループット値を指します。フロントエンド ページの js や css などのページ要素の読み込み時間については、特定のパフォーマンス テストで他のストレス ツールを使用することもできます。ストレス ツールの種類に制限はありません。ここではシーンの使い方を中心に説明します。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
ベースラインシナリオ
ベンチマーク シナリオはストレス テスト用の単一のインターフェイスです。これを誰もが知っている場合、ベンチマーク シナリオはどのように実行すればよいでしょうか?
- 環境整備
インターネット企業はパフォーマンス テストにオンライン ストレス テストを選択するのが一般的ですが、オンライン環境と整合性のあるストレス テスト環境を構築するには、ハードウェア費用、ソフトウェア費用、人件費、保守費用など、比較的高いコストがかかることは誰もが知っています。 , そのため、インターネット企業はオンライン ストレス テストを選択しています。第一線以外のインターネット企業や伝統的な業界では、ストレス テストは一般的にテスト環境で行われます。私が働いたことのある銀行会社や保険会社には、独自のストレス テスト環境があります。それらの環境は比較的独立しており、比較的簡単にストレス テストを行うことができます。ストレステストとチューニングを行うとより便利です。
ストレス テスト環境では、マシン構成がオンライン マシン構成と一致していることが推奨され、アプリケーション コンテナーの構成もオンライン環境と一致している必要があります。この方法によってのみ、ストレス テストの結果は真実になります。端的に言えば、ストレステスト環境はオンライン環境と整合性が取れている必要があり、整合性が取れていない場合は一定の割合でスケールダウンする必要があります。
- データの準備
データの準備については、ストレス テスト環境の寝具データの量を考慮する必要があります。通常、寝具データ ソースは、脱感作後の実際の生存データベース データです。ストレス テストを開始する前に、トラブルシューティングを容易にするためにデータベースをバックアップする必要があります。そして問題の場所。データの量がオンライン データの量と一致しない場合、ストレス テストの結果は信頼できなくなります。数百のデータベースとオンラインの数百万または数千万のデータベースのパフォーマンスを考えることができます。テスト中、その量はストレステスト環境における寝具データの影響を考慮する必要があります。
- パラメータの準備
パフォーマンス ストレス テスト スクリプトを実行する場合、パラメーター化されたデータを準備する必要があります。多くの人は、パフォーマンス テストには数個のデータで十分であり、パフォーマンス テストには大量のデータは必要ないと考えています。これにより、圧力が不均一になります。例えば、数十のデータ データ操作によって数千万、場合によっては数億のビジネスが生み出されるため、ストレステストで得られたシナリオの信頼性は何とも言えません。それでは、妥当なパラメータはいくつあるのでしょうか?
この質問に答えるには、シナリオが異なり、パラメータ化されたデータも異なるため、どのようなシナリオでパラメータ化が使用されるかを決定する必要があります。シナリオを考慮しない場合、100 スレッド、TPS は 800、システムは 1 分間実行されます。 1 時間、データの種類、制限と数量は次のように計算されます。
シナリオを考慮すると、実際のビジネスシナリオに応じてどのようなデータが使用されるかを分析し、パラメータ化されたデータの量を計算します。ここでのデータには、繰り返しデータと非繰り返しデータが含まれます。ここでは統合ログインを使用します。ログインの場合 ビジネスには 2 つのパラメータが必要です、1 つはアカウント番号、もう 1 つはパスワードです (これは確認コードによるログインを考慮していません)。アカウント番号とパスワードはシステムにログインできる必要があります。当然、異なる人は異なるアカウントでログインする必要があります。
➢ シーン 1
スクリプトを作成する際には、スレッドの数と同じ数のユーザーを設定し、各スレッドが同じユーザーを使用してループ内のビジネス操作を実行できるようにしますが、このようなパラメーターの設定は、特定のビジネス シナリオにのみ対応できます。このようなシナリオでは、スレッドの数と同じだけのユーザー データを準備する必要があります。
➢ シナリオ 2
電子商取引システムの場合、アカウントを使用して継続的に商品を購入するという動作は実際のシーンと完全に一致しないため、上記のパラメータに従うことはお勧めできません。このようなシナリオでは、TPS と期間、ユーザー データの計算方法のリファレンスを考慮する必要があります。
➢ シーン 3
スレッドが固定パラメータを再利用できる場合、この場合は実際の業務に応じて判断する必要があります。たとえば、100 個の圧力スレッドの場合、1000 個のデータを用意し、各スレッドに 10 個の異なるデータを使用させることができます。データ。このようなシナリオの数に固定の制限はなく、実際のビジネスに基づいて判断するしかありませんが、このパラメータを設定する前に、パラメータの種類を検討する必要があります。再利用可能なデータの場合は、非常にまれです。実際のパフォーマンス シナリオでは、つまり、1 つまたは複数のテスト データを使用する実際のシナリオは基本的にありません。
- パラメトリックデータ
使用されるパラメーターの数がわかったら、パラメーター化されたデータをどこで取得するかを解決する必要があります。このステップの目的は、パラメーター データが有効であることを確認することです。一般に、パラメーター化されたデータには 2 つのソースがあります。1 つは、バックグラウンド データベース、もう 1 つは圧力ツールによって作成されたデータベース データが存在しないことです。
つまり、パラメーター化されたデータ ソースはデータの有効性を保証する必要があり、これらのデータは次の 2 つの条件を満たす必要があります。
✓ 本番環境のデータ分散を満足する
✓ パフォーマンスシナリオにおけるデータ量要件を満たす
システムの場合、パラメータ化されたデータが合理的かどうかは、ストレス テストの結果が意味があるかどうかに直接影響します。圧力ツールが使用するデータ量が少ない場合、アプリケーション サーバー、キャッシュ サーバー、データベース サーバーなどが処理に少量のキャッシュを使用するため、さまざまなバックエンド サーバーのキャッシュを占有することができなくなります。実際のシーンにあるべきサイズに合わせてあるため、この状態では実際のシーンでの圧力をテストすることはできません。
データベース接続ストレージ デバイスにも影響があります。データ量が少ない場合、対応するストレージ I/O 使用量は低くなります。取得したパラメータが多すぎるとシステムへの負荷が大きくなり、取得したパラメータが少なすぎると実際のシーンのデータ量に適合せず、システムの実際の負荷をテストできなくなります。
パラメータがデータベースから取得された場合、通常はデータベース内のデータ ヒストグラムを確認する必要があります。本番環境から直接取得したデータの場合、データの配布はより正確になります。ただし、テスト環境で作成した一部のデータについては、データ作成後に本番環境とデータの分布が一致しているか確認する必要があります。上記の準備が完了したらベンチマークを開始しますが、ベンチマークを行う際には次の 2 つの点に注意する必要があります。
実装におけるベースライン シナリオはいつ完成しますか? あるいは、どのような状況でベンチマークシナリオが終了する可能性があるのでしょうか? 一般に、ストレス テスト中、インターフェイス呼び出しのシステム リソース使用率が 90% に達するか、システム リソースが完全に使い果たされると、ベンチマーク シナリオを停止できます。リソースが完全に使用されるようにパフォーマンスの問題を調整する必要があることに注意してください。 TPS と応答時間を達成するために、最も妥当な値になります。
容量シナリオ
キャパシティ シナリオは、前のベンチマーク シナリオのすべてのインターフェイスを一定の割合で組み合わせて実行するもので、「最大オンライン キャパシティはどれくらいか?」という質問に答えることが目的です。ここで問題となるのは、界面と界面の比率をどのように決定するかということです。圧力ツールで設定するにはどうすればよいですか? これらの問題が解決できない場合、キャパシティ シナリオを設計することはできません。学生の中には、すべてのインターフェイスを 1 つのシーンに配置し、それらを 1、2、3 の倍数で直接実行すれば十分であると言う人もいるかもしれません。各インターフェイスの比率を考慮する必要はなく、最大値を直接実行するだけですが、実際のシーンとギャップがあり、出てくるシーンは現実離れしているため、どのように設計すればよいでしょうか? もう 1 つの疑問は、キャパシティ シナリオがいつ停止するのかということです。
まず、運用ログを抽出します。どこの企業にもログ システムがあると思います。ログ システムがない場合は、awk コマンドを使用してログを抽出することもできます。また、ELFK を使用してログを抽出することもできます。上記のデータを使用して、ビジネス ロジックを整理できます。
当社は、ラムダプラットフォームを通じてストレステストされたログを取得し、検索条件を通じて一定期間の必要なインターフェースデータを取得できます。
そのようなシステムがない場合は、Nginx ログで関連データを取得でき、Python スクリプトを作成するか、シェル コマンドを使用して必要なデータを取得することで処理できます。データ形式は次のとおりです。
このようにして、各時間帯の各リクエストの数を知ることができ、対応するビジネス率を得ることができます。
生存ログを抽出するELFKであれば、このような環境構成を自分で導入し、関連条件を設定して、上記データの対応関係のデータ型を抽出することができます。
注:特定のリクエストの同時実行性が高い時点が他のリクエストと同じ時点ではない場合、シナリオ内のビジネス モデルが変化するため、複数のシナリオをシミュレートする必要があります。
上記の手順でストレス テスト済みのインターフェイスのリクエストに対する呼び出しの比率を取得できると仮定すると、特定のリクエストの数をリクエストの総数で割って、各インターフェイスの比率を取得できます。ここではテーブルを使用して、説明します (データは仮説であることに注意してください):
実稼働データ比率を取得する手順の概要は次のとおりです。
実際のプロジェクトのビジネス統計プロセスでは、複数のビジネス シナリオが存在する可能性があることに注意してください。このアイデアにより、パフォーマンス シナリオと運用シナリオの間の不一致を解決できます。ビジネス比率が得られたら、ビジネス シナリオを整理し、ビジネス 比率をカバーするシナリオを使用する必要があります。シナリオ 比率はどのように設計されるべきですか? それを考えて、上記のインターフェイス ビジネス比率をカバーできるいくつかのシナリオを設計できます。 . ここでは説明しませんので、ご自身で考えてください。
JMeter では、TPS を制御するためにスループット タイマーが使用されます。
Throughput Controllerコントローラーのシーン比率については、情報を確認して解決することができます。
上記のビジネス比率を基に、キャパシティ シナリオがいつ終了するかを考えることができます。容量シナリオを実行するときは目標を決定する必要があります。そうしないと、終了時点が存在しません。ビジネス比率を割り当てる際、データの合計量を比率として各インターフェイスに割り当て、この合計量が容量テストの目標であることをまだ覚えていますか。
安定性シナリオ
容量シナリオはシステムが耐えられる最大容量を確認するものであるのに対し、安定性シナリオは主に長期サービスを提供する際のシステムのパフォーマンスの安定性を確認し、長期にわたるシステムの累積効果を観察するものであると前述しました。期間運用。したがって、実行時間は安定性シナリオにおいて非常に重要な指標となります。
ここで、安定性実行時間は固定されておらず、ビジネス システムの特定のアプリケーション シナリオに依存することを理解する必要があります。したがって、安定性時間はどのように計算されるべきでしょうか? ここでは、実行時間を計算するための計算方法を提供します。
実稼働システムの統計によれば、前回の運用および保守サイクルではビジネス キャパシティが 6,000 万で、キャパシティ シナリオで得られた最大 TPS が 1,000 であったと仮定します。次に、次の式で計算できます。
安定稼働時間 = 6,000万（累計業務量）÷1,000（TPS）÷3,600（秒）≒16（時間）。
どのようなシステムであっても、安定したシナリオを実行するには累積業務量（一度に行う業務の総量）を決める必要があり、それを実行する際には最大TPSをそのまま使用して実行します。システムが最大 TPS 状態で正常である場合 システムがテストに耐えられるかどうかは、実行することによってのみ検証できます。
異常な光景
異常シナリオの設計では、まずシステムアーキテクチャを分析し、異常シナリオにおける需要点を分析し、それをカバーする対応ケースを設計します。なぜシステムアーキテクチャを分析するのでしょうか? なぜなら、アプリケーションでは機能をテストした後、通常 2 種類の異常問題が発生します。1 つはアーキテクチャ レベルの異常、もう 1 つは容量に起因するパフォーマンスの異常です。アーキテクチャレベルの例外については、アーキテクチャの観点からのみ分析できます。
パフォーマンステクノロジーの観点からは、ホスト障害、ネットワーク障害、アプリケーション障害などの一般的なテスト手法が基本的に使用されますが、現在ではカオスツールが市販されており、カオスツールを使用して異常テストを行うこともできます。全員が操作できるようにする方法:
✓ ホスト: 電源オフ、再起動、シャットダウンなど。
✓ ネットワーク: ifdown コマンドを使用してネットワーク カードをシャットダウンし、ジッター パケット損失、遅延再送信などをシミュレートします。
✓ 適用: キル、停止など。
ここで異常シナリオ設計のロジックについて説明しますと、技術アーキテクチャのすべてのコンポーネントを列挙し、異常を引き起こす可能性のある箇所を分析し、異常箇所の分析に基づいて対応するシナリオを設計するのが第 1 ステップです。多くの場合、感情に基づいているため、異常なシナリオが不完全にカバーされてしまいますが、FMEA では従うべきルールを設定できるため、異常なシナリオを設計するために FMEA 障害モデルを参照することをお勧めします。ここで注意するのは、どのような方法論にも論理があるということです。実践の際にはそれを多用しないでください。ただし、内容の合理性に注意してください。
これは設計上のアイデアを提供するためのものであり、着陸の際には、会社や業務に合わないものを使用しても構いません。ご自身のシステムに適合する一連の異常シーン モデルを設計していただければ幸いです。
以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクは、何百万人ものユーザーによって最大化されました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
