パフォーマンス要件が曖昧な場合、パフォーマンス テスト ツールを見つけてパフォーマンス テストを開始する初心者を多く見てきましたが、この場合、得られたパフォーマンス テスト結果はシステムの実際の能力をほとんど反映していないか、システムの実際の能力と一致していない可能性があります。システムの実際の能力、現実世界のパフォーマンスには程遠いものです。
パフォーマンス テストは、機能テストよりも技術的に複雑です。過去のテスト プロセスでは、パフォーマンス テストはテスト プロセスの一部にすぎず、システム テストまたは受け入れテストのオプションでした。しかし、検査技術の発展により。多くの企業では、パフォーマンス テストを個別に分離し、専用のパフォーマンス テスト グループまたはチームを設立しています。次に、パフォーマンス テストでも、実装プロセス中に独立したプロセスと仕様を確立する必要があります。
Master Chong は、他の本で提案されているプロセスとは少し異なる、独自のパフォーマンス テスト プロセスを提案しました。プロセスの実行に絶対的な正解・不正解はなく、自分に合ったプロセスが正解です。
以下で説明したプロセスを見てみましょう
パフォーマンス要件の分析
性能要件分析は性能テスト作業全体の基礎となるものであり、性能要件さえ理解していなければ、その後の性能テストツールについて語ることはできません。
この段階では、パフォーマンステスターは、需要担当者（顧客）、リーダー、プロジェクト関係者とコミュニケーションをとりながら、プロジェクトのさまざまなデータを収集し、システムを分析し、テストの意図を確認する必要があります。もちろん、お客様のパフォーマンスに対する姿勢も求められます。
テスト要件分析フェーズの主なタスクは、テスト戦略とテスト範囲を決定することです。戦略は主にソフトウェアの種類とシステムに対するユーザーの性能要件に基づいて決定され、テスト範囲は主にシステムの機能モジュールを分析して調査および分析されます。明確な要件を最終決定します。
パフォーマンステスト計画
明確な要件を決定したら、パフォーマンス テスト計画を作成する必要があります。パフォーマンス テスト プロセス中に必要なすべての作業を策定および計画します。
テスト計画の一般的な内容:
プロジェクトの簡単な背景説明、このパフォーマンス テストのニーズと目的、パフォーマンス要件分析の結果。テスト環境の準備、どのようなソフトウェアとハードウェアの構成が必要か、ネットワーク状態のログイン。テスト データの準備: 一部のパフォーマンス テストでは、事前にテスト データを準備する必要があります。
テスト戦略: 前述の要件分析の目的は、テスト戦略を策定すること、つまり要件を満たすテスト シナリオを設計することです。システムのどのビジネス モジュールをテストする必要があり、どのようにテストするか? どのようなシナリオを設計する必要があるか、およびこれらのシナリオを設計する目的。
最後に、開発、DBA、運用保守担当者の参加と支援の必要性、パフォーマンス テストのタイミングなどの人員配置を明確にします。
テスト環境のセットアップ
テスト環境の構築はハードウェア環境とソフトウェア環境に分けられ、ハードウェア環境は主にハードウェア機器の上司による承認が必要ですが、大規模な性能試験などでは会社でハードウェア機器を購入またはレンタルする必要がある場合があります。または、将来的に元の設定を展開して再編成する場合は、その時点でネットワーク エンジニアの参加または支援が必要になります。
ソフトウェア環境の構築は、Microsoft の Windows + IIS + SQL Server 2005 + .NET プラットフォーム、Windows/linux+tomcat/weblogic+mysql+java、linux+ apache+ mysql+ の 3 つの一般的な環境など、開発者にとってストレスのないものでなければなりません。 PHP およびその他の環境。もちろん、パフォーマンス テスターとして、ソフトウェア プラットフォームを構築できる必要があるだけでなく、各プラットフォームの部分をより深く理解する必要もあります。パフォーマンス テストの分析はシステム アプリケーション層に焦点を当てていないためです。ミドルウェア、データベース、システム、ハードウェアはすべてシステムのボトルネックになる可能性があります。
パフォーマンスツールの紹介
実はこの段階で性能テストツールを導入する必要があり、私たちの日常業務ではまずテストツールを選定し、その後要件を分析してテスト計画を立てることが多いです。このように、性能要件を分析する際には、選択したツールで性能要件を達成できるかどうかを検討することが多く、達成できない場合には、その要件を諦めたり、要件を変更したりすることがあります。このように、特定のツールに基づくパフォーマンス テストの結果は不正確である可能性があります。
ツールの導入は、自社開発と市販の既存ツールの導入に分かれます。市場にある既存のツールは有料、オープンソース、無料に分かれており、それぞれに独自の長所と短所があります。私たちがしなければならないのは、既存のオープンソースツールのコスト、購入コスト、開発コスト、二次開発コスト、人材の学習と使用コスト、時間コストなどに至るまでのニーズを分析することです。
ここでもう一度強調しておきますが、ストレス テスト ツールだけがパフォーマンス ツールであるわけではなく、テスト データ生成ツールやパフォーマンス監視ツールなど、パフォーマンス テスト プロセスで使用されるすべてのツールがパフォーマンス ツールであるということです。
テストの実行
テストの実行は大規模なコンテンツである必要があります。これは、パフォーマンス テスト アーキテクチャに関する前のセクションで述べたものです。ユーザー行動生成→プレッシャージェネレーター→ユーザーエージェント→テストスケジュール→システムモニタリングなど
パフォーマンス テスト エンジニアは、選択したツールがどのようにニーズを達成できるかを十分に理解しています。プロトコルを理解するには、プログラミングのスキルなどが必要な場合があります。実際、多くの初心者は、特定のツールの使用からパフォーマンスを学習し始めます。
テスト結果の分析
繰り返しになりますが、テスト ツールは、データを明らかにして提示するためのさまざまな方法を提供するだけです。ツール自体はパフォーマンス結果の分析には役立ちません。
パフォーマンス テストの結果を分析するには、パフォーマンス テスト エンジニアは、テスト環境全体のさまざまなソフトウェアとハードウェアを深く理解する必要があります。もちろん、このプロセスでは、開発者、DBA、運用保守など、さまざまな立場の担当者の支援が必要になることがよくあります。シニア パフォーマンス テスト エンジニアになるまでには、まだまだ長い道のりがあります。
ソフトウェアおよびハードウェア構成の調整と最適化
簡単に言うと、このリンクはシステムのチューニング段階に属します。この項目は必須リンクではありません。これは、このパフォーマンス テストのニーズと目的によって異なります。システムの機能を確認するだけの場合。テスト結果を分析した後、パフォーマンステストレポートを発行できます。
私たちテスターにとって、システムの機能テストの目的は、システムの機能が要件を満たし、利用可能であるかどうかを検証することですが、欠陥が発見された後は、追跡して修復する必要があり、発見された欠陥を書き留めることではありません。 . レポートは以上です。もちろん、機能上の欠陥やパフォーマンス上の欠陥には本質的に欠陥があります。性能試験の過程で要件を満たさない欠陥が発見された場合、チューニングは不可欠な工程です。
システムを調整する必要がある場合、テストの実行、結果の分析、およびシステムの調整が周期的かつ継続的なプロセスを形成します。お客様のニーズが満たされるまで。
-----------------------------------------------
上記のテスト プロセスにリストされている部分については、今後のブログ投稿で詳しく説明します。もちろん、私が提案したプロセスについて通信することもできます。メッセージを残していただいても構いません。
7 日間で 30 の実践的なインターフェイス自動テスト プロジェクトを実践した後、28,000 人がバイト テストのポジションに加わりました。[自動テスト/インターフェーステスト/ソフトウェアテスト/パフォーマンステスト/Jmeter]
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。