【備忘録】 「はじめて学ぶ ソフトウェアのテスト技法」 を読む
うぃろぅです。
炎上していた前のプロジェクトが無事終了したため読んでいきます。
ちょうど自宅研修が許可されたので都合もいいし。
今日の本
- 作者:リー・コープランド
- 発売日: 2005/11/03
- メディア: 単行本
ながーく使えるテスト設計技本の基礎本。
テストには散々苦しめられたし今一度基本に立ち返ることが大事。
当たり前だが全ての章を詳細に書くわけにはいかないためただのメモになっている箇所がいくつかあるが、思い出せるようにしておくことが大事。
はじめに
そもそもテストなんてどうしてするのよ、なんの意味があるのよ、といったことが語られている。
会社においては品質の担保や保守性の向上が挙げられる。
大事なことは、テストは「安心」のためにあるものではなく「精神的な規律」とするために あるものだということ。快適に開発しような。
1. テストのプロセス
- 順番通りに動かさなければ動かないテスト
- どの順で実行しても動くテスト
前者は一つ一つのテストケースが小さくなるが、後者は大きくなる。どちらが良いかは処理速度や実行時間にも夜ため一概には決められない。
テストの種類は大きく分けて4種類。基本情報とかでよくみるアレ。
全てをテストすることはできないということを念頭に置く必要がある。バグは必ず起きる。
2. ケーススタディ
わかりやすく説明するための例としてケーススタディを付録に用意したよ、というお話。
ブラックボックステスト技法
ブラックボックステストは、「中身が詳細にわからないプログラム」のテスト。
要件と仕様書を頼りにテストを行う。
全てのテスト工程で適用可能である。
実装全てをテストすることは当然不可能だが、正しく実施すれば少ない手順で多くをテストできる…はず。
3. 同値クラス
例えば「学生の学科テスト」の入力データを検証するプログラムがあったとして、
- 点数は
0~100 - クラスは
1~9 - 学年は
1~3
が検証OKになるとする。この時、それぞれの値にそれぞれ-1, 0, 1, 2…と順番に値を入れていってテストする必要はないよね、ということ。
| 点数 | クラス | 学年 | 期待値 |
|---|---|---|---|
| 21 | 2 | 1 | OK |
| 150 | 3 | 2 | NG |
| 90 | 12 | 3 | NG |
| 70 | 6 | 7 | NG |
というように、それぞれ「正常値」と「異常値」が仕様書に書いてあるのであればその2択で十分テストできるよね、という話である。
言われてみれば当たり前だが、大事な基本。
そもそも文字列を入れてテストするかどうかは仕様によるため、適宜判断が必要。
4. 境界値
同値テストから一歩進んで、同値である範囲の境界値を使ってテストを行う。 例えばさっきの点数で
0~59はC60~79はB80~100はA
という評価をするとしたら、テストケースとしては以下となる。
| 点数 | 期待値 |
|---|---|
| -1 | NG |
| 0 | C |
| 59 | C |
| 60 | B |
| 79 | B |
| 80 | A |
| 100 | A |
| 101 | NG |
-1と101は入力時点で弾く可能性もあるため場合による。
同値の境界を適切にテストすれば十分だよね、という考え方。
5. デシジョンテーブル
表が大きくなるため具体例は書かないが、複合条件によって期待値が一つに定まる場合は表にしてそれぞれの値を適切に管理してテストを実行すべし、という話である。
ラジオボタンが「携帯電話」が「電話番号(携帯電話)」が入力必須、「固定電話」なら「電話番号(固定電話)」が入力必須とか、そういう時にちゃんとラベルごとに整理して試験しようねと。
ここでの条件が連続値の範囲だった場合、境界値の考え方も有効である。知識が連鎖していく。
6. ペア構成
組み合わせが膨大になるテストがある際、直交表を元に値を決定してテストを行うことで全ての組み合わせを網羅できる、という考え方。
https://geechs-magazine.com/tag/lifehack/20161004_1
例えばこの記事が詳しい。
もしくは、全ペアを生成するアルゴリズムを用いて全ペアを生成する方法でも考え方は同じ。
このページからダウンロードできる。
どちらにしてもテストケースを大幅に減らすことが可能なため、存在を知っておくことが大事。
7. 状態遷移
状態遷移図や状態遷移表を用いたテスト。
こちらの記事が詳しい。
例えばオタクの敵であり友である「e+」のチケット状態が「支払い待ち」 → 「発券待ち」 のような状態を試験する。今だと「払戻待ち」も重要かな。
8. ドメイン分析
複数の変数を同時にテストするときの技法。
ドメインテストとは from Kumiko Ohmi
www.slideshare.net
こちらのスライドがとてもわかりやすい。
9. ユースケース
いわゆるシナリオテスト。1人のユーザーが新規登録して何かしらのアクションをして…といったケースを用意し、その通りに操作できるかどうかをテストする。
もちろん正常系だけではなく変な操作(戻って最初からやり直す操作)も行う。デバッグ作業めいたもの。
それぞれの機能について最低1回ずつ試験すれば概ねカバーできるため、システムテストに良さそう。
ここまでがブラックボックステスト技法である。ペア構成テストはこれまでしっかり学んでこなかったためがっつり学習せねば。
ホワイトボックステスト技法
プログラムの構造がわかっている際に行うテスト。テストコードを書いて条件分岐を網羅したり異常なデータを作り出してエラーを検証したりするのはこちら。
単体テストだけではなく結合テストやシステムテストにも適用可能なテストが存在する。
その性質上、プラグラムに関する知識が必要不可欠となる。
こちらも大事なのは全ての入力データに対するテストは困難であることを知っておくこと。
10.制御フロー
条件分岐があるプログラムに対して、命令網羅、分岐網羅、条件網羅…とフローを追ってテストしていく。
基本情報試験等でよく出るので知っている人も多いはず。
一つ一つのメソッドを小さく設計すればそこまで負担にならない…はず。
11. データフロー
プログラムの中で変数が意図していない値になっていないかを試験する。
スコープが正しく設定されているか、といったことも同じ観点。
Haskellのような再代入不可の言語はここが強い気がする。
ホワイトボックステスト技法については以上。よりこまかく試験できるよ、とざっくり理解。
テストのパラダイム
パラダイムとは、ざっくり「考え方の規範になるもの」ということ。
パラダイムシフトという言葉は聞いたことがあるはず。
テストにおいては大別して「スクリプトテスト」と「探索的テスト」の2つのパラダイムが存在する。
12. スクリプト
ウォーターフォールのプロセスの一部として登場するテスト。
テストが開始できるようになる前からテストを計画する。
「仕事を計画し、計画に従って仕事する」という言い方が的確。
要約されたドキュメント(原文)がこちら。
本では噛み砕かれて説明している。
13. 探索的
プログラムについての探索をしながらテストを進めていくパラダイム。
「ウミガメのスープ」や「20の扉」のように「これができるか調べる」 → 「解決する」の繰り返しをテストに当てはめていく考え方。
スクリプトテストと違ってテストの習熟度が効率に大きな差をもたらすが、熟練のテスト設計者がテストを実行した時の効果がとても大きい。
スクリプトテストの補完として実行しても有用なため、どちらかが絶対的に優れているということはない。適材適所。
14. テスト計画
テスト計画は、一回したらそれっきりということではなく、継続したプロセスであるということが解説されている。
PDCA、大事。
支援技法
テストが大事だということはわかった。では、何をテストの開始地点として何をテストの終了地点とすればいいのよ、という話。
そのための足がかりとしての支援技法の解説。
15. 欠陥の分類
テスト計画のとっかかりとして、またテスト抜け漏れ防止のチェックリストとして様々な人が提唱した欠陥の分類が説明されている。
分類に唯一の正解は存在しないため、既存の分類を基に自分の分類を作り上げていく必要がある。
「私は通信処理でバグを入れ込みやすいから分類を詳細にしておこう」とか「変数を極力使わないコーディングをしているからデータフローは一般的なチェックで十分」とか。
分類はテストをMESEにするために大事。
16. テストの終了判定
バグを全て見つけられることに期待はしないほうがいいため、じゃあいつ終わればいいのよ、と。
(テストが完了していない箇所も含めて)全体の見通しがついたら、というのが一つの基準になりそう。
「わかりやすいバグは全て改修が終わって起きるとしたらこことここの処理のレアケース」のような状態であれば世に出しても大抵なんとかなる。
致命的でなければ出したらもう直せないわけではないし。
個人的には「いいから出荷しろ」と上司に言われたら、というケースが非常に納得がいく。納期。うーむ。
終わりに
座学だけでは身につかない。いいから手を動かすんだよ!!(雑な要約)
読後感
やはり「知識のインデックス」を作ることが大事。
テスト設計をする際に読み返すと大きな支えになりそうな良本だった。
ではまた。
