開始から中止までのパフォーマンステストについての詳細な話：パフォーマンステストの初見

もともとは7つの記事に分けて書こうと思っていたのですが、その深い気持ちを見たときにページをめくる必要もあると考え、1つの記事を作って書くだけでした。
テキストを書く前に、小さなストーリーを共有します：
人々：
Small Cockワイヤー：テストマネージャー
ギャング：プロダクトマネージャー、
Small Cockワイヤーxxは最近プロジェクトを行っています。プロジェクトはすぐに結びつき、兄は突然Small Cockワイヤーのパフォーマンステストを行うように依頼しました。
ことわざにあるように、プロジェクトを行うには、標準化されたプロセスとプロジェクト計画が必要です。
Xiao Diaosiは目がくらんでいるように見えました。3秒後、Xiao Diaosiは4つの質問を送信しました
〜〜Xiao Diaosi：まず最初に、プロジェクトの最初に、このプロジェクトがパフォーマンステストを必要としないかどうか、そして顧客がパフォーマンスレポートを必要とするかどうかを評価しますか？ 、3番目に、契約はソフトウェアおよびハードウェア機器の情報、期待されるパフォーマンスおよびその他の情報を提供します。4番目に、導入のためにお客様のサイトに行く必要がありますか？
ビッグブラザー：ええと...
Xiao Diaosi：次に、パフォーマンステストを実行して、レポートの完全性を反映するのか、それともチームの闘牛を反映するのか？
ビッグブラザー：パフォーマンステストレポートが欲しいだけです！
リトルディックシルク：...

おい！ため息をついてみましょう〜
プロのパフォーマンステストエンジニアとして、プロジェクトリーダー/顧客に最も合理的で最適なソリューションを提供する必要があるため、話を戻しましょう。彼らが理解していないからといって笑わないでください。
結局のところ、他のすべてのラインは山のようなものです~~~

次に、Xiaoyuをフォローして、パフォーマンスの方法を詳しく学びましょう！
Xiaoyuerを使用すると、開始からあきらめまで、すぐにできます〜〜

1.テストプロセス

魯迅氏の言葉を引用すると、ルールなしにはルールはありません。

もちろん、パフォーマンステストにはプロセス仕様も必要です。これはプロジェクト管理プロセスに沿ったものです。ハンサムかどうかはあなた次第です~~
このプロセス仕様を見てみましょう

上記のフローチャートで、次に各リンクを詳しく紹介します
。①ビジネスラーニング：文書を見たり、実際の運用を通してシステムの機能を理解する。
②要件分析：システムの非機能要件を分析し、パフォーマンステストの範囲を定義し、システムパフォーマンスインジケーターを理解します。
③作業評価：作業負荷内訳、作業負荷評価、計画資源投入（人・日）。
④ テストモデルの設計：パフォーマンステストの範囲を区切った後、ビジネスモデルをテストモデルにマッピングします。
この文章を聞いて混乱していますか？テストモデルとは何ですか？
簡単に言えば、パフォーマンステストケースの設計+パフォーマンステスト計画の
ユースケースはビジネスのみに焦点を当て、モデルは実装方法、操作性、検証可能性などに焦点を当てる必要があり、最後に、さまざまなテスト目的に従ってテストシナリオに組み込む必要があります。 。
⑤ 計画の準備：計画のテスト作業を、明確に文書内などの試験範囲、人材入力、期間、作業内容、リスク評価、リスク対応戦略を、リストアップ。
⑥スクリプト開発：パフォーマンススクリプトの記録または記述、バッフルプログラムの開発とテスト、およびテストプログラムの開発。サードパーティ製のツールがない場合でも、サードパーティ製のツールの後にプログラムを開発してテストする必要があります。
>バッフルプログラム：サードパーティのサポートに代わる独自のプログラムを開発します。
>>たとえば、航空システムとやり取りする必要があるが、航空会社が技術サポートを提供していない場合は、代わりに独自のプログラムを開発する必要があります。
⑦ テスト環境の準備：パフォーマンステスト環境には、サーバーとロードマシンの2つの部分があります。
サーバー：テスト対象システムのオペレーティングプラットフォーム（ソフトウェア、ハードウェア）
ロードマシン：ロードの生成、ロードツールのインストール、およびスクリプトの実行に使用するマシン。
⑧テストデータの準備：データモデルに従って、テストしたシステムのマスターデータとビジネスデータを準備します。
⑨ テストの実行：このステップは成功または失敗の鍵です。人、設計シナリオ、テストの実行が異なるため、結果はかなり異なる可能性があるためです。
⑩ 欠陥管理：パフォーマンステストプロセスで見つかった欠陥 ⑪ パフォーマンス分析：パフォーマンステスト結果によって
明らかになる可能性のある問題を分析して、理由を特定します。
>>パフォーマンス分析の実行方法については、Xiaoyuの「パフォーマンス分析プロセス」を参照してください
。⑫パフォーマンスチューニング：コラボレーションが必要です。パフォーマンステスターと開発リーダーが協力して、パフォーマンスの問題を解決する必要があります
>>パフォーマンスチューニングの実行方法暁さん「を参照してくださいパフォーマンスチューニングを行うにはどのように」
⑬Testのレポート、テスト結果の概要を：。
>>一般的なパフォーマンス指標には、TPS、RT、CPU使用などが
あります。⑭レポートのレビュー：パフォーマンスレポートの内容を確認し、問題を確認して、オンライン/配信のリスクを評価します。

