測試與改錯(2)

　　盡管已經明白了測試的目的是為了發現盡可能多的缺陷，但當測試人員真的發現了一堆缺陷時，卻不可樂顛顛地跑去恭喜那個倒霉的開發者，否則會打架的。

　　7.1.3 測試的真理

　　測試只能證明缺陷存在，而不能證明缺陷不存在。

　　這個真理告訴我們，對于一個復雜的系統而言，無論采取什么樣的測試手段都不能證明缺陷已經不復存在。“徹底地測試”只是一種理想。在實踐中，測試要考慮時間、費用等限制，不允許無休止地測試。

　　7.1.4 測試與質量的關系

　　測試有助于提高軟件的質量，但是提高軟件的質量不能依賴于測試。測試與質量的關系很象在考試中“檢查”與“成績”的關系。

　　學習好的學生，在考試時通過認真檢查能減少因疏忽而造成的答題錯誤，從而“提高”了考試成績(取得他本來就該得的好成績)。

　　而學習差的學生，他原本就不會做題目，無論檢查多么細心，也不能提高成績。

　　所以說，軟件的高質量是設計出來的，而不是靠測試修補出來的。

　　7.2 測試人員的選擇

　　測試需要開發人員參與嗎?

　　測試需要獨立的測試小組嗎?

　　測試需要用戶參與嗎?

　　讓我們先看一看Microsoft公司關于測試的經驗教訓，再回答上述問題。

　　7.2.1 Microsoft公司的經驗教訓

　　在80年代初期，Microsoft公司的許多軟件產品出現了“Bug”。比如，在1981年與IBM PC機一起推出的BASIC軟件，用戶在用“.1”(或者其他數字)除以10時，就會出錯。在FORTRAN軟件中也存在破壞數據的“Bug”。由此激起了許多采用Microsoft操作系統的PC廠商的極大不滿，而且很多個人用戶也紛紛投訴。

　　Microsoft公司的經理們發覺很有必要引進更好的內部測試與質量控制方法。但是遭到很多程序設計師甚至一些高級經理的堅決反對，他們固執地認為在高校學生、秘書或者外界合作人士的協助下，開發人員可以自己測試產品。在1984年推出Mac機的Multiplan(電子表格軟件)之前，Microsoft曾特地請Arthur Anderson咨詢公司進行測試。但是外界公司一般沒有能力執行全面的軟件測試。結果，一種相當厲害的破環數據的“Bug”迫使Microsoft公司為它的2萬多名用戶免費提供更新版本，代價是每個版本10美元，一共化了20萬美元，可謂損失慘重。

　　痛定思痛后，Microsoft公司的經理們得出一個結論：如果再不成立獨立的測試部門，軟件產品就不可能達到更高的質量標準。IBM和其它有著成功的軟件開發歷史的公司便是效法的榜樣。但Microsoft公司并不照搬IBM的經驗，而是有選擇地采用了一些看起來比較先進的方法，如獨立的測試小組，自動測試以及為關鍵性的構件進行代碼復查等。Microsoft公司的一位開發部門主管戴夫·穆爾回憶說：“我們清楚不能再讓開發部門自己測試了。我們需要有一個單獨的小組來設計測試，運行測試，并把測試信息反饋給開發部門。這是一個偉大的轉折點。”

　　但是有了獨立的測試小組后，并不等于萬事大吉了。自從Microsoft公司在1984年與1986年之間擴大了測試小組后，開發人員開始“變懶”了。他們把代碼扔在一邊等著測試，忘了唯有開發人員自己才能阻止錯誤的發生、防患于未來。此時，Microsoft公司歷史上第二次大災難降臨了。原定于1986年7月發行的Mac機的Word 3.0，千呼萬喚方于1987年2月問世。這套軟件竟然有700多處錯誤，有的錯誤可以破壞數據甚至摧毀程序。一下子就使Microsoft名聲掃地。公司不得不為用戶免費提供升級版本，費用超過了100萬美元。[Cusumano 1995]

　　7.2.2 測試人員的分工

　　從Microsoft公司的教訓中可知，公司內部對產品的測試(稱為α測試)，需要開發人員與獨立的測試小組共同參與。開發人員應該執行“白盒”測試，即測試源程序的邏輯結構以及實現細節(“白盒”是指看得見程序的內部結構)。而獨立測試小組應該執行“黑盒”測試，即按照規格說明來測試程序是否符合要求(“黑盒”是指看不見程序的內部結構)。比如在測試一個模塊時，“白盒”測試方法要對模塊的所有代碼進行單步跟蹤測試。而 “黑盒”測試方法只需測試模塊的接口是否符合要求，它關心程序的外部表現而不是內部的實現細節。

　　小型的軟件公司可能沒有條件設立獨立的測試小組，也有可能測試小組人員不多而忙不過來。這時，可以讓開發小組的成員相互測試對方的程序。

原文轉自：http://www.uml.org.cn/Test/200608303.htm