軟體測試的實質

 

　　最近在讀《軟體測試》 一書，叫這個名字的書好基本多，我讀的是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的主要職責是建立和加強促進軟體開發並防止軟體缺陷的標準和方法。