OOAD-テストと品質保証

プログラムコードを記述したら、その中のすべてのエラーを検出して処理するためにテストする必要があります。テストの目的で、いくつかのスキームが使用されます。

もう1つの重要な側面は、プログラムが目的の目的を果たしているかどうかを確認するプログラムの目的の適合性です。適合性はソフトウェアの品質を定義します。

オブジェクト指向システムのテスト

テストは、ソフトウェア開発中の継続的なアクティビティです。オブジェクト指向システムでは、テストには、単体テスト、サブシステムテスト、およびシステムテストの3つのレベルが含まれます。

ユニットテスト

単体テストでは、個々のクラスがテストされます。クラス属性が設計に従って実装されているかどうか、およびメソッドとインターフェースにエラーがないかどうかがわかります。単体テストは、構造を実装するアプリケーションエンジニアの責任です。

サブシステムテスト

これには、特定のモジュールまたはサブシステムのテストが含まれ、サブシステムリードの責任です。これには、サブシステム内の関連付けと、サブシステムと外部との相互作用のテストが含まれます。サブシステムテストは、サブシステムの新しくリリースされた各バージョンの回帰テストとして使用できます。

システムテスト

システムテストには、システム全体のテストが含まれ、品質保証チームの責任です。チームは、新しいリリースを組み立てるときに、回帰テストとしてシステムテストを使用することがよくあります。

オブジェクト指向のテスト手法

グレーボックステスト

オブジェクト指向プログラムをテストするために設計できるさまざまなタイプのテストケースは、グレーボックステストケースと呼ばれます。グレーボックステストの重要なタイプのいくつかは次のとおりです。

  • State model based testing −これには、状態カバレッジ、状態遷移カバレッジ、および状態遷移パスカバレッジが含まれます。

  • Use case based testing −各ユースケースの各シナリオがテストされます。

  • Class diagram based testing −各クラス、派生クラス、関連付け、および集計がテストされます。

  • Sequence diagram based testing −シーケンス図のメッセージのメソッドがテストされます。

サブシステムテストの手法

サブシステムテストの2つの主なアプローチは次のとおりです。

  • Thread based testing −サブシステムで単一のユースケースを実現するために必要なすべてのクラスが統合され、テストされます。

  • Use based testing−階層の各レベルのモジュールのインターフェースとサービスがテストされます。テストは、個々のクラスからクラスで構成される小さなモジュール、徐々に大きなモジュール、そして最後にすべての主要なサブシステムまで始まります。

システムテストのカテゴリ

  • Alpha testing −これは、ソフトウェアを開発する組織内のテストチームによって実行されます。

  • Beta testing −これは協力する顧客の選択されたグループによって実行されます。

  • Acceptance testing −これは、成果物を受け入れる前に顧客によって実行されます。

ソフトウェア品質保証

ソフトウェアの品質

SchulmeyerとMcManusは、ソフトウェアの品質を「ソフトウェア製品全体の使用への適合性」と定義しています。高品質のソフトウェアは、本来の機能を正確に実行し、ユーザーが定めた要件仕様の満足度の観点から解釈されます。

品質保証

ソフトウェア品質保証は、ソフトウェア製品が使用に適している程度を決定する方法論です。ソフトウェアの品質を判断するために含まれるアクティビティは次のとおりです。

  • Auditing
  • 標準とガイドラインの開発
  • レポートの作成
  • 品質システムのレビュー

品質要因

  • Correctness −正確さは、ソフトウェア要件が適切に満たされているかどうかを決定します。

  • Usability −ユーザビリティは、ソフトウェアをさまざまなカテゴリのユーザー(初心者、非技術者、専門家)が使用できるかどうかを決定します。

  • Portability −移植性は、ソフトウェアがさまざまなハードウェアデバイスを備えたさまざまなプラットフォームで動作できるかどうかを決定します。

  • Maintainability −保守性は、エラーの修正とモジュールの更新の容易さを決定します。

  • Reusability −再利用性は、モジュールとクラスを他のソフトウェア製品の開発に再利用できるかどうかを決定します。

オブジェクト指向メトリクス

メトリックは、プロジェクトメトリック、製品メトリック、およびプロセスメトリックの3つのカテゴリに大きく分類できます。

プロジェクトメトリクス

プロジェクトメトリクスを使用すると、ソフトウェアプロジェクトマネージャーは進行中のプロジェクトのステータスとパフォーマンスを評価できます。次のメトリックは、オブジェクト指向ソフトウェアプロジェクトに適しています-

  • シナリオスクリプトの数
  • キークラスの数
  • サポートクラスの数
  • サブシステムの数

製品メトリクス

製品メトリクスは、開発されたソフトウェア製品の特性を測定します。オブジェクト指向システムに適した製品メトリックは次のとおりです。

  • Methods per Class−クラスの複雑さを決定します。クラスのすべてのメソッドが等しく複雑であると想定される場合、メソッドが多いクラスはより複雑であるため、エラーが発生しやすくなります。

  • Inheritance Structure−いくつかの小さな継承ラティスを持つシステムは、単一の大きな継承ラティスを持つシステムよりも適切に構造化されています。経験則として、継承ツリーのレベル数は7(±2)を超えてはならず、ツリーのバランスが取れている必要があります。

  • Coupling and Cohesion −結合度が低く、凝集度が高いモジュールは、再利用性と保守性が向上するため、より適切に設計されていると見なされます。

  • Response for a Class −クラスのインスタンスによって呼び出されるメソッドの効率を測定します。

プロセスメトリクス

プロセスメトリックは、プロセスのパフォーマンスを測定するのに役立ちます。それらは、長期間にわたってすべてのプロジェクトにわたって収集されます。これらは、長期的なソフトウェアプロセスの改善の指標として使用されます。いくつかのプロセスメトリックは次のとおりです。

  • KLOC(Kilo Lines of Code)の数
  • 欠陥除去効率
  • テスト中に検出された障害の平均数
  • KLOCあたりの潜在的な欠陥の数