第一章 軟件測試的背景
軟件缺陷
1、在本書中，所有軟件問題都被稱爲缺陷。
2、產品說明書：對開發的產品進行定義。給出產品的細節，如何做、做什麼、不能做什麼。
3、至少滿足下列五個規則之一才稱發生了一個軟件缺陷。
（1）軟件未實現產品說明書要求的功能。
（2）軟件出現了產品說明書指明不應該出現的錯誤。
（3）軟件實現了產品說明書未提到的功能。
（4）軟件未實現產品說明書雖未明確提及但應該實現的目標。
（5）軟件難以理解、不易使用、運行緩慢。
第（3）條：多增加功能雖然有了更好，但是會增加測試的工作，甚至帶來更多的缺陷。
4、導致軟件缺陷最大的原因是產品說明書。
軟件缺陷的第二大來源是設計。
5、修復軟件缺陷的費用是隨着時間推移而增加的。指數級增長。
6、軟件測試員的目標是儘可能早地找出軟件缺陷，並確保其得以修復。
修復缺陷並非指一定要改正軟件。可以是指在用戶手冊中增加一段註釋或爲用戶提供特殊的培訓。
7.優秀的軟件測試員應具備的素質：
他們是羣探索者。
他們是故障排除員。
他們不放過任何蛛絲馬跡。
他們具有創造性。
他們是羣追求完美者。
他們判斷準確。
他們注重策略和外交。
他們善於說服。
除了這些素質外，在軟件編程受過教育也很重要。瞭解軟件是怎樣編寫的，可以從不同角度找出軟件缺陷，從而使得測試更加高效，有助於開發測試工具。
第二章 軟件開發的過程
產品的組成部分
1、在軟件行業中，用於描述製造出來並交付他人的軟件產品組件的術語是可交付的部分。解釋所有可交付部分內容的最簡便方法是分門別類。
2、編寫軟件的目的是滿足一些人的需求，這些人稱爲客戶。
3、從軟件產品的潛在客戶中獲得直接反饋的流行做法是藉助焦點人羣。焦點人羣通常由辦公室設在商業場所的獨立問卷調查公司來組織。
4、產品說明書。
5、軟件產品的一個關鍵部分是進度表。目的是瞭解哪項工作完成了，還有多少工作要做，何時全部完成。
6、軟件設計文檔：對於稍大一些的程序而言，必須要有一個設計過程來規劃軟件如何編寫。
7、常用軟件設計文檔的清單：
結構文檔。描述軟件整體設計的文檔。
數據流圖。表示數據在程序中如何流動的正規示意圖。也稱爲泡泡圖，用圓圈和線畫的。
狀態轉換圖。把軟件分解爲基本狀態或者條件的另一種正規示意圖，表示不同狀態間轉換的方式。
流程圖。用圖形描述程序邏輯的傳統方式。
代碼註釋。
8、測試文檔。
比較重要的測試提交清單：
測試計劃。描述用於驗證軟件是否符合產品說明書和客戶需求的整體方案。
測試用例。列舉測試的項目，描述軟件的詳細步驟。
缺陷報告。描述執行測試用例找出的問題。
測試工具和自動測試。如果測試小組使用自動化測試和工具測試軟件，不管是購買的還是自己編寫的工具，都必須有文檔記錄。
度量、統計和總結。測試過程的彙總。
9、錯誤提示信息是軟件產品最容易忽視的部分。
軟件項目成員
項目經理自始至終驅動整個項目。通常負責編寫產品說明書、管理進度、進行重大決策。
體系架構師是產品小組中的技術專家。一般經驗豐富，可以勝任設計整個系統的體系架構或軟件。
程序員設計、編寫軟件並修復軟件中的缺陷。
測試員負責找出並報告軟件產品的問題。
技術作者編制軟件產品附帶的文件和聯機文檔。
配置管理員負責把程序員編寫的代碼及技術作者寫的全部文檔資料組合在一起，合成一個軟件包。
軟件開發生命週期模式
1、軟件產品從最初構思到公開發行的過程稱爲軟件開發生命週期模式。
2、四種最常用的模式：
大爆炸模式
邊寫邊改模式
瀑布模式
螺旋模式
大爆炸模式
一大堆東西（人力和資金）放在一起，巨大的能量釋放——通常很野蠻——產生了優秀的軟件產品——或者一堆廢品。
大爆炸模式的優點是簡單。計劃、進度安排和正規開發過程幾乎沒有，所有精力都花在開發軟件和編寫代碼上。
多數情況下，大爆炸模式幾乎沒有什麼測試。如果有的話，也是擠在產品發佈前進行。
儘量避開在此模式下進行測試。
邊寫邊改模式
項目小組在未刻意採用其他開發模式時默認的開發模式。比大爆炸更近一步，至少考慮了產品需求。
邊寫邊改模式適合意在快速製作而且用完就扔的小項目。
瀑布模式
採用瀑布模式的項目從最初的構思到最終產品要經過一系列步驟。每一個 步驟結束時，項目小組組織審查。如果項目未準備好，就停滯下來。
瀑布模式非常強調產品的定義。
各個步驟是分立的，沒有交叉。
無法回溯。
優點：所有一切都有完整細緻的說明，測試對象非常明確。
缺點：測試僅在最後進行，所以一些根本性問題可能出現在早期，直到準備發佈產品時纔可能發現。
螺旋模式
總體思想是一開始不必詳細定義所有細節。從小開始，定義重要功能，努力實現這些功能，接受客戶反饋，然後進入下一個階段。重複上述過程，直到得到最終產品。
螺旋測試中包含了一點瀑布模式（分析、設計、開發和測試的步驟）、一點邊寫邊改模式（螺旋測試的每一次）和一點大爆炸模式（從外界觀察）。
該模式發現問題早、成本低。
PS：有一種開發過程叫敏捷軟件開發。未成主流，容易偏離主題而造成混亂。
第三章 軟件測試的實質
測試的原則
1、完全測試一個程序是不可能的。
2、軟件測試員要學會一個關鍵的思想是，如何把數量巨大的可能測試減少到可以控制的範圍，以及如何針對風險做出明確的抉擇，哪些測試重要，哪些不重要。
3、我們的目標是找到最優的測試量，使測試不多不少。
4、可以報告軟件缺陷存在，卻不能報告軟件缺陷不存在。任何情況下都不能保證軟件缺陷沒有了。唯一的方法是繼續測試，可能還會找到一些。
程序員也有心情不好的時候。
程序員往往犯同樣的錯誤。
某些軟件缺陷實乃冰山一角。
5、並非所有的軟件缺陷都要修復。
不需要修復軟件缺陷的原因有：
沒有足夠的時間 。
不算真正的軟件缺陷。
修復的風險太大。
不值得修復。
6、確認是保證軟件符合產品說明書的過程。驗證是保證軟件滿足用戶要求的過程。