性能調整
開発者がシステムを調整した後、最適化が効果的であるかどうかを検証するために、テスターの協力を得てパフォーマンス テストを実行する必要があります。パフォーマンス指標が以前のパフォーマンス指標よりも優れている場合は、システムの最適化が効果的であることを意味します。逆に言えば、チューニングが理想的ではないことを意味します。
新しいサービスと新しいインターフェースが開始される
システムをゼロからオンラインにして、新しいシステムの能力が一定期間のシステム利用要件を満たせるかどうかを検証しないと、ピーク時にシステムが崩壊してしまう可能性があります。
システムの安定性を確認する
パフォーマンステストの場合、1時間、2時間、あるいは数十分程度の実行で十分ですが、システムの安定性や長時間安定して動作できるかどうかは十分ではありません。システムで発生する安定性の問題には、通常、メモリ リーク、接続番号リーク、デッドロック、不十分なカーソルなどが含まれます。これらの問題は、短期間では明らかにならない可能性があります。システムの安定性を検証するには、通常、ピーク パフォーマンスの同時実行数 (つまり、システムがサポートする同時実行の最大数) * 7 日 * 24 時間が使用されます。システムのスループット、平均応答時間、その他のパフォーマンス指標が適切である場合、通常、システムの安定性は良好であると考えられます。システムの重要性に応じて、実行時間は適切に調整できますが、少なくとも一晩のストレス テストが必要です。
システムアーキテクチャにボトルネックがないか確認する
同じシステムに対して、アーキテクトは異なるアーキテクチャ ソリューションを提供します。では、さまざまな設計ソリューションのどれが優れているのでしょうか? パフォーマンス テストを通じて、さまざまなソリューションのパフォーマンスを検証できます。第 2 に、システムに問題が発生する前にシステムがどの程度の同時実行レベルに達するかを理解し、システム アーキテクチャのどの部分を理解できるかがわかります。ピークパフォーマンスに達するとボトルネックが発生するため、開発者が目的のシステムチューニング作業を実行できるようにします。
パフォーマンステスト範囲の定義
一般に次の点が考慮されます。
・システム内でよく使う機能や呼び出されるインターフェースなど
- システムには多数のデータベースの読み取りおよび書き込み機能が含まれます。
- 大量のシステムキャッシュ部分を読み書きし、キャッシュが有効かどうかを検証する機能
一般に、ユーザーの訪問数が多い場所、データベース操作が頻繁に行われる場所、およびコア システム機能がパフォーマンス テストの範囲内にあることを考慮する必要があります。
パフォーマンステストの原則
3+1 原則 (量、充実度、深さ + 速度を指す)
主にパフォーマンス テストの設計、テストの実行、データ分析に重点を置きます。
ボリューム: ビジネス ボリューム (ビジネス タイプ)、負荷ボリューム (システムによって処理されるトラフィック)、構成ボリューム (ソフトウェア構成およびハードウェア構成)、ユーザー ボリューム (静的ユーザーと動的ユーザー)、および時間ボリューム (テスト時間) を含みます。
フル: 主にテストケース用。テスト ケース管理には、事前設定条件、テスト ステップ、および予想される結果の 3 つの部分が含まれます。この「完全な」焦点は、テスト結果の観察と、事前設定条件とテスト ステップのデータです。
深い: まず、システムの理解が深くなければなりません。次に、欠陥の分析が深くなければなりません。
高速: まず、テスト設計や観察などの漏れを避けるためのテスト経験の定着です。経験をテンプレートやツールに固めることで、経験の継承が容易になり、テストの重複や漏れを減らすことができます。2つ目は、パフォーマンステスト環境の構築、テスト実行、テスト分析の自動化など、パフォーマンステストの自動化です。テスト効率です。
2-5-10原則
主に応答時間のためです。簡単に言うと、ユーザーは 2 秒以内に応答が得られるとシステムの応答が速いと感じ、2 ～ 5 秒以内に応答が得られるとシステムの応答速度は問題ないと感じます。 5 ～ 5 秒以内に応答があれば、システムの応答速度は問題ないと感じます。10 秒以内に応答を受信すると、システムの応答速度は非常に遅いと感じますが、許容範囲内です。ユーザーがまだ受信できない場合は、システムの応答速度が遅いと感じます。 10 秒以上応答がない場合、ユーザーはシステムがひどいか、システムが応答を失ったと感じ、この Web サイトを離れるか、2 番目の要求を開始するかを選択します。
80/20の原則
リスクを軽減し、より多くのテストに集中するために使用されます: 80/20 原則はパレートの法則です。ユーザーはソフトウェア製品の機能の 20% を 80% の時間使用します。「キーテスト」はこれら 20% の機能をテストするもので、残りの 80% の機能は優先度の低いテスト範囲に属し、テスト リソースの 20% を占めます。
例: テスト強度の推定
基本コンセプト: 毎営業日行われる業務の 80% は 20% の時間で完了します。
たとえば、1 日 8 時間働く場合、1 日の業務の 80% は 8*20%=1.6 時間以内に完了します。
例: 昨年は約 100 万件のビジネスが処理されましたが、そのうち 15% の業務処理では各ビジネスごとにアプリケーション サーバーへの 7 回のリクエストが必要で、70% の業務処理では各ビジネスごとにアプリケーション サーバーへの 5 回のリクエストが必要でした。 ; ビジネス処理の残りの 15% では、各ビジネスが 3 つのリクエストをアプリケーション サーバーに送信します。過去の統計結果によれば、年間の業務増加率は15％となっており、今後3年間の事業展開を考慮すると、既存の業務量の2倍でテストを実施する必要がある。
強度は次のように推定されます。
年間のリクエストの合計数は次のとおりです。
(100*15%*7+100*70%*5+100*15%*3)*2＝1,000万回/年
1 日あたりのリクエスト数は次のとおりです。
1000/160=62,500/日 <注: 各月は 20 営業日なので、1 年は 160 日です>
1 秒あたりのリクエスト数: (62500×80%)/(8*20%*3600)=8.68 回/秒
パフォーマンステスト環境のセットアップ
特に次の 3 つの側面から、パフォーマンス テストと実際の運用環境の間の一貫性を確保します。
ハードウェア環境
たとえば、サーバーのモデル、サーバーが他のアプリケーションと共有されているかどうか、クラスター環境にあるかどうか、負荷分散がBIGIPを通じて実行されているかどうか、顧客が使用するハードウェア構成、使用するスイッチ モデル、ネットワークなどです。伝送速度。
ソフトウェア環境
バージョンの一貫性
オペレーティング システム、データベース、ミドルウェアのバージョン、テスト対象のシステムのバージョンが含まれます。
構成の一貫性
システム (オペレーティング システム/データベース/ミドルウェア/テスト対象システム) パラメータは一貫して設定されており、これらのシステム パラメータの設定はシステムに大きな影響を与える可能性があります。したがって、テスト環境で使用するソフトウェアのバージョンが実際の環境と一致していることを確認するだけでなく、パラメータの設定が一致しているかどうかにも注意を払う必要があります。
使用シナリオの一貫性
基本的なデータの一貫性
予測されるビジネス データ量とデータ タイプの割り当てが含まれます。非常に単純な例として、システム データベースにはわずか 10 個のデータがあり、データベースには数千万個のデータがあり、それに対してパフォーマンス テストを実行すると、得られるパフォーマンス指標が大きく異なる場合があります。
毎回より一貫したテスト環境を確保するために、ディスク使用量とディスクの断片化も多かれ少なかれパフォーマンスに影響します。
使用パターンの一貫性
実際のシナリオでユーザーの使用状況をシミュレートするために最善を尽くします。実際、私たちはパフォーマンス テストの初期段階で需要分析を行っており、その主な目的はユーザーの使用状況をより現実的な方法でシミュレートすることです。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。