ソフトウェアテスト

1月 1, 2003 · Posted in ソフトウェアテスト · Comment 

テストの重要性はかなり昔から説かれているが、きちんとしたテストを行っているプロジェクトは少ないように思う。なぜ設計〜開発の遅延に対してテスト工数を減らすのだろうか。
とりあえずメモ書き。

Vモデル

要求分析
基本設計（外部設計）
詳細設計（内部設計）
実装（コーディング）
↑
↓
静的チェック（文法チェック（コンパイラ））
単体テスト
結合テスト
システムテスト

ウォーターフォール開発の構築とテストの関係をVモデルと呼ぶ。要求分析〜システムテストまでの流れを開発者、ユーザーという概念も考慮してモデル化すると、アルファベットのVのような図になるため、この名称が付けられた。

最近ではアジャイル開発プロセスが主流となっているので、静的チェック〜システムテストの一連の流れは一貫して行われるのではなく、繰り返し行われることが多い。そして単体テストは開発と平行して随時行われることもあるので、開発プロセスの中で決まった位置に出現するわけではない。

テストの粒度（単体・結合・システムなどの区分け）は、今も昔もほぼ同じ考え方で適応することができるが、開発プロセスがウォーターフォールからアジャイル開発にシフトしている影響をうけ、ソフトウェアテストもまた、アジャイルな開発プロセスにあわせた形式で行わなければならない。

静的チェック

昔は記述したソースコードをコンパイルするのに手間がかかったのに加え、文法チェッカが存在しない言語もあったので、文法上の誤りなどを目視チェックで確認していた。この作業が静的チェックである。
最近ではソースコードの構文は、IDEなどの機能でチェックすることが可能であるのに加え、コンパイルも容易に行うことができるようになったので、静的チェックを意識する必要がほとんどなくなった。

※静的チェックの例として、HTMLの文法をチェックするAnother HTML-lint gatewayがある。

単体テスト

構造化プログラミングなどの、一昔前に主流であったプログラミング技法ではモジュールや関数単位で単体テストを行うことが多い。

オブジェクト指向プログラミングでは、主にクラス単位で単体テストを実施する。クラス設計がしっかりしていると、単体テストも効果的に行うことができる。逆にテストの容易性を重視した設計を行うこともある。

結合テスト

結合テストでは、単体テストが完了したクラス同士を結合させてテストを行うことで、主にクラス間のメッセージングやインタフェースの正当性をチェックすることになる。
モジュール単位で設計されているシステムでは、外部モジュールの代理としてスタブやドライバと呼ばれるモジュールを用意して結合テストを行っていた。オブジェクト指向のシステムでも似たような方法としてMockオブジェクトを利用する方法がある。
単体テスト時に見逃していたバグや仕様漏れなども、この時点で発見できることが多い

結合テストの技法として以下のものがある

  • トップダウンテスト
  • ボトムアップテスト
  • ビッグバンテスト

トップダウンテスト

階層が上位のモジュールから順に結合を行っていく方法。未結合の下位モジュールに対しては、スタブと呼ばれるダミーモジュールが利用される。

ボトムアップテスト

階層が下位のモジュールから順に結合を行っていく方法。未結合の上位モジュールに対しては、ドライバと呼ばれるダミーモジュールが利用される。

ビッグバンテスト

すべてのモジュールを纏めて結合後、テストを実行する方法。規模の小さいシステムに向いている。

システムテスト

システム全体を対象に、ユーザーの要求をシステムで実現できているか確認する。システムの動作環境やパフォーマンステスト（ストレステスト）もこの段階で行うことが多い。

ホワイトボックステスト

システムの内部構造に着目してテストを行うことをホワイトボックステストという。ソースコード内の条件分岐や命令実行などがきちんと行われているかチェックする。
単体テストの際にホワイトボックステストを行うことが多く、テストの粒度による分類名称がある。

  • 命令網羅(C0:Statement Coverage)
  • 判定条件網羅(C1:Branch Coverage)
  • 条件網羅(C2:Condition Coverage)
  • 複数条件網羅(C無限:Full Coverage)

単体テスト（Unitテスト・Coverageテスト）

命令網羅(C0:Statement Coverage)
コード中のすべての命令を最低一度は実行するようにテストケースを設計すること。

判定条件網羅(C1:Branch Coverage)

コード内のすべての条件判定を一度は実行するようにテストを行うこと。

条件網羅(C2:Condition Coverage)

すべての条件判定において、結果が必ず一度は真と偽になるようにテストケースを設計すること。

複数条件網羅(C無限:Full Coverage)

すべての条件判定の組み合わせを網羅するようにテストケースを設計すること。

ブラックボックステスト

システムの外部仕様に着目してテストを行うことをホワイトボックステストという。ユーザーが求めている機能をシステムが実現できているかチェックする。
内部構造を一切意識せず、入力値に対する出力結果に着目する。

ブラックボックステストを行う際の入力値を導き出す分析方法として以下の技法がある。

  • 限界値分析
  • 同値分析
  • 原因結果グラフ

限界値分析

処理を正常に通過するデータと正常に通過しないデータの境界値を用いてテストデータを導出する技法。境界値に対するバグは比較的発生しやすいので、限界値分析を行うことは非常に有効です。

同値分析

処理を正常に通過するデータ群と正常に通過しないデータ群をそれぞれ集合として捕らえ、集合の中の任意のデータをテストデータとして抽出する技法。

原因結果グラフ

入力と出力の関係を表す表を作成し、テストを行う技法。

テストファースト

テストファーストとは、テストコードを先に記述してからソースコードを記述していく方法である。
テストを記述している時点で仕様の確認も同時に行うことができるというメリットがある。

テスト駆動開発(Test Driven Development – TDD)

テストコードを元に開発を進める手法。TDDは「開発技法」であるということがテストファーストとの明確な違い。

テスティングフレームワーク(Testing Framework)

テストの自動化をサポートするために開発されたフレームワークのこと。POJO(Plain Old Java Object)をテストするものや、特定の環境におけるプログラムをテストするためのフレームワークなど、様々な環境に対応したテスティングフレームワークがあります。

単体テストフレームワークの分類 – （参考：Cactusのドキュメント）

  • コードロジック単体テスト(code logic unit testing)
  • 統合単体テスト(integration unit testing)
  • 機能単体テスト(functional unit testing)

コードロジック単体テスト(code logic unit testing)

コードロジック単体テストとは、特定のコンテナなど、実際の動作環境を使用せずに単体テストを行う方法です。

統合単体テスト(integration unit testing)

統合単体テストとは、特定のコンテナなどを使用して、相互連携を行いながら単体テストを行う方法です。

機能単体テスト(functional unit testing)

機能単体テストとは、コードには着目せず外部からの観点で単体テストを行う方法です。実際の動作環境において、サーバーからの戻り値をテストします。

Tags: no tags