パフォーマンステストはいつ始まりますか? パフォーマンステストプロセスの概要

プロジェクト開発計画、要件仕様、設計仕様などの文書にはすべて、パフォーマンステストの要件が含まれる場合があります。これらの資料を収集することで、予備的な性能要件を見つけることができます。ただし、これらのパフォーマンステスト要件は十分に正確ではないことが多く、パフォーマンステスト担当者による専門的な指導が必要です。

類似品

自社の他の製品や過去のプロジェクトなどにもデータが蓄積されており、参考にすることができます。

ユーザー使用モデル

ユーザー使用モデルを分析することは、どのユーザーがシステムのどの典型的なサービスを使用するか、何人のユーザーがどの機能をいつ実行するかを考慮して、パフォーマンステスト要件を取得する効果的な手段です。例: OA システムでは、毎朝 8:00 の 10 分間に 200 人のユーザーがシステムにログインします。毎日のクエリトランザクションのピークは、9:00 ～ 11:00 と 14:00 ～ 16:00 です。このユーザーはモデルを使用し、80/20 原則を組み合わせて、OA システムのログインとトランザクションクエリビジネスの同時実行量を計算します。

80/20の原則

80/20 の原則とは、システムのビジネスの 80% が営業日ごとの 20% の時間で完了するか、システムのユーザーの 80% が 20% の時間でアプリケーションの操作に集中するということです。2 つの例を挙げて説明しましょう。

(1) Web サイトには毎日合計 100,000 人の訪問者がおり、そのうち 30% が製品ページの閲覧、20% が検索サービス、50% がログイン + 購入サービスです。80-20 の原則を使用し、8 時間の 20% をベンチマーク時間として使用して、各ビジネスの同時接続数を計算します。

検索ビジネス: (100000*20%*80%)/(8*3600*20%)=2.78 四捨五入 3

単一の製品ページを参照: (100000*30%*80%)/(8*3600*20%)=4.17 四捨五入して 5

ログイン+購入: (100000*50%*80%)/(8*3600*20%)=6.94 四捨五入して 7

(2) システムの年間業務は 8 か月に集中し、月平均 20 日の稼働日、1 日あたりの稼働時間は 8 時間となり、80/20 の原則によれば、業務の 80% が 1.6 時間で完了します。 1日あたり何時間も。昨年、約 100 万件のビジネストランザクションが処理されました。そのうちの 15% のビジネス処理では、ビジネスごとにアプリケーションサーバーに 7 つのリクエストを送信する必要があり、そのうち 70% のビジネス処理では、アプリケーションサーバーに 5 つのリクエストを送信する必要がありました。残りの 15 % ビジネス処理では、各ビジネスは 3 つのリクエストをアプリケーションサーバーに送信する必要があります。過去の統計結果によると、ビジネスの年間成長率は15%となっており、今後3年間のビジネス展開を考慮したテストでは、現在のビジネス量の2倍のリクエスト数に基づいてシステムが達成すべきTPSを算出する必要があります。

年間の総リクエスト数 = (100万*15%*7+100万*70%*5+100万*15%*3)*2=1,000万

TPS=(10000000*80%)/(8*20*8*3600*20%)=8.68、TPS=9

応答時間の標準

2秒以内にユーザーは気分が良くなります

2 ～ 5 秒、ユーザーは許容できると判断します

5 ～ 10 秒間、ユーザーは非常にイライラし、受信できなくなり、頻繁にページを更新するようになります。

10秒以上全く受信できず、そのまま退出してしまう

パフォーマンステストエンジニアのビデオチュートリアル: 2023 年最新の実際の企業パフォーマンステストプロジェクトの全プロセスの詳細な説明。履歴書に記入できる種類のものです。面接_哔哩哔哩_bilibili https://www.bilibili.com/video/ BV1PW4y1R7ye/?spm_id_from=333.999.0.0

2. 性能試験シナリオの取得

1.オンラインシステム

単一シーン:

オンラインシステムのログ分析結果から、アクセス数の多い機能、変更される機能および変更による影響を受ける可能性のある機能、お金に関連する機能を抽出します。念のため、影響を受ける機能を開発者に確認することをお勧めします。

混合シーン:

オンラインシステムのログ分析結果に基づいて、システムレベルでの最大同時実行数が取得され、毎日の増加傾向に従って増加して最終的な最大同時実行数が取得されます。次に、ログ分析結果の重要な各機能の割合に応じてユーザーを割り当てます。

安定性シナリオ:

単一シーンと混合シーンを決定した後、安定性シーンも考慮する必要があります。その目的は、システムにメモリリークがあるかどうかをテストすることであり、システムの平均故障間隔をテストすることもできます。したがって、混合シーンで長期安定性テストを実行できます。

2. 新しいプロジェクト

単一シーン:

重要なコア機能

共通機能

複雑なビジネスプロセスを伴う機能

リソースを大量に消費する関数 (複数テーブルのクエリや複数のテーブルへのデータの挿入など)

混合シーン:

特定の比率に従ってすべての重要な機能をミックスシーンに追加します

安定性シナリオ:

