非破壊ソフトウェアテスト(NDT):その概要、テスト戦略
⚡ スマートサマリー
非破壊テストは、アプリケーションが有効な入力を受け取った際に正しく動作するかどうかを検証するものであり、そのためテスターはこれをポジティブパステストまたはハッピーパステストとも呼びます。これは、文書化された要件に対して期待される結果を確認するものです。

ソフトウェアの非破壊テストとは何ですか?
非破壊検査 これは、ソフトウェア アプリケーションのテストと適切な操作を伴うソフトウェア テスト タイプです。 つまり、非破壊ソフトウェア テスト (NDT) は、ポジティブ テストまたはハッピー パス テストとも呼ばれます。 期待どおりの結果が得られ、ソフトウェア アプリケーションが期待どおりに動作していることが証明されます。
この名称は工学分野から借用したもので、非破壊検査とは物理的な部品を損傷することなく検査する手法です。ソフトウェアにおいても同様の考え方で、アプリケーションは設計どおりに使用され、テストに合格すれば正常に動作するというものです。
例: ログインモジュールに正しいデータを入力し、認証情報が受け入れられるかどうかを確認し、次のページに移動する。
以下のスクリーンショットは、テスト実行前にユーザー名フィールドに有効な値が入力されたログインフォームを示しています。
上記の例に対して非破壊テストを実行するには、ログインフォームに有効なユーザー名とパスワードを入力します。入力内容が要件を満たしているため、期待される結果は肯定的となり、テスターはアプリケーションが次のページに進むことを確認するだけで済みます。
ソフトウェアの非破壊テスト (NDT) を行うのはなぜですか?
非破壊テストは、すべての関係者がビルドに関して最初に抱く疑問、つまり「その機能は実際に要求されたとおりに動作するのか?」という問いに答えるものです。チームが非破壊テストを実施する理由は以下のとおりです。
- NDT法の一番の利点は、メインフローで発見された欠陥を早期に修正できるため、ソフトウェアの品質が向上することです。
- ソフトウェア機能が仕様に従って動作していることを実証するため。
- 性能要件が満たされていることを確認するため。
- エンドユーザーの要求が満たされていることを確認するため。
- コードや機能のごく一部が期待どおりに動作しており、関連する機能を損なっていないことを確認するため。
- 法廷で提示できる証拠を作成する ユーザー受け入れテスト 顧客が故障モードではなく、意図した動作を確認したいと考える段階、つまり承認段階。
非破壊検査 (NDT) はいつ実行されますか?
ここでは、ほとんどの手法よりもタイミングが重要になります。なぜなら、正常系処理がその後のすべての処理を左右するからです。
- これは、テスターがアプリケーションに対して行う最初のテスト形式であり、つまり、 SDLC.
- 非破壊検査は、完全な検査サイクルを行うのに十分な時間がない場合によく行われます。なぜなら、非破壊検査でも合格基準が満たされていることを証明できるからです。
- これは、悪影響や破壊的なシナリオが発生する前に実行されます。メインフローが破損した場合、エラー処理テストは実際の欠陥ではなく、ノイズを報告します。
- これは、欠陥修正のたびに繰り返され、そこで重複する 回帰試験.
非破壊検査のための検査戦略
非破壊検査の戦略は意図的にシンプルに設計されており、重要なのはツールではなく、常に前向きな姿勢を保つことである。
- 非破壊検査へのアプローチは、肯定的なものであるべきだ。
- NDT技術の目的は、有効な入力データが与えられた場合にアプリケーションが正しく動作することを証明することである。
- 非破壊検査を実施するのに、特別な要件や環境は必要ありません。
- 非破壊検査における最良の方法は、システムが本来の機能を正しく実行しているかどうかを確認することです。
以下の図は、その戦略がテストサイクル全体を通して通常どのように構成されるかをまとめたものです。
非破壊(ポジティブ)テストケースの書き方
非破壊テストケースは、入力が証明可能な妥当性を持ち、期待される結果がテスターの仮定ではなく要件から得られる場合にのみ有用です。以下の手順は、そのような種類のテストケースを生成します。 テストケース.
ステップ1)受け入れ基準を1つ選択します。 要件を読み、それを検証可能な単一の記述として書き直してください。例えば、「ユーザー名フィールドには、6文字から20文字の英数字を入力できます」のように。
ステップ2)有効な入力データを選択します。 許容範囲内に収まる値を選択してください。 等価分割 ここでは、有効なパーティションごとに代表値が1つあれば通常は十分です。
ステップ3)実行前に期待される結果を記述する。 期待される結果は仕様に基づいて記述する必要があります。実行後に記述すると、テストはビルドがたまたま行ったことを記述するだけのものになってしまいます。
ステップ4)手順をユーザーの順序で維持する。 この手順は、実際のユーザーがタスクを完了する手順と一致させるべきである。なぜなら、この手法の目的は、意図された手順を確認することにあるからだ。
ステップ5)要件識別子を記録します。 Tracケースをその基準に戻すことで、チームは審査中に補償範囲を証明できるようになります。
ログインモジュールの具体的な使用例は以下のとおりです。
| フィールド | 非破壊検査の事例 |
|---|---|
| 要件 | ユーザー名には6~20文字の英数字を入力できます。 |
| テストデータ | guru99tester有効なパスワードが一致します |
| ステップ | ログインページを開き、認証情報を入力して、「ログイン」を選択します。 |
| 期待される結果 | 認証情報が受け入れられ、ホームページが表示されます。 |
| タイプ | ポジティブ/ハッピーな道 |
ケース内でフィールドを破壊しようとするものは何もないことに注目してください。エラーメッセージを見るために 5 文字を入力するケースは 陰性検査非破壊的な方法ではない。
非破壊検査の例
以下の例は、欠陥が修正された後、複数のモジュールからなるアプリケーション全体で非破壊検査がどのように動作するかを示しています。
- アプリケーションは、ログインページ、ホームページ、ユーザー詳細ページ、新規ユーザー作成、タスク作成の5つのモジュールで構成されています。
- ログインページにバグがあるとします。ユーザー名欄に6文字未満の英数字しか入力できないというバグです。これは、ユーザー名は6文字未満であってはならないという設定要件に反するため、不具合となります。
- バグは通常の方法で開発チームに報告されます 欠陥管理プロセス修正が完了すると、ビルドはテストチームに送り返されます。
- テストチームは、不具合が修正されたログインページだけでなく、他のモジュールもテストします。有効なデータを使用してすべてのモジュールをテストする際には、アプリケーション全体が正常に動作していることを確認するため、非破壊テストを実施します。
非破壊検査と破壊検査
この2つの技術は、同じ構造に関する正反対の疑問に答えるため、しばしば一緒に教えられる。 破壊試験 ソフトウェアが限界に達するポイントを探し出す一方、非破壊検査は意図した動作が維持されていることを確認する。
| 側面 | 非破壊検査 | 破壊試験 |
|---|---|---|
| 意図 | アプリケーションを正しく操作し、良好な結果を確認してください。 | 異常または無効な入力を与えて、障害箇所を特定する |
| 入力データ | 要件から抽出された有効なデータ | 無効、破損、または順序がずれたデータ |
| 必要な要件 | はい、ケースは受入基準に基づいて作成されます。 | 必ずしもそうとは限りません。テスターはユーザーストーリーに偏ることなく作業します。 |
| それが明らかにするもの | 仕様に対する機能上の弱点 | 設計、堅牢性、および復旧性における弱点 |
| 関連技術 | スモークテスト, 機能テスト | 猿を使った実験, 探索的テスト |
この2つは代替手段ではなく、補完的な関係にある。非破壊検査だけではエラー処理の検証ができず、破壊検査だけでは製品が正しく機能していることを証明できない。
非破壊ソフトウェアテストの利点と限界
その技術がどこまで有効でなくなるのかを知ることは、その技術が何をカバーしているのかを知ることと同じくらい重要です。
優位性
- テストデータは仕様書から直接得られるため、設計と実行が迅速に行えます。
- 特別な環境、障害注入、または破損したデータセットは必要ありません。
- 要件と1対1で対応した証拠を生成するため、監査や承認手続きに適しています。
- 同じように機能します 手動テスト そして台本通りに 自動化テストそのため、同じケースを回帰テストスイート内で再利用できます。
- ユニットからあらゆるレベルでの建物の健全性について早期かつ正直なシグナルを発します。 統合テスト 〜へ システムテスト.
製品制限
- 完全合格は、アプリケーションが無効な入力に対してどのように動作するかについては何も示さないため、深刻なエラー処理の欠陥があっても合格しない可能性がある。
- 対象範囲は要件の品質によって制限されます。規定されていない事項は一切テストされません。
- リリース前にハッピーパスだけを実行すると、誤った自信を生み出す可能性がある。
- これは、堅牢性、回復力、またはストレス下でのパフォーマンスを測定するものではなく、これらはより広範な手法から独自の技術を必要とします。 ソフトウェアテストの種類.
非破壊検査を他のすべての技術の基礎となるベースラインとして扱い、より広範な計画の中に組み込む。 ソフトウェアテストのライフサイクル 単発的な活動としてではなく。


