ソフトウェア・テストの技法 を読んだので、要点と感想
テスト
ポエム
投稿日 2022年05月26日
読んだ本
ソフトウェア・テストの技法第2版
41IeGuTGutL.jpg
1,2,3,4,7章を読みたくてGWからちょくちょく読んでいました。
刺さったところ、要点・メモを書いておきます。感想含むためポエムタグつけときます。
1章: 自己診断テスト
入力ダイアログから3つの整数を読んで、不等辺三角形・二等辺三角形・正三角形のどれであるかを示すプログラム
簡単なプログラムでさえテストは容易でない
複雑なプログラムを完全にテストすることは不可能
2章: プログラム・テストの心理学と経済学
心理学
テストとは？
エラーを見つけるつもりでプログラムを実行する過程
"プログラムにエラーがないことを証明するため"にテストを書くことがあるが、人間は心理的に失敗に導かれないようなデータを選択する
一方で、エラーを見つける確率が高いデータを選んだ方が価値が高いテスト
"プログラムにエラーがないことを証明するため"という定義をすると、達成は不可能。
しかし、"プログラムのエラーを発見する過程"と定義すると、実現性が高いので心理的障壁を壊せる。
経済学
全てのエラーを見つけるためのテストは可能か？→否。
ブラックボックステストもホワイトボックステストもどちらも実行不可能。
徹底的な入力テストは、全ての入力可能性のあるテストは無限にある。(前の処理に依存していたらなおさら)
経路テストも天文学的な数値になる。
3章: プログラムの検査、ウォークスルー、検討
3章は人的テストについて述べている。
結論言うと、人的テストは手法は非常に有効。
チェックリストや仲間内での検討。ウォークスルー(説明)。
4章: テストケースの設計
仕様が入力条件の組み合わせを含んでいる場合は、原因-結果グラフを作る
どんな場面でも限界値分析を行う
必要であれば同値分割のテストケースを追加する
エラー推測
プログラムの論理を調べる
論理の調べ方は以下。
判定条件網羅 > 条件網羅 > 判定条件/条件網羅 > 複数条件網羅
後ろに行くほど完全に近い。けど、量も多くて時間がかかる。
エラー推測
手順化が難しいが、直感と経験からエラーを推測して、そのエラーを発見するためのテストケースをかける人がいる。
手順はないが、最良の代替案は、プログラムを設計したときに見逃したかもしれない特別なケースをあげること。
原因-結果
原因結果グラフ技法の解説(1)
7章: デバッグ
エラーの位置発見の原則
考える
行き詰まった時は、明日までのばす or 他人に説明する
デバッグ道具に頼らない
思考の代わりではなく、補助として使う
実験は最後の手段
全体の感想
日本語訳が非常に読みにくい。
けど書かれている内容は、原理原則なので得るものが多かった。
自分の中で言語化されていないものが言語化されていて、要点を再認識できた。
逆にいうと既に行動まで出来ているものもあった。
原理原則抑えたいのならおすすめすると思う。
今回読んでいないものは次の機会に。
以上です~
0
0
comment
0
mitsuhiro_K
@mitsuhiro_K(Mitsuhiro Koga)
痩せたい。寿司食べたい。