ソフトウェアテストを導入するにあたり、まず「バグ」と「欠陥」の概念を明確にする必要があります。IEEEの定義によると、「バグ」は主にソフトウェア開発プロセスに対するものであり、「欠陥」は主にソフトウェア製品に対するものです。
ソフトウェア開発プロセスにおいてソフトウェア開発者が犯したエラーは、ソフトウェア製品の欠陥の原因であり、その逆もまた然りです。「エラーはエラーの結果であり、現れです。
ソフトウェア・テストの目的は、ソフトウェアが生産的な運用に入る前に、ソフトウェア製品のエラーを できるだけ多く発見することです。ソフトウェアのエラーを発見するためには、エラーを明らかにするようなテストケースを設計するよう、あらゆる努力を払わなければなりません。
テストケースは、テストデータと期待される結果から構成されます。良いテストケースとは、これまでに見つかっていないエラーを高い確率で発見できるものです。成功するテストとは、これまで発見されなかったエラーを発見するものです。
効率的なテストとは、少ないテストケースで、テスト対象のソフトウェアのバグをできるだけ多く見つけることです。ソフトウェアテストの目標は、できるだけ少ない時間と労力で、ソフトウェア製品のバグをできるだけ多く見つけることです。
ソフトウェアテストの段階
テスト・フェーズの観点から、ソフトウェア・テストは通常、ユニット・テスト、統合テスト、システム・テストに分けられます。
単体テスト
単体テストはモジュールテストとも呼ばれ、通常プログラミングのフェーズに位置づけられます。プログラマは自分で書いたモジュールをテストし、モジュールが詳細設計仕様で指定された機能やアルゴリズムを実装しているかどうかをチェックします。
単体テストは、プログラミングと詳細設計で発生したエラーを発見することに重点を置いており、単体テスト計画は詳細設計の段階で作成する必要があります。
単体テストでは、モジュールのインターフェース、ローカルデータ構造、重要な実行パス、エラー処理パス、境界条件などがテストされます。
モジュールをテストするには、ドライバー・モジュールと、そのモジュール用のいくつかのステーキング・モジュールを書く必要があります。
- ドライバ・モジュールは、テスト対象のモジュールを呼び出すために使用され、テスターからテスト・データを受け取り、そのデータをテスト対象のモジュールに送信し、テスト対象のモジュールからテスト結果を受け取り、何らかの目に見える方法でテスターに返します。
- パイル・モジュールは、テスト対象のモジュールから呼び出されるサブモジュールをシミュレートするために使用され、テスト対象のモジュールからの呼び出しを受け入れ、呼び出しパラメータを検証し、可能な限り単純な操作で呼び出されたサブプログラム・モジュールの機能をシミュレートし、テスト対象のモジュールに結果を返します。
ドライバモジュールはトップレベルのモジュールテストには必要ありませんし、ステーキングモジュールはボトムレベルのモジュールテストには必要ありません。モジュールの結合度が高ければ、単体テストのプロセスを単純化することができます。各モジュールが 1 つの機能だけを実行するのであれば、必要なテストシナリオの数は大幅に減ります。
統合試験
アセンブリテストとも呼ばれる統合テストは、モジュールから組み立てられたプログラムのテストであり、モジュール間のインターフェースや通信の問題を特定することを主な目的としています。例えば、インターフェイスを越えてデータが失われたり、あるモジュールが過失によって他のモジュールに悪影響を及ぼしたり、サブ機能が意図したメイン機能にならないような形で組み合わされたり、許容できるように見える個々のエラーが許容できないレベルまで蓄積されたり、全体を通してデータ構造に問題があったりします。
統合テストは、設計段階で発生したエラーを発見することに重点を置いており、統合テスト計画は概要設計段階で策定する必要があります。
統合の方法は、非インクリメンタルとインクリメンタルに分類することができます。
- 非インクリメンタルインテグレーションとは、まずすべてのモジュールをテストし、次にこれらすべてのモジュー ルを一度に統合し、巨大なプログラム全体をテストすることです。このテスト方法の出発点は「ワンステップ」で済むことですが、テスターは大量のエラーに直面し、どれが「本当の」エラーで、どれが他のエラーによる「偽のエラー」なのかを区別するのはしばしば困難です。「また、エラーの診断、特定、修正も非常に困難です。非インクリメンタルな統合は、非常に小さなソフトウェアにしか適していません。
- インクリメンタルインテグレーションとは、単体テストと結合テストを組み合わせたもので、モジュール構造図に基づき、ある順序で、まだテストされていないモジュールを選択し、テスト済みのモジュールと組み合わせてテストを行い、その都度モジュールを追加していき、すべてのモジュールがプログラムに統合されるまでテストを行います。このテスト方法は、エラーの発見と修正が容易であり、インクリメンタルインテグレーションは、現在、統合テストで一般的に使用されています。
インクリメンタルインテグレーションは、さらにトップダウンインテグレーションとボトムアップインテグレーションに分類することができます。トップダウン統合は、まず上位モジュールをテストし、次に下位モジュールをテストします。下位モジュールは上位モジュールがテストされるときにテストされるので、別途ドライバモジュールを書く必要はありません。ボトムアップ・インテグレーションは、まず下位モジュールをテストし、次に上位モジュールをテストします。この場合も、下位モジュールがテストされるときに上位モジュールもテストされるので、別途ステーキング・モジュールを書く必要はありません。
これらの2つの統合方法は、それぞれの長所と短所を持って、一方の方法の利点は、他の方法の短所に対応し、実際のテストは、ソフトウェアの特性に応じて柔軟に対応することができ、最も適切な方法をスケジューリングし、また、2つの方法の混合物を使用することができます。
システムテスト
システムテストは、単体テストと結合テストを基礎として実施されるソフトウェアテストの最終的かつ最も完全なテストであり、ソフトウェアシステムの機能要件と性能要件をグローバルな視点から検討します。システムテストの計画は、要求分析の段階で策定する必要があります。
通常、システムテストには確認テストと受け入れテストが含まれます。
- 確認テストは、主にソフトウェア要求仕様書に基づいて、ソフトウェアの機能、性能、およびその他の機能がユーザーのニーズと一致しているかどうかをチェックします。ソフトウェア構成のレビューも確認テストの重要な要素です。レビューの目的は、ソフトウェア構成のすべてのコンポーネントが完了していることを確認することであり、要件、文書および手順の品質は、必要な詳細のソフトウェアのメンテナンスの完了と完全に一致しています。
- 受入テストは、ソフトウェアが顧客向けにカスタマイズされている場合、その要件がすべて満たされていることを確認するために顧客によって実施されます。ソフトウェアシステムは複雑であるため、受け入れテストは、ソフトウェアがユーザーによって実際に使用された後も、長期間にわたって継続されることがあります。ソフトウェアが製品として多くの顧客に使用される場合、各顧客が受入テストを実施することは不可能であり、また必要でもありません。
ソフトウェア開発者の大半は、一見エンドユーザーにしか見つけられないようなバグを見つけるために、テストやテストと呼ばれるプロセスを使っています。
- アルファテストは、開発者の敷地内で、開発者の指導のもと、ユーザーによって実施されます。開発者は、発見されたバグや使用中に発生した問題を記録する責任があります。言い換えれば、テストは「管理された」環境で行われます。
- ベータテストは、ソフトウェアのエンドユーザーによって、1人または複数のユーザーの現場で実施されます。通常、開発者は不在で、バグや発生した問題を文書化し、開発者に報告する責任を負います。言い換えれば、テストは「管理されていない」環境で行われます。体系的なテストの後、ソフトウェアは通常、納品可能な状態になります。
ホワイトボックステストとブラックボックステスト
テスト手法の観点から、ソフトウェアテストはホワイトボックステストとブラックボックステストに分類することができます。
ホワイトボックステスト
ホワイトボックステストは、構造テストとも呼ばれ、主に単体テストフェーズで使用されます。これは、プログラムが透明なホワイトボックスの中にあるかのように見ることができ、テスト者はプログラムの構造と処理アルゴリズムを完全に理解しているという前提に基づいています。この方法では、プログラムの内部ロジックに従ってテストケースを設計し、プログラムの主要な実行パスがすべて意図したとおりに動作するかどうかをチェックします。
ホワイトボックステストは、ソフトウェアの内部ロジックに基づいてテストケースを設計します。一般的に使用される手法は論理カバレッジで、テスト対象のプログラムをテストデータで実行したときのプログラムロジックのカバレッジの程度を調べます。主なカバレッジ基準には、ステートメントカバレッジ、デシジョンカバレッジ、条件付きカバレッジ、デシジョン/条件付きカバレッジ、複合条件付きカバレッジ、パスカバレッジの 6 つがあります。
文のオーバーライド
ステートメントカバレッジとは、テスト対象のプログラムの各ステートメントが、テストケースの実行時に少なくとも一度は実行されるように、十分なテストケースを選択することを意味します。
明らかに、ステートメント・カバレッジは非常に弱いカバレッジ基準です。
管轄権オーバーライド
判定カバレッジは分岐カバレッジとも呼ばれ、各ステートメントが少なくとも1回実行されるだけでなく、各判定の結果の可能性が少なくとも1回実行されることを意味します。判定カバレッジはステートメントカバレッジよりも強力ですが、それでもプログラムロジックのカバレッジには及びません。
条件付き補償
条件付きカバレッジとは、各ステートメントを少なくとも1回実行するだけでなく、判定式の各条件をさまざまな可能性のある結果にすることです。
条件付補償は必ずしも判断補償を含まず、判断補償は必ずしも条件付補償を含みません。
ジャッジメント／コンディショナル・オーバーライド
判定カバレッジと条件カバレッジの両方を満たす論理カバレッジを、判定/条件カバレッジと呼びます。これは、判定式の各条件のすべての可能な結果が少なくとも一度は発生し、各判定のすべての可能な結果自体が少なくとも一度は発生するように、十分なテストケースが選択されることを意味します。
条件付併用補償
条件付き組み合わせカバレッジとは、各判定式の条件結果のすべての可能な組み合わせが少なくとも一度は発生するように、十分なテストケースが選択されていることを意味します。当然ながら、条件付き組み合わせカバレッジを満たすテストケースは、判定/条件付きカバレッジも満たさなければなりません。
このように、条件付き組み合わせカバレッジは、前述の5つのカバレッジ基準の中で最も強力なものです。しかし、条件付き組み合わせカバレッジは、プログラム内のすべての可能なパスが少なくとも一度は通過することを保証するものではありません。
ルートカバレッジ
パス・カバレッジ。パスカバレッジとは、プログラムが実行される可能性のあるすべてのパスを少なくとも一度は通過するように、十分なテストケースが選択されていることを意味します。
パスカバレッジは、実際には、プログラムにおけるさまざまな判定結果のすべての可能な組み合わせを考慮するものであり、したがって、より強力なカバレッジ基準です。しかし、パスカバレッジは、判定における条件付き結果の組み合わせを考慮しないため、条件付きカバレッジや条件付き組み合わせカバレッジの代わりにはなりません。
ブラックボックステスト
ブラックボックステストは、機能テストとも呼ばれ、主に結合テストや確認テストの段階で用いられます。ソフトウェアを不透明なブラックボックスとみなし、ソフトウェアの内部構造や処理アルゴリズムを完全に無視し、ソフトウェア要求仕様の要求事項に従ってソフトウェアの機能が正常に使用できるか、ソフトウェアが入力データを正しく受け取り、正しい出力情報を生成できるか、ソフトウェアの動作中に外部情報の整合性が保てるかだけをチェックします。
ブラックボックステストは、ソフトウェア要求仕様で指定された機能に基づいてテストケースを設計するもので、ソフトウェアの内部構造や処理アルゴリズムを考慮したものではありません。一般的に使用されるブラックボックステスト技法には、等価クラス分割、マージン分析、エラー推測、因果関係図などがあります。
等価クラス分割
等価クラス分割は、テストケースを設計するときに最もよく使われるブラックボックステスト手法の一つです。等価クラスとは、等価クラス内の入力値に対して、プログラムのエラーを発見する能力において等価である入力ドメイ ンの集まりです。つまり、等価クラス内の入力がエラーを検出できる場合、等価クラス内の他の入力も同じエラーを検出できます。逆に、等価クラス内の入力があるエラーを検出できない場合、等価クラス内の他の入力もそのエラーを検出できません。
等価クラス内のデータが要求仕様に合致している、妥当なデータである場合、この等価クラスは有効な等価クラスと呼ばれます。有効な等価クラスは、主にソフトウェア要求仕様で指定された機能をソフトウェアが実現しているかどうかをチェックするために使用されます。
等価クラス内のデータが要件に合致していない、不合理なデータ、不正なデータである場合、その等価クラスは無効等価クラスと呼ばれます。無効等価クラスは、主にソフトウェアの耐障害性をテストするために使用されます。
等価クラス分割法を用いたブラックボックステストにおけるテストケースの設計手順は以下の通りです：
ソフトウェアの機能記述に基づいて、入力条件ごとに有効な等価クラスの数と無効な等価クラスの 数を決定し、各有効な等価クラスと無効な等価クラスに番号を付けます。まだカバーされていない有効な等価クラスをできるだけ多くカバーするテストケースを設計します。有効な等価クラスをすべてカバーするまで、この手順を繰り返します。まだカバーされていない無効な等価クラスをカバーするテストケースを設計します。すべての無効な等価クラスをカバーするまで、この手順を繰り返します。
無効等価物は異常な入力データをテストするために使用されるため、各無効等価物はソフトウェアのエラーを発見する可能性があり、各無効等価物に対してテストケースを設計する必要があります。
マージン分析
経験上、ソフトウェアは境界ケースを扱うときに最もエラーが発生しやすくなります。ソフトウェアがたまたま境界付近で実行されるように、多くのテストケースを設計することは、ソフトウェアのエラーを明らかにする可能性が多少高くなります。
一般的に、各同値クラスの境界は強調してテストされるべきであり、テストデータは境界値と正確に等しいか、境界値よりわずかに小さいか、境界値よりわずかに大きくなるように選択されるべきです。
等価クラス分割とマージン分析を組み合わせることで、ソフトウェアのエラーを検出できる可能性が高くなります。
誤推定
等価クラスとマージン分析テクニックを使用することで、ソフトウェアのエラーを簡単に発見できる代表的なテストシナリオを設計することができます。しかし、特定のソフトウェアには、通常、エラーが発生しやすい特別な領域があります。
エラー推測法は、テスターの経験と直感に大きく依存し、様々な可能性のあるテストシナリオの中から、プログラ ムにエラーを引き起こす可能性が最も高いものを選択します。
げんいんず
因果関係図法は、入力条件と出力結果の因果関係に基づいてテストケースを設計する手法で、まず入力条件の様々な組み合わせを検討し、入力条件に対する出力結果の依存関係を見つけ出し、出力条件の組み合わせごとにテストケースを設計します。
欠陥の分類とレベル
IEEE 規格および Paul C. Jorgensen の教科書によると、ソフトウェアテストで発見されるエラーの主なカテゴリーは、以下の通りです： 入力/出力エラー。これには、正しい入力を受け取っていない、正しくない入力を受け取っている、記述が正しくない、あるいは欠落している、パラメー タが正しくない、あるいは欠落している、出力結果が正しくない、出力形式が正しくない、出力時間が正しくない、結果が一貫し ていない、結果が欠落している、結果が非論理的である、スペル/文法の誤り、修飾子の誤りなどが含まれます。論理的エラー。ケースの欠落、ケースの重複、極端な条件エラー、不正確な解釈、条件の欠落、不正確な外部条件、不正確な変数テスト、不正確なループ反復、不正確な演算子。計算エラー。アルゴリズムの誤り、計算の欠落、オペランドの誤り、演算の誤り、ブラケット・エラー、精度が不十分な組込み関数の誤り。インターフェースのエラー。誤った割り込み処理、誤った入出力タイミング、誤ったプロシージャの呼び出し、存在しないプロシージャの呼び出し、パラメータの不一致、互換性のない型、過剰なインクルード。データエラー。誤った初期化、誤った格納/アクセス、誤った識別子/インデックス値、誤ったパッキング/アンパッキング、誤った変数の使用、誤ったデータ参照、誤ったデータ範囲または単位のスケール、誤ったデータ寸法、誤った添え字、誤った型、誤ったデータ範囲、限界外のデータ、データのオーバーフロー、一貫性のないデータ。
エラーの結果の重大性に応じて、ベイザーはエラーを10段階に分類しています：
軽度。中程度。目に不快。使用に支障。深刻。非常に深刻。極めて深刻。耐え難い。壊滅的。伝染性。
デバッグ
デバッグとも呼ばれ、デバッグはテストの成功と密接に関係しています。テスト成功の証は、エラーの発見です。エラーの兆候に基づいてその原因と正確な場所を特定し、それを修正することは、デバッグ技術に大きく依存しています。
デバッグはかなり骨の折れるプロセスですが、その理由は、開発者の障害の心理的な側面だけでなく、エラーのプログラムに隠されているため、次のような特殊な性質を持っています：
エラーの外的な兆候は、特に高度に結合したプログラム構造では、エラーの内部原因から遠く離れています。あるエラーを修正すると、別のエラーが消えてしまいます。エラーの兆候の中には偽のものもあります。オペレータの過失によるエラー兆候の中には、追跡が容易でないものがあります。エラーの原因がプログラムではなくタイムシェアリングによるもの。入力条件を正確に再現するのが難しい。特に組込みシステムでは、エラー表示が散発的。複数の異なるプロセッサにタスクを分散させたために発生するエラー。
ソフトウェアのトラブルシューティングプロセスでは、大小、問題のすべての種類に遭遇する可能性があり、問題の増加に伴い、トラブルシューティング担当者の圧力も増加し、過度の緊張は、同時に問題の排除と、より多くの新しい問題の導入で開発者によって引き起こされます。トラブルシューティングは良い技術ではありませんが、まだ効果的な方法と戦略の数があります。
一般的に使用されるトラブルシューティング戦略は、3つのカテゴリーに分類されます：
プリミティブクラスプリミティブクラスは、最も一般的に使用され、トラブルシューティングの最も非効率的な方法は、それを使用する無力な場合にのみ、主なアイデアは、"コンピュータを介してエラーを見つける "ことです。 例えば、出力メモリ、レジスタの内容は、プログラムの出力文の数などを手配するために、現場情報の多数の美徳によって、そこからエラーの手がかりを見つけることです。最終的には成功することもありますが、多くの時間とエネルギーを費やすことは避けられません。
バックトラック・クラスバックトラック・メソッドは、プログラムのトラブルシューティングにうまく使うことができます。その方法は、エラーの根本原因が発見されるまで、エラーの発生点から制御フローを手作業でトレースバックするというものです。 残念ながら、プログラムが大きくなるにつれて、バックトラック可能な経路の数は劇的に増加するため、完全な手作業によるバックトラックは不可能になります。
除外カテゴリー。消去法は帰納的および演繹的原則に基づき、「分割」の概念を用います。つまり、エラーの発生に関連するすべてのデータをまず分析し、エラーの仮説的原因を仮定し、データを用いてそれを証明または反証します。特定のテストの結果、仮説が有望であることが示されると、データは改良され、勝利が追求されます。
