最近在讀《軟件測試》 一書，叫這個名字的書好基本多，我讀的是Ron Patton 寫的那本，對！2002年的中文版，已經(jīng)十年了，雖然沒《軟件測試的藝術(shù)》那么經(jīng)典，那么有深度，但絕對也是一本不錯的好書。讀到第三章“軟件的實質(zhì)”，覺得確實不錯，這里摘錄與大家分享。
實質(zhì)，哲學(xué)中的本質(zhì)，又稱為“實質(zhì)”是指某一對象或事物本身所必然固有的。說的通俗點也就是說軟件測試的本來的面目。
軟件缺陷的定義
來看一下Ron Patton 為我們的軟件缺陷所下的定義。
1、軟件沒有實現(xiàn)產(chǎn)品的說明書所描述的功能。（個人覺得“描述”比“宣稱”更貼切）
2、軟件實現(xiàn)了產(chǎn)品說明書描述不應(yīng)有的功能。
3、軟件執(zhí)行了產(chǎn)品說明書沒講的操作
4、軟件沒有實現(xiàn)產(chǎn)品說明書沒講但應(yīng)該實現(xiàn)的功能。
5、從軟件測試員的角度來看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認為不對。
為什么一個定義要這么多條來描述？這個“缺陷”的定義有這么復(fù)雜么？不，它其實并不復(fù)雜，作者只是想更加全面的來給“缺陷”下定義。下面我們來以建一棟房子為例，來說明一下每一條定義的意思。需要說明的是沒有十分完美而且一成不變的產(chǎn)品說明說，而且在實際項目中，它可能非常簡陋，模棱兩可，甚至經(jīng)常變動。
1、軟件沒有實現(xiàn)產(chǎn)品說明書的描述的功能。房子的主人希望有一個落地的大窗戶，讓陽光更好的照進屋子里，而且他特意在房子的設(shè)計圖紙中畫出來，并且還加以說明。結(jié)果，他看到的是四面全是墻壁，只有一個小門的房子。那么對于測試人員來說，他就是一個缺陷。
2、軟件實現(xiàn)了產(chǎn)品說明書中描述的不應(yīng)有的功能。由于房子的主人生活在南方，天氣溫暖，而請來的泥瓦匠是北方的，結(jié)果給主人建造的房子具然有一個大大的取暖的煙筒，而且主人特意在房子的設(shè)計圖紙中說明，自己的房子不要煙筒。那么對于測試人員來說，這也是個缺陷。
3、軟件執(zhí)行了產(chǎn)品說明書沒講的操作。與第二條類似，不同的是第二條是主人已經(jīng)明確說了自己不要煙筒，而這一條強調(diào)的是在主人沒說的情況下。泥瓦匠自作聰明的加了一個煙筒上去。對于測試人員來說，畫蛇添足的功能同樣被視為缺陷。
4、軟件沒有實現(xiàn)產(chǎn)品說明書沒講但應(yīng)該實現(xiàn)的功能。房子的主要對屋子的高度、格局，材料，顏色描述的非常清楚。泥瓦匠在建造房子的時候發(fā)現(xiàn)，主人沒有提地基這回事，為了使房子牢固，所以，所有的房子都是必須要先打地基的，雖然主人沒有說，但地基的功能必須要做。如果因為沒有描述沒有去做，但這又一件必須去做的事。對于測試人員來說，也可以視其這缺陷。
6、從軟件測試員的角度看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認為不對。軟件測試員是軟件除了測試軟件運行的缺陷，同樣是作為一個用戶在再對軟件進行使用。如果感覺自己都很難使用，或軟件效率非常低且界面丑陋等情況，也可以認為其存在缺陷。或者是最終用戶拿到產(chǎn)品時發(fā)現(xiàn)這根本不是自己想要的東西，也可以現(xiàn)其為缺陷。當(dāng)然，用戶說不是自己想要的東西，也不能憑借一面之詞，可以拿合約，產(chǎn)品說明書來評估。
Ok ，上面分析一下缺陷的定義，如何去判定一個缺陷。下面來看一下測試的原側(cè)，我們可以視其為軟件測試過程中的“交通規(guī)則”。它會有助于我們更好的進行軟件測試的工作。
全完測試程序的可能性
初做軟件測試者可能認為拿到軟件后就可以進行完全測試了，找出所有軟件缺陷，并使軟件完美。遺憾的是這是不可能的，我們無法對一個軟件進行完全測試，即使最簡單的程序也不行。主要原因如下：
以上的“太多”的可能性加在一起，致使測試條件難以確定。原書中引用計算器的例子，太復(fù)雜了，好吧！我們換個更簡單有郵箱登錄。雖然對以“登錄”為樣例表示方案，就像每個介紹編程的書上來的第一個例子就是“hello world”。但這個例更能簡單的說明問題，這里就再用一下。
以126郵箱為例，其用戶長度為50個字符，密碼確實不太好計算（因為都是*號），所以這里也按50個字符來計算。好吧！雖然，我已經(jīng)知道了正確的用戶名和密碼。
在輸入正確用戶名的情況下：
1、輸入正確的密碼名是還否可以登錄，
2、那么錯誤輸入0 呢？1呢？2呢？......直到
99999999999999999999999999999999999999999999999999 ，
3、如果密碼不是數(shù)字，而是字符呢，a 、b、c ... aa、bb 、cc .....
4、如果是大寫呢 A 、B、C.... AA 、BB、CC.....
5、如果是大小寫呢 Aa、Ab ....
6、如果是小寫+數(shù)字呢 1a 、1b 、1c ....2a 、2b 、2c.....
7、如果是大寫+數(shù)字呢 1A 、1B 、1Cc....2A 、2A 、2A.....
8、如果是大寫+小寫+數(shù)字呢 1Aa 、1Bb 、1Cc ....1Aa 、1Bb 、1Cc.....
9、如果有特殊字符呢 @#￥%……&*
10、如果輸入字符有空格呢 a b、adbc ee......
11、如果是其它字符+大小寫字母+數(shù)字呢+空格呢 ！@#&+123AIBKIkklzcb ......
......
12、再換正確的密碼，錯誤的文件名再來一次。
13、用錯誤的用戶名和密碼再把上面的情況驗證一次。（這樣會匹配到所有的用戶名密碼）
14、什么都不輸，直接點擊登錄
這樣窮舉下去，哪怕世界上超級的計算機，也需要計算十年、百年才能驗證所有情況。如果覺得某些測試條件是重復(fù)的或都無必要的或都為了節(jié)省時間，而將其剔除，那么就不能稱為完全測試。
軟件測試是有風(fēng)險的
好吧！你已經(jīng)知道了不進行完全測試是有風(fēng)險的，如果決定不去測試所有的情況，那么我們就選擇了風(fēng)險。在上面的郵箱登錄的例子中，（假如）由于程序所使用語言的特點，有些字符在存儲的時候會被轉(zhuǎn)義，如& 會被轉(zhuǎn)義為_ 存儲，一個叫“&&” 用戶，一個叫“ __”的用戶，使用了相同的密碼，碰巧程序員沒考慮到這種情況，那么程序該如何登錄呢？（我也不知道，這只是個假設(shè)的例子）
對于一個免費開放的郵箱來說，會有成千上萬的用戶每天都有用戶注冊登錄，如果有用戶遇到了上面的問題呢？程序該如何處理？當(dāng)然，對于一個郵箱系統(tǒng)，你可能不以為然，他的修復(fù)速度與成本都不算高，假如，這個用戶有非常保密且重要的郵件，結(jié)果被別一個用戶登錄查看了呢？假如這不是一個郵箱系統(tǒng)，而是一個銀行系統(tǒng)呢？那有可能用戶的財產(chǎn)就會受到損失。（相比較而言，互聯(lián)網(wǎng)產(chǎn)品（B/S架構(gòu)）比客戶端產(chǎn)品（C/S架構(gòu)）的修復(fù)速度與成本要低。
這樣說有些聳人聽聞，又不能全部測試，不測試又會漏掉軟件缺陷。軟件終歸要分布的，此時測試就要停止，但是如果這么快停止下來，還有測試沒做。怎么辦？
如上圖所示，縱軸是表示缺陷的數(shù)量，橫軸表示測試工作量。缺陷的數(shù)量隨著測試工作的進展在不段減少；但測試費用也隨著工作量在不段提高。
也就是說要想發(fā)現(xiàn)更多的缺陷就必須投入更多費用（這個費用包括時間、人力，物力）， 對一個新項目，我們前提可能1天發(fā)現(xiàn)10個缺陷。到后面可能10天發(fā)現(xiàn)1個缺陷，或者發(fā)現(xiàn)一個缺陷所需要的時間更長，我們有必要為發(fā)現(xiàn)一個缺陷而繼續(xù)增加費用么？本來就不存在完美的產(chǎn)品，我們的目標(biāo)是找到最合適的測試量，使投入（測試費用）與回報（修復(fù)缺陷數(shù)）達到最優(yōu)。
測試無法顯示潛在的軟件缺陷
仔細理解一下這個標(biāo)題。當(dāng)測試人員對一個軟件進行測試時，他發(fā)現(xiàn)了很多缺陷，功能的，界面的，兼容性能。然后，測試人員可以好不憂郁的說，這個軟件存在缺陷。
當(dāng)測試人員又對另一個軟件進行測試時，他用盡各種測試方法，測遍所有功能（當(dāng)然，這是不可能，上面已經(jīng)說了無法完全測試），他投入了大量的時間和精力卻最終沒有發(fā)現(xiàn)一個缺陷。那么測試人員不能保證這個軟件是沒缺陷的，當(dāng)然，他更無法去報告這些潛伏的缺陷。也就是說測試人員只能報告已經(jīng)發(fā)現(xiàn)的缺陷，對于未知的誰也不能肯定。
?。ㄟ@也是測試人員遭受質(zhì)疑的地方，你既然不能保證軟件的質(zhì)量，要你何用。測試人員可以提高軟件的質(zhì)量，至于能提高多少，全憑測試人員的能力決定了。不像開發(fā)人員對于一個功能的實現(xiàn)，能或不能是很明確的兩個答案。）
找到的軟件缺陷越多，就說明軟件的缺陷越多
我們先來體會下面兩句話。
“找到的軟件缺陷越多，說明軟件遺留的缺陷越少”
“找到的軟件缺陷越少，說明軟件遺留的缺陷越少”
不管是開發(fā)還是測試，我們期望軟件遺留的缺陷少。但是上面的兩句話都不成立。我們發(fā)現(xiàn)缺陷的多少和最終軟件遺留的缺陷多少毫無關(guān)系。那么為什么會有上面兩種推斷呢？
“找到的軟件缺陷越多，說明軟件遺留的缺陷越少”這種情況，假設(shè)缺陷在一定數(shù)量的情況下，測試人員業(yè)務(wù)非常精通，測試極其認真，發(fā)現(xiàn)越多的缺陷 ，說明還遺留的缺陷就越少。那么，我也可以假設(shè)隨便這么一測，就發(fā)現(xiàn)這么多缺陷，那這個軟件應(yīng)該還有很多。
“找到的軟件缺陷越少，說明軟件遺留的缺陷越少”這種情況，假設(shè)開發(fā)人員經(jīng)驗非常豐富，而且工作非常認真，測試人員花費了很大的時間和精力都不能找到缺陷，說明軟件本身的質(zhì)量很好，也就是說其本身遺留的缺陷越少。那么，我也可以假設(shè)為，是不是測試對業(yè)務(wù)不夠熟悉，經(jīng)驗不夠豐富，為什么發(fā)現(xiàn)不了缺陷。那么可能軟件遺留的缺陷還有很多，只是我沒有發(fā)現(xiàn)。
更嚴謹說法，或者更準確的說法是“找到的軟件缺陷越多，只能說明軟件的缺陷越多?！蔽覀儼l(fā)現(xiàn)的缺陷越多，只能說明軟件的缺陷多。并無法正明軟件還遺留的缺陷的多少。
當(dāng)然，也并不是無法評估軟件遺留缺陷的多少，我們可以根據(jù)開人員的工作經(jīng)驗與技術(shù)能力，測試人員的工作經(jīng)驗，測試技能，對業(yè)務(wù)的熟悉程度以及以往完的成項目質(zhì)量進行評估。
并非所有軟件缺陷都能修復(fù)
“每一個測試人員都一顆追求完美的心”，當(dāng)我們發(fā)現(xiàn)了一個缺陷時，我們希望它能夠被修復(fù)，我們不能容忍被發(fā)現(xiàn)的缺陷眼睜睜的存在著而無法得到修復(fù)。在軟件測試中，令人沮喪的現(xiàn)實是，即使拼盡全力，也不是所有的軟件缺陷都能修復(fù)。
這并不意味著軟件測試員未達到目的，或者項目小組將發(fā)布質(zhì)量有缺陷的產(chǎn)品。其真正的含義是要軟件測試員具備本文開頭（缺陷的定義）中所描述的測試的素質(zhì)---進行良好的判斷，搞清楚在什么情況下不能追求完美。項目小組需要每對一個軟件缺陷進行取舍，根據(jù)風(fēng)險決定哪些要修復(fù)，哪些不要。
不需要修復(fù)軟件缺陷的原因：
* 沒有足夠的時間。在任何一個項目中，通常是軟件功能較多，而代碼編寫人員和軟件測試人員較少，而且在項目進度中沒有給測試留出足夠的空間。
* 不算真正的缺陷?；蛘哂腥苏f，這不算缺陷，而是一項新的功能。在某些特殊場合，錯誤理解、測試錯誤或說明書變更會把軟件缺陷當(dāng)作附加功能來對待。
* 目前技術(shù)無法解決。你不會相信，人類有豐富的想象力，很多時候是受制于技術(shù)上無法實現(xiàn)。
* 修復(fù)的風(fēng)險太大。這種情況非常常見。軟件本身是脆弱的、難以理清頭緒。修復(fù)一個軟件缺陷可能導(dǎo)致其它軟件缺陷出現(xiàn)。在緊迫的產(chǎn)品發(fā)布進度壓力之后，修復(fù)軟件將冒引入更多缺陷的情況下。我們只能不去理睬現(xiàn)有的缺陷。
* 修復(fù)成本太高，當(dāng)我們使用一種技術(shù)去完成一項工作，當(dāng)技術(shù)將要完成的時候發(fā)現(xiàn)一個缺陷無法解決，需要換用另一個技術(shù)才能有效規(guī)避這個缺陷。那這個修復(fù)成本將非常高。迫于時間與成本的壓力。我們需要暫時不去理會。
* 不值得修復(fù)。雖然有些不中聽，但這是真的。不常出現(xiàn)的軟件缺陷和在不常用的功能中出現(xiàn)的缺陷，或都出現(xiàn)也不會造成什么影響，那么就不值得去修復(fù)。這些都要歸結(jié)為商業(yè)風(fēng)決策。
軟件說明書不斷變化
軟件開發(fā)者面臨一個難題。整個行業(yè)變化太快，去年還很時髦的產(chǎn)品今年就過時了，同時，軟件變得更龐大、更復(fù)雜，功能越來越多，導(dǎo)致軟件開發(fā)周期不斷變長。這兩種反作用力形成了矛盾，結(jié)果是產(chǎn)品說明書一變再變。
除了緊跟變化沒有其他方法。假定我們的產(chǎn)品有一個不得更改的最終產(chǎn)品說明書。經(jīng)過兩年按部就班的開發(fā)快要完工時，結(jié)果競爭對也手發(fā)布了一個產(chǎn)品，結(jié)果從功能、性能、用戶體驗都要優(yōu)于我們即將完工的產(chǎn)品。我們是繼續(xù)完成一個失去競爭力的產(chǎn)品，還是重新討論產(chǎn)品功能，重寫產(chǎn)品需求，并開發(fā)修訂產(chǎn)品？明智的選擇是后者。
軟件測試員必須要想到產(chǎn)品需求可能改變。未曾計劃的特性會增加，經(jīng)過測試并報告軟件缺陷的特性可能發(fā)生變化甚至被刪除。這些者是可能的。
軟件測試術(shù)語
準確與精確
關(guān)于軟件準確與精確之間是存在區(qū)別的。我的理解在保證準確的基礎(chǔ)上求精確。拿一個計算器來做例子。我最喜歡拿一個計算器來輸入10除以3 ，如查等于3.0（四舍五入）了，那么它就不夠準確。如果計算的結(jié)果是3.3.... 那么要我看他的小數(shù)點后面有幾個3 ，3越多表示越精確。（個人認為在軟件測試中，這個用到的不多）
驗證和合法性檢查
雖然驗證和合法性檢查常?；Q使用，但是他們有不同的定義。其中的差別對軟件測試很重要。
驗證是保證軟件符合產(chǎn)品需求的過程。合法性檢查是保證軟件滿足用戶要求的過程。
驗證更多的是站在產(chǎn)品需求的角度去測試軟件，合法性（或叫“合理性”合適）是站在用戶的角度是測試軟件，當(dāng)他們發(fā)生沖突時，就需要對產(chǎn)品時行衡量。但我偏向于用戶角度，因為產(chǎn)品的最終目的是給用戶使用，而不是為了符合需求文檔。
質(zhì)量和可靠性
質(zhì)量解釋為“優(yōu)秀程度”或者“超越同類的”。如果說軟件產(chǎn)品質(zhì)量高，就是指它能夠滿足客戶要求。客戶會感到該產(chǎn)品性能卓越，優(yōu)于其他產(chǎn)品。
如果在測試過程一直穩(wěn)定、可靠，就會認為這是高質(zhì)量的產(chǎn)品。這樣理解錯誤?？煽啃灾皇琴|(zhì)量的一個方面。那么產(chǎn)品在各種機型上是否一樣運行穩(wěn)定。是否有技術(shù)支持，是否使用方便且性能優(yōu)秀，這些灰是質(zhì)量的組成部分。
測試與QA
軟件測試人員的目標(biāo)是找出軟件的缺陷，盡可能早的發(fā)現(xiàn)并確定修復(fù)缺陷。
QA的主要職責(zé)是創(chuàng)建和加強促進軟件開發(fā)并防止軟件缺陷的標(biāo)準和方法。
