最近、コストを節約するために、同社はコンピューター室の移行を次々と実行し、南米の展開アーキテクチャの一部を統合しました。Google Cloud への移行や Alibaba Cloud への移行など、いくつかの大きな調整があります。コンピュータ ルーム移行プロジェクトでは、パフォーマンス テストをどのように実行するかを考える必要があります。この種の大規模なコンピュータ ルーム移行 SRE (運用および保守) では、コンポーネントの単一コンポーネントのパフォーマンス テストをいくつか実行しますが、全体の移行後には、全体的なパフォーマンスは同じレベルに達しますか? 移行前は一貫していましたが、あまり明確ではありませんでした。このため、QA としては、移行前にパフォーマンス品質を総合的に評価する必要があります。ここでは、パフォーマンス テストに関するガイドラインをいくつか示します。
1。概要
パフォーマンス テストは、特定の負荷下での実行中のシステムのパフォーマンスに焦点を当てたソフトウェア テストの形式です。これはソフトウェアのバグや欠陥の発見とは何の関係もありません。さまざまな種類のパフォーマンス テストが、ベンチマークや標準に対して測定されます。パフォーマンス テストは、ボトルネックを解消するために必要な診断情報を開発者に提供します。
この記事では、次のことについて学びます。
パフォーマンステストの種類
パフォーマンス テストの実行手順
パフォーマンステストインデックス
ソフトウェアテストのベストプラクティス
2. ソフトウェアパフォーマンステストの種類
まず、ユーザーのシステム上でソフトウェアがどのように動作するかを理解することが重要です。ソフトウェア テスト中に、さまざまな種類のパフォーマンス テストを適用できます。これは、システムの準備状況を判断するために設計された非機能テストです。(機能テストはソフトウェアの個々の機能に焦点を当てます。)
テストの種類
負荷テスト
負荷テストでは、ワークロードの増加に伴うシステムのパフォーマンスを測定します。このワークロードは、同時ユーザーまたは同時トランザクションを意味する可能性があります。ワークロードが増加すると、システムが監視され、応答時間とシステムの継続能力が測定されます。作業負荷は通常の動作条件のパラメータの範囲内です。
圧力試験
負荷テストとは異なり、ストレス テスト (疲労テストとも呼ばれます) は、通常の動作条件のパラメータを超えたシステム パフォーマンスを測定するように設計されています。このソフトウェアは、処理できるより多くのユーザーまたはトランザクションを提供します。ストレス テストの目的は、ソフトウェアの安定性を測定することです。ソフトウェアはいつ障害が発生し、ソフトウェアは障害からどのように回復しますか?
スパイクテスト（スパイクテスト）
スパイク テストは、ワークロードが急速かつ繰り返し増加した場合のソフトウェアのパフォーマンスを評価するストレス テストです。短期間の作業量は通常の予想を超えます。
耐久試験
耐久性テスト (ソーク テストとも呼ばれる) は、長期間にわたる通常のワークロード下でソフトウェアがどのように動作するかを評価するものです。耐久性テストの目的は、メモリ リークなどのシステムの問題をチェックすることです。(メモリ リークは、システムが破棄されたメモリを解放できないときに発生します。メモリ リークは、システムのパフォーマンスに影響を与えたり、システム障害を引き起こす可能性があります。)
スケーラビリティテスト
スケーラビリティ テストは、ソフトウェアが増加するワークロードを効果的に処理しているかどうかを判断するために使用されます。これは、システムのパフォーマンスを監視しながら、ユーザーの負荷またはデータ量を徐々に増やすことで判断できます。また、CPU やメモリなどのリソースが変化しても、ワークロードは同じレベルに留まる可能性があります。
ボリュームテスト
バッチ テストは、ソフトウェアが大量の予測データに対してどれだけ効率的に実行できるかを決定します。このテストはシステムにデータを大量に送信するため、フラッド テストとも呼ばれます。
パフォーマンス テストで観察される最も一般的な問題
ソフトウェアのパフォーマンス テスト中に、開発者はパフォーマンスの症状や問題を探します。
応答が遅い、読み込み時間が長いなどの速度の問題がよく観察され、対処されています。
その他のパフォーマンスの問題が観察される場合があります。
ボトルネック - ボトルネックは、ワークロードを処理するのに十分な容量がないためにデータ フローが中断または停止されるときに発生します。
スケーラビリティが低い - ソフトウェアが必要な数の同時タスクを処理できない場合、結果が遅れたり、エラーが増加したり、その他の影響が発生する可能性があります。
ディスクの使用状況
CPU使用率
メモリーリーク
オペレーティング システムの制限事項
ネットワーク構成が不適切
ソフトウェア構成の問題 - 多くの場合、ワークロードを処理するには不十分なレベルに設定されています。
ハードウェア リソースが不十分 - パフォーマンス テストでは、物理メモリの制限や CPU パフォーマンスの低下が示される場合があります。
3. 7 つのパフォーマンス テストのステップ
テストベッドとも呼ばれるテスト環境は、パフォーマンス テストを実行するためにソフトウェア、ハードウェア、およびネットワークがセットアップされる環境です。パフォーマンス テストにテスト環境を使用するには、開発者は次の 7 つの手順を実行できます。
1. テスト環境を決定します。
利用可能なハードウェア、ソフトウェア、ネットワーク構成、ツールを特定することで、テスト チームは早期にテストを設計し、パフォーマンス テストの課題を特定できます。パフォーマンス テスト環境のオプションには次のものがあります。
低スペックのサーバーが少ない運用システムのサブセット
同じ仕様の少数のサーバーを備えた運用システムのサブセット
本番システムのコピー
実際の生産体制
2. パフォーマンス指標を特定します。
応答時間、スループット、制約などの指標を特定することに加えて、パフォーマンス テストの成功基準を決定します。
3. パフォーマンス テストを計画および設計します。
ユーザーの変動性、テストデータ、ターゲットメトリクスを考慮したパフォーマンステストシナリオを特定します。これにより、1 つまたは 2 つのモデルが作成されます。
4. テスト環境を構成します。
リソースの監視に必要なテスト環境の要素と計測機器を準備します。
5. テスト設計を実装します。
テストを開発します。
6. テストを実行します。
パフォーマンス テストの実行に加えて、生成されたデータを監視してキャプチャします。
7. 分析、レポート、再テスト。
データを分析し、結果を共有します。同じパラメータまたは異なるパラメータを使用してパフォーマンス テストを再度実行します。
どのパフォーマンス テスト指標を測定するか
パフォーマンス テストの品質と有効性を理解するには、メトリクスが必要です。測定しなければ改善はできません。説明が必要な 2 つの定義:
測定
- 収集されるデータ (リクエストへの応答にかかる秒数など)。
測定
- 平均応答時間 (合計応答時間/リクエスト) などの結果の品質を定義するメトリクスを使用する計算。
速度、スケーラビリティ、安定性を測定する方法はたくさんありますが、パフォーマンス テストのすべてのラウンドでそのすべてを使用することは期待できません。パフォーマンス テストで使用される指標の中で、次の指標が一般的に使用されます。
反応時間
リクエストを送信してから応答を取得するまでの合計時間。
待ち時間
平均レイテンシーとも呼ばれ、リクエストを送信してから最初のバイトを受信するまでにかかる時間を示します。
平均ロード時間
ユーザーの観点から見ると、各リクエストの配信にかかる平均時間が品質の主な指標となります。
ピーク応答時間
これは、リクエストを完了するまでに必要な最大時間の尺度です。ピーク応答時間が平均よりも大幅に長い場合は、問題のある異常を示している可能性があります。
エラー率ソフトウェアテスト
この計算は、すべてのリクエストと比較した、エラーとなったリクエストの割合です。これらのエラーは通常、負荷が容量を超えたときに発生します。
同時ユーザー
これは最も一般的な負荷の尺度であり、同時に存在するアクティブ ユーザーの数を表します。ペイロード サイズとも呼ばれます。
1秒あたりのリクエスト数
処理されたリクエストの数。
トランザクションの成功/失敗
成功または失敗したリクエストの合計数の尺度。
スループット
スループットは、キロバイト/秒で測定され、テスト中に使用された帯域幅の量を示します。
CPU使用率
CPU がリクエストを処理するのにかかる時間。
メモリ使用率
リクエストを処理するために必要なメモリの量。
4. パフォーマンス テストのベスト プラクティス
おそらく、パフォーマンス テストの最も重要なヒントは、早期にテストし、頻繁にテストすることです。1 回のテストでは、開発者が知る必要があるすべてのことがわかるわけではありません。パフォーマンス テストを成功させるには、一連の小規模なテストを繰り返す必要があります。
開発プロセスの早い段階でテストします。プロジェクトの最後にパフォーマンス テストを急いで実行しないでください。
パフォーマンス テストは、完成したプロジェクトだけを対象とするものではありません。個々のユニットまたはモジュールをテストすることには価値があります。
複数のパフォーマンス テストを実行して、一貫した結果を確認し、メトリクスの平均を決定します。
アプリケーションには、データベース、サーバー、サービスなどの複数のシステムが関与することがよくあります。ユニットを個別に、または一緒にテストします。
パフォーマンス テストは、反復的なテストに加えて、一連のパフォーマンス テストのベスト プラクティスに従うことで、より成功します。
開発者、IT スタッフ、テスターを巻き込んでパフォーマンス テスト環境を作成します。
実際の人々はパフォーマンス テストが行われているソフトウェアを使用することになることを忘れないでください。結果がテスト環境サーバーだけでなくユーザーにどのような影響を与えるかを判断します。
パフォーマンス テストのパラメータを超えてください。ユーザーのアクティビティを可能な限り考慮したテスト環境を計画してモデルを開発します。
ベースライン測定は、成功か失敗かを判断するための開始点となります。
パフォーマンス テストは、実稼働システムにできる限り近いテスト環境で行うのが最適です。
パフォーマンス テスト環境を、品質保証テストに使用される環境から分離します。
必要なことをすべて実行できるパフォーマンス テスト ツールはありません。リソースが限られていると、オプションがさらに制限される場合があります。適切なパフォーマンス テスト ツールを調査します。
テスト環境を可能な限り一貫した状態に保ちます。
平均を計算すると、実用的な指標が得られます。外れ値を追跡することにも価値があります。これらの極端な測定により、潜在的な障害が明らかになる可能性があります。
パフォーマンス テストの結果を共有するレポートを作成するときは、対象読者を考慮してください。また、システムおよびソフトウェアの変更もレポートに含めてください。
パフォーマンス テストでよくある 5 つの間違い
パフォーマンス テストの際、特定のエラーが信頼性の低い結果につながる可能性があります。
テストには時間が足りない。
開発者は関与していません。
本番システムと同様の QA システムは使用されていません。
ソフトウェアの調整が不十分です。
トラブルシューティング計画はありません。
パフォーマンス テストの誤謬
パフォーマンス テストのエラーは、エラーやパフォーマンス テストのベスト プラクティスに従わなかったことが原因で発生する可能性があります。Sofia Palamarchuk 氏によると、これらの信念はソフトウェアを開発する際に多額の費用とリソースがかかる可能性があります。
パフォーマンス テストは開発の最終ステップです。
「パフォーマンス テストのベスト プラクティス」セクションで説明したように、パフォーマンスの問題を予測して解決することは、ソフトウェア開発の初期段階で行う必要があります。ソリューションを早期に実装すると、ソフトウェア開発の最後に大規模な修正を行うよりもコストが低くなります。
ハードウェアを増やすと、パフォーマンスの問題を解決できる可能性があります。
プロセッサー、サーバー、メモリーを追加してもコストが増加するだけで、何も解決しません。より効率的なソフトウェアはより適切に実行され、ハードウェアの追加またはアップグレード時にも発生する可能性のある潜在的な問題を回避できます。
テスト環境は十分に近いです。
運用環境と同様のテスト環境でのパフォーマンス テストがパフォーマンス テストのベスト プラクティスであるのには理由があります。コンポーネント間の差異は、システムのパフォーマンスに大きな影響を与える可能性があります。パフォーマンス テストを正確な運用環境で実行することはできない場合がありますが、以下に一致するようにしてください。 ソフトウェア開発ライフ サイクル
ハードウェアコンポーネント
オペレーティング システムと設定
システムで使用されるその他のアプリケーション
データベース
現在機能しているものは完全に機能しています。
結果の外挿には注意してください。少数のパフォーマンス テスト結果を受け入れて、要素が変更されても同じであると想定しないでください。また、逆方向にも作用します。負荷テストに基づいて、最小のパフォーマンスと要件を推測しないでください。すべての仮定はパフォーマンス テストによって検証する必要があります。
パフォーマンス テスト シナリオは 1 つだけで十分です。
1 つのパフォーマンス テスト シナリオですべてのパフォーマンスの問題を検出できるわけではありません。ただし、リソースにより、実行できるテストの量は制限されます。中央には一連のパフォーマンス テストがあり、パフォーマンスに最も大きな影響を与える最もリスクの高いシナリオを対象としています。さらに、綿密に計画され、適切に設計されたパフォーマンス テスト以外で問題が発生する可能性があります。実稼働環境を監視すると、パフォーマンスの問題を検出することもできます。
各部分をテストすることは、システム全体をテストすることと同等です。
パフォーマンス テストのために機能を分離することは重要ですが、個々のコンポーネントのテスト結果はシステム全体の評価を構成しません。ただし、システムのすべての機能をテストするのは現実的ではない場合があります。パフォーマンス テストは、利用可能なリソースを使用して可能な限り完全になるように設計する必要があります。ただし、何がテストされていないのかに注意してください。
彼らにとってうまくいくものは、私たちにとってもうまくいきます。
特定のユーザー セットが複雑さやパフォーマンスの問題を経験した場合、それをすべてのユーザーに対するパフォーマンス テストとは考えないでください。パフォーマンス テストを使用して、プラットフォームと構成が期待どおりに動作することを確認します。
ソフトウェア開発者は経験豊富なので、パフォーマンス テストは必要ありません。
パフォーマンスの問題の原因は経験不足だけではありません。過去にフリーソフトウェアを作成した開発者でも間違いを犯します。特にシステム内に複数の同時ユーザーがいる場合、より多くの変数が影響します。
以下はサポート情報です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅にも同行してくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
