テストソフトウェアの方法とそれらを比較します。 「ブラックボックス」テストと「ホワイトボックス」の方法の試験方法

テストソフトウェア（SW）に対処する必要があるコードの隙間、欠点およびエラーを識別する。 また、分析の助けを借りて、ソフトウェアの機能性と正確性を評価するプロセスとして定義することができます。 統合およびソフトウェアアプリケーションのテストの基本的な方法と品質が仕様、デザイン、コーディング、信頼性評価、検証、検証をテストすることであることを確認してください。

方法

ソフトウェアテストの主な目的は - 慎重に制御された条件下での体系的なデバッグ用アプリケーションによるソフトウェアシステムの品質の確認をその完全性と正確性を決定するだけでなく、隠れたエラーの検出。

検証の方法 （試験）プログラムは、 静的および動的に分割することができます。

前者は非公式、モニタリングおよびテクニカルレビュー、検査、工程分析、監査、並びに静的データ・フロー解析および管理することにより工程を含みます。

動的な技術は以下のとおりです。

1. ホワイトボックステスト。 これは、プログラムの内部ロジックおよび構造の詳細な研究です。 これは、ソース・コードの知識が必要です。
2. ブラックボックステスト。 この技術は、アプリケーションの内部の仕組みについての知識を必要としません。 私たちは、に関連するか、その内部の論理構造の数に関連付けられていない、システムの基本的な側面を考慮します。
3. 灰色のボックス方法。 これは、前の2つのアプローチを組み合わせています。 アプリケーションの内部機能の限られた知識でデバッグは、システムの基本的な側面の知識と組み合わされます。

透明テスト

手続き設計のテストスクリプト制御構造を使用してホワイトボックス方法。 この技術は、ソフトウェアの内部の仕組みの一部を解析することにより、このような劣悪管理コードシステムとして実装誤差を、明らかにすることができます。 これらの試験方法は、統合、モジュールとシステムレベルに適用可能です。 テスターは、ソースコードへのアクセス権を持っており、不適切な振る舞いどのユニットを見つけるためにそれを使用する必要があります。

ホワイトボックスでプログラムをテストすると、次のような利点があります。

• 不要な行を除去することにより、隠しコードのエラーを検出することができます。
• 副作用の使用;
• 最大のカバレッジは、テストスクリプトを記述することによって達成されます。

短所：

• 熟練したデバッガを必要とする高コスト工程;
• すべての可能な隠れたエラーの完全なチェックは非常に複雑であるため、多くの道は未踏のまま。
• コードの一部は気付か渡されます。

ホワイトボックステストは、しばしば透明またはオープンボックス、構造的、論理的なソースコードに基づいてテスト、および論理アーキテクチャをテストすることによって参照されます。

主な品種：

1）フロー制御を試験 - 少なく、より複雑な、より簡単な方法を好むように構造的戦略は、プログラム制御フローモデルを用いて、

2）分岐も合わせた溶液を含む各制御オペレータ、の）（真または偽の各オプションのデバッグを研究するために設計されています。

テスターは、実行パスの基本セットを単離するための論理的な複雑さの測度手続きプロジェクトを確立することを可能にするメインパス、3）試験。

;広告についての情報をカウントし、プログラム変数を使用して、注釈の研究のフロー制御戦略 - 4）データ・ストリームをチェックします

5）試験のサイクルは - 完全にサイクリックプロセスの正しい動作に焦点を当てました。

行動のデバッグ

ブラックボックステストは、「ブラックボックス」などのソフトウェアを扱います - プログラムの内部動作についての情報がカウントされ、システムの基本的な側面をチェックされません。 この場合、テスターは、ソースコードにアクセスすることなく、システムアーキテクチャを知る必要があります。

このアプローチの利点：

• 大規模なコードセグメントの効率;
• 知覚テスターの容易さ;
• ユーザの視点を明確に現像視点（プログラマーとテスターは互いに独立している）から分離されています。
• テストのより迅速に作成。

テストソフトウェアのブラックボックス方法は、以下の欠点があります。

• 実際に限られたカバレッジをもたらす、テストケースの選択数を行います。
• テストスクリプトを開発することは困難で明確な仕様の欠如。
• 効率が低いです。

この技術の他の名称-行動、非透過性、 機能テスト およびクローズドボックスのデバッグ方法。

