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

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

成都創(chuàng)新互聯(lián)專注于自貢企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站開發(fā),購物商城網(wǎng)站建設(shè)。自貢網(wǎng)站建設(shè)公司,為自貢等地區(qū)提供建站服務(wù)。全流程按需規(guī)劃網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

測試的價值不僅僅是發(fā)現(xiàn)Bug

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

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

l  軟件測試的目的就是盡早發(fā)現(xiàn)Bug。

l  一個成功的測試就是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的Bug的測試。

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

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

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

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

小貼士：

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

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

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

下面是軟件測試2-8原則的詳細內(nèi)容。

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

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

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

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

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

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

   對于復(fù)雜的模塊，前期的測試設(shè)計和思考可能會耗費大量時間，而產(chǎn)出的用例量可能并不大。對于復(fù)雜的系統(tǒng)，特別是對于全新系統(tǒng)，必須舍得投入充足的時間來優(yōu)先考慮設(shè)計，前期方案、用例設(shè)計的時間越短，后期的風(fēng)險越大。

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

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

肖利瓊著

電子工業(yè)出版社出版