知識ゼロから学ぶソフトウェアテスト 第3版 メモ

改訂版は読んでいて、今回アジャイルやAIについても追加されたということでKindleで購入

駆け出し時に読んだ内容の更新と忘れてる部分の再学習が目的

ホワイトボックステスト

• Junitとかの自動テストはここに含まれる
• coverage：網羅率、カバー率
• ステートメントカバレッジ
  • 分岐なしの網羅率
• ブランチカバレッジ
  • 分岐も含めた網羅率
• Googleはステートメントカバレッジ採用（意外）
  • 60％許容、75%推奨、90%規範
  • ただ前提としてGoogleが広告収入で成り立つ企業ということは要意識。
• 目指せブランチ80％。でも予算とリソースはちゃんと確保
• カバレッジテストの限界
  • ループ処理→カバレッジでは担保できない
  • マルチタスク→未だに未解決の領域
  • 仕様の誤りや機能の不存在→仕様自体のミスには気づけない
  • 扱うデータ起因→カバレッジでは担保できない

ブラックボックステスト

• 前提としてソフトウェアの振る舞いは以下4つ
  • 入力
  • 出力
  • 計算
  • 保存
• 境界値分析
  • 入力と出力のチェックに対応
  • 異なる処理が行われる最も近い2点で動作をテストする
  • 洗い出せるバグ
    • 閉包関係バグ
      • 「閉包関係」は対象値を含むか含まないか（">"か">="）を示す意味として理解した
    • 仕様の読み間違い、数値の打ち間違い
    • 境界がないケース
    • 余分な境界があるケース
  • ※面白かった差分として、同値分割の内容がこの版では全面カットされていた
    • その理由として挙げられていたのは以下
      • 境界値分析がしっかりできていれば理論上は不要
      • 無駄な同値分割がテストケース肥大の要因になる
• ディシジョンテーブル

探索的テスト

• ドメインを理解し、バグが潜んでいる箇所を集中的にテストする
  • “探索的テストとは、ソフトウェアの理解とテスト設計とテスト実行を同時に行うテストである” Cem Kaner
• 一般のテスターでもテストケースベースのテストと同等のカバレッジ、システムを理解したテスターが実施するとテストケースベースのテストを遥かに上回るカバレッジが得られる
• ユーザビリティにおいてはテストケースベースと比較して４倍近いバグを見つけられる
• 著者は「やらない理由はない」と言っている。
• テストケースは基本書いたりしないが、テストの証跡はしっかり残す。
• やり方
  • まず、システムが満たしておくべき判定基準（pass/fail基準）を明文化する
  • テストする機能の範囲をリストアップする
  • バグが潜んでいそうな弱いエリア（機能、操作など）に的を絞る
  • テストを行い、バグを記録する
• ただし非機能テストには向かない。