Loading article…
ストレス テストは、通常の動作の限界を超えてテストすることでソフトウェアの堅牢性を判断するソフトウェア テストアクティビティです。ストレス テストは、特に「ミッション クリティカル」なソフトウェアにとって重要ですが、すべての種類のソフトウェアに使用されます。ストレス テストでは、通常、通常の状況下での正しい動作よりも、高負荷時の堅牢性、可用性、エラー処理に重点が置かれるのが一般的です。
システム ストレス テストとは、通常の状況下での正しい動作ではなく、高負荷時の堅牢性、可用性、エラー処理に重点を置いたテストを指します。特に、このようなテストの目標は、計算リソース (メモリやディスク領域など) が不足している場合、同時実行性が異常に高い場合、またはサービス拒否攻撃が発生した場合にソフトウェアがクラッシュしないことを確認することです。
例:
- ウェブサーバーは、スクリプト、ボット、およびさまざまなサービス拒否ツールを使用してストレス テストされ、ピーク負荷時のウェブサイトのパフォーマンスを観察できます。これらの攻撃は通常、1 時間未満、またはウェブ サーバーが許容できるデータ量の限界が見つかるまで続きます。
ストレス テストは負荷テストと対比できます。
- 負荷テストでは、応答時間を測定しながら環境とデータベース全体を検査しますが、ストレス テストでは、特定されたトランザクションに焦点を当て、トランザクションまたはシステムが破損するレベルまで負荷をかけます。
- ストレス テスト中にトランザクションに選択的にストレスがかかると、データベースに大きな負荷がかからないものの、トランザクションに大きなストレスがかかる場合があります。一方、負荷テスト中は、データベースに大きな負荷がかかるものの、一部のトランザクションにはストレスがかからない場合があります。
- システム ストレス テスト (ストレス テストとも呼ばれます) では、同時ユーザーの負荷をシステムが処理できるレベルを超えて増加させ、システム全体の最も弱いリンクで障害を引き起こします。
現場経験
失敗は次のようなことに関連している可能性があります:
- 非本番環境の特性、例：小規模なテストデータベース
- 負荷テストやストレステストが全く行われていない
根拠
ストレステストを行う理由は次のとおりです。
- テスト対象のソフトウェアは「ミッションクリティカル」です。つまり、ソフトウェアの障害 (クラッシュなど)は悲惨な結果をもたらします。
- 従来のテスト方法では、テストに費やされる時間とリソースの量は、通常、ソフトウェアがリリースされたときに使用されるすべての状況をテストするには不十分です。
- テストを書くための十分な時間とリソースがあっても、ソフトウェアが使用されるさまざまな方法をすべて事前に決定することはできない場合があります。これは、テストの時点では存在しないソフトウェアによって最終的に使用されることになるオペレーティング システムとミドルウェアの場合に特に当てはまります。
- お客様は、テストに使用されるコンピューターよりも計算リソース (メモリやディスク容量など) が大幅に少ないコンピューターでソフトウェアを使用する場合があります。
- 入力データの整合性は保証できません。入力データはソフトウェア全体にわたります。データ ファイル、ストリーム、メモリ バッファー、コマンド ライン実行ファイルに渡される引数やオプション、GUI アプリケーションでアクションをトリガーするユーザー入力などです。ファジングやモンキー テスト手法を使用して、データの破損や不整合による問題を検出できます。
- 並行性は、従来のテスト方法では特にテストが困難です。競合状態やデッドロックを見つけるには、ストレス テストが必要になる場合があります。
- インターネット経由でアクセス可能なWeb サーバーなどのソフトウェアは、サービス拒否攻撃の対象となる可能性があります。
- 通常の条件下では、メモリ リークなどの特定の種類のバグは、テストが実行される短期間では比較的無害で検出が困難な場合があります。ただし、これらのバグは潜在的に深刻な場合があります。ある意味では、比較的短期間のストレス テストは、より長い期間の通常の操作をシミュレートするものと見なすことができます。
支店網羅性との関係
分岐カバレッジ(コード カバレッジの特定の種類) は、テストで実行された分岐の数のメトリックです。ここで、「100% の分岐カバレッジ」とは、プログラム内のすべての分岐が何らかのテストで少なくとも 1 回は実行されていることを意味します。分岐カバレッジは、ソフトウェア テストの最も重要なメトリックの 1 つです。分岐カバレッジが低いソフトウェアは、一般的に徹底的にテストされているとは見なされません。 [編集]コード カバレッジ メトリックは、ソフトウェアのテストの特性であり、テスト対象のソフトウェアの特性ではないことに注意してください。
高い分岐カバレッジを達成するには、意図された使用方法をテストする通常のポジティブテスト バリエーションに加えて、ネガティブテスト バリエーション、つまりソフトウェアが何らかの方法で失敗すると想定されるバリエーションを記述することがしばしば必要になります。ネガティブ バリエーションの例としては、不正なパラメータを持つ関数の呼び出しが挙げられます。ただし、ネガティブ バリエーションを使用しても達成できる分岐カバレッジには制限があり、一部の分岐はテストの制御が及ばないエラーの処理にのみ使用される場合があります。たとえば、テストでは通常、メモリ割り当てを制御できないため、「メモリ不足」エラーを処理する分岐はテストが困難です。
ストレス テストでは、特定のエラー処理分岐を実行する条件を生成することで、より高い分岐カバレッジを達成できます。フォールト インジェクションを使用すると、カバレッジをさらに向上できます。
例
負荷テストとストレステスト
ストレステストは通常、障害点を特定し、障害回復をテストするために指定された制限を超えるテストで構成されます。[1] [2]
負荷テストは、低負荷から高負荷へと変化する制御された環境を意味します。ストレステストは、よりランダムなイベント、混乱、予測不可能な状況に焦点を当てています。Webアプリケーションを例に挙げると、ストレスが発生する可能性がある方法は次のとおりです。[1]
- 同時ユーザー数/HTTP接続数のベースラインを2倍にする
- サーバーを接続するネットワーク スイッチ/ルーターのポートをランダムにシャットダウンして再起動する (たとえば、SNMP コマンド経由)
- データベースをオフラインにして再起動する
- システムの実行中にRAIDアレイを再構築する
- Web サーバーおよびデータベース サーバー上のリソース (CPU、メモリ、ディスク、ネットワーク) を消費するプロセスを実行する
- システムが障害にどのように反応し回復するかを観察する
- 状態は保存されますか?
- アプリケーションはハングしてフリーズしますか、それとも正常に失敗しますか?
- 再起動すると、最後の正常な状態から回復できますか?
- システムはユーザーとログに意味のあるエラー メッセージを出力しますか?
- 予期しない障害によりシステムのセキュリティが侵害されることはありませんか?
信頼性
Deng Fenglei、Wang Jian、Zhang Bin、Feng Chao、Jiang Zhiyuan、Su Yunfei によって開発された、メタデータ破損脆弱性の悪用可能性評価のためのパターンベースのソフトウェア テスト フレームワークでは、ソフトウェアの品質保証と保護への注目がどのように高まっているかについて説明しています。しかし、残念ながら、今日のソフトウェアは、特にヒープ メタデータの安全でない構成がある場合、サイバー攻撃から保護されていません。著者らは、ヒープ メタデータがサイバー攻撃者によって破損および悪用される可能性があるかどうかを調査することを目的としており、マシン レベルでメタデータ破損に対する人間の悪用行動をシミュレートするソフトウェア テスト フレームワークである RELAY を提案しています。RELAY は、消費されるリソースが少なく、エクスプロイト パターンに従ってレイアウトの問題を解決し、最終的なエクスプロイトを生成します。
学習オブジェクトの粒度を定義する方法論は、BENITTI, Fabiane Barreto Vavassori によって開発されました。著者はまず、近年の e ラーニング コミュニティにおける学習オブジェクトが主要な研究テーマの 1 つであること、粒度が学習オブジェクトの再利用の重要な要素である理由について説明します。次に、コンピューティング領域における学習オブジェクトの粒度を定義する方法論と、ソフトウェア テストのケース スタディを紹介します。その後、著者は 5 つの実験を実行して、作成された学習オブジェクトからの学習の可能性を評価し、学習オブジェクトの再利用の可能性を実証します。実験の結果も記事で紹介されており、学習オブジェクトによって概念の理解と応用が促進されることがわかります。
最近の記事「クラウド サービスに基づくソフトウェアの信頼性検証」は画期的な効果をもたらし、ソフトウェア業界がソフトウェアの各コンポーネントの信頼性を測定する方法を必要としていることを説明しています。この記事では、クラウド サービスに基づく保証検証方法が提案されています。この記事ではまず、各コンポーネントの信頼性がコンポーネント サービスの保証検証の観点から定義されるかどうかについて説明します。次に、記事で効果的なコンポーネント モデルが定義され、提案されたモデルに基づいて、コンポーネント サービスの検証プロセスがアプリケーション サンプルで説明されています。
参照
- ソフトウェアテスト
- この記事では、予期しない、またはまれな（ストレスのかかる）ワークロードでのソフトウェアの信頼性のテストについて説明します。関連記事もご覧ください。
- スケーラビリティテスト
- 負荷テスト
- 負荷テスト用のソフトウェア ツールの一覧 (負荷テスト#負荷テスト ツール)
- 一般的な議論のためのストレステスト
- ブラックボックステスト
- ソフトウェアパフォーマンステスト
- シナリオ分析
- シミュレーション
- ホワイトボックステスト
- Technischer Überwachungsverein (TÜV) - 製品のテストと認証
- CHESS モデルチェッカーを使用した並行性テスト
- Jinx (買収とプロジェクト中止のため廃止) は、起こりそうにない実行シナリオを自動的に探索することで、ストレス テストを自動化しました。
- ストレステスト（ハードウェア）