ソフトウェアにおける破壊的テストとは何ですか?

⚡ スマートサマリー

破壊的テストは、ソフトウェアアプリケーションを意図的に限界まで追い込み、故障させることで、通常の機能チェックでは決して検出できない、不適切な使用、無効な入力、予測不可能な動作によって堅牢性が損なわれる正確な箇所を明らかにする。

  • 💥 核となるアイデア: このアプリケーションは、意図的に失敗するように設計されているため、その失敗箇所が明確になり、測定可能になる。
  • 🔎 必要な条件はありません。 仕様に関する事前知識は必須ではないが、あればテスト戦略をより的確に立てることができる。
  • <XNUMXxEXNUMX><XNUMXxEXNUMX><XNUMXxXNUMXA><XNUMXxXNUMX><XNUMXxXNUMXA>️️ 反対のペア: 非破壊検査は順調な道を進むが、破壊検査はあらゆる間違った角度からその道を攻撃する。
  • 🧰 アプローチ: 障害点分析、テスターに​​よるピアレビュー、ビジネスレビュー、および実行シートを用いた探索的テスト。
  • 🧪 再利用されたメソッド: 回帰テスト、インターフェーステスト、同値分割テスト、ループテスト、受け入れテストはすべて破壊的な目的のために用いられる。
  • 📉 正直な限界: 調査範囲を保証するのは難しく、労力も大きく、結果の再現も困難な場合がある。

ソフトウェアにおける破壊的テストとは何か、その方法と技術について

破壊検査とは何ですか?

破壊試験 破壊的テストは、ソフトウェアプログラムの障害箇所を見つけるために使用されるソフトウェアテスト手法です。この手法では、アプリケーションを意図的に障害状態にすることで、その堅牢性を確認し、障害箇所を特定します。アプリケーションが本来行うべき動作を検証するテスト手法とは異なり、破壊的テストはアプリケーション内部における予測不可能なユーザー動作を検証します。

破壊試験には、元の要件に関する知識は必須ではありません。ただし、開発においては、ある程度の知識があると役立ちます。ping 優れたテスト戦略。

下の図は、その考え方を的確に表している。つまり、テスターは製品と協力するのではなく、製品に対抗する形でテストを行うということだ。

破壊的テストの概念:アプリケーションを意図的に故障する寸前まで追い込むこと

なぜ破壊試験を行うのか?

  • これは、ソフトウェアが不適切な使用状況に置かれた場合に、予測可能なソフトウェアの動作を理解するのに役立ちます。
  • ソフトウェア製品の堅牢性をチェックするのに役立ちます。
  • これは、一般ユーザーが決して引き起こさないものの、製造過程で後から現れる稀な欠陥を明らかにする。

破壊試験と非破壊試験

この2つのアプローチは、競合するものではなく、互いに補完し合うものである。 X線非破壊検査装置 (ポジティブテストまたはハッピーパステストとも呼ばれる)は、ソフトウェアと正しくやり取りし、ビルドをそのまま維持します。破壊的テストはその逆で、何らかの不具合が発生するまで、無効なデータや誤ったシーケンスを投入します。

側面 破壊試験 X線非破壊検査装置
意図 アプリケーションを強制的に失敗させる アプリケーションが仕様どおりに動作することを確認してください。
入力が使用されました 無効、形式が不正、範囲外、順序が間違っています 期待される範囲内の有効なデータ
質問への回答 どこで、どのように壊れるのか? それは本来の役割を果たしているか?
要件に関する知識 オプション 不可欠
標準的な費用 より高度な — 探求的で自由な発想 下位レベル - スクリプト化され、繰り返し実行可能
結果 故障箇所、範囲制限、復旧動作 仕様に合否判定される

破壊試験では何を検査しますか?

破壊テストでは、動作境界の両側を調べます。

  • 適切なソフトウェア動作
  • 不適切なソフトウェア動作
  • 不適切な使用法
  • 不適切な入力データ
  • 適切な出力データ

演習全体を通して、以下の2つの条件が満たされなければならない。

  • 本ソフトウェアは、無効な入力データを処理または受け入れてはならない。
  • 入力データの妥当性や正確性に関わらず、ソフトウェアは常に適切な出力データを生成するべきである。

破壊試験はどのように行うのですか?

破壊テストには、テストスクリプトの設計、それらのスクリプトの実行、バグの報告、バグの解決、そしてイテレーションの最後にステークホルダーに合否判定結果を提供するなど、多くの活動が含まれます。

