クラスメートが私にプライベート メッセージを送ってきて、パフォーマンス テストに関するいくつかの話題についてチャットしたところ、彼のパフォーマンス テストに対する理解が誤解されていることがわかりました。
いくつかの技術交流グループでは、パフォーマンス テストに関する誤解により多くの学生が引き起こした次のようなさまざまな問題にも遭遇しました。
登録ユーザーの数 = 同時実行数の場合、サービスは直接中断されます。
· 本番環境での直接の圧力テスト: 本番サービスがダウンし、顧客から苦情が寄せられます。
もちろん、これらは比較的基本的な質問なので、勉強を始めたばかりの学生はこのような間違いを犯す可能性があります。実際のプロジェクト経験があれば、パフォーマンス テストが思ったよりもはるかに複雑であることが理解できるでしょう。テクノロジーの幅広さと深さに対する一定の要件に加えて、ビジネスへの精通、要件とシナリオを分析して理解する能力、さらにはストレス テストの実施中のコミュニケーションと調整能力にも一定の要件があります。
この記事では、パフォーマンス テストに関連するトピック、その実装の目的、さまざまなシナリオでの焦点、およびいくつかの無視されている点について説明します。
パフォーマンステストの目的
まず第一に、パフォーマンス テストに含まれるテクノロジ スタックに関係なく、パフォーマンス テストの本質は機能テストと何ら変わらないことを認識する必要があります。要件分析、シナリオ設計、テストケースとテストデータの準備も必要です。機能テストは手動でユースケースを実行し、結果を観察することですが、パフォーマンステストは主にツールまたはスクリプトを使用してテストケースを実行し、結果を観察します。
機能テストの目的は、製品設計の正しさを検証し、設計と矛盾するバグを見つけることです。パフォーマンス テストは、アプリケーション サービスの処理能力のボトルネックを見つけて、オンラインの容量計画とサービスを確保するために対象を絞った最適化を実行することです。安定性、セックスがサポートを提供します。ここで問題が生じます。いわゆる処理能力のボトルネックをどのように定義するかということです。これには、ビジネス価値を固定する必要があります。
パフォーマンス テストの要件は基本的にビジネスから生じます。たとえば、ユーザーがAPP の応答が遅すぎると報告したり、財務またはコスト部門が IT のハードウェア コストが高すぎると報告したり、運用活動が理由でビジネス目標を達成できなかったりするなどです。システム障害に至る。分類の観点から見ると、これらの問題はユーザーと企業にとっての悩みの種です。
· APP の応答が遅すぎる: 処理速度を上げ、応答時間 (RT) を減らします。
· ハードウェア コストが高すぎる: ハードウェア コストを削減し、単位リソースあたりの処理能力 (TPS) を改善します。
· ビジネス目標未達成: システムの安定性の向上 - ビジネスの成功率の向上 (99% ～ 99.99%)。
要約すると、コストを削減し、ユーザー エクスペリエンスを向上させ、ビジネス目標を確実に達成すること、これがいわゆるビジネス価値です。
パフォーマンス テストの最終的な目的は機能テストと本質的に同じであり、正しく安定したサービスと優れたユーザー エクスペリエンスをユーザーに提供して、ビジネス目標の達成を確実にすることです。ユーザーや企業のニーズを満たすために採用された一連の技術ソリューションは、この目標を達成するための手段にすぎません。
さまざまなプロジェクトに焦点を当てる
パフォーマンス テストの目的について話した後、具体的なプロジェクトの実践に戻ります。日常業務で最も一般的なタイプのプロジェクトは、次のカテゴリに大まかに分類できます。
バージョンの反復
バージョンの反復はソフトウェア エンジニアの日常業務であり、この種のプロジェクトでは、パフォーマンス テストの主な焦点はシステムの処理能力にあります。要件の繰り返しや新しいコードの導入によってシステムの処理能力が低下していないかを検証するためのもので、主な指標としてはTPS、99RT、リクエストの成功率などが挙げられます。システム構築の観点から、パフォーマンスのベースラインを確立することで、システムの長期的なパフォーマンス品質を評価できます。
構成の変更
オンライン障害の多くが変更によって引き起こされることは誰もが知っていますが、実際には、多くの場合、パフォーマンスの変化は小さなパラメーターの変更によって引き起こされる可能性があります。細分化すると、パフォーマンス テスト シナリオの 1 つは構成テストと呼ばれ、システム パラメーターやサービス構成の変更によるパフォーマンスの変化を検証します。一般的なものは 2 つあります。
ソフトウェアパラメータの変更 : スレッドプール接続数、タイムアウトなど。
· ハードウェア構成の変更: サーバーのアップグレードおよびダウングレードによるパフォーマンスの変化の比較など。
このような構成変更によってもたらされるパフォーマンスの変化は、そのような変更は見落とされがちであるため、ミドルウェアと基本的なサービス レベルにより関係しますが、そのような変更はオンライン サービスのパフォーマンスと安定性に大きな影響を与えます。
新サービス開始
毎日のバージョンの反復に加えて、新しいサービスが開始されることは比較的一般的です。たとえば、技術的な変革、サービスの分割、新しいサービスプロバイダーの導入などでは、通常、既存のシステムに影響を与えるかどうかを検証するためにパフォーマンステストが必要です。
新しいサービスのパフォーマンス テストの主な目的は、システムの堅牢性を検証することです。つまり、メモリ リーク、ビジネスの過剰販売、デッドロック、SQL の遅さなど、明らかなパフォーマンスの問題を見つけることです。
安定性の保証
パフォーマンス テストのほとんどはオフライン環境で実行されますが、パフォーマンス テストの結果は、オンラインの容量計画と安定性の保証をサポートするものでなければなりません。そうでない場合、パフォーマンス テストの価値はほとんどありません。
すでに 2023 年になり、本番環境のフルリンク ストレス テストが提案されてから 11 年近くが経ちますが、これまでのところ、ほとんどの企業はまだ本番環境でパフォーマンス テストを実行する能力を持っていません。これには多くの理由があります。 。たとえば、実稼働環境でのストレス テストのコストが高く、リスクが高い、たとえば、ほとんどの企業では同時訪問者数がそれほど多くない、たとえば、技術的な構築と予備が十分に深くないなど、根本的な原因が考えられます。原因は実際には入力と出力のバランスです。
もちろん、テクノロジーがビジネス価値をどのように生み出すかは非常に複雑な問題ですが、フルリンク ストレス テストについては誤解があり、これも多くの人が見落としています。
本番環境のフルリンク ストレス テストは、特定のビジネス ニーズを持つ特定の企業にのみ適しており、実装できるかどうかは、適切な組織管理能力と対応する技術アーキテクチャがあるかどうかによって決まります。実稼働環境のフルリンク ストレス テストは特効薬ではありませんし、単なる技術的なテスト手段でもありません。実稼働環境のフルリンク ストレス テストが実稼働サービスの安定性を促進するための技術的実践であるとみなされる場合、検討すべき点はたくさんあります。価値点。しかし、実際の導入プロセスでは、テクノロジーの理解やビジネス価値の認識について、誰もが誤解に陥っているとしか言いようがありません。
シーンモデリングにおける誤解
学生はよく「ユーザーのデータを使用して圧力テストを繰り返すことはできますか?」と尋ねますが、いずれにせよ、これは同時リクエストでもあります。
機能テストでは、テストするシナリオやテストケースに応じて、対応するシナリオに対応したテストデータを用意しますが、なぜ性能テストでは無視されるのでしょうか？これは実際には認識上の誤解です。パフォーマンス テストは、高い同時実行性をシミュレートし、システムにリクエストを送信することです。
正しいアプローチは機能テストと同様で、ビジネス モデル、トラフィック モデル、データ モデルの間のマッピング関係を確立し、テスト シナリオに準拠した対応するテスト データを準備し、データ量がテストに十分であることを確認します。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
これらの資料は、[ソフトウェア テスト] の友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト。お役に立てれば幸いです。エンジニア