ネオシステムの平原です。
今回は、ソフトウェアテストの工程について勉強したことを簡単にまとめてみました。
目次
- テスト工程とは
- テストの種類
- V字型モデル
- 機能要件と非機能要件
- テスト手法(ブラックボックステスト、ホワイトボックステスト、グレーボックステスト)
- ブラックボックステストの代表的なテスト技法
- ホワイトボックステストの代表的なテスト技法
テスト工程とは
開発したアプリや製品が要件どおりに正しく動くか、また、一定の品質を保てているかを検査する工程です。
テスト工程はさらに「テスト計画」、「テストの準備」、「テストの仕様化」、「テストの実行」、「テストの完了」5つのサブ工程に分けることができ、基本的には記載した順にこれら５つのサブ工程を進めていきます。
以下、各サブ工程についての概要です。
テスト計画
テストの準備から完了まで、全てのテスト活動をあらかじめ計画し、指針を定める工程です。
テスト対象システムの仕様を確認し、テストの目的や戦略(テストの目標、対象範囲、方法など)、テストを実施するために必要なタスクやそれらを実行する際の留意点およびスケジュールを決定し、計画書を作成していきます。
テストを行うメンバーや場所といった組織設定も行います。
テストの準備
テスト計画書やシステムの仕様書から、テストケースを作成するために必要な情報の取得と具体的なテスト技法について決定します。また、テスト用の環境設定もこの工程で行います。
テストの仕様化
テストケースの作成を行う工程です。テストーケースではテストの内容、実行条件、実行手順、実行結果といったことを記載します。また、テストを実際に実施するためのテスト用環境について細かい調整が必要な場合はこの工程で行います。
テストの実行
テストケースを基にテストを実際に行います。出力結果を記録し、報告します。
テストの完了
「テストの実行」工程で得られたテスト結果から、テストの目標が達成されているかを評価し、テスト完了の是非を判定します。また、ソフトウェアのリリース後に機能追加やバグ修正などの改良を行うことが予想されるため、それらに備えてテストツール、テストケース及びテストデータといったテスト環境を整理します。
※テスト完了の判定の際に、テスト目標に到達できなかった場合は、その原因について追及します。設計工程が原因の場合、欠陥修正の作業後、再テストを行います。テスト工程が原因の場合は、範囲や影響度の大きさに応じてどの工程まで遡り、どのような対応をするか（例：テスト計画まで遡り再計画、テスト仕様化まで遡りテストケースの修正等）を決定し、テスト工程を再度実施していきます。
テストの種類とV字型モデルについて
テストはテスト対象や目的に応じて「単体テスト」、「結合テスト」、「システムテスト」、「運用テスト」、「受入テスト」の5種類に分類することができます。以下、各テストについての概要です。
単体テスト
1つの機能(モジュール)毎に正しく動作するかを検証するテストです。
結合テスト
複数の機能を組み合わせて、相互に影響しないかを検証するテストです。
システムテスト
全体のシステムが要求仕様に沿って動作するか検証するテストです。
運用テスト
ユーザーがシステムの納品を受け入れる前に、開発者側が本番環境や実際のデータを用いて、ユーザー側が要求する機能を満たしているか確認するテストです。
受け入れテスト
ユーザーがシステムの納品を受け入れるかどうかを判定するためのテストです。運用テスト同様、本番環境や実際のデータを用いて、ユーザー側が要求する機能を満たしているか確認します。
V字型モデル
V字型モデルは、システム開発の開始から終了までの流れを表した一般モデルの一つで、上流から下流までの流れの中で、プログラミング開発から後の工程を折り返すことで、V字型になるように表現されたモデルです。
V字型モデル(一例)
V字にすることで、設計の詳細度に対応するテストの種類について明示的に表現することでき、また、プロジェクトや組織に応じて設計側とテスト側の関係性についてカスタマイズすることができます。
このV字型モデルを活用することで、以下のようなメリットが得られます。
- 開発工程とテスト工程の理解がしやすい
- プロジェクトの進捗状況の把握が容易
- 不具合の原因特定や修正が容易
- 品質の高いシステム開発が可能
機能要件と非機能要件
機能要件と非機能要件はともに、ITシステムの開発においてユーザーが求める要件を表す言葉です。それぞれの要件の概要について以下で説明します。
機能要件
機能要件とはシステムに実装するように要求される機能のことを指します。
以下に機能要件の例を示します。（下記の例は"Microsoft Power Platform と Dynamics 365 の要件を把握する"から引用しています。）
-
販売ユーザーとして、営業案件を失注としてクローズし、今後の販売戦略を改善するために失注した理由を把握できる必要がある。
-
販売マネージャーとして、見積もりの値引きを承認して合計価格を下げ、顧客に値引きを提供できる必要がある。
-
スタッフの経理担当として、後で再度開く必要がないように、保留中の品目があるバッチは閉じないようにする必要がある。
上記例のように、機能要件では機能内容だけでなく、使用者やその機能を使う理由が表記されており、テスト業務においては、それら要件全体の内容を踏まえたうえで、正しく機能が動作しているかをテストする必要があります。
非機能要件
非機能要件とは機能要件以外の要求事項のことを指します。
以下に非機能要件の例を示します。（下記の例は"Microsoft Power Platform と Dynamics 365 の要件を把握する"から引用しています。）
- モバイル以外の内部ユーザーの画面読み込みの平均時間は 3 秒未満です。
- 外部ポータルでは、ケースの送信を実行している 100 人のユーザーに同時に対処できる必要があります。
上記例のように、非機能要件とは「画面の読み込み」や「ケースの送信」といった機能部分ではなく、処理時間の速さや同時接続の負荷に対する強さといった品質に関わる要件のことです。
また、非機能要件では機能の品質について明確に理解できるように具体的な数字で記載しており、テスト業務においてはこの数値に基づいて、テストしていく必要があります。
非機能要件を評価する項目としては以下のようなものがあります。
- 機能性
機能の中で機能要件で要求されている機能以外の性能や品質についての項目です。
(例：出力結果表示する機能について、正しい結果を表示しているか等) - 信頼性
障害や災害が発生しても、業務を維持できるかあるいは復旧できるかの程度を表す項目です。
稼働率やシステムが停止してからの復旧時間などが関係します。 - 使用性
システムの使いやすさや操作性、容易さを表す項目です。 - 効率性
システムの資源（CPU、メモリ、電力）利用量や処理時間からシステムがどれだけ効率的に稼働しているかを評価する項目です。
資源利用量が少なく、処理時間が短いほど効率性が高いといえます。 - 保守性
システム修正の際に、修正のしやすさを表す項目です。
ソースコードの読みやすさやテスト・デバッグの容易さなどが評価点として挙げられます。 - 移植性
異なる環境に移植される際の容易さを表します。
使用するハードウェアやソフトウェアに対するシステムの依存性や移植される際に必要な変更やテスト多さなどが評価点として挙げられます。
テスト手法(ブラックボックステスト、ホワイトボックステスト、グレーボックステスト)
テスト手法には大きく分けてブラックボックステストとホワイトボックステストの２種類があります。
以下、それぞれのテスト手法の概要です。
ブラックボックステスト
要求仕様や外部仕様を基にテストを設計し、ユーザ視点で、外部からの入力に対して出力結果が意図したものであるか検証するテストで、単体テストより大きな対象でのテストで実施されることがほとんどです。メリットとしてはテスト設計が比較的容易である一方で、複数の条件を組み合わせて行うテストについては組み合わせ方に工夫を入れないとテストするデータ量(テストケースなど)が非常に多くなるといった問題が起きます。
ホワイトボックステスト
内部パス、構造や設計情報を基にテストを設計し、プログラムの内部情報を理解した上で一つ一つの動作が意図したものであるかを検証するテストです。テストする対象が小さい場合は効果が高くなる一方で、テスト対象が大きすぎると、把握すべき情報量が多すぎて扱いきれなくなります。そのため、基本的には単体テストで採用されるテスト手法です。
上記記載の通り、ブラックボックステストは結合テスト以上の大きな対象に対して、ホワイトボックステストは単体テストで使うことが多いため、テスト工程では対象の大きさに応じてこれら手法を使い分けてテストすることが一般的です。
また、ブラックボックスとホワイトボックスの中間的な方法としてグレーボックスと呼ばれるテスト手法もあり、こちらについても説明します。
グレーボックステスト
内部パス、構造や設計情報を把握したうえで、ブラックボックステストのように外部仕様に基づいて、意図した動作をするかを確認するテストです。設計やコードの中身を知っていることで、エラーや不具合が起こりそうな箇所を特定することができるため、データ量（テストケース等）を抑えることができる手法です。
ブラックボックステストの代表的なテスト技法
代表的なブラックボックステスト技法について以下にまとめました。
同値クラステスト
- 同値クラス毎に代表的なテストケースを一つ作成する技法です。
- 同値クラスとは同じ動作をする値の集合のことです。
（例：数値型変数xの値域が1 ≦ x ≦ 5のときを真、それ以外を偽が出力されるとした場合、1 ≦ x ≦ 5の領域の集合が同値クラスであり、また、x ≧ 6 or x ≦ 0の領域の集合も同値クラスとなる。） - 同値クラステストでテストケースを作成する場合は代表値となる値を使用します。代表値としては、中間値、デフォルトの設定値や入力される頻度の高い値が採用するケースが多いです。
（例：1 ≦ x ≦ 5の領域の集合が同値クラスの時、代表値として中間値のx = 3をテストデータとして使用する。） - システムの入力として正しい値の集合を有効同値、エラーとなる値の集合を無効同値といいます。
境界値テスト
- 入力項目が連続する領域を持つ場合、同値クラスごとに分類したうえで、各同値クラスの最大値または最小値を境界値とし、境界値毎に境界値と境界値の一つ上及び境界値の一つ下の値の３つを用いてテストケースを作成する技法です。
（例：数値型[整数]の変数xの値が1≦xのときを有効同値クラスとした場合、境界値テストで使用するxの値は0、1、2の3つ） - 境界値付近ではエラーや不具合が発生しやすいため、この技法が使われています。
- 使用する値の内、境界値の一つ上の値と一つ下の値について、同値クラスの境界値と同じ出力結果が出るものについては省略可能です。
（先程の1 ≦ xの例でいうと、x = 2については境界値x = 1と同じ同値クラスに含まれるため省略可能） - 境界値の一つ上の値、一つ下の値については仕様書から入力値の最小単位を確認して設定するがあります。
（例：x = 10を境界値かつ最小単位を0.1とした時、境界値テストで使用するxの値は9.9、10、10.1(省略可)の3つ）
無効値テスト・異常値テスト
- 受け付けることを想定していない値や機能が有効となる領域範囲外の値を入力したときに、エラー処理など正しく動作しているか確認するためのテストケースを作成する技法です。
- これらの技法は同値クラステストと同義になることがあります。(無効同値クラステスト)
ペア構成テスト
- 複数の入力項目の中から2つの項目ペアのパターンをすべて取り出し、また、そのペア毎にすべての条件の組み合わせを網羅しつつ、テストケースの量を作成する技法です。
- この技法は複数の入力条件項目がある際に、全ての条件の組み合わせを網羅してテストケースを作成するには量が多くなりすぎるため、2つの項目の関係性に絞ることでテストケースの量を削減するために使われている。
- ペア構成テストにはオールペア法と直行表の2種類の方法があります。
- オールペア法は全てのテストケースを見たときに各項目ペアの条件の組み合わせについて重複が最小限に抑えられるようにテストケースを作成する方法です。
- 直行表は全てのテストケースを見たときに各項目ペアの組み合わせについてどのペアであっても数が均一に重複するようにテストケースを作成する方法です。
状態遷移テスト
- システムの状態に着目し、状態遷移の全状態を1回経由するようにテストケースを作成する技法です。
- テストケースを作成する際は初期状態と最終状態の間に状態変化した回数(Nスイッチカバレッジ)について設定する必要があります。
（0スイッチカバレッジは途中の状態変化なし、1スイッチカバレッジは途中に状態変化を一度挟みます。）
ドメイン分析テスト
- 複数の変数を同時に入力し、同時入力による影響を確認するために使用するテスト技法です。
- このテスト技法では複数の変数を境界（on）、境界と一つ隣かつ境界と出力が異なる値（off）、境界外（out）、境界上（in）の値で同時にテストします。
- 一つの変数をonまたはoffの値を設定し、それ以外はinの値を使用するテストケースがよくつかわれる。
デシジョンテーブルテスト
- 全ての入力条件とそれらの組み合わせ及び全ての出力をリストアップして整理した表(デシジョンテーブル)を作成し、それを基にテストケースを作成する技法です。
- この技法を使用することで、複雑な条件と結果の関係を視覚化し、仕様についての理解が容易になります。また、不要なテストケースの整理をしつつ、条件や結果の組み合わせについて網羅的にカバーすることができるため、テスト効率や品質を向上させることできます。
ユースケーステスト
- システム利用者が目的を果たすための具体的な手順や、操作結果のフローをまとめたユースケースに基づいてテストを行う技法です。
- この技法を使うことでユーザーの視点からシステム側で求められる機能品質を明確にしつつ検証することができます。
ホワイトボックステストの代表的なテスト技法
代表的なホワイトボックステスト技法について以下にまとめました。
制御フローテスト/制御パステス
- モジュール内の実行パスを識別して、それらのパスを網羅するようにテストケースを作成する技法です。
- 全てのパスを網羅しようとすると莫大なテストケースの量となってしまうため適切な網羅率（カバレッジ）を設定する必要があります。
- カバレッジのレベルは8段階で定義されています。
データフローテスト
- モジュールの全ての変数について、定義-使用-消滅までの流れを少なくとも1回は網羅するテストケースを作成する技法です。
- この技法は「未定義の変数の使用」や「使用しない変数が定義されている」といった不正パターンを見つけるために使われます。
※注意書き
本記事については以下のリンクや文献を参考に記載しております。