このカテゴリには、次のソフトウェアテスト技術を含むことがあります。

1）入力されたソフトウェア・モジュール・データが別個の部分に分割されるように、テストデータのセットを減少させることができるパーティションに相当します。

2）の境界値分析は、境界又は極端な限界値の検証に焦点を当て - 最小値、最大値、および誤差の典型的な値。

3）ファジング - 自動または半自動モードでのエラーまたは破損したデータpoluiskazhennyhを入力することにより検索を実現するために使用されます。

4因果関係の）カウント - グラフの作成に基づく技術と行動とその理由の間の関係を決定する：アイデンティティ、否定、論理和と論理積 - 4つの主要な文字、原因と結果の関係を表します。

5）直交配列の検証は、徹底的な研究の可能性を超えて、比較的小さな入力領域の問題に適用されます。

6）全ての対を試験 - 試験値のセットは、入力パラメータの各対のすべての可能なバイナリの組み合わせを含む技術。

7）デバッグ状態遷移-マシンの状態を確認、並びにナビゲートするための有用な技術 のGUI ユーザ。

ブラックボックステスト：例

ブラックボックス技術は仕様、マニュアル、およびソフトウェアインタフェースまたはシステムの記述に基づいています。 また、あなたは、ソフトウェアの正常な動作を表現する、（公式または非公式）モデルを使用することができます。

典型的には、この方法は、ユーザインタフェースをデバッグするために使用されるデータ収集およびデータの結果を導入することにより、アプリケーションとの対話を必要とする - 画面から、レポートや印刷物から。

テスタは、従って、スイッチ、ボタンまたは他のインターフェースに作用することによって、入力することにより、ソフトウェアと相互作用します。 次の例に示すように、入力データの選択は、投与またはアクションのシーケンスの順序は、これらの組み合わせの膨大な数をもたらすことができます。

どのように多くのテストでは、4つのウィンドウフラグとワンオフフィールド可能なすべての値をチェックするために作成する必要がある時間を秒単位で設定されていますか？ 一見計算で簡単である：2つの可能な状態を有する4つのフィールド - 24 = 16、99 00からの可能な位置の数で乗算されなければならない、すなわち、1600の可能テスト。

しかし、この計算は間違っている：我々は2点フィールドはまた、スペースを含めることができると判断することができ、それは英数字2箇所で構成されている場合、このように英数字、特殊文字、スペース、などを含むことができ、すなわち....システムは、16ビットコンピュータであり、それらが実行する場合68719476 736の合計を与えることのフラグ16個の組み合わせで乗算されるべき得4294967296テストケースの各位置に対して216 = 65536いずれかを回します毎秒1回の試験、合計続きで olzhitelnostテストは2 177.5年です。 32または64ビットのシステムの場合、持続時間がより一層。

したがって、許容可能なレベルまでこの期間を短縮する必要があります。 したがって、技術は、テストの範囲を低下させることなく、テストケースの数を減らすために適用されるべきです。

同値分割

同等のパーティションは、入力または出力値か否かをソフトウェア中に存在する任意の変数に適用シンボリック、数字、および他の単純な方法である。これは、パーティションの一当量からのすべてのデータが同じように扱わによってされるという原理に基づいています同じ指示。

試験中、各特定の等価パーティションの一つの代表を選択しました。 これは、あなたが体系的にコマンドや関数の適用範囲を失うことなく、可能なテストケースの数を減らすことができます。

この分割の別の結果は、異なる変数とテストケースの関連した減少との間の組み合わせ爆発を低減することです。

例えば^、1/2（1 / X）における3つのデータ・シーケンス三の同等のパーティションを使用して：

1.すべての正の数は同じように扱われ、正しい結果を与える必要があります。

2.すべての負の数は同じ結果と同じように処理されます。 負の数のルートは虚数であるので、これは、間違っています。

3.ゼロは別々に扱われ、「ゼロによる除算」エラーを与えるであろう。 これは、単一の値を持つセクションです。

したがって、我々は、単一の値に低減される一方は3つの別個のセクションを参照されたいです。 信頼性の高い結果が得られる一つの「正しい」セクションと、誤った結果を持つ2つの「間違っている」があります。

境界値分析

