ソフトウェアテストにおける安定性テスト

安定性テストとは何ですか?

安定性試験 ソフトウェア アプリケーションが長期間継続して機能する効率と能力を測定するために実行される非機能ソフトウェア テストの一種です。 安定性テストの目的は、ソフトウェア アプリケーションがクラッシュするか、通常の使用時にフェイルオーバーするかどうかを、その使用範囲全体を実行して、いつでも確認することです。

安定性テストは、開発された製品の通常の動作能力を超えた効率性をチェックするために行われます。多くの場合、ブレークポイントまで行われます。通常の状況下でのシステムの動作をチェックするよりも、高負荷下での製品のエラー処理、ソフトウェアの信頼性、堅牢性、スケーラビリティの方が重要です。

安定性テストは、安定性の問題を評価します。このテストは主に、ソフトウェア コンポーネントに最大限のストレスをかけることを目的としています。これは非機能的手法です。

安定性テストは、負荷または 耐久試験.

テスト対象のシステムが安定性テストを受けていない場合のリスク

多数のユーザーが導入されるテスト対象のアプリケーションや、再起動せずに数か月間実行する必要があるアプリケーションの場合、次のような多くの問題が発生する可能性があります。

起こり得るエラーに直面する可能性がありますが、

• システムが遅くなる
• システムに機能上の問題が発生しました
• システムは有線動作を示します
• システムが完全にクラッシュする

ソフトウェアエンジニアリングでは、 安定性試験 通常、ヘビー ユーザー (仮想) でシステムを実行し、パフォーマンス パラメーターを測定して、システムが予想される負荷をサポートできるかどうかを確認します。

安定性テストを行う理由

この種のテストは、ユーザーが実際の状況でシステムがどのように動作するかを理解するのに役立ちます。

したがって、安定性テストでは次のことを確認できます。

• テスト対象のシステムの安定性に自信を与えます。
• システムが大規模なプログラムを処理できることを確認してください。
• システムの有効性を監視します。
• ストレス下でのシステムの安定性をテストします。

これは、リリース前にテスト対象のソフトウェア製品の限界を判断したり、製品が実際に稼働する前または本番環境に移行する前にさらに改善すべき領域を判断したりするために使用されるため、製品開発において重要な役割を果たします。

安定性テスト手法の非常に一般的な例は次のとおりです。

Online Sホップping Portals: 安定性テストは、Web サイトがどのように動作するかをチェックします –

• ピーク時に大量のデータが入力される
• 特定の時間におけるヒット数
• 同時にページ読み込みの問題も発生
• システムの動作
• システムの応答性やその他多くのことが当てはまります 安定性試験

もう一つの例

A CPU テストは安定性テストの一般的な形式です。 性能試験 技術。 このテストでは、プロセッサの安定性をチェックし、プロセッサのワークロードが増加したときのパフォーマンスも監視します。

安定性テストの方法

• テストの範囲と目的を決定するには、ロード テストの実行中にアプリケーション サーバーがクラッシュしないことを確認する必要があります。
• ビジネス上の問題を特定するには、エンド ユーザーの観点からシステムのパフォーマンスと負荷を確認します。
• テスト計画の作成など、さまざまな責任と役割を割り当てるには、 テストケース 設計、テストケースレビュー、テスト実行など
• 指定された時間内にテスト成果物を確実に提供するため
• 適正を確保するために 負荷テスト ツールと経験のチームも同様に存在します。
• リスクとコストを測定するにはテストが必要です。 これにより、CPU 使用率とメモリの観点から各実行のコストが決まります。
• を決定する 欠陥 trac王と報告と適切な地図ping 要件を満たしています。

CPU パフォーマンスの安定性テストのテスト ケース

• システムの上限を確認します。
• システムがクラッシュまたは回復する方法。
• リクエストごとに完了したトランザクションの合計数。
• トランザクションの応答が安定しているか、時間の経過とともに増加するか。
• 高負荷時にシステムがどのように動作するか。
• 高負荷時の応答と動作。

安定性試験の試験報告書

テスト実行中にいくつかの統計が収集され、測定されます。これらの数値はレポートを生成し、パフォーマンスの問題の可能性を特定するために分析されます。

テストで収集される統計の例は次のとおりです。

• トランザクションの応答時間: テスト中のトランザクションの実行にかかる平均時間です。 この統計は、サーバーのパフォーマンスが、システムに定義されている許容可能な最小および最大トランザクション パフォーマンス期間内にあるかどうかを評価します。この情報は、Web サーバーによるリクエストの処理とアプリケーション サーバーへの送信にかかる時間を評価します。ほとんどの場合、データベース サーバーにリクエストが行われます。
• XNUMX 秒あたりのヒット数: ユーザーがサーバー上で行ったヒット数。 これらの統計は、ヒット数に関してユーザーが生成する負荷の数を判断するのに役立ちます。
• スループット： テスト中の Web サーバーのスループット量 (バイト単位で測定)。 スループットとは、ユーザーが一定の時点でサーバーから受信したデータの量を意味します。 この統計は、ユーザーが生成する負荷の量を評価するのに役立ちます。
• XNUMX 秒あたりのトランザクション: これらは、テスト中に実行された完了したトランザクション (成功と失敗の両方) の合計数です。 この統計は、システム上の実際のトランザクション負荷を確認するのに役立ちます。
• CPU： テスト中に費やされた CPU 使用率。
• メモリ： テスト中のメモリ使用量。
• ディスク： テスト中に消費されたディスク領域の使用率。

