軟件測試的本質是什么？

　　最近在讀《軟件測試》 一書，對叫這個名字的書多，我讀的是Ron Patton 寫的那本，對!2002年的中文版，已經十年了，雖然沒《軟件測試的藝術》那么經典，那么有深度，但絕對也是一本不錯的好書。讀到第三章“軟件的實質”，覺得確實不錯，這里摘錄與大家分享。

　　實質，哲學中的本質，又稱為“實質”是指某一對象或事物本身所必然固有的。說的通俗點也就是說軟件測試的本來的面目。

　　軟件缺陷的定義

　　來看一下Ron Patton 為我們的軟件缺陷所下的定義。

　　1、軟件沒有實現產品的說明書所描述的功能。(個人覺得“描述”比“宣稱”更貼切)

　　2、軟件實現了產品說明書描述不應有的功能。

　　3、軟件執行了產品說明書沒講的操作

　　4、軟件沒有實現產品說明書沒講但應該實現的功能。

　　5、從軟件測試員的角度來看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認為不對。

　　為什么一個定義要這么多條來描述?這個“缺陷”的定義有這么復雜么?不，它其實并不復雜，作者只是想更加全面的來給缺陷下定義。下面我們來以建一棟房子為例，來說明一下每一條定義的意思。需要說明的是沒有十分完美而且一成不變的產品說明說，而且在實際項目中，它可能非常簡陋，模棱兩可，甚至經常變動。

　　1、軟件沒有實現產品說明書的描述的功能。房子的主要希望有一個落地的大窗戶，讓陽光更好的照進屋子里，而且他特意在房子的設計圖紙中畫出來，并且還加以說明。結果，他看到的是四面全是墻壁，只有一個小門的房子。那么對于測試人員來說，他就是一個缺陷。

　　2、軟件實現了產品說明書中描述的不應有的功能。由于房子的主人生活在南方，天氣溫暖，而請來的泥瓦匠是北方的，結果給主人建造的房子具然有一個大大的取暖的煙筒，而且主要主要特意在房子的設計圖紙中說明，自己的房子不要煙筒。那么對于測試人員來說，這也是個缺陷。

　　3、軟件執行了產品說明書沒講的操作。與第二條類似，不同的是第二條是主人已經明確說了自己不要煙筒，而這一條強調的是在主人沒說的情況下。泥瓦匠自作聰明的加了一個煙筒上去。對于測試人員來說，畫蛇添足的功能同樣被視為缺陷。

　　4、軟件沒有實現產品說明書沒講但應該實現的功能。房子的主要對屋子的高度、格局，材料，顏色描述的非常清楚。泥瓦匠在建造房子的時候發現，主人沒有提地基這回事，為了使房子牢固，所以，所有的房子都是必須要先打地基的，雖然主人沒有說，但地基的功能必須要做。如果因為沒有描述沒有去做，但這又一件必須去做的事。對于測試人員來說，也可以視其這缺陷。

　　6、從軟件測試員的角度看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認為不對。軟件測試員是軟件除了測試軟件運行的缺陷，同樣是作為一個用戶在再對軟件進行使用。如果感覺自己都很難使用，或軟件效率非常低且界面丑陋等情況，也可以認為其存在缺陷?；蛘呤亲罱K用戶拿到產品時發現這根本不是自己想要的東西，也可以現其為缺陷。當然，用戶說不是自己想要的東西，也不能憑借一面之詞，可以拿合約，產品說明書來評估。

　　Ok ，上面分析一下缺陷的定義，如何去判定一個缺陷。下面來看一下測試的原側，我們可以視其為軟件測試過程中的“交通規則”。它會有助于我們更好的進行軟件測試的工作。

　　全完測試程序的可能性

　　初做軟件測試者可能認為拿到軟件后就可以進行完全測試了，找出所有軟件缺陷，并使軟件完美。遺憾的是這是不可能的，我們無法對一個軟件進行完全測試，即使最簡單的程序也不行。主要原因如下：

　　輸入量太大

　　輸出結果太多

　　軟件實現的途徑太多

　　軟件說明書沒有客觀標準。從不同的角度看，軟件缺陷的標準不同。

　　以上的“太多”的可能性加在一起，致使測試條件難以確定。原書中引用計算器的例子，太復雜了，好吧!我們換個更簡單有郵箱登錄。雖然對以“登錄”為樣例表示方案，就像每個介紹編程的書上來的第一個例子就是“hello world”。但這個例更能簡單的說明問題，這里就再用一下。

　　以126郵箱為例，其用戶長度為50個字符，密碼確實不太好計算(因為都是*號)，所以這里也按50個字符來計算。好吧!雖然，我已經知道了正確的用戶名和密碼。

　　在輸入正確用戶名的情況下：

　　1、輸入正確的密碼名是還否可以登錄，

　　2、那么錯誤輸入0 呢?1呢?2呢?......直到

　　99999999999999999999999999999999999999999999999999 ，

　　3、如果密碼不是數字，而是字符呢，a 、b、c ... aa、bb 、cc .....

　　4、如果是大寫呢 A 、B、C.... AA 、BB、CC.....

　　5、如果是大小寫呢 Aa、Ab ....

　　6、如果是小寫+數字呢 1a 、1b 、1c ....2a 、2b 、2c.....

　　7、如果是小寫+數字呢 1A 、1B 、1Cc....2A 、2A 、2A.....

　　8、如果是小寫+數字呢 1Aa 、1Bb 、1Cc ....1Aa 、1Bb 、1Cc.....

　　9、如果有特殊字符呢 @#￥%……&*

　　10、如果輸入字符有空格呢 a b、adbc ee......

　　11、如果是其它字符+大小寫字母+數字呢+空格呢 !@#&+123AIBKIkklzcb ......

　　......

　　12、再換正確的密碼，錯誤的文件名再來一次。

　　13、用錯誤的用戶名和密碼再把上面的情況驗證一次。(這樣會匹配到所有的用戶名密碼)

　　14、什么都不輸，直接點擊登錄

　　這樣窮舉下去，哪怕世界上超級的計算機，也需要計算十年、幾百年才能驗證所有情況。如果覺得某些測試條件是重復的或都無必要的或都為了節省時間，而將其剔除，那么就不能稱為作完全測試。

　　軟件測試是有風險的

　　好吧!你已經知道了完全測試是有風險的，如果決定不去測試所有的情況，那么我們就選擇了風險。在上面的郵箱登錄的例子中，(假如)由于程序的所使用語言的特定，有些字符在存儲的時候會被轉義，如& 會被轉義為_ 存儲，一個叫“&&” 用戶，一個叫“ __”的用戶，使用了相同的密碼，碰巧程序員沒考慮到這種情況，那么程序該如何登錄呢?(我也不知道，這只是個假設的例子)

原文轉自：http://blog.csdn.net/fnngj/article/details/8597036