## テストで大事なこと

- テストで大事なのは、どの部分にバグが出やすいか、そこをどのようにテストすれば十分な品質が得られるかを知ること
- バグは平均的に散らばっているものではない。バグの出やすい箇所、出にくい箇所がある。(80%のバグが20%のコードに含まれているというデータもある)
- テストは限られた時間で行う最大公約数的な仕事。時間がないからテストしないという選択肢はない
- James曰く、「ソフトウェアは4つの仕事しかしない。なので、その4つの振る舞いをテストすれば良い」
- 4つとは、 `入力を処理する`、 `出力を処理する`、 `計算を行う`、 `データを保存する` それらに対して適切にテストすれば、ほとんどのバグが発見できる
- テストケースを省略するのはやむを得ないが、その省略されたテストケースでバグを出してはいけない
- テストするのに「良いデータ」と「悪いデータ」が存在する
- 良いデータ例
- ユーザーがよく使いそうなデータ
- プログラムが許す最小のデータ
- プログラムが許す最大のデータ
- ゼロ
- 悪いデータ例
- 非常に小さなデータ(-99999,0.0000001など)
- 非常に大きいデータ(999999,1099999など)
- 長いデータ(abdajohadamklmdklamombamoaなど)
- 無効なデータ
- とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、どうやって防止するかに時間を費やすかが、より建設的なテスト担当者の役割
- 品質を目に見えるものにするには
- なるべく誤差がなく人間の市場や恣意に左右されないものを選ぶ
- 開発するソフトウェアの品質を十分代表するものを選ぶ
- Googleのバグ予測システムでは、いつ何回修正されたかしか見ていない。修正された回数が多いほど、修正が最近ほどバグが潜んでいるということ。

# テスト手法

## ホワイトボックステスト

- プログラムの論理構造が正しいかを解析するテスト
- 人間の時間をたくさん使って内部構造を解析しテストする
- 論理構造の正しさのみをテストするため、 `ソフトウェアの仕様が間違っていることから起こるバグは発見できない。`

### 制御パステスト

- プログラムがどのような振る舞いをして、どのように制御されていくかをテストする手法
- カバレッジ率の値を取るために使われる
- 制御パステストによるコードカバレッジテストの本質は、フローチャートをちゃんとカバーすることにある

### ステートメントカバレッジ

- 制御パステストの一部
- ステートメントカバレッジだけでテストを終了することは危険
- 分岐条件がカバーしきれないなど、非常に弱いテスト手法

### ブランチカバレッジ

- `分岐コードに対してそれぞれの判定条件がTrue/Falseの結果を少なくとも1回ずつ持つようにテストケースを書く`
- 分岐を網羅するため、テストケースの数がかなり増える点が問題点
- バグの発生状況を見てから、バグがたくさん出る部分に対してブランチカバレッジを実行するのは悪くないアイデア

## ブラックボックステスト

- ブラックボックステストは、プログラムをブラックボックスと見立てて、 `様々な入力を行うことによって、ソースコード利用せずテストを行う手法`

### 同値分割法

- 同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を透過とみなす作業
- つまり、可能な入力値のうち同様の入力値は等価とみなしてテストする手法
- 同値クラスの分け方は
- 有効同値：プログラムが期待する入力値
- 無効同値：有効同値以外の入力値
- 実践的な同値クラスの選び方は、 `ポイントは代表する同値が全てのエレメントを網羅しているか`です

### 境界値分析法

- 同値分割法とセットで使われる手法
- プログラムで「境界」と呼ばれる場所は常にバグが潜んでいるので、強化位置近くは詳しくテストする必要がある

## ランダムテスト/アドホックテスト

- テストケースを考えず、行き当たりばったり、なんら考えなしに入力や操作を行う手法

### まとめ

テストは

1. まずは強化位置テストを行い、境界地にまつわるバグを全て潰す
2. ディシジョンテーブルテスト行う
3. 状態遷移テストを行う

## 探索的テスト

- ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト
- すべてのテストを実施するのは時間的に無理、できてもすべてのバグは見つからない。
それならいちいちテストケースを書く代わりに、製品を 学習 したうえでテスト 設計 して 実行 してバグ報告を 並行 してやっちゃえば手っ取り早い。 というスタイル
- 探索的テストの唯一のデメリットは、非機能要求(=品質特定)のテストにあまり向かない

## 非機能要求のテスト

- 非機能要求(=品質特定)とは、「ソフトウェアが持つべき特性」で、機能的な側面と非機能的な側面の両方の属性を示したもの。
- とくに大事なのは、機密性、信頼性、パフォーマンス

### パフォーマンステスト

- ソフトウェアを設計もしくは企画する段階で設定されたソフトウェアの性能が期待された通り出ているかをチェックするためのテスト
- レスポンスタイムや、入力データサイズなどの設計前にソフトウェアのパフォーマンスを定義する