こんな本読みました。
知識ゼロから学ぶソフトウェア開発
高橋寿一さん著の知識ゼロから学ぶソフトウェアテストを読んでみたのでまとめてみました。
【もくじ】
- ソフトウェアテストの基本
- エンジニアが最もよく使う手法
- 探索的テスト
- 機能あらざるもののテスト・難関テストに挑む
バグとは何かを考える。
IEE Software誌の元編集長であり『 コードコンプリート（ Code Complete）[ MCC 04]』 の著者でもあるSteve McConnellはこんなことと言ってるらしい。
###ソフトウェアテストは最もポピュラーな品質改善方法である。
どんなソフトウェアにもバグは潜んでいる。
###品質が悪いソフトウェアとは
バグによって本来の機能が制限され、そのソフトウェアに期待される機能（価値）を顧客やユーザーに提供出来ないもの
ソフトウェアのバグは最悪人命に関わることもある。
###『アリアン5』フライト501
【1996年6月4日―『アリアン5』フライト501】
アフリカの欧州宇宙機関の開発したロケット、アリアン5は1996年4月に快晴の中で所定の時刻に打ち上げられた。
点火シークエンス後40秒にして高度3,700mに達した。しかし、その後突然軌道を外れて、自壊。爆発事故を起こした。
事故は64ビットの浮動小数点数を16ビットの符号付き整数に変換する際に起きたオペランドエラーが原因で、バグによりコンピュータがクラッシュし、エンジンが過剰に出力され爆発を引き起こしてしまった。
最終的な損害 : 日本円にして600億円
--
wired「史上最悪のソフトウェアバグ」ワースト10を紹介
NASAの火星探査機が行方不明に
1999年9月23日
エンジン噴射推力の計算を行うプログラム内部での単位の扱いをヤードとメートルで間違えていたことにより火星探査機が行方不明に。
｢Faster, Better, Cheaper｣（早く、良く、安く）の哲学の「Faster, Better」が強調されすぎた。
テストをする者の心得
- バグを全部見つけるのは無理！(バグが残っている可能性はほぼ無限)
- バグが絶対に無いといえるソフトウェアはほぼ存在しない
例えば、以下のプログラムで最大限のテストを行うとなると、
入力 A： 1 から 999 まで 入力 可能
入力 B： 1 から 999 まで 入力 可能
出力 C： A×B
Aに1を入れてBに100を入れるテスト、 Aに999を入れてBに999を入れるテストがある。
999 × 999 = 998, 001（ 約 100 万）通りのテストを行わなければ完全無欠のソフトウェアと証明出来ない。
- エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない
- バグは偏在する。
- プログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例する。
- テストケースを書くことはプログラムを書くことより難しい
ソフトウェアテストではどの部分にバグが出やすいのか、どのようなテスト手法を適用すれば十分な品質が得られるかを知ることが大事
ホワイトボックステスト
特徴
ソフトウェアテスト黎明期から行われているテスト
論理構造の正しさのみをテストする
仕様の間違いは検知出来ない
制御パステスト
####ステートメントカバレッジ
コード内の命令文（ステートメント）を少なくとも一回は実行して動作を確認する。
以下の例では、x > 3の時にxに1加算されていることを確認する.
if x > 3
x += 1
end
X >= 3の時は確認しない。
分岐はチェックしないので、非常に弱いテスト手法だと言える。
####ブランチカバレッジ
テスト対象となるプログラムコード内部の分岐（ブランチ）の可能なすべて結果（真偽）のうち、テストを実施する
#####カバレッジテストでカバー出来ないコード
- エラー処理
- 使われていないコード
カバレッジテストで発見出来ないバグ
- プログラムのループに関するバグ
-カバレッジの基準が定まっていない
【ループのテストは以下をやるとよい】
ループがスキップされる場合のテスト
ループの回数が1回の場合
もっとも典型的なループの回数のテスト
最大ループ回数より1少ない回数でのテスト
最大ループ回数でのテスト
最大ループ回数より1大きい回数でのテスト
- 要求・仕様自体が間違っていたり、機能が備わっていないバグ
- データに関するバグ
- タイミングに関するバグ
これまでのホワイトボックステストのメリット
カバレッジのテストをやることで、ソフトウェアテストにおいて、テスト対象となるプログラムコード（内部ロジック）全体の中で、テストが行われた部分が占める割合を一定数値として出すことが出来る。
デメリット
カバレッジが100％に近づけば近づくほど、それにかかるコストは等比級数的に増えていく。
--
ホワイトボックステストはITの発達により書かれるプログラムのサイズが大きくなればなるほど、効率よくテストするには向かない手法だと言われてきたが、アジャイルやスクラムの開発
手法が脚光を浴びると、ホワイトボックステストが再度注目されはじめた。
ブラックボックステスト
プログラムを一種のブラックボックスと見立て、 さまざまな入力を行うことによって、 ソースコードを利用せず（見ずに） テストを行う手法。
James Whittaker 曰くソフトウェアテストでは4つのふるまいをテストすればOKらしい
- 入力処理
- 出力処理
- データ保存
- 計算
同値分割法と境界分析法
ブラックボックステストの基本
入力処理と出力処理をテストする。
####同値分割法
＜ 要求仕様 ＞
入力 A： 1 から 999 まで 入力 可能
入力 B： 1 から 999 まで 入力 可能
出力 C： A×B
＜コード＞
if( a > 0 && a <= 999)
// 正しい 値 が 入力 さ れ た とき の 処理
else
// 間違っ た 値 が 入力 さ れ た とき の 処理
end
有効同値（プログラムが期待する入力値）と無効同値（有効同値以外の入力値）に分けてテストする。
無効同値のテストは実際の現場ではある程度省略されるのはやむを得ないが、省略したテストケースでバグを出すことは許されない。
#### 境界値分析法
同値分割法と常にセットで行われる。
プログラムでは境界と呼ばれる場所にバグが潜んでいる可能性が高い。
前述のプログラムを例に上げると 1 と 999 の周りの数値は非常にバグになりやすい入力値である。 なぜならプログラム上は無効同値と有効同値の間に必ず条件文が必要になり、その 文が正しく書けていないことがあり得るから。
・境界値 0,1,999,1000
on-offポイント法
条件分岐の一番近い異なる2つの入力値でテストする
ディシジョンテーブル手法
非常に小さいソフトウェアか大きいソフトウェアの一部分をテストするのに有効。
入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記する。
表には状態、ルール(状態の組み合わせ)、動作(アクション)がまとめられ、その表の通りにテストが行われる。
状態遷移テスト
プログラムの状態と操作による状態の遷移を表にまとめ、プログラムがどのように状態遷移するか、そして、しないかを表現し、正しく遷移するか(正常系)、しないか(異常系)のテストを網羅的に行う。
- GUIソフトウェア
- オブジェクト指向ソフトウェア
- 通信プロトコルテスト
などには有効である。
ブラックボックステストをやっても以下の場合にバグが新たに見つかる場合がある。
- ブラックボックステストのアプローチが間違っている。
- ホワイトボックステストでしか見つからないバグが見つかった。
60％のバグが見つかればOK!
探索的テスト
テストケースを書いてテストするんじゃなくて、アプリケーションの目的、機能を明確にして、怪しいところを叩くテスト.テスト実行結果は報告し、これらのプロセスを継続的に実行する
テストの自動化
テストコードの保守コスト低く保つことが重要。
自動化に向くテスト
- スモークテスト たくさんの回数繰り返すため
- パフォーマンステスト たくさんの人を集めるより、ツールでたくさんの人をシミュレートした方が良い
- APIのテスト APIはそれほど変わらないため
自動化に向かないテスト
- 回帰テスト
- グラフィックやサウンドのテスト