測試的第二重境界：站在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版）》一書

肖利瓊著

電子工業出版社出版