長期安定性テストには、混合シナリオの使用を検討してください。

3. 性能試験データの決定

パフォーマンステストで非常に重要なポイントは、シーンデータの設計です。たとえば、データクエリシナリオでは、そのシナリオに対応するデータベーステーブルにデータが 10 個しかない場合、クエリ結果は比較的高速である必要があります。ただし、このクエリシナリオに対応するデータベーステーブルに 1,000 万個のデータがある場合、クエリ結果は、データが 10 個のみのクエリ結果よりも確実に遅くなります。パフォーマンステストでデータ量が考慮されていない場合、パフォーマンステストの結果は不正確になり、オンライン化後にデータ量を考慮していない要因によってパフォーマンスの問題が発生する可能性が高くなります。

オンラインシステムの場合、各テーブルのデータ量は、オンラインシステム内の各テーブルのデータ量と増分に応じて決定できます。新しいシステムは、開発ドキュメントおよび関連するプロジェクト関係者 (顧客代表、プロジェクトマネージャー、要件アナリスト、システムアーキテクト、プロダクトマネージャーなど) に従って決定する必要があります。

4. パフォーマンステストケースの設計

1. 単一シーン

シナリオの説明: ユーザーのログインをシミュレートする

同時実行: テストのために同時ユーザー数をそれぞれ 1、10、50 としてシミュレートします。

圧力試験時間：各回15分

データ量: MySQL ユーザーテーブルには 700,000 のアカウントがあります

待ち合わせ: 待ち合わせなし

指標に注目します: 応答時間、トランザクション成功率、アプリケーションサーバーのリソース使用量 (CPU、メモリ、IO)、MySQL データベースのリソース使用量 (CPU、メモリ、IO)、アプリケーションログにデッドロックなどのエラーがあるかどうか、データベースログ内のエラーデッドロック、JVM メモリ使用量、GC 条件などのエラー

予想される指標: 2 秒以内の応答時間、トランザクション成功率 100%、アプリケーションサーバーとデータベースサーバーの CPU 使用率 ≤ 60%、メモリリークなし、データベースデッドロック、スレッドデッドロックなど。

2. ミックスシーン

混合シナリオでは、すべてのテストシナリオを組み合わせて大規模なシナリオを形成するわけではありませんが、データベースクエリ操作の混合シナリオ、データベース書き込み操作の混合シナリオ、データベースクエリと書き込み操作など、混合シナリオのさまざまな組み合わせを最初に検討する必要があります。ミックスシーン。次のように：

シナリオの説明: ユーザーがデータベースの読み取りおよび書き込み操作を実行する必要がない混合シナリオをシミュレートします。シナリオには、ユーザーログイン、広告ワードのデフォルトクエリ、新しい広告グループ、広告ワードのデフォルトの作成、広告レビュー、広告の検証、広告が含まれます単語を価格順に並べ替えます。

同時実行性: 合計 300 ユーザーが同時に動作するようにシミュレートされます。そのうち、ログイン操作が 20%、広告のデフォルトのクエリが 25%、新しい広告グループが 15%、広告のデフォルトの作成が 8% を占めます。、広告のレビューが 10%、広告の有効化が 15%、価格順に並べ替えられた広告ワードが 7%

圧力試験時間：各回15分

データ量: MySQL の cpc テーブルには 150 万件のデータ、プランテーブルには 100,000 件のデータ、グループテーブルには 500,000 件のデータ、監査テーブルには 100 万件のデータ、MongoDB レポートテーブルには 1TB のデータ、ユーザーテーブルには 900,000 件の記事データがあります。

待ち合わせ: 待ち合わせなし

予想される指標: ログイン、広告言葉のデフォルトクエリ、新しい広告グループなどの操作の応答時間は 2 秒以内、広告言葉のデフォルト作成、広告レビュー、広告の有効化、広告の順序付けなどの操作の応答時間は 2 秒以内です。価格別の単語は 3 秒以内、トランザクション成功率 100%、アプリケーションサーバーおよびデータベースサーバーの CPU 使用率 ≤ 60%、メモリリーク、データベースデッドロック、スレッドデッドロックなどがないこと。

3. 安定性シナリオ

圧力試験時間: 過去 2*24 時間

待ち合わせ: 待ち合わせなし

メトリクスに焦点を当てる: JVM メモリ使用量と GC

予想されるメトリクス: メモリリークや発生の兆候はない

5. 性能試験環境の準備・構築

パフォーマンステスト環境には、ソフトウェア環境、ハードウェア環境、ネットワーク環境が含まれます。これら 3 つの環境には、アプリケーションサーバー環境だけを指すのではなく、データベースサーバー、キャッシュサーバー、ファイルサーバー、およびその他の中間アプリケーションサーバー環境も含まれます。

ハードウェア環境には、CPU、メモリ、ディスク、その他の基本的な要素が含まれます。

ソフトウェア環境には、オペレーティングシステムのバージョン番号、構成、Linux ディスクパーティション、JDK バージョン、ビット番号、メーカー、ミドルウェアのバージョン番号、ビット番号、データベースのバージョン番号、ビット番号が含まれます。また、これらのソフトウェアのインストールパスも、以下と比較して最適です。オンライン環境は一貫しています。設定ファイルには、JVM 設定、ミドルウェア設定、データベース設定ファイルなどが含まれます。

