有效測試軟件的方法與技術

1. 測試的常識與道理

　　1.1 你真的懂測試嗎
　　◆　編程大師說：沒有錯誤的程序世間難求。 （《編程之道》）
　　◆　你在學校里學過測試嗎？（讀到博士可能也不懂測試）
　　◆　你所在的企業重視測試嗎？ （小公司程序員的技能更加全面）
　　◆　臨時抱佛腳行嗎？你以為有文檔模板就會測試了嗎？
　　◆　如果不懂得有效地進行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。
　　◆　職業軟件工程師應當掌握需求開發、系統設計、編程、測試、維護 所有技能。

　　1.2 測試的目的是什么
　　◆　測試的目的是為了發現盡可能多的缺陷，不是為了說明軟件中沒有缺陷。
　　◆　推論：成功的測試在于發現了迄今尚未發現的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷。
　　◆　千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。
　　◆　如果產品通過了嚴格的測試，大家不要不吭氣，應當好好地宣傳一把 。

　　1.3 一些常識和經驗之談
　　◆　測試能提高軟件的質量，但是提高質量不能依賴測試。
　　◆　測試只能證明缺陷存在，不能證明缺陷不存在?！皬氐椎販y試”難以成為現實，要考慮時間、費用等限制，不允許無休止地測試。我們應當祈禱：軟件的缺陷在產品被淘汰之前一直沒有機會發作。
　　◆　測試的主要困難是不知道如何進行有效地測試，也不知道什么時候可以放心　地結束測試。
　　◆　每個開發人員應當測試自己的程序（份內之事），但是不能作為該程序已經通過測試的依據（所以項目需要獨立測試人員）。
　　◆　80-20原則：80％的缺陷聚集在20％的模塊中，經常出錯的模塊改錯后還會經常出錯
　　◆　測試應當循序漸進，不要企圖一次性干完，注意“欲速則不達”。

　　2. 測試的分類與比較

　　◆　問題1：有了“黑盒”測試為什么還要“白盒”測試？
– 黑盒測試只能觀察軟件的外部表現，即使軟件的輸入輸出都是正確的，卻并不能說明軟件就是正確的。因為程序有可能用錯誤的運算方式得出正確的結果，例如“負負得正，錯錯得對”，只有白盒測試才能發現真正的原因。

– 白盒測試能發現程序里的隱患，象內存泄漏、誤差累計問題。在這方面，黑盒測試存在嚴重的不足。
　　◆　問題2：由于單元測試要寫測試驅動程序，非常麻煩，能否等到整個系統全部開發完后，再集中精力進行一次性地單元測試呢？
　　– 如果這樣做，在開發過程中，缺陷會越積越多并且分布得更廣、隱藏得更深，反而導致測試與改錯的代價大大增加。最糟糕的是無法估計測試與改錯的工作量，使進度失去控制。因此為圖眼前省事而省略單元測試或者“偷工減料”，是“得不償失”的做法。
　　◆　問題3：如果每個單元都通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？
　　– 要把N個單元集成一起肯定靠接口耦合，這時可能會產生在單元測試中無法發現的問題。例如：數據通過不同的接口時可能出錯；幾個函數關聯在一起時可能達不到預期的功能；在某個單元里可以接受的誤差可能在集成后被擴大到無法接受的程度。所以集成測試是必要的，不是多此一舉。
　　◆　問題4：在集成測試的時候，已經對一些子系統進行了功能測試、性能測試等等，那么在系統測試時能否跳過相同內容的測試?
　　– 不能！因為集成測試是在仿真環境中開展的，那不是真正的目標系統。再者，單元測試和集成測試通常由開發小組執行。根據測試心理學的分析，開發人員測試自己的工作成果雖然是必要的，但不能作為成果已經通過測試的依據。
　　◆　問題5：既然系統測試與驗收測試的內容幾乎是相同的，為什么還要驗收測試？
　　– 首先是“信任”問題。對于合同項目而言，如果測試小組是開發方的人員，客戶怎么能夠輕易相信“別人”呢? 所以當項目進行系統測試之后，客戶再進行驗收測試是情理之中的事。否則，那是客戶失職。
　　– 不論是合同項目還是非合同項目，軟件的最終用戶各色各樣（如受教育程度不同、使用習慣不同等等）。測試小組至多能夠模仿小部分用戶的行為，但并不具有普遍的代表性。
　　◆　問題6：能否將系統測試和驗收測試“合二為一”？
　　– 系統測試不是一會兒就能做完的，比較長時間的用戶測試很難組織。用戶還有自己的事情要做，他們為什么要為別人測試呢？即使用戶愿意做系統測試，他們消耗的時間、花費的金錢大多比測試小組的高。
　　– 系統測試時會找出相當多的軟件缺陷，軟件需要反反復復地改錯。如果讓用戶發現“內幕”，一是丟臉，二是會嚇跑買主。所以還是關起門來，先讓測試小組做完系統測試的好。

原文轉自：http://www.anti-gravitydesign.com