読んだ本
- 作者: 高橋寿一
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
レビュー
読書ログ 『 知識ゼロから学ぶソフトウェアテスト 』 高橋寿一 ★★★★★ 5.0 - （テストエンジニア、QAエンジニアを除くと）エンジニアってのはどうしても、テストの勉強は後回しにしている人が... http://t.co/ES1L2lQ2yc #読書ログ #読書
— すーくん (@su_kun_1899) 2015, 4月 25メモ
スモークテスト
→煙が出ないか確認する
→まず最初にやるソフトウェアテスト
→入力、出力、計算、データ保存
→非機能要件を除くとこれしかない-
- 入出力のテスト
- 境界値と同値分割
- デシジョンテーブル
- 状態遷移テスト
もし入力項目があるなら境界値テスト
- 入力項目が複数あるならデシジョンテーブルテスト
画面が複数あるなら状態遷移テスト
モンキーテストで見つかるバグは氷山の一角に過ぎない
→無意味だ探索的テスト
→作成するケースからバグは見つからない
→ケース作成にかける時間より、実行に時間をかけた方がいい自動化をする前に読むべき
→テストデザインしてくれるテストエンジニアはあまりいない
→アプリエンジニア主導になりがちバグはバグが出たところから出る
探索的テストはアジャイル開発手法と親和性が高そう
→これを出来る人はいるのだろうか。。テスト担当者にエンジニアがプログラム構造を説明すると網羅率が跳ね上がる
非機能要件で重要視すべきは
- セキュリティ
- 信頼性
- パフォーマンス
パフォーマンステストほど初期段階からやるべき
→パフォーマンステストで見つかるバグは最悪のバグセキュリティテストのゴール
- 機密性→許可されたものだけが情報にアクセスできる
- 完全性→情報及びその処理方法が正確でかつ安全であることを維持、保護すること
- 可用性→認可されたものが必要な時に、特定の情報に確実にアクセスできること
攻撃は２種類
- 制御を奪うor不能にする
- データを改ざんする
モンキーテストは、セキュリティテストにおいてのみ意義は大きい
→手法が無いため →ファジングテストテスト計画はスケジュールを正確に見積もるのが重要なのではなく、コントロールできるスケジュールが必要
計画段階で考慮すべきリスクの種類
- 複雑度
- 新規性
- 変更
- 上位依存性
ケースの数を品質の指標に使ってはいけない
バグの数でも総数だけでは微妙。
→メトリクスはその指標の質を知ることが大事。コード行数におけるバグ密度は本質的には意味が無い
→バグは無限にあるものだから
→だがそれを理解して利用すれば、有用なメトリクスになるメトリクスは人の成果や能力を測るのに使ってはいけない
→あくまでソフトウェアの客観的な指標として扱うべきメトリクス管理はコストがかかる
一定規模以上であれば、専任をおくのがよい考えもなしに自動化しても成果は得られない
自動化に向くテスト
- スモークテスト
- パフォーマンステスト
- APIのテスト
自動化に向かないテスト
- 回帰テスト
- グラフィックスやサウンドなどメディア関連のテスト
* テストをするだけの人はいらなくなる