同等のパーティションの境界上の処理は、予想とは異なる行うことができます。 限界値の調査 - そのような領域にソフトウェアの挙動を分析する公知の方法。 この技術は、このようなエラーを特定することを可能にします：

• 関係演算子の不適切な使用（<、>、=、≠、≥、≤）。
• 単一のエラー;
• サイクルとの反復での問題、
• 間違った種類や情報を格納するために使用される変数のサイズ。
• データ型と変数に関連付けられた人工的な制限。

半透明のテスト

灰色のボックスの方法を使用して、黒と白の技術の組み合わせを介してシステムのすべての困難なレベルに焦点を当てることができ、テストカバレッジを増加させます。

この技術を使用して、テスト値の開発のための試験装置は、内部データ構造及びアルゴリズムの知識を有していなければなりません。 次のようにグレーボックステスト方法の例であります：

• 建築モデル;
• 統一モデリング言語（UML）;
• 状態モデル（有限状態マシン）。

灰色のボックスの方法でテストケースを開発する白色エンジニアリングコードのモジュールを研究し、そして実際の試験は、黒色技術プログラムのインターフェイス上で実行されます。

これらの試験方法は次のような利点があります。

• 利点技術白と黒のボックスの組み合わせ;
• テスターがインターフェースと機能仕様ではなく、ソースコードに基づいています。
• デバッガは偉大なテストケースを作ることができます。
• チェックは、ユーザーではなく、プログラムの設計者の視点から作られています。
• カスタムテストの開発を作成します。
• 客観性。

短所：

• ソースコードへのアクセスがないため、テストカバレッジが制限されています。
• 分散アプリケーションの欠陥の複雑。
• 多くの方法は、未踏のまま。
• ソフトウェア開発者がテストを開始した場合は、さらに調査が過剰になることがあります。

灰色のボックス技術のもう一つの名前 - 半透明のデバッグ。

このカテゴリには、テストのような方法が含まれています。

1）直交 - すべての可能な組合せのサブセットを使用します。

2）プログラムデータの状態を使用して、マトリックスのデバッグ。

ソフトウェアへの新しい変更で実施3）回帰検査。

優れたアプリケーションの設計とアーキテクチャを分析4）テンプレート試験。

ソフトウェアのテスト技術の比較

動的メソッドの使用は、開発実装して実施する必要のあるテストの数の組み合わせ爆発につながります。 すべての技術は、アカウントにその限界を取って、実践的に使用する必要があります。

存在していない唯一の真の方法は、唯一の特定のコンテキストに適しているものがあります。 構造工学は、私たちは役に立たないか、悪意あるコードを見つけることができますが、それらは複雑であり、大規模なプログラムには適用されません。 仕様に基づくメソッド - 欠落しているコードを識別することができる唯一のものが、彼らは部外者を識別することはできません。 いくつかの技術は、他のものよりも、特定の試験レベル、エラーのタイプまたは文脈に適しています。

次の3つの動的テスト技術の主な違いは、 - ソフトウェアをデバッグする3つの形態の間の比較表が与えられています。

様相	ブラックボックス方法	灰色のボックスの方法	ホワイトボックス法
プログラムの構成に関する情報の入手	の基本的な側面を調べ	プログラムの内部構造についての部分的な知識	ソースコードへのフルアクセス
プログラムの断片化の程度	低いです	セントラル	高いです
デバッグを生産誰ですか？	エンドユーザー、テスターと開発者	エンドユーザー、開発者およびデバッガ	開発者やテスター
ベース	テストは、外部の緊急事態に基づいています。	図データベース、データフロー図、アルゴリズム及びアーキテクチャの内部知識の状態	内部デバイスは完全に認識しています
被覆度	以下、包括的かつ時間の最小値が必要です	セントラル	潜在的に最も包括的な。 時間のかかります
データと内部の境界線	唯一の試行錯誤によってデバッグ	彼らが知られている場合は、データドメインと内部の境界を確認することができます	最高のテストデータドメインと内部の境界線
適性検査アルゴリズム	ノー	ノー	はい

自動化

ソフトウェアテストの自動方法はあまり関係なく、技術的環境との関係の、検査のプロセスを簡素化されます。 彼らは2つの場合に使用されます。

1）このようなテスターより重要な点の濃度の時間を解放するために数千行のファイル比較として、退屈な反復または細心のタスクを自動化します。

