最近在讀《軟件測試》 一書，對叫這個名字的書多，我讀的是Ron Patton 寫的那本，對！2002年的中文版，已經十年了，雖然沒《軟件測試的藝術》那麼經典，那麼有深度，但絕對也是一本不錯的好書。讀到第三章“軟件的實質”，覺得確實不錯，這裏摘錄與大家分享。
實質，哲學中的本質，又稱爲“實質”是指某一對象或事物本身所必然固有的。說的通俗點也就是說軟件測試的本來的面目。
軟件缺陷的定義
來看一下Ron Patton 爲我們的軟件缺陷所下的定義。
1、軟件沒有實現產品的說明書所描述的功能。（個人覺得“描述”比“宣稱”更貼切）
2、軟件實現了產品說明書描述不應有的功能。
3、軟件執行了產品說明書沒講的操作
4、軟件沒有實現產品說明書沒講但應該實現的功能。
5、從軟件測試員的角度來看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認爲不對。
爲什麼一個定義要這麼多條來描述？這個“缺陷”的定義有這麼複雜麼？不，它其實並不複雜，作者只是想更加全面的來給缺陷下定義。下面我們來以建一棟房子爲例，來說明一下每一條定義的意思。需要說明的是沒有十分完美而且一成不變的產品說明說，而且在實際項目中，它可能非常簡陋，模棱兩可，甚至經常變動。
1、軟件沒有實現產品說明書的描述的功能。房子的主要希望有一個落地的大窗戶，讓陽光更好的照進屋子裏，而且他特意在房子的設計圖紙中畫出來，並且還加以說明。結果，他看到的是四面全是牆壁，只有一個小門的房子。那麼對於測試人員來說，他就是一個缺陷。
2、軟件實現了產品說明書中描述的不應有的功能。由於房子的主人生活在南方，天氣溫暖，而請來的泥瓦匠是北方的，結果給主人建造的房子具然有一個大大的取暖的煙筒，而且主要主要特意在房子的設計圖紙中說明，自己的房子不要煙筒。那麼對於測試人員來說，這也是個缺陷。
3、軟件執行了產品說明書沒講的操作。與第二條類似，不同的是第二條是主人已經明確說了自己不要煙筒，而這一條強調的是在主人沒說的情況下。泥瓦匠自作聰明的加了一個煙筒上去。對於測試人員來說，畫蛇添足的功能同樣被視爲缺陷。
4、軟件沒有實現產品說明書沒講但應該實現的功能。房子的主要對屋子的高度、格局，材料，顏色描述的非常清楚。泥瓦匠在建造房子的時候發現，主人沒有提地基這回事，爲了使房子牢固，所以，所有的房子都是必須要先打地基的，雖然主人沒有說，但地基的功能必須要做。如果因爲沒有描述沒有去做，但這又一件必須去做的事。對於測試人員來說，也可以視其這缺陷。
6、從軟件測試員的角度看，軟件難以理解、不易使用、運行緩慢，或者最終用戶認爲不對。軟件測試員是軟件除了測試軟件運行的缺陷，同樣是作爲一個用戶在再對軟件進行使用。如果感覺自己都很難使用，或軟件效率非常低且界面醜陋等情況，也可以認爲其存在缺陷。或者是最終用戶拿到產品時發現這根本不是自己想要的東西，也可以現其爲缺陷。當然，用戶說不是自己想要的東西，也不能憑藉一面之詞，可以拿合約，產品說明書來評估。
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、什麼都不輸，直接點擊登錄
這樣窮舉下去，哪怕世界上超級的計算機，也需要計算十年、幾百年才能驗證所有情況。如果覺得某些測試條件是重複的或都無必要的或都爲了節省時間，而將其剔除，那麼就不能稱爲作完全測試。
軟件測試是有風險的
好吧！你已經知道了完全測試是有風險的，如果決定不去測試所有的情況，那麼我們就選擇了風險。在上面的郵箱登錄的例子中，（假如）由於程序的所使用語言的特定，有些字符在存儲的時候會被轉義，如& 會被轉義爲_ 存儲，一個叫“&&” 用戶，一個叫“ __”的用戶，使用了相同的密碼，碰巧程序員沒考慮到這種情況，那麼程序該如何登錄呢？（我也不知道，這只是個假設的例子）
對於一個免費開放的郵箱來說，會有成千上萬的用戶每天都有用戶註冊登錄，如果有用戶遇到了上面的問題呢？程序該如何處理？當然，對於一個郵箱系統，你可能不以爲然，他的修復速度與成本都不算高，假如，這個用戶有非常保密且重要的郵件，結果被別一個用戶登錄查看了呢？假如這不是一個郵箱系統，而是一個銀行系統呢？那有可能用戶的財產就會受到損失。（相比較而言，互聯網產品（B/S架構）比客戶端產品（C/S架構）的修復速度與成本要低）
這樣說有些聳人聽聞，又不能全部測試，不測試又會漏掉軟件缺陷。軟件終歸要分佈的，此時測試就要停止，但是如果這麼快停止下來，還有測試沒做。怎麼辦？
如上圖所示，縱軸是表示缺陷的數量，橫軸表示測試工作量。缺陷的數量隨着測試工作的進展在不段減少；但測試有費用也隨着工作量在不段提高。
也就是說要想發現更多的缺陷就必須投入更多費用（這個費用包括時間、人才，物力）， 對一個新項目，我們前提可能1天發現10個缺陷。到後面可能10天發現1個缺陷，或者發現一個缺陷所需要的時間更長，我們有必要是去爲發現一個缺陷而繼續增加費用麼？本來就不存在完美的產品，我們的目標是找到最合適的測試量，使投入（測試費用）與回報（修復缺陷數）達到最優。
測試無法顯示潛在的軟件缺陷
仔細理解一下這個標題。當測試人員對一個軟件進行測試時，他發現了很多缺陷，功能的，界面的，兼容性能。然後，測試人員可以好不憂鬱的說，這個軟件存在缺陷。
當又測試人員又對另一個軟件進行測試時，他用盡各種測試方法，測遍所有功能（當然，這是不可能，上面已經說了無法完全測試），他投入了大量的時間和精力卻最終沒有發現一個缺陷。那麼測試人員不能保證這個軟件是沒缺陷的，當然，他更無法去報告這些潛伏的缺陷。也就是說測試人員只能報告已經發現的缺陷，對於未知的誰也不能肯定。
（這也是測試人員遭受質疑的地方，你既然不能保證軟件的質量，要你何用。測試人員可以提高軟件的質量，至於能提高多少，全憑測試人員的能力決定了。不像開發人員對於一個功能的實現，能或不能是很明確的兩個答案。）
找到的軟件缺陷越多，就說明軟件的缺陷越多
我們先來體會下面兩句話。
“找到的軟件缺陷越多，說明軟件遺留的缺陷越少”
“找到的軟件缺陷越少，說明軟件遺留的缺陷越少”
不管是開發還是測試，我們期望軟件遺留的缺陷少。但是上面的兩句話都不成產。我們發現缺陷的多少和最終軟件遺留的缺陷多少毫無關係。那麼爲什麼會有上面兩種推斷呢？
“找到的軟件缺陷越多，說明軟件遺留的缺陷越少”這種情況，假設缺陷在一定數量的情況下，測試人員業務非常精通，測試極其認真，發現越多的缺陷 ，說明還遺留的缺陷就越少。那麼，我也可以假設隨便這麼一測，就發現這麼多缺陷，那這個軟件應該還有很多。
“找到的軟件缺陷越少，說明軟件遺留的缺陷越少”這種情況，假設經驗非常豐富，而且工作非常認少，測試人員花費了很大的時間和精力都不能找到缺陷，說明軟件本身的質量很少，也就是說其本身遺留的缺陷越少。那麼，我也可以假設爲，是不是我對業務不夠熟悉，經驗不夠豐富，爲什麼發現不了缺陷。那麼可能軟件遺留的缺陷還有很多，只是我沒有發現。
更嚴謹說法，或者更準確的說法是“找到的軟件缺陷越多，就說明軟件的缺陷越多。”我們發現有缺陷越多，只能說明軟件的缺陷多。並無法正明軟件還遺留的缺陷的多少。
當然，也並不是無法評估軟件遺留缺陷的多少，我們可以根據開人員的工作經驗與技術能力，測試人員的工作經驗，測試技能，對業務的熟悉程度以及後以往完的成項目質量進行評估。
並非所有軟件缺陷都能修復
“每一個測試人員都一顆追求完美的心”，當我們發現了一個缺陷時，我們希望它能夠被修復，我們不能容忍被發現的缺陷眼睜睜的存在着而無法得到修復。在軟件測試中，令人沮喪的現實是，即使拼盡全力，也不是所有的軟件缺陷都能修復。
這並不意味着軟件測試員未達到目的，或者項目小組將發佈質量有缺陷的產品。其真正的含義是要軟件測試員具備本文開頭（缺陷的定義）中所描述的測試的素質---進行良好的判斷，搞清楚在什麼情況下不能追求完美。項目小組需要每對一個軟件缺陷進行取捨，根據風險決定哪些要修復，哪些不要。
不需要修復軟件缺陷的原因：
* 沒有足夠的時間。在任何一個項目中，通常是軟件功能較多，而代碼編寫人員和軟件測試人員較少，而且在項目進度中沒有編制和測試留出足夠的空間。
* 不算真正的缺陷。或者有人說，這不算缺陷，而是一項新的功能。在某些特殊場合，錯誤理解、測試錯誤或說明書變更會把軟件缺陷當作附加功能來對待。
* 目前技術無法解決。你不會相信，人類有豐富的想象力，很多時候是受制於技術上無法實現。
* 修復的風險太大。這種情況非常常見。軟件本身是脆弱的、難以理清頭緒。修復一個軟件缺陷可能導致其它軟件缺陷出現。在緊迫的產品發佈進度壓力之後，修復軟件將冒引入更多缺陷的情況下。我們只能不去理睬現有的缺陷。
* 修復成本太高，當我們使用一種技術去完成一項工作，當技術將要完成的時候發現一個缺陷無法解決，需要換用另一個技術纔能有效規避這個缺陷。那這個修復成本將非常高。迫於時間與成本的壓力。我們需要暫時不去理會。
* 不值得修復。雖然有些不中聽，但這是真的。不常出現的軟件缺陷和在不常用的功能中出現的缺陷，或都出現也不會造成什麼影響，那麼就不值得去修復。這些都要歸結爲商業風決策。
軟件說明書不斷變化
軟件開發者面臨一個難題。整個行業變化太快，去年還很時髦的產品今年就過時了，同時，軟件變得更龐大、更復雜，功能越來越多，導致軟件開發週期不斷變長。這兩種反作用力形成了矛盾，結果是產品說明書一變再變。
除了緊跟變化沒有其他方法。假定我們的產品有一個不得更改的最終產品說明書。經過兩年按部就班的開發快要完工時，結果競爭對也手發佈了一個產品，結果從功能性能用戶體驗都要優於我們即將完工的產品。我們是繼續完成一個失去競爭力的產品，還是重新討論產品功能，重寫產品需求，並開發修訂產品？明智的選擇是後者。
軟件測試員必須要想到產品需求可能改變。未曾計劃的特性會增加，經過測試並報告軟件缺陷的特性可能發生變化甚至被刪除。這些者是可能的。
軟件測試術語
準確與精確
關於軟件準確與精確之間是存在區別的。我的理解在保證準確的基礎上求精確。拿一個計算器來做例子。我最喜歡拿一個計算器來輸入10除以3 ，如查等於3.0（四捨五入）了，那麼它就不夠準確。如果計算的結果是3.3 那麼要我看他的小數點後面有幾個3 ，3越多表示越精確。（個人認爲在軟件測試中，這個用到的不多）
驗證和合法性檢查
雖然驗證和合法性檢查常常互換使用，但是他們有不同的定義。其中的差別對軟件測試很重要。
驗證是保證軟件符合產品需求的過程。合法性檢查是保證軟件滿足用戶要求的過程。
驗證更多的是站在產品需求的角度去測試軟件，合法性（或叫“合理性”合適）是站在用戶的角度是測試軟件，當他們發生衝突時，就需要對產品時行衡量。但我偏向於用戶角度，因爲產品的最終目的是給用戶使用，而不是爲了符合需求文檔。
質量和可靠性
質量解釋爲“優秀程度”或者“超越同類的”。如果說軟件產品質量高，就是指它能夠滿足客戶要求。客戶會感到該產品性能卓越，優於其他產品。
如果在測試過程一直穩定、可靠，就會認爲這是高質量的產品。這樣理解錯誤。可靠性只是質量的一個方面。那麼產品在各種機型上是否一樣運行穩定。是否有技術支持，是否使用方便且性能優秀，這些灰是質量的組成部分。
測試與QA
軟件測試人員的目標是找出軟件的缺陷，儘可能早的發現並確定修復缺陷。
QA的主要職責是創建和加強促進軟件開發並防止軟件缺陷的標準和方法。