ソフトウェアテストを学ぶ その３．ソフトウェアテストの種類

こんちは。見る夢全てオールカラー、ふっくら太郎です。

今回は「ソフトウェアテストの種類」について勉強したいと思います。

ソフトウェアテストの種類

ソフトウェアテストは、確認方法や確認内容によって次のように分類できる。

• 「ソフトウェアテストの方法」で分類

　　　＝　動的テスト

　　　＝　静的テスト

• 「ソフトウェアテストの技法」で分類

　　　＝　ホワイトボックステスト

　　　＝　ブラックボックステスト

•  「ソフトウェアテストの範囲」で分類

　　　＝　単体テスト

　　　＝　結合テスト

　　　＝　システムテスト

　　　＝　受入テスト

「ソフトウェアテストの方法」で分類してみる

ソフトウェアテストは、「動的テスト」と「静的テスト」の２つの実行方法で分類できる。

動的テスト

「動的テスト」はソフトウェアを動作させて確認するテスト。テスト工程で行う。

主な動的テストは・・・

• デバック
• 単体テスト
• 結合テスト
• システムテスト
• 受入テスト

などがある。

人ががっつりテストしたり、自動テストなどが、動的テストに該当する。

静的テスト

「静的テスト」はソフトウェアを動作せず行うテスト。開発工程で行う。

主な静的テストは・・・

• 各種仕様書のレビュー
• ソースコードレビュー
• 机上デバック
• ソースコードの静的解析

などがある。

ソフトウェアテストは、ソフトウェアの検証だけでなく、ソフトウェアの設計図である各種開発仕様書の設計検証も対象となる。

そのため、レビューもソフトウェアテストに含まれる。 

 「ソフトウェアテストの技法」で分類してみる

ソフトウェアテストをテスト技法で分類すると、「ホワイトボックステスト」と「ブラックボックステスト」に分かれる。

ホワイトボックステスト

「ホワイトボックステスト」はソフトウェアの内部構造(制御フローやデータフロー)に着目して確認するテスト。

ホワイトボックステストで使われる主なテスト技法は・・・

• 制御フローテスト
• データフローテスト

などがある。

ソフトウェアの論理構造の検証が目的のテストなので、カバレッジレベル (網羅率)が高いテストを実施するほど、ソフトウェア品質は高まる。

でも、その分テストに掛かる工数、費用は増える。

ブラックボックステスト

「ブラックボックステスト」はソフトウェアの入力と出力に着目して確認するテスト。

ブラックボックステストで使われる主なテスト技法は・・・

• 機能テスト
• 状態遷移テスト
• 境界値テスト
• 同値クラステスト
• デシジョンテーブルテスト
• 組み合わせテスト

などがある。

ブラックボックステストは、プログラム的に影響する入力条件に限定して確認するテスト。

パターン網羅を目的としていないため、ホワイトボックステストで論理構造の設計検証を十分に行った上で実行する必要がある。 

でないと、バグが山ほど出る。

「ソフトウェアテストの範囲」で分類する

ソフトウェアテストは開発工程毎にテストを分類できる。

上の図は「V字モデル」と呼ばれる開発モデル (開発に必要な工程や方法を標準化したもの)で、V字の左部分は、開発工程を並べており、右部分はそれに関連するテスト工程を並べている。

左上の要件定義から右上の運用テストまでを工程毎に順番に実施することで、品質の高いソフトウェアを作ることができる。

 開発工程

• 要件定義

　　　＝　顧客の要求・要望を抽出し、ソフトウェア作成に必要な要件を定義する。

• 基本設計

　　　＝　要件定義の内容をもとにソフトウェアの基本機能や、実現方法を決める。

• 詳細設計

　　　＝　基本設計をもとにソフトウェアの機能の詳細な実現方法を決める。

• プログラム設計

　　　＝　詳細設計をもとに必要なプログラム構成、具体的な処理内容を決める。

　　　　　またプログラムをテストするためのテスト書 (単体テスト書)を作成する。

• 実装

　　　＝　プログラム設計の内容に従い、ソースコードを作成する。

 要件定義からプログラム設計までの開発工程では、ソフトウェア作成に必要な各種開発仕様書を作成する。実装工程ではソースコードを作成する。 

テスト工程

テスト工程では、各開発仕様書を元にテスト書を作成し、ソフトウェアテストを行う。

• 単体テスト

　　　＝　プログラムを構成する部品単位で行うテスト。論理構造を設計検証する。

• 結合テスト

　　　＝　複数のモジュールやコンポーネント、システムを結合して確認するテスト。

　　　　　入力に対して期待した出力が行われることをもって、インターフェイス間の

　　　　　動作を確認する。

• システムテスト

　　　＝　システムが仕様に従い動作することを確認するテスト。

　　　　　機能要件だけでは無く、性能や脆弱性など非機能要件もテストする。

• 受入テスト

　　　＝　システムがユーザーの要求通り動作することを確認するテスト。

　　　　　実際の業務フローや実データを使用して問題無くシステムが稼働することを

　　　　　確認する。

 各開発工程ごとにテストを行い、開発プロセスが正しく行われていることの検証、成果物の妥当性確認を行うことを「verification and validation (検証と妥当性確認)」という。

単体テスト～システムテストまでは、対象の開発仕様書の通りソフトウェアが作られ、動作することを確認する。

(仕様書の記載通りソフトウェアが作られていることを検証する)

運用テストでは、ユーザーの要求通りソフトウェアが動作することを確認する。

(ユーザーの要求と各開発仕様書の妥当性を確認する)

 まとめ

• ソフトウェアテストは、確認方法や確認内容によって分類できる。
• テスト工程毎に適切なソフトウェア技法、実行方法を選択し組み合わせることで、機能的かつ効率的に必要なテストを行うことが可能になる！　　　　　　　

つまり、開発サイクルを通じて、開発工程と一貫でテスト計画、戦略を立てることが重要になる。

[参考]

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

若手SEのための ソフトウェアテストの常識