読者です 読者をやめる 読者になる 読者になる

『 知識ゼロから学ぶソフトウェアテスト 』を読んだ。

読んだ本

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

レビュー

メモ

  • スモークテスト
    →煙が出ないか確認する
    →まず最初にやる

  • ソフトウェアテスト
    →入力、出力、計算、データ保存
    →非機能要件を除くとこれしかない

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

  • もし入力項目があるなら境界値テスト

  • 入力項目が複数あるならデシジョンテーブルテスト
  • 画面が複数あるなら状態遷移テスト

  • モンキーテストで見つかるバグは氷山の一角に過ぎない
    →無意味だ

  • 探索的テスト
    →作成するケースからバグは見つからない
    →ケース作成にかける時間より、実行に時間をかけた方がいい

  • 自動化をする前に読むべき
    →テストデザインしてくれるテストエンジニアはあまりいない
    →アプリエンジニア主導になりがち

  • バグはバグが出たところから出る

  • 探索的テストはアジャイル開発手法と親和性が高そう
    →これを出来る人はいるのだろうか。。

  • テスト担当者にエンジニアがプログラム構造を説明すると網羅率が跳ね上がる

  • 非機能要件で重要視すべきは

    • セキュリティ
    • 信頼性
    • パフォーマンス  
  • パフォーマンステストほど初期段階からやるべき
    →パフォーマンステストで見つかるバグは最悪のバグ

  • セキュリティテストのゴール

    • 機密性→許可されたものだけが情報にアクセスできる
    • 完全性→情報及びその処理方法が正確でかつ安全であることを維持、保護すること
    • 可用性→認可されたものが必要な時に、特定の情報に確実にアクセスできること  
  • 攻撃は2種類

    • 制御を奪うor不能にする
    • データを改ざんする  
  • モンキーテストは、セキュリティテストにおいてのみ意義は大きい
    →手法が無いため →ファジングテスト

  • テスト計画はスケジュールを正確に見積もるのが重要なのではなく、コントロールできるスケジュールが必要

  • 計画段階で考慮すべきリスクの種類

    • 複雑度
    • 新規性
    • 変更
    • 上位依存性  
  • ケースの数を品質の指標に使ってはいけない

  • バグの数でも総数だけでは微妙。
    →メトリクスはその指標の質を知ることが大事。

  • コード行数におけるバグ密度は本質的には意味が無い
    →バグは無限にあるものだから
    →だがそれを理解して利用すれば、有用なメトリクスになる

  • メトリクスは人の成果や能力を測るのに使ってはいけない
    →あくまでソフトウェアの客観的な指標として扱うべき

  • メトリクス管理はコストがかかる
    一定規模以上であれば、専任をおくのがよい

  • 考えもなしに自動化しても成果は得られない

  • 自動化に向くテスト

    • スモークテスト
    • パフォーマンステスト
    • APIのテスト
  • 自動化に向かないテスト

    • 回帰テスト
    • グラフィックスやサウンドなどメディア関連のテスト

  * テストをするだけの人はいらなくなる

  • テストが大変?
    →組み合わせテストのテストケースが多すぎるのではないか?
    →多くの場合、組み合わせテストでしか見つからないバグは10%以下
    →組み合わせテストにかけるコストが80%以上になっていることが多い

  • 本来組み合わせテストで見つかるようなバグはアーキテクチャで防ぐべき
    →Webは複数タブとかセッションの絡みがいつも出てくるよね。。

  • 品質の低いモジュールを徹底的に叩く
    →ソフトウェアの品質は足し算ではない
    →ある限られたモジュールにバグは集中する

  • Googleのバグ予測アルゴリズムは修正頻度を見ている