実行方法は数多くあります。以下にいくつかの例を示します。

  • 故障箇所分析方法: さまざまなポイントで何が問題になる可能性があるかを評価するシステムのウォークスルー。 ビジネスアナリスト この戦略では、以下のことが想定される。
  • テスターに​​よるピアレビュー: あなたの テストケース システムや機能にあまり詳しくない同僚のテスターに​​よって分析またはレビューされる。
  • テストケースのビジネスレビュー: エンドユーザーや専門家は、テスターが見落としてしまうような有効なシナリオを思いつくことが多い。なぜなら、テスターは明示された要件にばかり焦点を当てているからだ。
  • 実行シートを使用して探索的テストを実施する: 探索的テスト ランシートにはテスト内容が記録され、テストの繰り返しが可能になり、テストの網羅性を管理しやすくなります。
  • 別の情報源を使用する: 他の人にソフトウェア製品を分解してもらい、発見されたシナリオを分析してもらう。

破壊試験の例

銀行アプリのログイン画面とプロフィール画面を考えてみましょう。破壊的な攻撃は、次のようなケースで効果を発揮します。

  • 50文字に制限された入力欄に5,000文字の文字列を貼り付け、入力欄が文字列を切り捨てるのではなく、拒否することを確認してください。
  • 数値入力欄には、文字、記号、負の値を入力してください。
  • 想定される手順を破り、前の手順を完了せずに直接支払い確認ページを開く。
  • 重複レコードが作成されるかどうかを確認するために、送信ボタンを繰り返し、かつ短時間で連続して押してください。
  • トランザクションの途中でネットワーク接続を切断し、アプリケーションが正常に復旧するか、部分的な記録が残るかを確認します。

それぞれのケースには明確な期待値があります。それは、明確な検証メッセージが表示され、データが破損しておらず、未処理の例外が発生していないことです。これら以外の場合は、不具合として報告するべき問題です。

破壊的試験方法

ソフトウェアエンジニアリングにおいて、破壊的テストの目的を達成するために、以下の手法が用いられます。

破壊的試験技術

以下の手法は、多少の変更を加えて使用できます。

堅牢性を目標とする場合に追加すべき関連技術は以下のとおりです。 ネガティブテスト, ストレス試験, 回復テスト (NAIST) と ファズテスト.

破壊試験の利点と欠点

その技術をリリースに組み込む前に、トレードオフについて明確に述べておく価値がある。

優位性

  • Rev仕様主導型テストでは決して到達できない、欠陥箇所を解消します。
  • 実際の動作範囲を明確に設定することで、製品をその範囲内で安心して使用できるようになります。
  • 発売からかなり時間が経ってから製造過程で明らかになる、稀な欠陥を明らかにする。
  • 過酷な使用状況下における耐久性、復旧性、およびエラー処理能力を検証します。

デメリット

  • 本質的に無制限であるため、カバー範囲を保証したり、容易に測定したりすることはできません。
  • 時間がかかり、テスターの経験と創造性に左右される。
  • 使用した手順を注意深く記録しておかないと、結果を再現することは難しい。
  • 管理が不十分な実行は共有テストデータを破損させる可能性があるため、隔離された環境が必要です。

よくあるご質問

両者は重なり合う部分もあるが、その範囲は異なる。 陰性検査 定義済みの無効な入力を、想定されるエラー処理と照合します。破壊的テストはより広範囲かつ無差別であり、アプリケーションが失敗するあらゆる条件を探し出します。

通常は経験豊富なQAエンジニアが中心となり、モジュールに不慣れな同僚やビジネスユーザーのサポートを受けながらテストを行います。外部の視点が重要なのは、機能を開発した担当者は設計どおりにテストを行う傾向があるためです。

機能スイートが安定したら、障害は未完成の機能ではなく堅牢性を示すものとなる。多くのチームはシステムテスト中にこれをスケジュールし、メジャーリリース前に繰り返す。 テストライフサイクル.

モデルは、テスターでは到底対応できない量の不正なペイロード、境界値、異常な動作シーケンスを生成し、どの異常が発生したかをランク付けします。過去の欠陥データに対する機械学習は、どのモジュールが最も厳しい処理を受けるべきかを予測します。

GitHubコパイロット 入力ジェネレータ、境界条件、およびティアダウンルーチンを迅速に作成します。どの障害モードが重要か、また観測された動作が許容可能な結果とみなせるかどうかは、依然としてテスターが判断します。

使用された正確な入力またはシーケンス、観測された障害、ログとスクリーンショット、環境、および影響の深刻度。イテレーションの合否メトリクスは、関係者に提供されます。 欠陥記録.

決して本番環境には使用しないでください。復元可能なデータを持つ隔離された環境で実行してください。意図的に無効な入力や強制的なクラッシュが発生すると、修復にコストのかかる不完全な記録が残ってしまう可能性があるためです。

セッション中は、すべての操作と入力内容を順番に記録した実行シートを作成してください。シートをクリーンな状態から再生し、それでもなお不具合が発生する最短のシーケンスに絞り込んでください。