この記事について
高橋寿一さん著の知識ゼロから学ぶソフトウェアテストを読んであまりに感銘を受けたのでついまとめてしまった...
TDD、アジャイル開発隆盛のご時世、あらゆる開発者に読んでほしい良本.
上記本の1章から4章までを ざっくりと まとめた.
心得
- テストケースを書くのはプログラムを書くのよりも圧倒的に難しい
- 例) ユーザが数値を連続して入力した時に、それらの値から作られる三角形が正三角形、二等辺三角形、不等辺三角形を判別するプログラムのテスト
- すべてのバグを見つけるのは無理
- ソフトウェアテストではどの部分にバグが出やすいのか、どのようなテスト手法を適用すれば十分な品質が得られるかを知ることが大事
- バグは遍在する
- ある部分にエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する
ホワイトボックステスト
特徴
論理構造の正しさのみをテストする.
仕様の間違いはテストできない.
一時不要と思われていたがTDDの隆盛により再び脚光を浴びる
具体的なテスト手法 - 制御パステスト
制御構造がどのように実行されるか、どのような振る舞いをするかをテストする
カバレッジ率を取得するために必要
ステートメントカバレッジ
コード内の命令文を少なくとも1回はテストする.
if文の中などをテストする.下の例ではx > 0の時にxに1加算されていることを確認する.
x <= 0のときは確認しない.
弱いテスト手法.
if x > 0
x += 1
end
ブランチカバレッジ
分岐構造に対して条件がそれぞれTRUEのときとFALSEの時をテストする.
カバレッジテストでカバーされないコード
- エラー処理
- 使われていないコード
カバレッジテストで検出できないバグ
- プログラムのループ
- 要求仕様自体の誤りや機能が備わっていないバグ
- データに関するバグ
- マルチタスクや割り込みに関するバグ
※ ループテストの基準としては以下を行うと良い
- ループでテストすべき要件
- ループがスキップされる場合のテスト
- ループの回数が1回の場合
- もっとも典型的なループの回数のテスト
- 最大ループ回数より1少ない回数でのテスト
- 最大ループ回数でのテスト
- 最大ループ回数より1大きい回数でのテスト
ブラックボックステスト
ソフトウェアテストでは4つのふるまいをテストすればOK(James Whittaker曰く)
- 入力処理
- 出力処理
- データ保存
- 計算
同値分割法と境界分析法
ブラックボックステストの中でも基本になる
入力処理と出力処理がテストできる
同値分割法 - どんな入力も正しく処理する
入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業
- 正しい入力が行われる有効同値クラスのテストケースを作成
- 誤った入力が行われる無効同値クラスのテストケースを作成
無効同値クラスは無数にあるので省略せざるを得ないが 省略した部分でエラーを出してはいけない
境界値分析法 - バグの住む場所を探す
プログラムでは境界付近にバグが潜みやすい
有効と無効の境界の もっとも近い異なる2点 をテストする
100 ~ 999の入力を許可する場合
- 100(有効な入力の下限)
- 99(無効な入力の上限)
- 599(有効な入力の真中)
- 999(有効な入力の上限)
- 1000(無効な入力の下限)
- 0(0は特別な値なので必ずテストする)
ディシジョンテーブル - 複雑な入出力のためのテスト
境界値分析法を、多数の入力に対して多数の出力を確認するように拡張 した感じのもの
非常に小さいソフトウェアか大きいソフトウェアの一部分をテストするのに有効
入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記する.
表には状態、ルール(状態の組み合わせ)、動作(アクション)がまとめられ、その表の通りにテストが行われる.
状態遷移テスト
以下の場合に状態遷移テストは有効
- GUIソフトウェア
- オブジェクト指向ソフトウェア
- 通信プロトコルテスト
有限状態マシンを用いるが、一般に状態数が多くなりモデリングが複雑になるのでサポートするツールを用いるとよい
まとめ
- 入力ダイアログボックスがあったら境界値テストを行う
- 複数のダイアログボックスがあったらディシジョンテーブルを使う
- ダイアログボックスの遷移があれば状態遷移テストを行う
これらを行ってそれでもバグが出る時には以下の2点が考えられる.
- ブラックボックステストのアプローチが間違っている
- ホワイボトックステストでしか見つからないバグ
バグの60%くらいはブラックボックステストで見つかる.
すべてのバグをテストで見つけようとするのではなく、
楽に60%くらいのバグを見つけて、それ以外のバグはなぜ発生したのか、どう防止するのかに時間を費やす方が建設的.
探索的テスト
ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト
著者のスライド
http://jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf
テストケースを書いてテストするんじゃなくて、アプリケーションの目的、機能を明確にして、怪しいところを叩くテスト.テスト実行結果は報告し、これらのプロセスを継続的に実行する.
コードの共有を受けた人、十分なトレーニングを受けた人が探索的テストを行うと最強というレポートがある.91%のカバレッジを出せたとも.
to be continued...
- 非機能要求のテスト
- ソフトウェアテスト運用の基本
- ソフトウェア品質管理の基本
- テストの自動化
- それでもテストがうまくいかない人へ