ネットワーク環境には、ネットワークプロトコルとネットワーク帯域幅が含まれます。

クラスタ環境には、アプリケーション関連サーバのロードバランシング環境、データベースのホットスタンバイまたはマスタスレーブ環境、クラスタ環境などが含まれます。

オフラインシミュレーションテスト環境を申請する場合は、次の原則に従う必要があります。

(1) ハードウェア環境は本番環境と可能な限り一致する

(2) クラスタ環境の場合、テスト環境にそれほど多くのサーバを申請することは不可能なので、オンラインの本番環境と整合性のある3台をオフラインの性能テストマシンとして申請することを検討できます。パフォーマンステストのプロセスでは、シングルマシン、ダブルマシン、および 3 マシンのロードバランシングのパフォーマンスをそれぞれテストし、ロードバランシングによるオンライン運用環境 (たとえば、100 台のマシン) のパフォーマンス損失を計算できます。ライン上の 100 台のマシンが負荷分散されている場合のパフォーマンス指標をより現実的に計算するために、3 つのケースのパフォーマンスにレートを設定します。

(3) データベースクラスター環境が大きすぎる場合 (たとえば、データベースに 32 台のマシンからなる 8 つのグループがある場合)、オフラインテストはパフォーマンステストの 32 台のマシンには適用されません。通常、この場合は、一連のデータベース (1 つのマスターと 3 つのスレーブ) のみがパフォーマンステスト用のデータベースとして適用されます。大規模なデータベースのクラスターは基本的にデータベースとテーブルを分割する戦略を採用しているため、巨大なデータベースクラスターが発生します。性能テストはデータベースマシン一式を申請することで実施でき、性能テストに使用するユーザーデータが申請したデータベース一式に含まれることを確認するだけで実施できます。

(4) ハードウェア環境とオンライン環境の整合性が確保できない場合は、低構成環境のみでテストを行い、低構成環境での測定結果がオンライン要件を満たせる場合は、オンラインの高構成環境は、確立された要件、パフォーマンス要件も満たす必要があります。CPU グラニュルの数、キャッシュ、物理メモリサイズ、ディスク速度が異なる場合、パフォーマンスモデリングによって得られるパフォーマンス結果が十分に正確ではないため、それを満たせない場合はモデリング推定は推奨されません。低構成マシンでのテストで要件を満たさない場合は、テスト環境をテストレポートに記載する必要があり、テスト環境の改善によりテスト環境が要件を満たしていることは保証できません。

モックサーバーの準備:

インターネット業界ではモックサーバーと呼ばれ、銀行やその他の金融業界ではパフォーマンステストバッフルと呼ばれます。システムの業務共同デバッグでは、他のシステムのインターフェイスを呼び出す必要がある場合がありますが、他のシステムの開発は完了していません。この状況に対する一般的な解決策は、一時サーバーを構築し、それらのサービスをシミュレートし、共同デバッグとテスト用のデータを提供することです。Mock Server を使用すると、通常、次の利点が得られます。

(1) 他のモジュールまたはシステムエラーに起因するこのモジュールのテストエラーを切り分けます。

(2) 他のモジュールの開発状況を隔離する。インターフェースが定義されていれば、開発が完了しているかどうかは関係ありません。

(3) 一部の遅い操作はモックオブジェクトに置き換えて、すぐに返すことができます。

6. スクリプトを作成する

ここでは詳しく説明しません。

セブン、走行シーン

テストケースに基づいてテストシナリオを実行します。

8、モニタリングを行う

パフォーマンステストのプロセスでは、まずコマンドを使用して監視し、問題がある場合はツールに接続して監視します。

9. 分析とチューニング

各チューニングの後、構成情報とテスト結果を詳細に記録する必要があります。

10. 回帰テスト

回帰テストの後、すべての目標が達成された後、パフォーマンステストレポートが作成され、プロジェクトチームのメンバーに送信されます。

11. 絵を描いてレポートを書く

1. テストの目的

どのシナリオ、同時ユーザー数、応答時間、TPS

2. テストの結論

合格/不合格

3. このテストの最適化

あるシナリオ: テスト開始時の TPS は 5 でしたが、最適化後は TPS が 30 に達しました。どのような問題が見つかり、どのように解決するか。

4. 最適化された変更

コード

JVM

データベース

ミドルウェア

Linuxサーバー

5. 具体的な試験条件

システム構造

テスト環境

試験方法

試験結果

6. その後の最適化の提案

要約:

私の記事を注意深く読んでくださった皆さん、ありがとうございました！！！

私は過去数年間のソフトウェアテストのキャリアでまとめたいくつかの技術資料を個人的に整理しました。これには、電子書籍、履歴書モジュール、さまざまなジョブテンプレート、インタビューブック、独習プロジェクトなどが含まれます。コメントエリア 333 にメッセージを残していただければ、無料で受け取ることができます。