測試的第二重境界：站在Bug之上

測試的第二重境界：站在Bug之上

   測試的價值僅僅是發現Bug嗎？通過“站在Bug之上”測試第二重境界的介紹，希望能幫助讀者正確理解測試的真正價值是什么，在實際工作中如何操作以體現這些價值。不同的理念，將會牽引著測試人員朝不同的方向邁進，“站在Bug之上”可以拓寬測試人員的視野，找到更多可以充分體現測試價值的測試鏈，讓測試人員為項目的成功做出更大的貢獻，從而帶來更寬范圍的測試成功。

測試的價值不僅僅是發現Bug

   一提到測試，大家馬上會想到Bug。測試僅僅就是為了發現Bug嗎？這是值得我們思考的問題。

從軟件測試最基本的定義出發，早在1979年J. Myers在《軟件測試的藝術》一書中提到：

l  軟件測試的目的就是盡早發現Bug。

l  一個成功的測試就是發現了至今為止尚未發現的Bug的測試。

   總之，測試就是為了發現Bug，測試所做的工作無一不是圍繞Bug而展開，如圖2-8所示。測試發現Bug越多，測試人員越自豪，越有成就感，這個觀點已幾乎根深蒂固地扎在了我們的心里，測試除了發現Bug真沒其他事情可做嗎？

   發現了很多Bug，測試人員高興了，但老板肯定是不高興的。很明顯的道理，為了解決這些Bug，他必須付出更多的成本，包括開發人員與測試人員的工資，更嚴重的還可能影響產品交付市場的時間。商場如戰場，時間就是金錢，時間能給產品帶來更多的市場空間，為企業贏得更多的利潤。理解這些商業知識能幫助我們做正確的事，并且正確地做事。認識到這一點后，相信測試朋友就不會再為某個Bug還沒有解決，版本卻上市而耿耿于懷了。測試人員應該跳出僅發現Bug就沾沾自喜的圈子，看到項目整體，站在公司的角度想測試可以做什么。只有項目成功了，公司才能獲得利潤，最終達到員工與公司雙贏的目標。

   質量、成本、時間是項目管理的三要素。它們像三足鼎立，穩如泰山，即質量好、成本低、工期短，這樣的項目當然是項目經理求之不得的。但它們又是矛盾地存在著，形象地看，它們猶如一個等邊三角形，如圖2-9所示。對其中的任何一個元素處理不當，三元素的三角關系就會變得不穩定，將給項目的成功帶來風險。

   軟件測試團隊是整個項目團隊大家庭中的成員之一，在軟件質量上把關，要盡可能早、盡可能多地發現Bug。這也是軟件測試成立的根本，是質量上能給項目做出貢獻的地方。那么在成本與時間的控制上，測試可以做些什么，要如何做呢？也就是前面提到的測試如何配合項目的成功做正確的事，并且正確地做事。

小貼士：

   對于測試，做正確的事就是站在用戶的角度，進行常用功能（模塊）重點測試，而避免非常用功能的過度測試，浪費成本，包括人力與時間的投入。正確地做事，就是采用合理、全面的測試方法驗證軟件是否符合用戶需求，不想當然地通過用戶根本不可能用到的非法操作或后門進行驗證。下面講述關于軟件測試的2-8原則，通過此2-8原則，可以使軟件測試在項目的成本與時間的應用上做到效益最大化。

   舉個大家在日常生活中常遇到的例子，如經常看到廣告上說，現在的手機軟件的功能如何強大，如何豐富，但每一功能用戶使用的頻度都一樣嗎？回答是否定的。這就有了在軟件測試范圍側重點上存在的2-8原則，即要把80%的精力放在測試20%的重點功能上。從用戶角度出發，這是值得的，也是需要這樣做的。

   首先，分析在我們的軟件系統中，哪些功能對用戶來說是核心且重要的功能，然后安排合適的測試工程師負責這些模塊。設計出的測試方案、用例進行重點評審，測試執行過程重點跟蹤。每一次軟件版本發布時，即使沒有更改此部分的代碼，也對它們進行回歸測試（這種回歸需講究策略與方法），因為它們太重要了，不允許有錯誤。

下面是軟件測試2-8原則的詳細內容。

1．80%的錯誤是由20%的模塊引起的

   簡單、容易的模塊或功能是很少引入過多Bug的，而對于存在復雜邏輯的一些關鍵模塊往往會引起系統80%的錯誤。只有關鍵模塊穩定了，整個系統才可能真正的健壯和穩定。

   這個原則對于測試來說就是站在用戶角度（而不是研發實現的角度），正確地選擇重要功能模塊作為測試的重點，不偏離方向。

2．80%的測試成本花在20%的軟件模塊中

   設計測試用例時，常會用日產多少條用例來衡量工程師的工作。用例的多少與需求量有關，而影響軟件架構設計的需求描述往往是比較少的。在這種情況下，設計測試用例時特別需要結合軟件的概要設計、詳細設計一起考慮。如果用例設計人員為了達到用例的數量，通過大量復制用例，修改個別字眼，而沒有真正去設計高效的測試用例，那么用如此低效甚至更多的用例數量來對待復雜的20%的核心模塊，在測試執行過程中必將導致一部分關鍵Bug找不出來。

3．80%的測試時間花在20%的軟件模塊中

   對于復雜的模塊，前期的測試設計和思考可能會耗費大量時間，而產出的用例量可能并不大。對于復雜的系統，特別是對于全新系統，必須舍得投入充足的時間來優先考慮設計，前期方案、用例設計的時間越短，后期的風險越大。

   在項目進展到一定階段后，增加人力并不一定能解決縮短時間的問題。例如，如果復雜且核心模塊在項目的后期才開始執行測試，由于Bug較多，而項目又需要短時間把版本穩定下來，通常的做法是加人。然而加入的新兵需要一段時間的熟悉期，必要時還需要老兵來帶，這本身又會影響到老兵的工作。另外一些性能測試、自動化測試工作也只有等版本穩定后才會有更好的效果。

本文節選自《軟件測試之魂：核心測試設計精解（第2版）》一書

肖利瓊著

電子工業出版社出版