徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第9弾。
コンポーネントテストとは
コンポーネントテストは、ユニットテストやモジュールテストとも呼ばれる。
日本では、通常単体テストとも呼ばれている。
テストの目的
コンポーネントとは、独立してテストできる最小単位で、ソフトウェアの機能やモジュールに相当する。
コンポーネントテストは、コンポーネントの振る舞いが設計・仕様通りであるかを検証し、欠陥を検出し、品質を高めることが目的。統合テストやシステムテストなどの上位レベルのテストのコンポーネント内の欠陥を持ち込まず、リスクを低減することができる。
コンポーネントテストの属性
- テストの目的
- ・コンポーネントごとの振る舞いが設計、仕様書通りであることの検証
- ・コンポーネントに存在する欠陥の検出
- ・コンポーネントの品質に対する信頼の積み上げ
- ・欠陥が上位のテストレベルまで見逃されることの防止
- ・リスクの低減
- テストベース
- ・詳細設計書
- ・コンポーネント仕様書
- ・データモデル
- ・コード
- テスト対象
- ・コンポーネント（ユニット、モジュール）
- ・クラス
- ・データベースモジュール
- ・コードとデータ構造の関連性
- 典型的な欠陥と故障
- ・正しくない機能（設計・仕様の記述と異なる）
- ・正しくないコードとロジック
- ・データフローの問題
- アプローチと責務
- ・コードを開発した担当者が行うのが一般的
- ・開発担当者以外が行う場合、その人がテスト対象のコードのアクセスできる必要がある
- ・テスト駆動開発では、テストコードを記述してテスト自動化を行う
以下にコンポーネントテストの特性として次の3点を挙げる。
アジャイル開発におけるリグレッションテストの自動化
ウォーターフォール開発モデルでは、仕様が確定したら"仕様の凍結"を宣言して、その記載内容通りにプログラミングを行う。
インクリメンタル開発モデルやイテレーション開発モデルでは、柔軟に仕様を変えることを是としているため、コードの変更が発生する。そのため、リグレッションテストを自動化して、変更が既存のコンポーネントを破壊していないか確認することが重要である。
ほかのコンポーネントと切り離してテスト
通常システムは、複数のコンポーネントが関連して動作することで目的を果たす。コンポーネントテストを行う際には、サービス仮想化によりダミーのコンポーネントを用意して、自コンポーネントだけを単独でテストする。
サービス仮想化には、テストドライバやスタブのほかに、モックオブジェクトやテストハーネスなどもある。
モックオブジェクト(mock object)とは
テスト対象のオブジェクトが呼び出し先オブジェクトと協調連携するかどうかを検証するために、呼び出し先の代わりに使うダミーオブジェクトのこと。スタブと似たようなもの。厳密な違いは以下。
- スタブ
- テスト対象（System Under Test : SUT）のテストを円滑にするためのもの
- どんな球が来ても優しく打ち返してくれる
- モックオブジェクト
- テスト対象が正しく相手オブジェクト値連携できるか検証するためのもの
- ストライクは打ち返してくれるが、ボールはフェール判定とする
テストハーネス(test harness)とは
テストの実行を自動化するためのソフトウェアのこと。 これは統合テスト、システムテスト、受け入れテストなど、他のテストレベルでも同様。スタブやテストドライバなどのテストスクリプトや、ポートを作成したりするフレームワーク（システム基盤）やソフトウェアシステム全体を表す。- 自動テストのテストハーネス
- テストライブラリを使用してテストスクリプトを実行し、その結果を収集・分析する
- 統合テストのテストハーネス
- 相互に作用する2つのコードまたはモジュールに対し、組み合わせた動作が期待通りか確認する
機能性と非機能性の両方
コンポーネントテストには、機能性と非機能性の両方の検証が含まれる。
両方含むのは統合テスト、システムテスト、受入テストなど、他のテストレベルでも同様。
※コンポーネントテストの対象はコンポーネント。コンポーネントの振る舞いが設計・仕様通りであることを検証し、欠陥があれば検出し、品質を高めることが目的。
テストベース
通常、コンポーネントのテストベースは詳細設計書である。
ケースによってはコンポーネント仕様書を作成していることもあり、その場合はそれがテストベースになる。ER図などのデータモデルもテストベースとして使われる。設計書がない場合は、コードを解析してテストベースにすることもある。
テスト対象
コンポーネントテストの対象は、ある大きさでまとまったコードのかたまりである。
具体的には
- コンポーネント（ユニット、モジュール）
- クラス
- データベースモジュール
などがある。
これらのコードとデータ構造の関連性がテスト対象になる。
典型的な欠陥と故障
機能面型の欠陥や故障は
- 設計書通りに動作しない
- そもそもコードやロジックが間違っている
- データフロー通りにデータが流れない
などがある。
開発担当者は自分で修正を行うことが多いが、その場合でもバグトラッキングシステムに欠陥を報告してから行うと、根本原因分析やプロセス改善に役立つ。
アプローチと責務
コンポーネントテストは、コードを開発した担当者によって行われるのが一般的。
そうでない場合は、少なくともテスト対象のコードにアクセスできる必要がある。
アジャイル開発では、アプリケーションコードを記述する前にテスト用コードを記述する自動テストの手法であるテスト駆動開発などが用いられることもある。
次回
テストレベル-統合テストについて（書いたらリンク貼る）