測試與改錯(3)

　　這里要強調的是，α測試不能依賴于開發人員或者測試小組中的任意一方，必須是雙方共同參與。“白盒測試”必須由開發者自己執行，因為別的測試人員無法了解到程序的內部實現細節。而“黑盒測試”必須由獨立的測試人員執行，因為開發者難以做到客觀、公正。開發者在測試自己的程序時存在一些弊?。?/p>

　　(1)開發者對自己的程序印象深刻，并總以為是正確的(自信是應該的)。倘若在設計時就存在理解錯誤，或因不良的編程習慣而流下隱患，那么他本人很難發現這類錯誤。

　　(2)開發者對程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發錯誤，這與大眾用戶的情況不太相似，所以自己測試程序難以具備典型性。

　　(3)程序設計有如藝術設計，開發者總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。即便開發者非常誠實，但“珍愛程序”的心理讓他在測試時不知不覺地帶入了虛假成份。

　　軟件產品正式發行前，在公司外部邀請一些用戶對產品進行測試，稱為β測試。β測試的涉及面最廣，最能反映用戶的真實愿望，但花費的時間最長，不好控制。一般地，軟件公司與β測試人員之間有一種互利的協議。即β測試人員無償地為軟件公司作測試，定期遞交測試報告，提出批評與建議。而軟件公司將向β測試人員免費贈送或者以很大的優惠價格發行軟件的正式版本。

　　7.3 測試的主要內容與常用方法

　　有一次文學考試，問高爾基是哪國人。一考生樂極而吟：“爾基啊爾基，你若不姓高，我怎知你是中國人。”這是一種瞎猜法。如果這種方法用于軟件測試，人累死也測不出什么結果來。

　　不論是對軟件的模塊還是整個系統，總有共同的內容要測試，如正確性測試，容錯性測試，性能與效率測試，易用性測試，文檔測試等。“白盒測試”是指開發人員從程序內部對上述內容進行測試，而“黑盒測試”是指獨立的測試人員從程序外部對上述內容進行測試。很多軟件工程教材講述了各種各樣的測試方法并例舉了不少示例[Pressman 1997] [Sommerville 1992] [楊文龍 1997]。本節簡明地講述常用的測試方法及其道理。

　　7.3.1 正確性測試

　　正確性測試又稱功能測試，它檢查軟件的功能是否符合規格說明。由于正確性是軟件最重要的質量因素，所以其測試也最重要。

　　基本的方法是構造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。倘若枚舉空間是無限的，那可慘了，還不如回家種土豆有盼頭。測試人員一定要設法減少枚舉的次數，否則沒好日子過。關鍵在于尋找等價區間，因為在等價區間中，只需用任意值測試一次即可。等價區間的概念可表述如下：

　　記(A, B)是命題f(x) 的一個等價區間，在(A, B)中任意取x1進行測試。

　　如果f (x1) 錯誤，那么f (x) 在整個(A, B)區間都將出錯。

　　如果f (x1) 正確，那么f (x) 在整個(A, B)區間都將正確。

　　上述測試方法稱為等價測試，來源于人們的直覺與經驗，可令測試事半功倍。

　　還有一種有效的測試方法是邊界值測試。即采用定義域或者等價區間的邊界值進行測試。因為程序員容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯。

　　例如測試 的一段程序。憑直覺等價區間應是(0, 1)和(1, +∞)?？扇=0.5以及x=2.0進行等價測試。再取 x=0以及x=1進行邊界值測試。

　　有一些復雜的程序，我們難以憑直覺與經驗找到等價區間和邊界值，這時枚舉測試就相當有難度。

　　在用“白盒測試”方式進行正確性測試時，有個額外的好處：如果測試發現了錯誤，測試者(開發人員)馬上就能修改錯誤。越早改正錯誤，付出的代價就越低。所以大多數軟件公司要求程序員在寫完程序時，馬上執行基于單步跟蹤的“白盒測試”。

　　7.3.2 容錯性測試

　　容錯性測試是檢查軟件在異常條件下的行為。容錯性好的軟件能確保系統不發生無法意料的事故。

　　比較溫柔的容錯性測試通常構造一些不合理的輸入來引誘軟件出錯，例如：

　　(1)輸入錯誤的數據類型，如“猴”年“馬”月。

　　(2)輸入定義域之外的數值，上海人常說的“十三點”也算一種。

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