2.成功または失敗の要因

Xiaoyuは、パフォーマンス分析に関する記事で次のように述べています。プロジェクトの各リンクをさまざまな分野と比較すると、パフォーマンステストは、要件、開発、テスト、運用と保守、調整と通信を統合した包括的なものです。
次の点から、パフォーマンステストの主な困難について話しましょう：
①需要分析
②シナリオ設計
③パフォーマンスの診断と調整
④環境の構築とシミュレーション

多くのパフォーマンステスターは、要件分析段階で適切な要件を分析せず、ユーザーの行動を正確に推定していませんでした。現場でユーザーの操作をうまくシミュレートできず、システムの負荷状況を実際にシミュレートできませんでした。
最終結果は、テストまたはUAT環境は非常に良好に稼働しており、オンラインにすると問題が頻繁に発生し、その結果を想像することができます。
同様に：
2008年オリンピック、
11.11 2012、宝物、
11.11 2012、あるドン
、
2014年1月9日12306 、Amazonウェブサイト2014年11月6 日。

素人や一部の大規模なパフォーマンステスターに​​とって、彼らはパフォーマンステストはツールを使用するかスクリプトを記述し、いくつかのサーバーを取得して「実行」してからレポートを発行することだと考えています。
通常、どれだけの同時実行性、どれだけの応答時間が実行できるかに注意してください。
パフォーマンステストが本当にそれほど単純なものである場合、始めてからあきらめるまでの言葉に値しますか~~~
次に、パフォーマンステストの重要なポイントを見てみましょう
。1.システムを評価し、どのニーズ分析で
明らかに顧客が必要とされないのか？重要なのは、
特定の需要データを提供するように運用および保守のリーダーと需要リーダーを導き、必要な情報を得るためにデータの二次分析を行うことです。
初めてのオンラインシステムの場合：ピアデータを使用してユーザーの行動を分析し、ビジネスデータ構造を推定して、必要なパフォーマンス要件を得るための計算を実行するための前提条件にする必要があります。
オンラインシステムの場合：運用・保守担当者を通じてTPSと時間比率分布図、ユーザー数と時間分布図、データベースER関係図、容量データなどを取得し、現在のシステムユーザーの行動やビジネスを直接的かつ正確に取得データの関係性を確認し、必要なパフォーマンス要件を取得します。
2.シナリオ設計とユースケース設計
オンラインシステムの負荷をできるだけ現実的にシミュレートする必要があります。
パフォーマンスの実行に参加する必要がある関数と、参加方法を決定する必要がありますか？これはユースケース設計です。
テストケースを効果的に整理する方法は、シナリオが行う必要があることです。たとえば、ビジネス分布、ビジネス量、ビジネス期間、およびビジネスロールに応じて、ユーザー数、実行時間、および実行比率を包括的に割り当てるなどです。
このシナリオの設計とユースケースの設計には多くの時間がかかります。
3.テストの実行、パスが
システムの弱点の特定、さまざまな監視、さまざまな問題のスクリーニング、システムの安定性の検証などのさまざまな負荷実行テストシナリオをシミュレートするかどうか
4.パフォーマンス診断の最適化
パフォーマンステストのリーダーは、パフォーマンスに対する鋭敏な認識を持ち、問題を（つまり、段階的に）改善し、各開発チームが問題の位置付け、分析、最適化を支援できるようにする必要があります。

