在長假的第四個悠閑的中午，滅掉了《軟件測試的藝術》這本書，好像最近看的號稱“藝術”的書比較多，《生活的藝術》，《項目管理的藝術》還包括這本《軟件測試的藝術》。一般來說，在IT行業(yè)一本書能夠在25年之后出第二版的，那么這本書的生命力算是強的。

總的來說這本書講的是中規(guī)中矩，感覺還是七十年代那種純學術化的氣息，讓人聯想到了大學的教科書。書的開頭還是非常精彩的，非常哲理化的開頭，講述了測試的本質，之后是一些看得頭暈的名詞和方法，最后的兩篇關于調試和極限測試的不錯，而新加的網站測試內容讓人有點失望?？偟膩碚f，對于想了解“軟件測試”的同學還是可以去看看的，至于要學到什么的話，可能還要從其他地方繼續(xù)深入了解。不過就了解測試的目的，一些常用名詞的意義，以及一些基本的原則來說，這本書還是不錯的。

開頭的經典：
-          軟件測試心理學：測試是為發(fā)現錯誤而執(zhí)行程序的過程。軟件不是為了證明軟件是好的，發(fā)現錯誤是他的目標。
-          軟件測試經濟學：軟件中包含的錯誤的總和永遠是個未知數，所以要找到軟件中包含的所有的錯誤，幾乎是不可能的。
-          原則1：測試用例中一個必需部分是對與其輸出或結果的定義。
-          原則2：程序員應當避免自己測試自己編寫的程序。
-          原則3：編寫軟件的組織不應當測試自己編寫的軟件。
-          原則4：應當徹底檢查每個測試的執(zhí)行結果。
-          原則5：測試用例的編寫不僅應當根據有效和與其的輸入情況，而且也應當根據無效的和未預料到的輸入情況。
-          原則6：檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”。
-          原則7：應避免測試用例用后即棄，除非軟件本身就是一個一次性的軟件。
-          原則8：計劃測試工作時不應默許假定不會發(fā)生錯誤。
-          原則9：程序某部分存在更多錯誤的可能性，與該部分已發(fā)現錯誤的數量成正比。
-          原則10：軟件測試是一項極富創(chuàng)造性，極具智力挑戰(zhàn)性的工作。

特別喜歡調試那個章節(jié)，感覺作者有過很多的代碼的經歷。

定位問題的原則：
1．  動腦筋
2．  如果遇到了僵局，就留到稍后解決。
3．  如果遇到了困境，就把問題描述給其他人聽。
4．  僅將測試工具作為第二種手段。
5．  避免使用試驗法－僅將其作為最后的手段。

修改錯誤的技術：
1．    存在一個缺陷的地方，很有可能還存在其他的缺陷。
2．    應糾正錯誤本身，而不僅是其癥狀。
3．    正確糾正錯誤的可能性并非100%。
4．    正確修正錯誤的可能性隨著程序規(guī)模的增加而降低。
5．    應意識到改正錯誤會帶來新錯誤的可能性。
6．    修改錯誤的過程是臨時回到設計階段的過程。
7．    應修改源代碼，而不是目標代碼。

特別是關于程序中出現的錯誤的分析，實際上是程序員提高最好的方法：
1．  什么原因導致的錯誤？
2．  如何避免這樣的錯誤？
3．  如果更早的發(fā)現這樣的錯誤？

幾個不是很好的地方：
1．  翻譯，也許給我有大學教科書感覺的不是作者本身，而是翻譯的人的問題。
2．  印刷，我覺得這樣內容少的書，為什么不用小本印刷，而要用這么大的，厚度又是這么沒有質感，很不舒服。