「知識ゼロから学ぶソフトウェアテスト 【改訂版】」という本が良書と聞き、最近読みました。読んで、各種テスト手法とテスト手法にかかわらず大事なことについてまとめています。

テストで大事なこと

• テストで大事なのは、どの部分にバグが出やすいか、そこをどのようにテストすれば十分な品質が得られるかを知ること
  • バグは平均的に散らばっているものではない。バグの出やすい箇所、出にくい箇所がある。(80%のバグが20%のコードに含まれているというデータもある)
• テストは限られた時間で行う最大公約数的な仕事。時間がないからテストしないという選択肢はない

• ソフトウェアは4つの仕事しかしない。その4つの振る舞いに対して適切にテストすれば、ほとんどのバグが発見できる。その4つとは

  • 入力を処理する
  • 出力を処理する
  • 計算を行う
  • データを保存する

• テストケースを省略するのはやむを得ないが、その省略されたテストケースでバグを出してはいけない

• テストするのに「良いデータ」と「悪いデータ」が存在する

  • 良いデータ例
    • ユーザーがよく使いそうなデータ
    • プログラムが許す最小のデータ
    • プログラムが許す最大のデータ
    • ゼロ
  • 悪いデータ例
    • 非常に小さなデータ(-99999,0.0000001など)
    • 非常に大きいデータ(999999,1099999など)
    • 長いデータ(abdajohadamklmdklamombamoaなど)
    • 無効なデータ

• とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、どうやって防止するかに時間を費やすかが、より建設的なテスト担当者の役割

• 品質を目に見えるものにするには

  • なるべく誤差がなく人間の市場や恣意に左右されないものを選ぶ
  • 開発するソフトウェアの品質を十分代表するものを選ぶ

• Googleのバグ予測システムでは、いつ何回修正されたかしか見ていない。修正された回数が多いほど、修正が最近ほどバグが潜んでいるということ。

テスト手法

ホワイトボックステスト

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

制御パステスト

• プログラムがどのような振る舞いをして、どのように制御されていくかをテストする手法
• 命令や条件分岐、繰り返しなどの処理(=制御パス)に対するテスト。
• テストの網羅率をカバレッジと呼ぶ。
• 制御パステストによるコードカバジテストの本質は、フローチャートをちゃんとカバーすることにある

ステートメントカバレッジ(=命令網羅率)

• 制御パステストの一部
• プログラムコード内部の命令文（=ステートメント）の結果を少なくとも1回ずつ持つようにテストケースを書く
• ステートメントカバレッジだけでテストを終了することは危険
• 分岐条件がカバーしきれないなど、非常に弱いテスト手法

ブランチカバレッジ

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

ブラックボックステスト

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

同値分割法

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

境界値分析法

• 同値分割法とセットで使われる手法
• プログラムで「境界(=条件分岐の分岐点)」と呼ばれる場所は常にバグが潜んでいるので、境界値近くは詳しくテストする必要がある

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

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

探索的テスト

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

非機能要求のテスト

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