3人の大物がパフォーマンスを見る

パフォーマンスが総合的主題であるので、のは、これらの大物を見てみましょう異なる視点からシステムの要件を：
みんなのテスト1.ブラックボックスの視点を：彼らは
気にシングルステップ応答時間とアプリケーションのパフォーマンスこれが良いか悪いかは、アプリケーション時間、つまりサーバー/サーバークラスターがネットワーク経由で送信された後のデータストリームの総往復時間に依存します。
2.開発ボスの観点から
①アーキテクチャの合理性
②データベース設計の合理性
③コード
④システムでのメモリ使用量systemシステムでの
スレッド使用量
systemシステムリソースが悪質で不当な競争であるかどうか
3.運用および保守ボスの視点
①ハードウェアリソース使用率レート
②JVM③DB④ システムは24時間年中
無休の
サービスをサポートしていますか⑤スケーラビリティ
、互換性、最大容量、ボトルネックの可能性4.①サーバーハードウェアパフォーマンスの
観点からのパフォーマンステスト ② 需要または履歴データに基づく
パフォーマンス目標③パフォーマンスパッシングモデルの確立④はいパフォーマンス分析用のコードフレームワークとハードウェアフレームワークを開発⑤開発バージョンとリリースバージョンのベンチマークテストを実行⑥ソフトウェアパフォーマンスの受け入れと安定性テストを実行⑦実稼働環境の比率と最適化⑧パフォーマンステストケースとシナリオ設計を実行⑨パーツ間の調整⑩特定のパフォーマンス分析

4、関連用語

1.読み込み：
2000ユーザーが注文するなど、サーバーに負荷をかけるビジネスオペレーションのプロセスをシミュレートします。
2.パフォーマンステスト：
ユーザー負荷をシミュレートして、システムの応答時間、スループット、およびその他のインジケーターが、負荷がかかった状態でのパフォーマンス要件を満たしているかどうかをテストします。
3.
特定のソフトウェアおよびハードウェア環境での負荷テスト（負荷テスト）。負荷（さまざまな仮想ユーザーの数）を継続的に増やし、パフォーマンスインジケーターに耐えられる最大ユーザー数を決定します。
>>ここでのパフォーマンスインジケータには、TPS（1秒あたりのトランザクション数）、RT（平均トランザクション応答時間）、CPU使用量（CPU使用量）、メモリ使用量（メモリ使用量）、その他のハードウェアおよびソフトウェアのインジケータが含まれます。
4.構成テスト
リソースを合理的に割り当て、システム運用効率を向上させるために、テスト方法を通じて構成情報を取得、検証、および調整するプロセス。
5.
特定のソフトウェアおよびハードウェア環境でのストレステスト（ストレステスト）、高負荷を介してサーバーのリソース（サーバーリソース、ハードウェアリソースを強調）を制限状態にして、テストシステムを長時間制限状態にする動作は安定していますか？
>> TPS（1秒あたりのトランザクション数）、RT（平均トランザクション応答時間）、CPU使用量（CPU使用率）、メモリ使用量（メモリ使用量）などの安定した指標を決定します。
6.耐久性テスト
特定のソフトウェアおよびハードウェア環境で、特定の負荷を長時間実行して、パフォーマンスインジケーターを満たす前提でシステムが安定して実行されているかどうかを判断します。ここでは、上記の第5条の圧力/強度テストとは異なり、安定性テストが限界状態で実行されないことが強調されます。
通常、性能要件を満たす負荷での試験のため、負荷を1.5〜2倍に増やします。
7.
1秒あたりのTPSによって完了したトランザクションの数は、通常、1秒あたりの成功したトランザクションの数を指します。これは、パフォーマンステストにおける重要な包括的なパフォーマンスインデックスです。トランザクションは、ビジネス測定の単位です。
例：
支払い操作の場合、バックエンドシステムでは、メンバーシップシステム、金融システム、支払いシステム、会計システム、銀行ゲートウェイなどが発生する可能性があります。ただし、ユーザーの場合、注文から支払いまでに費やす金額を知りたい長い時間。
8. RT / ART（応答時間/平均応答時間）
応答時間/平均応答時間は、トランザクションが完了するまでにかかる時間を指します。多くの場合、応答時間を何度もカウントしてから平均化します。これにより、時間の正確性が保証され、より代表的なものになります。
>>通常、ARTの代わりにRTを使用します。
9.PV（ページビュー）
ユーザーが1秒間にページにアクセスした回数。
>>このパラメーターは、1秒あたりのページにアクセスするユーザーの平均数を分析するために使用されます
10.仮想ユーザーの仮想ユーザー（Vuser）
。つまり、実ビジネスの論理ステップをシミュレートする仮想ユーザーと、仮想ユーザーシミュレーションの操作ステップが仮想ユーザースクリプトに記録されます。仮想ユーザースクリプトユーザーは、シナリオで仮想ユーザーが実行する操作について説明します。
11.並行
性：並行性には、ポイントレベルとラインレベルの2つの主要なポイントがあります。
①ポイントレベル：
例えば月曜日の朝7時30分に、小学生は運動場に行かなくてはならない。
>>つまり：同時に何かをする②
ラインレベル：
例：11：30-13：00正午、一部の小学生はゴムバンドをジャンプし、一部はフットボールをするが、同時にサーバーに圧力をかける。
>>つまり、1つの期間にさまざまなことを実行し
ます。ここではあまり紹介しません。詳細については、Xiaoyuが作成した「同時実行の一般的な問題」を参照してください。
12.シナリオの
パフォーマンステストプロセスでは、実際のユーザーのビジネス処理プロセスをシミュレートするために、トランザクション、スクリプト、仮想ユーザー、実行設定、実行計画、監視、およびLRに組み込まれた分析に基づくアクションのコレクションが呼び出されます。これはパフォーマンステストのシナリオです。
>>シナリオには、実行されるスクリプト、スクリプトグループ、同時実行数、負荷ジェネレーター、テストターゲット、テスト実行中の構成条件などが含まれます。
13.思考時間（思考時間）
は、実際のユーザーが実際の操作中に一時停止する時間間隔をシミュレーションします。
>>ビジネスの観点から：思考時間は、ユーザーが操作しているときの各リクエスト間の時間間隔です。
>>テストスクリプトから：これは、2つのリクエストステートメント間の時間間隔です。
14.標準偏差（Std。Deviation）
は、データ統計の概念から導き出されたものであり、標準偏差が小さいほど変動が小さく、システムが安定しているのに対し、逆にシステムが安定している。
>>含まれるもの：応答時間標準偏差、TPS標準偏差、実行仮想ユーザー標準偏差、負荷標準偏差、CPU標準偏差の使用など

