ソフトウェアテストプロセスの概要3.1
ソフトウェアプロセスをテストし、ソフトウェア開発プロセスは似ているだけでなく、テスト計画、テスト設計、テスト、開発、テスト実行と試験評価のいくつかの部分。
（1）テストプログラム。ユーザーによると、それ以降のすべてのテスト作業は、テスト要件を中心に行われることに対応したテストレポートの需要の定義を機能要件の仕様とパフォーマンス指標に関する報告書を必要とします。同時に、適切なテスト内容、合理的な取り決めテスター、テスト時間とテストリソースを選択します。
（2）試験デザイン。試験設計は、実行可能なテストプロセスの数に細分テスト要件を、開発し、試験結果の妥当性を保証するために、各試験工程のための適切なテストケースを選択するために、分解試験計画段階を指します。
（3）テストの開発。確立自動化されたテストプロセスが使用を繰り返すことができます。
（4）テストの実行。設立のテスト開発フェーズでの自動テスト、および発見された欠陥は、管理を追跡します。一般に、試験単体テスト、統合テスト、検証テストと回帰テストの手順によって行われます。
（5）試験および評価。結合ドメイン定量化テストカバレッジと作業の進捗状況及び総合評価のアプリケーションソフトウェアの開発チームの品質と効率上の欠陥追跡レポート。
単体テスト、統合テスト、検証、受け入れテスト、図3.1に示す：試験手順では、テストは、以下のステップを実行することによって行います。
図3.1ソフトウェアのテスト実行プロセス
（1）ユニットテスト：各最小ソフトウェアモジュールをテストすることによって、ソースコードの各ユニットのためのテストプログラムの実装では、各モジュールが実装されているか否かをチェックが正しくそれが動作できるようにする機能を所定。
（2）統合テスト：モジュールは、ソフトウェアの設計に関連したプログラム構造の問題をテストを目的とした組立の統合のためにテストされています。
（3）検証テスト：ソフトウェアをテストするソフトウェア構成が完全かつ正確に決定され、要求仕様における機能および性能の要件を満たしています。同時に、ソフトウェア製品を試験すること（例えば、ハードウェア、データベース及び操作員のような）システムの他の部分の実際の動作環境と連携することができます。
試験（4）受付：ソフトウェアのテスト工程を最終製品の品質としては、主なソフトウェアができ、試験及び試験の再実行サブセットへのユーザは新しいエラーのない導入を確実にないようになされています。
3.2ユニットテスト
1。ユニットテストの内容
テストプログラムモジュールをテストするための手段は、以下の5つの主なタスクがあります。図3.2に示すテストモジュールインタフェース、テストのローカルデータ構造、テストの境界条件、テスト実行パスとエラー処理試験、。
図3.2ユニットテストタスクが解決しようとします
1）試験インタフェースモジュール
試験の被試験モジュールにより、データストリームは、モジュールのうちチェックデータが正確です。したがって、モジュールの必須インタフェースは、パラメータテーブル、テスト等のサブモジュールを呼び出し、グローバルデータ、ファイル入力/出力操作のパラメータを含みます。具体的には、次のように。
（1）モジュール一致するパラメータの数は、モジュールの入力パラメータの実際の数を受け付けます。
仮パラメータ及びモジュール（2）の実際のパラメータのタイプが入力と一致します。
ユニットパラメータとモジュールによって使用される実際のパラメータの形でいるかどうか（3）入力が整列されています。
コール他のモジュールは、送信されたパラメータの実際の数の数は、モジュールの仮パラメータと呼ばれている（4）は同じです。
コール他のモジュール、実際のパラメータは、呼び出しモジュール一致の仮パラメータで送信（5）。
（6）ユニット、別のモジュールを呼び出して送信フォームの実際のパラメータは、呼び出しモジュールのパラメータが一致しています。
（7）内部関数呼び出し番号、および注文属性パラメータが正しいです。
複数の入口を有するモジュールの場合には（8）、入口の現在の参照パラメータ独立かどうか。
（9）リード・モディファイパラメータかどうか。
それらのモジュールのすべてのグローバル変数は同じ定義基準を持っているかどうか（10）。
外部I / Oモジュールを内に含む場合は、次の要因を考慮する必要があります。
（1）のファイル属性は正しいです。
（2）OPENとCLOSE文は正しいです。
（3）記録一致のバッファ容量の長さ。
かどうかは、読み取り/書き込み動作中に（4）の前に、ファイルを開きます。
（5）ファイルハンドルの終わりには、ファイルを閉じています。
（6）エラーのテキスト書き込み/入力。
（7）I / Oエラーチェックと取引を行うかどうか。
試験2）ローカルデータ構造
このようなデータ型の仕様として、テストチェック整合性の問題ローカルデータ構造は、初期化、デフォルトは、等、及びグローバルデータモジュールへの影響をテストします。
モジュールの過程で相互の関係と発生しないエラーの形で、内部データの内容を含め、データの整合性を維持することができるモジュール内部でテストする必要があります。
なお、エラーのローカルデータ構造タイプ：不正または矛盾タイプ記述、間違った初期またはデフォルト値、変数名エラー、例えばスペルミスや書き込みエラー等の、アンダーフロー、オーバーフローやアドレスエラー。
3）実行パス試験
基本的な実行パスとサイクルパスのテストは、多くの場合、エラーの多くを見つけることのできる重要なテストケースの実行パスのモジュールテスト、。試験は、生成されたエラーの計算誤差、間違った決意または通常の制御フローを発見することができなければならないからです。
一般的な誤り：不正確または誤解を招く算術優先;混合モード動作エラー、初期化エラー、精度が正確で十分ではない。式の誤った記号表現。
等しい精度に等しくすることができないであるべきであるがエラーに代わり、決定不正または誤っ;誤った論理演算又は優先異なるデータタイプの誤差比較：と決意条件に対するカバーは、テストケースは、次のエラーを見つけることができます変数;正しくないまたは存在しないループが終了、それは枝のリサイクルに来る終了することはできません。不適切ループ変数を変更します。
4）エラー処理の測定
検査モジュールをエラー処理は、エラーや欠陥が含まれています。例えば、不当な入力を拒否するか、エラーの説明が困難であるかどうかを故障箇所は、エラー処理にエラー状態前にすでに発生しているシステムは、エラーレポートの原因は、エラー条件の処理が間違っているか、間違っているか、間違っているかどうかを、理解します介入。
エラーが有効な仕事、エラー処理施設で発生したときに、キーテストエラーは、モジュールを取り扱います。
5）境界条件テスト
境界条件をテストするテストユニットの最終ステップであり、境界値分析は、テストケースを設計するために使用されなければなりません。試験は、境界で正常に動作して、テストモジュールセットは、データ処理を制限します。
このようなように最初、最後、最大値、最小値、最大値、最小値、最大値、最小値及び境界のようないくつかの関連データタイプ。
テストの境界条件では、テストは、次のことをチェックするように設計する必要があります。
（1）第0、... 1 n回Nサイクルでエラーが発生した場合。
誤差最小値があるかどうか、最大値（2）計算または決意を要します。
（3）データフロー、制御フローは誤差が少なく判定比較値未満であれば、正確に、より大きく、に等しいです。
ステップ2.テストユニット
ユニットテストは、通常、コーディングの段階で行われます。準備とレビューと検証を経て完全なソースコードは、構文エラーを確認しなかった後、ユニットテストのためのテストケースを設計し始めました。
モジュールは、そのテスト対象のモジュールに関連付けられている他のモジュールをシミュレートするために、いくつかの補助モジュールを使用して、アカウントに外の世界とのつながりを取って、テストモジュールを考える上で、独立したプログラムではありません。補助モジュールは、次の2つに分かれています。
（1）駆動モジュール（ドライブ）は：テストデータを受信するための被試験メインプログラムモジュールに対応する、被試験モジュールのアナログモジュールで使用され、そして試験開始の下で、被試験モジュールにモジュールをデータを送信します最後に、測定結果の出力。
（2）スタブ（スタブ）：テストモジュール下モジュールの経過をシミュレートするために使用されるが呼び出さ。スタブはすべて、あなたが必要としないで持ち込まれたサブモジュールの機能のみいくつかの一般的なデータ処理をしていたが、何もしないではありません。
被試験モジュールは、一緒に、図3.3に示す「テスト環境」を形成する駆動モジュールとスタブに関連しています。
図3.3ユニットテストテスト環境
3.3統合テスト
ソフトウェアの設計要件に従う方法は、モジュールは、ユニットテストと呼ばれる定義された組成物のようなソフトウェア・システムを介して互いに接続されている「統合」。統合テストは、モジュールのインターフェースとの間の依存関係に基づいて、このプロセスのための試験です。3.4示し、図のソフトウェア階層の一例を図。
統合テストは、実環境でのではなく、独立した開発環境やテスト環境で行われていないので、統合テストは、開発の頭の監督の下で、一般的な開発グループから選択された担当者のために必要。合理的な品質管理と監督に適切なテスト技術を使用して完全な統合テストの実施を確保するための責任ある開発チームのリーダー。統合テストを監視するために、独立した観察者によってテストし、テストします。
3.4ソフトウェアの階層構造の模式図
1.統合テストの主なタスク
一つの集積試験システムソフトウェアは、アセンブリ技術をテストして、後の組立ユニットテストの一緒に個々のモジュールの要件を設計に応じて、ソフトウェアは、インターフェースに関連する様々なエラーに見出される、現実的なシステムのソフトウェア構成を必要とします。統合テストは、次のいくつかのソフトウェアシステムのために主に適しています。
（1）は、航空宇宙ソフトウェア、通信ソフトウェア、基礎となるシステム・ソフトウェアとして高いソフトウェア品質のソフトウェアシステムを必要とします。
（2）広い範囲、ソフトウェアのユーザのより多くの使用。
（3）C / C ++と同様のポインタとソフトウェア開発言語プログラムを使用。
（4）ライブラリ、ミドルウェアおよびその他の製品。
統合テストの主なタスクは、次の5つの問題に対処することです。
（1）モジュールは、各モジュールは、インターフェースを介して、検査データが失われた呼び出し、互いに接続されています。
（2）それぞれの機能を組み合わせ、チェック機能が期待される要件を達成することができます。
関数は、別のモジュールへの機能モジュールが悪影響を受けることになる（3）です。
場合は、問題の（4）グローバルデータ構造は、珍しいの修正ではありません。
エラー許容できない程度を達成するように蓄積された単一のモジュールが拡大されているか否か（5）。
2.統合テスト方法
モジュールインタフェース、主にブラックボックステスト、適切に補充したホワイトボックスに基づいてテストので構造的な問題の主試験ソフトウェアの統合テスト、。統合テストは、次の手順に従ってください。
ステップ1：完全なシステム・モジュールの構成との関係を確認してください。
ステップ2：評価モジュールとの間の相互作用との通信ニーズは、モジュール間のインターフェイスを確認します。
ステップ3：テストケースセットを生成します。
ステップ4：順次、システムテストプロセス及び論理的/機能的配列に付加増分テストモジュールが繰り返されます。
テストキーモジュールに特に注意を払って統合テスト・プロセスは、キーモジュールは、通常、1つまたは複数の以下の特徴があります。
（1）いくつかの要求を同時に機能に対応します。
（2）高レベルの制御機能を有します。
（3）複雑な、エラーを起こしやすいです。
（4）特殊な性能要件。
試験の主な目的は、ソフトウェアシステム構成のインタフェースモジュールの各々の統合及び相互作用を検証することであるので、テスト要件からのデータの統合、コンテンツの難易度が非常に高くありません。統合は、実際のデータを使用していない、あなたは代表的なテストデータの一部を使用することができ、一般的にテストします。テストデータを作成する場合は、境界条件は、データが完全にソフトウェアシステムをテストしていることを確認する必要があります。
非増分統合テスト統合テストと増分統合テストを含みます。
1）非増分統合テスト
すべてのモジュールの個々のユニットテストの後、テストするための統合テスト非増分ステップ方法、プログラム構造は一緒にモジュールを接続図によれば、全体として試験後の接続手順。
2）インクリメンタル統合テスト
インクリメンタル統合テスト方法は、インクリメンタルトップダウンテスト、およびからサンドイッチを試験ボトムアップテストインクリメンタル統合を含みます。
（1）インクリメンタルトップダウンテスト。トップダウンテスト段階的増分と緩やかな統合構造図トップダウンテストによります。集積モジュールは、第1の順序統合のマスターモジュール（メインプログラム）であり、次いで下方制御ソフトウェア統合の階層を辿ります。トップダウン方法は、統合されてもよく、深さ優先戦略は、広さ最初の図3.5に示されている戦略を、。
3.5概略的な増分セルフテストダウン図
（2）ボトムアップ増分試験。「アトミック」モジュール（下のソフトウェアモジュール構造）から増分ボトムアップテスト、図漸進的統合及びテストのボトムアップ構造で始まります。図3.6は、増分テストのボトムアッププロセスを表します。
3.6増分試験のボトムアップの模式図
（3）サンドイッチ統合テスト。統合とも呼ばれるサンドイッチハイブリッド集積、それはトップダウンとボトムアップの長所と短所にロールバック。サンドイッチシステムは、三層のターゲット層としての中間層と一体化さに分割されています。トップダウンテスト統合テスト・モード、ターゲット層の下のボトムアップ戦略の統合レイヤの使用を使用して、ターゲット層の上部層は、ターゲット層は、最終的にテストされています。
ドライバD5及び底モジュールM7のD6機能を用いて、手順パイルS2、S3及びS4、M1テスト3.7インターフェイスユーザーを使用して示されているように、M8及びM9を試験しました。ときに全体の統合されたシステム、プログラムパイルS2、S3及びS4中間層モジュールM2、M3及びM4に、中間層、機能モジュールは、試験されるべきであるように、中間層のドライバD5、交換モジュールのD6 M5とM6。
図統合テストサンドイッチ3.7概略
3.4確認試験
ソフトウェアの正当性を検証するための確認試験のために、すなわち、ソフトウェア及びその他の特性の機能と性能を検証するために、ユーザの要件に合致しています。
テスト段階では、図3.8に示されている作業を確認するために行われる必要があります。あなたは最初のソフトウェア成果物になるために、専門家による後ソフトウェア構成、インストールおよび受け入れテストとテストだけでなく、審査の有効性をテストする必要があります。
図テスト確認ステップ3.8
1.妥当性検査
シミュレートされた環境下でのテストの妥当性は、テスト対象のソフトウェアを検証するためのブラックボックステスト方法の使用は、要求仕様に記載されている要件を満たしています。この目的のために、テスト計画は、一種のテスト規定は、実行するテストステップのセットを開発するために、テストケースを記述します。ソフトウェアは、ソフトウェアのすべてが性能要件を達成するために、すべてのソフトウェアの機能要件が満たされていることを保証するために、事前に定義されたテスト計画やテスト手順を実装することにより、要件に合致ますかどうかを判断するには、すべての文書が正しいと使いやすいです。
2.ソフトウェアコンフィギュレビュー
レビューの目的は、システムの実際の動作環境を含め、すべてのコンポーネントのソフトウェア構成ソフトウェア構成を、確実にするためである完全なサポート環境、すべての要件の遵守のすべての側面の品質です。検証テストプロセスでは、厳密に省略およびエラーが見つかった記録、文書の完全性と正確性を確認するために、ユーザーズマニュアルや手動操作を使用する手順の規定を遵守し、適切に補完し、正しい必要があります。
3.5受け入れテスト
ユーザー受け入れテストは、テストを主に、ソフトウェア開発者や品質保証の担当者も参加すべきです。ユーザによって、ユーザインターフェースを介してテストケースは、テストデータ入力の設計において試験の分析結果の出力を参加します。実際のデータは、一般に、製造テストに使用されます。ソフトウェアの機能や性能を考慮することに加えて、テスト時には、だけでなく、確認するために、移植性、互換性、保守性、エラー回復機能や他のソフトウェアに対処します。
3.5.1αテストやβテスト
ソフトウェアの引渡し後、ユーザーが実際には予測不可能である開発者のためのプログラムを使用する方法となります。一部のユーザーのための生成が明確であるように見えるが、他人のためにそれはハードユーザーを理解するために、異常データの組み合わせを、ユーザーの問題なので、ソフトウェアの操作方法の、このような誤解は、多くの場合、使用中に発生します出力、およびオンそう。
αおよびβ試験試験は、エンドユーザが見つけることができるかもしれエラーを見つけるために使用されます。ユーザーをテストするためのαテストでは、テストは、実際の動作環境のシミュレーションでは、企業ユーザー内で実行することができる、開発環境で実行することができます。αテストは、制御された環境下で実行されるテストです。試験の目的は、製品のインターフェイスおよび機能に特に重点を置いて機能、使いやすさ、信頼性、パフォーマンス、およびサポートするソフトウェア製品のFURPSα評価、です。試験の終了後Αの開始は、符号化ソフトウェア製品から起動、または試験が完了したモジュール（パーティション）後に開始することができ、テストを確認することができるその安定性と信頼性のある程度の中に製品。
βテストでは、ソフトウェアの複数のユーザがユーザの実際の環境の一つ以上で行った試験です。そして、αテスト異なるが、開発者は多くの場合、テストサイトをしないことです。したがって、βテストは、制御不能な環境下でのフィールド・アプリケーション・ソフトウェアの開発者で行われます。βテストでは、ユーザレコードのすべての問題は、現実と主観的な判断を含め、遭遇し、定期的に開発者に報告し、すべてのユーザーに配信包括的なユーザーレポート、メイク変化し、最終的にソフトウェア製品開発者の後使用しています。βテストでは、生産能力のドキュメント、顧客のトレーニングとサポートを含め、製品のサポートに焦点を当てています。αテストは、信頼性のあるレベルに達したときにのみ、βテストを開始することができます。
3.5.2回帰テスト
ソフトウェアのライフサイクルのどの段階では、限り、ソフトウェアが変更されたとして、あなたは、ソフトウェアの欠陥が問題を引き起こし与えることができます。変更は、ソフトウェアのエラーが原因である可能性が発見され、変更を行ったが、また、統合や保守フェーズが原因の可能性があり、新たなモジュールやその他の事情を追加しました。回帰テストは、システムを変更した技術の整合性と正確性を検証するためのテストである変化に起因するが、発見によって引き起こされる前に変更は新たなエラーを導入したりしないことを保証するために行われているテストのサブセットの再実装を指し、エラーが変更を確実にするために、あること、発見されていない意図せぬ副作用を持っていませんでした。そのため、ソフトウェア開発のすべての段階は、複数の回帰テストを行うことになります。
1。回帰テストの実施のための前提条件
エラーの追跡と管理システムが完全でない場合、ソフトウェアはエラーを含む（1）は、発見され、これらのエラーは修正を逃してもよいです。
;（2）誤解の開発者や不十分な、それが改正につながる可能性が唯一の外観のバグが修正されていますが、修正できなかった、その結果、エラー自体を修正しなかった作られました
（3）修飾は、それが正常な機能でエラーが発生うまくいくようにソフトウェアの部分に至る副作用は、新たな問題を生成するように変更されていない製造することも可能です。
2。2つの戦略の回帰テスト
回帰テストは、テスト活動のすべての段階を通してテストされ、欠陥検査の目的は、そこには正確な改変ではないと改訂プロセスは、新たな欠陥が発生していないことが判明しました。以下の戦略は、回帰テストのために使用することができます。
1）完全な再検査
繰り返しテストは、妥当性の問題を取り巻く修正試験方法を確認するためにすべての上に再び完全に実行され、完全なすべてのテストケースであり、変更が影響を受けるかどうか。欠点は、このように、プロジェクトのコストが増加する、完全な実装のユースケースを取ることによるもので、また、プロジェクトのスケジュールに影響を与えるだろう、完全に実装することは困難です。
2）選択的反復試験
選択的反復試験が問題修飾周囲の正しさを確認し、衝撃の試験方法の変更の対象となるために、一部を選択するために行うことができることをいいます。ここでは選択再送テストのいくつかの方法があります：
（1）変更方法を覆っています。
（2）方法外部からの影響。
（3）インデックスは、メソッドに達しました。
動作試験に基づいて、（4）断面図。
（5）リスクベースの選択試験。
3。回帰テストプロセス
回帰テストプロセスは、典型的には、以下の手順を実行しています。
ステップ1：戦略を開発するためのテスト、回帰テストにおける政策策定段階。
ステップ2：リグレッション・テスト・バージョンを確認します。
ステップ3：回帰がリリース、ポリシーに従ってテスト回帰テスト回帰テスト。
ステップ4：回帰テストにより、単一の欠陥がオフ追跡。
ステップ5：回帰テストが渡されていない、単一欠陥リターン、再編集するには、開発者は、回帰再びテストします。
4。回帰テストと一般的なテストの比較
異なる点の数と比較して、回帰テストおよび一般的な試験は、以下のものなど、時間と効率の完全な用語が導入され、試験計画、試験範囲、時間、情報の開発の可用性から割り当てられました。
状況（1）試験計画：一般的なテストシステム仕様および試験計画に従って、テストケースは新規であり;回帰テストは、仕様の変更、修正されたプログラムとテスト・プランを更新する必要があってもよいです。
（2）試験範囲：試験の一般的な目的は、全体のプログラムの正しさを検出することで、目標は、関連する修正されたシステムの部分と本来の機能との統合の正しさをテスト回帰を検出することです。
（3）時間の割り当て：ソフトウェアが通常開発される前に、一般的な予算をテストするのに必要な時間と、回帰テスト（特に補正回帰テスト）のために必要な時間は、多くの場合、製品のスケジュールに含まれていません。
（4）情報の開発：いつでも利用可能で一般的な知識のテスト開発と情報;および回帰テストは、異なる場所や時間に回帰テストの適切な発展を確保するための情報を保持する必要が行うことができます。
（5）終了時間：テストプログラムの回帰テストの一部だけので、それによってテストに必要な時間を完了すると、一般的に通常必要なテストよりも短い時間です。
（6）実行頻度：システムは、回帰テストの必要性について変更された後、回帰は、システムのライフサイクルの間に、多くの場合、何度もテストします。