安定性試験の基礎

安定性試験 パフォーマンス テストは、安定性、信頼性、可用性などのソフトウェアの品質特性の一部をチェックするために実行される手法です。

このテストは、特定のワークロード下でシステムまたはサブシステムがどれだけ速く実行されるかを判断するために使用されます。

パフォーマンス テストにはさまざまな種類があり、安定性テストもその XNUMX つです。

• ストレステスト: システムの能力を超えたシステムの堅牢性をチェックするテストタイプです。
• スパイクテスト: システムの負荷を瞬時に上げて、システムの動作を確認するために使用されます。 目的は、どの時点でシステムにパフォーマンスの問題が発生するか、または問題が解決するかを確認することです。
• スケーラビリティテスト: これは、システムの機能をチェックするために使用されます。システムが、増大するニーズ、サイズの変化、ボリュームの変化に対してどの程度効果的に動作するかを確認します。
• ボリュームテスト： これは、テスト対象のソフトウェアが大量のデータにさらされ、それに応じてシステムの動作がチェックおよび検証される非機能テスト手法です。
• 負荷または安定性のテスト: (すでに上で説明しました)

安定性試験ツール

パフォーマンス テスト用のツールには次のようなものがあります。

• ウェブロード
• LoadRunner
• アパッチ JMeter
• Neo負荷
• クラウドテスト
• ロードストーム
• ロードUI
• ワプト
• 負荷影響
• ロードスター
• Httpperf
• OpenSTA

このテストがパフォーマンス テスト ファミリーにどのように適合するか

性能テストは包括的な用語です。以下のバリエーションは、加える負荷の形状と負荷を維持する時間のみが異なるため、しばしば混同されます。

テストタイプ	負荷パターン	質問に答える
負荷テスト	予想されるピーク負荷、短時間	通常のピーク時トラフィックにおいて、システムは目標を達成しているか？
ストレステスト	容量を超えて増加し、最終的に故障する	どこで壊れるのか、そして、それは優雅に失敗するのか？
スパイクテスト	急激な上昇、その後の下落	交通渋滞による衝撃から生き残り、回復できるだろうか？
耐久試験	通常の負荷を何時間も保持	時間の経過とともに性能は低下しますか？
浸漬試験	長期間にわたる持続的な負荷	メモリリークやリソース枯渇は発生していますか？
安定性テスト	様々な条件下での負荷の変化	状況が変化しても、システムは信頼性を維持できるのか？
ボリュームテスト	一般ユーザー、データ量が非常に多い	データベースの規模が拡大しても対応できますか？

耐久試験と浸漬試験は、しばしば同義語として扱われる。 一般的には、どちらも長時間にわたって負荷を持続させるテストです。しかし、チームによっては両者を区別する場合、耐久テストは応答時間が上昇するかどうかに焦点を当て、負荷テストはメモリ、ファイルハンドル、接続プールなどのリソース消費に焦点を当てます。通常、どちらか一方を実行すれば、両方のテスト結果を得ることができます。

テスト中に取得すべき主要指標

パフォーマンステストの精度は、実行中に記録した内容によって決まります。サーバー側とクライアント側の両方で以下の6つの項目を記録し、直感ではなく基準値と比較してください。

メトリック	それが何を意味するか	警告サイン
平均応答時間	典型的なユーザー体験	ランニングコース全体にわたる上昇傾向
95パーセンタイル応答時間	最も動作の遅いユーザーの体験	平均をはるかに上回る、つまり一貫性がない
スループット	1秒あたりに処理されるリクエスト数	荷重が一定の状態で落下する
エラー率	失敗またはタイムアウトしたリクエストの割合	合意されたしきい値を超える上昇
CPUとメモリの使用状況	サーバーリソースの余裕	記憶は上昇し、二度と戻ってこない
データベース接続とスレッド	プールでの疲労	リリースなしで着実に増加する数

平均値とパーセンタイル値を一緒に読み取ってください。 平均応答時間が800ミリ秒で、95パーセンタイル値が900ミリ秒であれば、システムは安定していると言えます。一方、同じ平均応答時間でも95パーセンタイル値が9秒であれば、20人に1人のユーザーが応答に問題を抱えていることを意味し、平均値ではその問題が隠蔽されていることになります。

値だけでなく、形状にも注目してください。 長時間のテストでは、リソースのグラフが横ばいであれば合格、上昇していれば漏洩と判断されます。たとえテスト終了時点で絶対値が許容範囲内に収まっていても、この判断は変わりません。

よくあるご質問