ソフトウェアテストのお勉強。
ホワイトボックステストとは、プログラムの論理構造が正しいかを解析するテストです。
ホワイトボックステストは論理構造の正しさのみをテストするため、ソフトウェアの仕様が間違っていることから起こるバグは発見できないのです。
しかし2010年を過ぎたあたりから、アジャイルのXPやスクラムが開発スタイルとして流行り出すと、またホワイトボックステストが脚光を浴びてきたように思います。なぜならそういったアジャイル手法では、ホワイトボックステスト手法を用いた単体テストがMUSTだからです。
最後にTDDの本質は確実に品質保証するというより、スピードを持って開発し、そして変更に対して耐性を持つことです。
「ソフトウェアというものは四つの仕事しかない。なので君らはその四つの振る舞いをテストすれば良いのだ。」その四つとは、入力を処理する、出力を処理する、計算を行う、データを保存する。
「同値分割」とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を等価とみなす作業です。
■ブラックボックステストまとめ
まず境界値テストをやってください。そこで境界値に関わるバグをすべてつぶしてください。そしてもし入力エリアが二つ以上あるようなダイアログとかあるようなら、ディシジョンテーブルテストを行ってください。そして状態が遷移するようなソフトウェアの場合は状態遷移をやってください。
開発者の場合、最大で個人のスキルの差が24倍あるとされています。テストの分野においても24倍というと議論の分かれるところですが、まず10倍はあると見て差し支えないでしょう。
■探索的テスト
ソフトウェア機能を学習しながら、テスト設計とテスト実行を同時に行う。
探索的テストの効率性やそのバグ発見能力は、テストケースベースのテストを上回っています。すくなくとも探索的テストがテストケースベースのテストより低い能力を示すデータは現存しません。ということは探索的テストをしない理由はありません。しかし探索的テスト(もしくはほかの手法)単独の手法で品質を確保することはできないので、探索的テスト(もしくはほかの手法)だけでテストを終了することはできないのも事実です。
探索的テストはテスト担当者が十分なそのソフトウェアのドメイン知識を有していて、そしてテストの知識がある場合に抜群に力を発揮します。
■Microsoftはどんなメトリックスを使っているのか
〈バグのメトリックス〉
・時間軸でのバグ発見数
・コンポーネントごとのバグの発見数(バグが多過ぎないか、もしくは少なすぎないか)
〈テストのメトリックス〉
・コードカバレッジ
・テスト担当者以外のバグの発見数
・テストケースの数、テストの自動化率
〈ソースコードのメトリックス〉
・追加、削除、変更されたコードの行数
・KLOCs:どのくらいソースコードの行数が増加しているか
・コードの複雑度:MaCabeのルール
〈ソフトウェアの信頼性メトリックス〉
・実際の顧客がもっとも使うと思われるオペレーションをした際のMTBF
・信頼性成長曲線
・ストレステストを行った際のMTTF
〈ビルドのメトリックス〉
・ビルドにかかる時間
・ビルドで見つかった問題
・ビルドが失敗した原因
〈スケジュールのメトリックス〉
・当初に立てたスケジュールと実際のズレ