パフォーマンステストは、[要件調査ステージ]→[テスト準備ステージ]→[テスト実行ステージ]→[テストレポートステージ]→[テスト概要ステージ]の5つのステージに分かれています。
1. 需要調査段階
需要調査は、需要調査と需要分析の 2 つのステップに分かれています。
研究を依頼する
- 要件調査作業は、性能テスト実施者が主導し、プロダクトマネージャー、開発エンジニア、運用保守エンジニアが協力して完了し、主にシステムのオンライン環境の性能要件を決定します。
- 一般文書および詳細文書を読んで、システム情報（オンライン環境のハードウェア、パラメータ構成、システムアーキテクチャと導入方法、関連システムの導入など）、ビジネス情報（主要なビジネスロジックや処理フロー、トランザクションリスト、トランザクション量情報、業務分配ルールなど）、生産上の問題、ドキュメントなどを収集し、テスト対象システムのビジネスとテクノロジーを全体的に理解するために収集した情報を要約および整理します。
需要分析
- パフォーマンス要件を特定のパフォーマンス要件のインデックス値に変換する
例: TPS (Transaction per Second): 1 秒あたりにシステムによって処理されるトランザクションの数。導出プロセスは次のとおりです。
現在のオンラインAPP1.0トライアルシステムはクエリトランザクションが中心でトランザクションの40%を占めており、システム本番トランザクション量統計では月間約20万トランザクションとなっているが、APP2.0システムの開始後は業務量が急増すると仮定する。 1 日あたり 200,000 クエリの場合、1 日の合計取引量 T は次のようになります。
T = 20W/40%=500000 ペン/日
システム処理能力 TPS の導出: APP2.0 がオンラインになった後、最大トランザクション量は 1 日あたり 500,000 トランザクションであり、夜間にはシステムのトランザクション量はほとんどなくなります。2:8 原則によると、(500000*80%)/ (8*20%*3600)= 1 秒あたり 69.4 トランザクション、1 秒あたり 70 トランザクションに四捨五入され、年間のビジネス量の 50% 増加に基づいて計算され、1 年後のシステム処理能力指数は 70+70* にほぼ等しくなります。 50% = 1 秒あたり 105 トランザクション。
安定したトランザクション量の導出: システム処理能力の 60% * 継続時間 = 105 トランザクション/秒 * 60% * 8 * 3600 = 1814400 トランザクションを取得します。
分析後、テスト指標値に集計されます
Ø 需要分析の主な内容と規範的要件は次のとおりです。
n 性能試験要件：性能試験指標項目と要求指標値を正確に記載する必要があります。
n システム範囲: テスト範囲の関連システムの論理構成図や各関連システムの情報など、性能テスト要求指標値の基となるテスト範囲情報を正確に記述する必要があります。テスト対象システムの関連サブシステムの詳細を示します。
n 環境差異分析：テスト環境の全体ネットワークトポロジー図、テスト環境マシン構成表（台数、モデル、リソース）など、性能テスト需要指標値の基となるテスト環境情報を正確に記述する必要があります。 、オペレーティング システム）、および対応するソフトウェア構成、重要なパラメータ構成など。同時に、オンライン環境に関する上記の情報を正確に記述し、環境の違いを詳細に分析する必要があります。
上記の分析は、パフォーマンス テスト プログラムの重要な部分となります。
ビジネスモデル構築
- さまざまなビジネス テンプレートの割合
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
2. 試験準備段階
ビジネスモデルからテストモデルの構築、性能テスト実施計画の作成、テスト環境の準備、性能テストケースの設計、性能テスト監視計画の設計、パフォーマンステストスクリプトの作成、関連するテストデータの準備、および上記の関連する準備作業は終了します。その後、テスト計画に従って入学検査が実行されます。
テストモデルの構築、スキーム設計、ケース設計、データ準備などに焦点を当てます。
2.1 スキーム設計
計画書には、テスト要件、開始停止基準、テストモデルの設計、テスト戦略、テスト内容、テスト環境とツールの要件、各段階の出力ドキュメントを記載する必要があります。計画書には、性能試験作業のスケジュール計画、想定されるリスクやリスク回避方法なども説明する必要があります。テスト モデル設計の内容は、この段階でテスト モデル設計で形成されたテスト シナリオ、およびシナリオ内の典型的なトランザクションとその割合に基づいて決まります。
2.2 ケースの設計
ケース設計には、ケースの説明、テスト環境の説明 (ハードウェア、ソフトウェア、アプリケーションのバージョン、テスト データ)、遅延設定、ストレス シナリオ、実行の説明、期待される結果、監視ポイントが含まれます。
ケース設計はパフォーマンス テストの重要な部分であり、ケース設計の出力ドキュメントは「パフォーマンス テスト ケース」です。
2.3 データの準備
環境準備では基礎データの準備を行います。テストデータの量と論理的関係は非常に厳密であり、テスト基本データの準備には一般に自作のシミュレーションデータまたは感度の低いオンラインデータが採用されます。
2.4 テストスクリプトの開発
テストスクリプトの開発作業はLR(jmeter)をプレイする回です。
テスト スクリプトはビジネス オペレーションをプログラムで表現したものであり、スクリプトは一般にビジネス プロセスの記述です。このアクティビティは主に、テストの実装前に、各テスト ケースのスクリプトが単一のトランザクションと少数の反復の条件下で正しく実行できることを確認するために、スクリプトの記録 (書き込み)、変更、デバッグを目的としています。 。テスト スクリプト開発の一般的な手順は次のとおりです。
Ø 記録または書き込みによってスクリプトコードの生成を完了します。コードが生成されるとき、主に要件に従ってトランザクションが挿入され、テスト中にトランザクションの応答時間をカウントする単位として使用されます。
Ø テスト要件に従って、パラメータ化された設定を実行します。
Ø チェックポイントを設定し、メッセージ内容フィールドに従ってトランザクションが正しく実行されたかどうかを判断します。つまり、チェックポイントはアプリケーション レベルで設定されます。
Ø テスト要件に従って収集ポイントを設定するかどうかを決定します。
3. テスト実行フェーズ
テスト実行ステージは、テストケースを実行し、システム処理能力指標データを取得し、パフォーマンステストの欠陥を発見するステージです。テスト実行時は、テストツールを使用してテストシナリオやテストスクリプトを実行し、各種監視ツールと連携します。実行完了後は各種結果データを一元的に収集し分析します。必要に応じて、実行フェーズでシステムのチューニングや回帰テストを実行できます。
焦点: 結果の記録、テストの監視、結果の分析
3.1 テストの実行と結果の記録
- テスト実行プロセスには対応する優先度ポリシーがあり、テスト ケースの優先度に応じて、レベルの高いテスト ケースが優先されます。
- テスト中に、各テスト結果の分析を通じて、現在のケースを繰り返すか、新しいテスト ケースを実行するかが決定されます。
- 通常、ボトルネックが見つかるとすぐに調整され、現在のケースが通過するまでテスト ケースが再実行されます。
- 実行フェーズでは、テストの実行、分析と最適化、回帰テストが繰り返され、実行プロセス全体と実行結果が注意深く記録される必要があり、実行結果データはボトルネックを分析するための主な基礎となります。
3.2 テストモニタリング
テストの監視作業は実行作業と同時に行われ、シーンやスクリプトの実行が開始されると、監視プログラム（nmonやシステムコマンドtop/vmstat/iostatなどが利用可能）がITインフラストラクチャの性能指標を実行します。 TCP/SMTPなど
3.3 テスト結果の分析
テストプロセス中に、フロントエンドパフォーマンステストツールによって表示される結果とモニタリング結果に基づいて、テストで発生する問題を包括的に分析します。
例えば：
テストグループが「一般的な日常トランザクションモデル」の負荷テストを570TPSの負荷テストで実行したところ、データベース監視によりデッドロックの想定が存在することが判明しました。詳細は次のとおりです。
問題の分析: 開発で分析した結果、原因は次のとおりです。 フロー制御情報収集プログラム (pltflowGthDaemon) は、同じ窓口がミリ秒レベルで同時にトランザクションを実行すると、plt_flowgather テーブルでデッドロックが発生します。テスト環境でのオンライン取引は同じ窓口番号を使用して開始されるため、発生する可能性は比較的高くなります。
4. テストレポート段階
4.1 レポートの作成
パフォーマンス テスト レポートの主な内容には、テストの目的、範囲と方法、環境の説明、テスト結果の説明、結果分析、結論と提案などが含まれます。
4.2 試験結果の説明
テスト結果の説明は、パフォーマンス テストの実行プロセスを反映する必要があります。たとえば、混合シナリオの容量テスト結果の表示では、各同時勾配でのテスト結果とモニタリング結果を説明する必要があります。デジタル形式で記録する場合、小数点以下 3 桁までの精度が必要です。
4.3 テストの欠陥と問題
性能試験分析報告書には、試験工程で発見された不具合や問題点を記載し、試験不具合と確認された項目についてはリスク評価を実施し、リスク警告を行う必要があります。
4.4 最終結果の分析
テストの最終結果の分析、この部分は包括的、徹底的で、理解しやすく、図によってより直観的に表現される必要があります。
4.5 テストの結論
テストの結論は、パフォーマンス テスト分析レポートに含める必要がある内容です。テストの結果は、パフォーマンス テスト要件に記載されているさまざまな指標に明確かつ正確に答え、テスト要件を完全にカバーする必要があります。
5. テスト概要段階
パフォーマンス テストの要約作業では、主にタスクのテスト プロセスとテスト テクノロジを要約します。パフォーマンス テスト作業は概要段階に入りました。これは、パフォーマンス テスト作業が終了に近づいていることも意味します。この段階では、時間が許す限り、すべての重要なテスト資産をアーカイブする必要があります。
以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
