テストの自動化
テストの自動化は、開発作業全体の品質、コスト、サイクルタイムに大きな影響を与えます。自動化を検討するのに適したテストタスクには、次のようなものがあります。テスト実行制御テスト結果の標準出力との比較一貫性のないテスト結果の分析、文書化、分類、伝達総テストステータスの統計、レポート作成。テスト自動化とソフトウェア構成管理は表裏一体であり、テスト関連リソースは構成管理で考慮されるべきです。
オブジェクト指向テスト
伝統的なソフトウェアテスト戦略は、「小さなテスト」から始めて、徐々に「大きなテスト」へと移行していくものです。つまり、単体テストから始まり、統合テストへ、そして最終的にシステムテストへ。
オブジェクト指向プログラムの構造は、従来の機能モジュール構造ではなくなり、全体として、開発されたモジュールを段階的にまとめてテストするために必要な本来の統合テストは不可能になりました。また、オブジェクト指向ソフトウェアは、開発フェーズごとに以前の要求と結果が異なる従来の開発モデルを放棄しており、オブジェクト指向の分析・設計の結果を、機能洗練の観点からテストすることはもはや不可能です。そのため、従来のテストモデルはオブジェクト指向ソフトウェアには適用できなくなりました。
オブジェクト指向テストモデル
オブジェクト指向開発モデルは、伝統的なウォーターフォールモデルを打ち破り、開発をOOA、OOD、OOPの3段階に分けます。この開発モデルは、伝統的なテストステップの分割と組み合わせて、オブジェクト指向ソフトウェアテストは、オブジェクト指向分析テスト、オブジェクト指向設計テスト、オブジェクト指向プログラミングテスト、オブジェクト指向ユニットテスト、オブジェクト指向統合テスト、オブジェクト指向システムテストに分けることができます。
オブジェクト指向分析のためのテスト
従来のプロセス指向分析は、システムを分解可能な機能の集まりとして見る機能分解プロセスです。機能分解分析では、システムがどのような情報処理方法やプロセスを必要としているかに着目し、プロセスの抽象化によってシステムのニーズを扱います。一方、オブジェクト指向分析では、問題空間を直接マッピングし、問題空間内のインスタンスをオブジェクトとして抽象化し、問題空間内の複雑なインスタンスや複雑な関係をオブジェクトの構造に反映させ、インスタンスの特性や振る舞いを属性や操作で表現します。 OOAの結果は、クラスの選択と実装、後の段階でのクラス階層の編成と実装のためのプラットフォームを提供することです。したがって、OOA のテストは、次の側面から検討する必要があります。特定された構造のテスト。特定されたトピックに関するテスト。定義された属性とインスタンスの関連付けに関するテスト。定義されたサービスとメッセージの関連付けに関するテスト。
オブジェクト指向設計のテスト
従来の構造化設計手法は、システムを分解し、プロセス実現系をベースに構築されたジョブ群を提案し、問題領域の分析を解決領域の設計に変換し、分析結果を設計フェーズのインプットとするジョブ指向の考え方を採用しています。一方、OODは、OOAに基づいてクラスを要約し、クラス構造を構築したり、さらにクラスライブラリを構築して、分析結果の問題空間への抽象化を実現します。
OODはOOAの別の考え方ではなく、OOAをさらに洗練させ、より高度に抽象化したものであり、OODとOOAの境界を厳密に区別することは通常困難であることがわかります。 OODは、現在の要求分析の要求を満たすためにクラスとクラス構造を決定するだけでなく、より重要なことは、組み替えや適切な補足を通じて、ユーザーの要求に継続的に適応するために、機能の再利用と拡張を容易に実現することができます。したがって、OODのテストは次の3つの側面から考える必要があります。構築されたクラス階層のテストクラスライブラリのサポートテスト
オブジェクト指向プログラミングのテスト
典型的なオブジェクト指向プログラムでは、継承、カプセル化、ポリモーフィズムといった新機能により、従来のテスト戦略を変更する必要があります。
カプセル化とは、データを隠すことであり、外部は提供される操作を通じてのみデータにアクセスしたり、変更したりすることができます。これにより、データが恣意的に変更されたり、読み書きされたりする可能性が低くなり、従来の手順におけるデータの不正操作のテストを減らすことができます。
継承はオブジェクト指向プログラムの重要な特徴です。継承はコードの再利用性を高めると同時に、エラーが伝播する確率を高くします。
ポリモーフィズムはオブジェクト指向のプログラムを外部的に強力にしますが、同時にプログラム内の「同じ」関数の振る舞いを複雑にします。
オブジェクト指向のプログラムは、機能の実装がクラス間で分散されています。機能を正しく実装したクラスは、メッセージパッシングを通じて協調し、設計で要求された機能を実現します。したがって、OOP の段階では、クラス機能の実装の詳細は無視され、テストの焦点はクラス機能の実装とそれに対応するオブジェクト指向プログラムのスタイルに置かれます。データメンバがデータカプセル化の要件を満たしているかどうか。クラスが必要な機能を実装しているかどうか。
オブジェクト指向ユニットテスト
従来の単体テストは、ソフトウェア設計の最小単位であるモジュールに対して行われ、詳細な設計仕様に基づいています。単体テストでは、モジュール内のエラーを発見するために、モジュール内のすべての重要な制御パスのテストケースを設計する必要があります。ユニットテストは、ホワイトボックステスト技法を使用し、システム内の複数のモジュールを並行してテストすることができます。
オブジェクト指向ソフトウェアでは、ユニットの概念が変わります。個々のモジュールの代わりに、各クラスやクラスのインスタンスは、このデータを操作する属性や操作をカプセル化し、テスト可能な最小単位がカプセル化されたクラスやオブジェクトになります。その結果、単体テストの意味が大きく変わりました。もはや、個々の操作は単独でテストされるのではなく、操作はクラスの一部として扱われます。
オブジェクト指向統合テスト
伝統的な統合テストでは、2 つの典型的な統合戦略があります。トップダウン統合は、主制御モジュールから開始し、深さ優先または幅優先の戦略で、ソフトウ ェアの制御階層に従ってモジュールを徐々に統合していきます。ボトムアップ統合：「原子」モジュールから開始し、テストのためにそれらを組み立てるもの。オブジェクト指向ソフトウェアには階層的な制御構造がないため、従来のトップダウンとボトムアップの統合戦略はもはやあまり意味を持ちません。
さらに、一度に1つの操作を1つのクラスに統合することは、しばしば不可能です。また、OO ソフトウェアの統合テストには、2つの異なる戦略があります。1つ目はスレッドベースのテストと呼ばれるもので、システムへの入力やイベントに必要な一連のクラスを統合し、各スレッドを個別に統合してテストし、リグレッションテストで副作用が発生しないことを確認します。もうひとつは、利用ベースのテストと呼ばれるもので、他のクラスをほとんど利用しないクラスが最初にテストされ、システムの構築を開始し、独立したクラスがテストされた後、独立したクラスを利用する次のレベルのクラスがテストされます。このクラス依存レベルでの一連のテストは、完全なシステムが構築されるまで続きます。
オブジェクト指向システムテスト
システムテストは、ソフトウェアの全体的な動作性能を検出するだけでなく、別の側面から見れば、ソフトウェア開発の設計を再確認することでもあります。
オブジェクト指向テストの全体的な目標は、最小の労力で最大のエラーを発見することであり、これは従来のソフトウェアテストの目標と同じですが、OOテストの戦略は従来のテストとは大きく異なります。この違いは、主に2つの側面に反映されています。1つ目は、テストの焦点がプロセスの成果物からクラスに移ったこと、2つ目は、テストの視点が分析および設計モデルを含むように拡張されたことです。
