「はじめて学ぶソフトウェアのテスト技法」を読みました。
概要
ソフトウェアテストについて知らないことが多く、会社の先輩がおすすめしていた「はじめて学ぶソフトウェアのテスト技法」を読みました。そのアウトプットのために書いた記事になります。本自体は3-4時間ほどで読めました。初心者が読んでもとても分かりやすく、今まで曖昧だったテスト技法が頭の中で形になった気がします。おすすめです。
テストとは何か
「実際どうなっているか」と「本来はどうあるべきか」を比較するプロセス。
テストケースの設計
テストケースは、以下の3つで構成されるべき
1. 入力
- キーボード、インターフェース、DBからの読み出し、実行環境からのデータなど
2. 出力
- インターフェース、DBの書き込み、システムの実行によって状態や環境が変化することなど
- テストオラクル（テスト対象のソフトウェアの実行結果と比較する期待結果のソースのこと。コードではない。）
3. 実行
- 実行の順番には、以下の2通りがある。
- 前のテストケースに依存するテストケース
- それぞれ独立しているテストケース
テストの種別
ブラックボックステスト
- テスト対象のソフトウェアの要件や使用に基づいてテストを実施する。実装などに関する知識は不要。
グレーボックステスト（はじめて聞いた)
- テスト対象のソフトウェアがどんな風に実装されているのかある程度まで調べ、その知識を生かして通常のブラックボックステストより効果的なテストケースを作成する。
ホワイトボックステスト
- テスト対象のソフトウェアの内部パス、構造、実装に基づいてテストを実施する。プログラミングの詳細なスキルが必要。
テストのレベル
単体テスト→結合テスト→システムテスト（機能テストなど）→受け入れテスト
ブラックボックステスト
- 要件や仕様書をもとにテスト
- 手順（大まか）
- それぞれの入力値に対して期待する出力値を決定
- 選択した入力値を使ったテストを作成
- テストを実行
- 実際の出力と期待する出力を比較
- 適用対象
- 単体テスト、結合テスト、システムテスト、受入テストの全てのテストで適用
- 難点
- ソフトウェアの内部のどれだけの部分をテストできたか知ることが不可能
- 欠陥を見つけるための全ての組み合わせを作成するのは不可能
ブラックボックステストの例
デシジョンテーブルテスト
以下のようなテストケースのテーブルを作成し、テストを行う。
| テストケース1 | テストケース2 | テストケース3 | テストケース4 | |
|---|---|---|---|---|
| 入力 | ||||
| ユーザーは20歳以下か | Yes | Yes | No | No |
| 学生か | Yes | No | Yes | No |
| 期待される結果 | ||||
| アクション1 | 500円割引する | 200円割引する | 100円割引する | 割引しない |
| アクション2 | クーポンの発行をしない | クーポンの発行をする | クーポンの発行をする | クーポンの発行をする |
ペア構成テスト
複数のデータを必要とするシステムにおいて、「すべての変数のすべての値のすべての組み合わせ」をテストするのではなく、「変数値のすべてのペアをテストする」 ペアにすることで、テストケースを大幅に削減できる。
ペアを見つけ出す技法
- 直交法
- 全ペアアルゴリズム
状態遷移テスト
状態遷移図、状態遷移表を使用して行うテスト。
- 状態遷移図：システムが受け取って処理するイベントをシステムの応答と一緒に図にしたもの。
- 状態遷移表：現在の状態、イベント、アクション、次の状態という4つの列で構成された表。
状態
- 円で表される。状態はシステムが1つまたは複数のイベントを待っている状況。状態は過去にシステムが受け取った入力値を記憶し、あとでイベントが発生したときにどう応答するか規定する。状態はシステムの1つ以上の変数値によって表現する。
遷移
- 矢印で表される。イベントによってある状態から別の状態へと変わることを表す。
イベント
- 矢印のそばのラベルで表される。イベントは状態を変更させる何か。
アクション
- /に続くラベルで表される。状態の変更によって引き起こされる操作。
例
テストケースの作成
- 全ての状態を少なくとも１回は訪れるような１組のテストケースを作成する。
- すべてのイベントが少なくとも1回は起動されるような1組のテストケースを作成する。
- テスト対象の全てのパスが少なくても1回は実行されるような１組のテストケースを作成する。
- 全ての遷移を少なくとも１回はテストするような１組のテストケースを作成する。
例
ドメイン分析テスト
複数の変数を一緒にテスト可能な場合に、有効で効率の高いテストケースを特定できる技法。同値クラステストや境界値クラステストをn次の多次元に拡張して一般化したもの。
技法の解説
- onポイントは、境界上にある。
- offポイントは、境界上でなく、境界に隣接する値。
- 境界が閉じている（<=, >=, =で定義されている）とき、offポイントはドメイン境界の外側にある。
- 境界が開いている（<または>で定義されている）とき、offポイントはドメイン境界の内側にある。
- inポイントは、全ての境界条件を観たすが境界上にはない値。
- outポイントはいずれの境界条件も満たさない値。
- それぞれの不等式条件（=>, >, <=, <）に対して、1つのonポイントと1つのoffポイントを選択する。
- それぞれの等値（=）条件に対して、1つのonポイントと2つのoffポイント（1つは条件値より少しだけ小さい値、もう1つは条件値よりも大きな値）を選択する。
| 変数 | 条件 | ポイント | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 数学 | 数学の点数 >= 70 | on | 70 | |||
| 数学 | 数学の点数 >= 70 | off | 69 | |||
| 数学 | 数学の点数 >= 70 | in | 80 | 90 | ||
| 合計点 | 数学の点数 + 国語の点数 >= 140 | on | 80/70 | |||
| 合計点 | 数学の点数 + 国語の点数 >= 140 | off | 90/69 | |||
| 合計点 | 数学の点数 + 国語の点数 >= 140 | in | 70/71 | 69/72 | ||
| 期待される結果 | 合格 | 不合格 | 合格 | 不合格 |
ユースケーステスト
個別のトランザクションの1つ1つをテストすることによって、システムの機能を最初から最後まで通しで実行することのできるテストケースの設計を行う。一般的にはユースケース図を利用。
- ユースケースとは、アクター（ユーザー）がある特定の目的を達成するためにシステムをどう使うかを示すシナリオのこと。
- 主成功シナリオに対して少なくとも1つのテストケースを作成し、さらにそれぞれの拡張に対しても少なくとも1つずつテストシナリオを用意すれば、あるレベルのテストカバレッジは達成できる。
ホワイトボックステスト
-
テスト対象のソフトウェアの内部パス、構造、実装に関する知識をよりどころにしたテスト戦略。詳細なプログラミングスキルを必要とする。
-
手順
- テスト対象ソフトウェアの実装を分析する
- テスト対象ソフトウェアのパスを識別する
- テスト対象ソフトウェアの特定のパスを実行するような入力を求める
- テストを実行する
- 実際の出力結果と期待する出力値を比較する
- テスト対象ソフトウェアが正常に機能しているかどうかを判定する
-
適用対象
- 単体テスト、結合テスト、システムテスト
-
難点
- テストパスの数が、全てテストをすることが不可能なくらい多くなる
- テストケースの選択によっては、データの値に依存する欠陥を見つけることができない
- 制御フローが正確であることが前提
- テスト対象のソフトウェアを理解して評価できるだけのプログラミングスキルをテスト担当者が持っていなければならない
ホワイトボックステストの例
制御フローテスト
プログラムコードのモジュール内の実行パスを識別して、それらのパスを網羅するようなテストケースを作成して実行する。
技法の解説
- 制御フローグラフ
モジュールの制御構造を記述したもの。コードはグラフに変換され、グラフの中のパスが分析され、その分析結果をもとにテストケースを作成する。
a. 処理ブロック
始まりの始まりの部分から終わりの部分まで順次的に実行される、ステートメントの１本の系列。
b. 判定ポイント
モジュール内で制御の流れが変化できる場所
c. 合流ポイント
複数の制御の流れが合流する場所
データフローテスト
モジュール内で使用するデータや変数が「定義→使用→消滅」というライフサイクルを通っているかをデータフローダイアグラムを使用して検証する。
技法の解説
モジュール内全ての変数に関して、定義、使用、消滅の状態を詳細に示した図（データフローダイアグラム）を作成することによって、定義-使用-消滅のパターンが正しいかどうかを確認する。静的データフローテストでは図を机上で検査し、動的データフローテストではテストケースを作成して実行する。
感想
すべてのケースに対してテストをすることは不可能であり、システムやソフトウェアの仕様や要件に応じてブラックボックステストやホワイトボックステストを使い分ける、またはバランスよく取り入れることが大切だと感じました。また、ホワイトボックステストはシステムやソフトウェア、プログラミングに対しての知識が必要であり、実際にテストを行う、テストコードを書くことでより知識が深められるかと思います。この本を読むことで、曖昧だった各テスト技法について知識をつけることができ、とても参考になりました。
Discussion