1.每當測試乙個程式時，應當想到要為程式創造一些價值。
通過測試來提高程式的價值，是指測試提高了程式的可靠性或質量。提高了程式的可靠性，，是指找出並最終修改了程式的錯誤。
2.測試是為發現錯誤而執行成勛的過程
3. 軟體測試更適宜被視為試圖發現程式中錯誤的破壞性過程。
乙個成功的測試用例，通過誘發程式發生錯誤，可以在這個方向上促進軟體質量的改進。
4.即使是規模很小的程式，一般來說，發現程式的所有錯誤也是不切實際的。
5.軟體測試的原則
測試用例中乙個必需部分是對預期輸出或結果的定義。
程式設計師應當避免測試自己編寫的程式
編寫軟體的組織不應當測試自己編寫的軟體
應當徹底檢查每個測試的執行結果
測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況。
檢查 程式是否「未作其應該做的」僅是測試的一半，測試的另一半應該是檢查是否「做了其不應該做的」。
應避免測試用例用後即棄，，除非軟體本身就是乙個一次性的軟體。
計畫測試工作時，不應默許假定不會發現錯誤。
程式某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比
軟體測試是一項極富創造性，極具智力挑戰性的工作。
黑盒測試又稱為資料驅動的測試或輸入輸出驅動的測試。
使用這種測試方法時，將程式視為乙個盒子。測試目標的程式內部結構無關。將重點集中放在發現程式不按期規範正確執行的環境條件。
如果想用這種測試方法測試程式的所有錯誤，判定的標準時窮舉輸入測試，將所有的輸入條件都作為測試用例。
我自己的理解時：黑盒測試在測試程式時，並不關注程式本身的結構與內部機制，所以只需要將所有的輸入條件都作為測試用例，以書中例子為例，僅乙個很小的程式所需要的測試用例就需要很多乃至天文數字。
在使用到資料儲存時尤其嚴重，以書中為例航班訂票系統，所依賴的測試不僅是有效的和無效的，還需要依賴每次事務處理的順序。
總結：窮舉輸入測試是無法有效的。
兩方面的含義：
一是無法測試乙個程式以確保它是無錯的
二是軟體測試中需要考慮的乙個基本問題就是軟體測試的經濟學。
白盒測試又稱邏輯驅動測試。要求測試策略對程式的邏輯結構進行檢查。
窮舉路徑測試，與窮舉輸入測試相類似：如果使用測試用例執行了程式中所有可能出現的控制流路徑，那麼程式就有可能得到了完全測試。
然而這種測試策略也存在很大問題
一：在程式中得到所有不同邏輯路徑的數量可能也是乙個天文數字，從現實來看是不和實際的。
二：第二個問題就算是窮舉路徑測試也不能完全確定該程式就是無錯的：有這麼幾種可能性：
1）如果程式本身設計出現問題，測試了所有邏輯路徑也不能百分百確定程式是正確的，舉例來說，如果要求是設計乙個公升序排序的程式，但卻設計了降序的程式，此時在使用窮舉路徑測試就沒有價值了有點南轅北轍的感覺。。。
2）程式可能會因為缺少某些路徑而存在問題，但是窮舉路徑測試當然不能發現缺少了哪些必須路徑。（不是很理解）
3）窮舉路徑測試可能不會暴露資料敏感錯誤，比如資料型別或是有無符號的問題。
總結：
白盒測試與黑盒測試
1白盒測試 定義 透明的，可以看見內部結構的，按照程式內部邏輯結構和編碼結構設計測試資料並完成測試的一種測試方法。分類 靜態測試和動態測試 邏輯覆蓋 語句覆蓋 每一條語句至少被執行一次 語句覆蓋是最弱的邏輯覆蓋 判定覆蓋 每乙個分支至少通過一次即每一條分支語句的 真 值和 假 值都至少執行一次。判定...
黑盒測試與白盒測試
黑盒測試 黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作乙個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接...
黑盒測試與白盒測試
軟體的黑盒測試意味著測試要在軟體的介面處進行。把測試物件看做乙個黑盒子,測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書,檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試。軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做乙個開啟的盒子，它...