5つのパフォーマンスツール

市場にはかなりの数のパフォーマンステストツールがありますが、最もよく使用されているJMeterおよびLoadrunnerに精通しており、それを使用しています。
ゆっくりご紹介しますので、ご安心ください。
1.パフォーマンステストツールの選択方法ツール
を選択する場合、次の側面のみを考慮することができます
。①専門的、安定的かつ効率的。
②シンプルで使いやすく、テストスクリプトに多くの時間を費やす必要はありません。
③技術サポートと健全な文書化。
④入力と出力の比率。
2.どのような一般的なパフォーマンスツールです
HP社の①Loadrunner
②ApacheのJMeter
の③Grinder④QALoad
コンピュウェア社
、マイクロソフト社の⑤WAS
のRADviewの⑥WebLoad
IBM社の会社⑦RPT
など⑧OPENSTA
ここで、暁は、パフォーマンステストのコアが選択されているツールではないことを強調したが、それはパフォーマンス分析です。重要なことは考え、実装することです。ツールの選択とは関係が
ないため、優先度を分析する必要があります。

6、基準に合格

パフォーマンステストに合格するかどうかを判断するには、TPSとRTに依存するだけでなく、サーバーパフォーマンス、フロントエンドパフォーマンス、およびユーザーエクスペリエンスパフォーマンスから分析します。
一般的なテスト合格基準は次のとおりです。

セブン、まとめ

パフォーマンステストの基本的な状況について説明しましたが、誰もがこれらの姿勢をよく理解して理解できると思います。
パフォーマンステストには、専門的なスキルだけでなく、コミュニケーションスキルも必要です。
パフォーマンステストをよりよく学び、習得するためには、分析の観点からも自分自身を改善する必要があると思います。結局のところ、コアポイントはパフォーマンス分析です。