2）容易に100分の1秒単位で測定することができるような性能の検証または解析応答時間などの人々によって実行することができないトラッキングやタスクを実行します。

テストツールは、さまざまな方法で分類することができます。 次の分割は、彼らがサポートするタスクに基づいています。

• プロジェクト管理のサポート、バージョン、構成、リスク分析、テストの追跡、エラー、欠損、およびレポート作成ツールを含むテスト管理、;
• ストレージ要件や仕様、完全性と曖昧さのためにそれらをチェックし、その優先順位と各テストのトレーサビリティが含ま要件管理、;
• 欠陥を検出するために、通信元のドキュメントとコードの静的解析を追跡するフローの監視、およびタスク、コメントの記録と保存、欠陥検出および計画修正チェックリストとルールへの管理リンク、などの重要なレビューと静的解析、コードを書くの基準の遵守を確保し、構造および依存関係の分析、コードおよびアーキテクチャのメトリックパラメータの計算。 また、コンパイラ、アナライザ、発電機および相互参照の関係を使用します。
• モデリングの企業行動のためのツールが含まれており、モデルをテストモデリング、。
• テスト開発は、条件とリスクの管理、統計解析のルールに基づいてデータ検証、条件およびユーザー・インターフェース・モデルやコードに基づいて予想されるデータの生成を保証し、ファイルとデータベースを作成または変更するために管理し、メッセージング。
• 成功と失敗のテストを識別しやすくするためのコンパレータを使用してグラフィカル・ユーザー・インターフェース、API、コマンドラインを介してデータを入力することにより、重要な図です。
• あなたは巻で、不足しているハードウェアまたはソフトウェアを交換することを可能にする支援デバッグ環境。時間。決定された出力のサブセット、端末エミュレータ、携帯電話やネットワーク機器に基づいてシミュレーション機器、環境の言語、オペレーティングシステム、およびチェックするための ハードウェアを 不足しているコンポーネントのドライバを置き換えることで、架空のOSを捕捉し、修正するためのモジュールなど、ならびにツールは、CPUシミュレーション限定されないが、RAM、ROM、またはネットワークを要求.;
• ...データファイル、データベースの比較、テスト中および後に予想される結果を確認が完了し、ダイナミックかつバッチ比較、自動「オラクル」をINCL。
• システムリソースレポートの測定、分析及び検証のための成長の現実的なシナリオでは、模擬負荷発生負荷アプリケーション、データベース、ネットワークまたはサーバーの下でメモリリークの局在と間違ってその制御動作を推定するシステムのための測定を塗布します。
• セキュリティ;
• パフォーマンステスト、負荷及び動的解析。
• 巻。時間内の他のツールは、。綴りと構文、チェックする ネットワークセキュリティ、 すべてのウェブサイトのページや他の可用性を。

展望

ソフトウェア業界で変化する傾向と、デバッグのプロセスは、変更される場合があります。 その上、このようなサービスorientirovannaeアーキテクチャ（SOA）などのソフトウェアテストの新しい方法、無線技術、モバイルサービス、およびがあります。E.は、テストソフトウェアの新しい方法を開きました。 今後数年間で業界に期待されている変更のいくつかを以下に示します。

• テスターは、開発者が自分のコードをチェックすることができます軽量なモデルを提供します。
• 早い段階での閲覧やモデリングプログラムを含むテスト方法、の開発は矛盾の多くを排除します。
• 複数のインターセプトテストの存在は、エラー検出の時間を短縮します。
• 静的アナライザと検出がより広く使用されることを意味します。
• そのような仕様のカバレッジなどの鉱物マトリクスの使用は、モデルとコードカバレッジの範囲は、プロジェクトの開発を決定します。
• コンビナトリアル・ツールは、テスターは、デバッグのための優先分野を決定することができます。
• テスターは、ソフトウェア開発プロセス全体より直感的で価値のあるサービスを提供します。
• デバッガは、ツールとソフトウェアで書かれたメソッドをテストし、さまざまなプログラミング言語との相互作用を作成することができます。
• デバッグの専門家は、より専門的に訓練されます。

システムとの相互作用の仕方やリスクを軽減し、ビジネスの変化の恩恵を大きくしながら、彼らが提供する情報を変更するには、新しいビジネス指向ソフトウェアのテスト方法に置き換えられます。