做軟件測試工作的三重境界

測試的第一重境界：圍著Bug轉

“意 識決定行動，行動決定結果”是管理學中眾所周知的名言。做測試的前幾年，筆者并沒有這個意識，也沒有主動地去思考過這個問題，但隨著一個個項目任務、一樁 樁事件的歷練，慢慢感悟到這句話也適合對測試工作境界的理解。“心態決定命運”，“態度決定一切”，有很多名家學者都寫過這方面的書籍，基本上已成了我們 不可否認的真理了，但是要真正應用在自己的工作生活中，恐怕就不那么簡單了。誠然，測試工作，除了需要擁有過硬的測試技術外，還必須有正確的測試心態，也 正是這些心態意識左右著你的日常工作。不同的心態反映了不同的測試境界高度，最終體現出不同的結果。

圍著Bug轉，是測試三重境界中的第一重。概括起來，它又可以分為三個階段，第一，發現Bug；第二，定位Bug；第三，關閉Bug。這三個階段對測試人員 的要求不僅在技術上需要逐層遞進，在綜合素質上也提出更高的要求。三個階段之間環環相扣。直到Bug的生命周期結束。圍著Bug轉的三個階段對測試人員的 要求及Bug被發現到關閉的生命周期示意圖。如圖2-1所示。

圖2-1 圍著Bug轉的三個進階圖

談到圍著Bug轉的的三個階段，不禁想起中國近代著名學者王國維在《人間詞話》中提到的人生的三重境界：

“昨夜西風凋碧樹，獨上高樓，望盡天涯路”。

“衣帶漸寬終不悔，為伊消得人憔悴”。

“眾里尋他千百度，驀然回首，那人卻在燈火闌珊處”。

細細思量，感覺它們之間亦有異曲同工之處。

第一重“昨夜西風凋碧樹，獨上高樓，望盡天涯路”是說“古今之成大事業、大學問者，首先要樹立明確的目標，即使長路漫漫，也下定決心將這條長路走下去。這是一個人在孤獨之中尋找理想、尋找生命的落腳點的痛苦時刻”。圍著Bug轉的第一階“發現Bug”，同樣首先必須有明確清晰的目標，找Bug的過程是漫長的，反反復復、枯燥無味是工作的特點，但是為了達到目標“長路再漫漫，也得堅持走下去”，直到找到一堆堆的Bug。特別是對一些偶現的嚴重Bug，重現Bug的過程真如大海撈針，但是堅持就是勝利。筆者曾經在經歷的一個項目中，花了近1個月的時間去重現與解決一個嚴重問題，最后在與開發人員的緊密合作下，終于找到問題的根源。

第二重“衣帶漸寬終不悔，為伊消得人憔悴”是說“執著的追求、忘我的奮斗，直至憔悴消瘦，連衣服都變得寬大，這一切努力都是為了心中的夢想”。對應軟測中圍著Bug轉的第二階“定位Bug”。 這一階段不僅在技術上提出了更高的要求，還要有刻苦鉆研、窮追到底、不撞南墻不回頭的執著精神，直到把問題的原因搞清楚才罷休。在國內目前的測試領域，大 部分公司這一步并沒有要求測試人員來做，但是在國外，特別是一些知名的大公司，如在微軟，幾乎所有的測試人員都擁有深入調試程序的技能。它除了包含以最短 路徑重現問題，還要分析問題的可能結果（例如分析Bug會影響到哪些模塊），甚至給開發人員提出解決方案。顯然，這一步要求測試人員要比開發人員具有更高的設計分析能力、代碼調試能力、解決問題的能力。讀者朋友，看到這里，對一些測試專業網上?？吹降?ldquo;測試人員是否要懂編程”這一問題已釋然于懷了吧。

第三重“眾里尋他千百度，驀然回首，那人卻在燈火闌珊處”。這一階段是指經過不斷磨煉，多次的失敗，某一時刻忽然靈犀一點，領悟真諦，發現自己想要的東西原來就在自己的身邊或領悟后的心里。在旁人看來，他的“驀然回首”是如何偶然而幸運，但其背后的用功之勤、平時的積累之深，又豈是常人所能堅持，所能想象的呢？這時候，世俗目標是否已經達到已不再重要，重要的是靈魂的解放和心靈的歸屬。對應圍著Bug轉的第三階“關閉Bug”，如果僅從字面理解，很簡單，不就是開發解決了Bug，回歸Bug，然后把Bug關閉。如果是這樣，筆者認為這種觀念仍屬于第一階。第三階的關閉Bug，是指測試人員提交一個Bug后，要有主動意識推動開發人員解決問題，并協助他們解決，只有問題解決了，軟件的質量才得以提高，測試人員的最終目的才能達到。提交的有些問題嚴格來說，它不屬于Bug， 而是一種設計缺陷，此時測試人員該怎么辦呢？需主動召集相關專家進行其影響面的風險分析，并跟進此問題的整個解決過程，如果風險點涉及其他專業的更改（如 嵌入式軟件涉及硬件、機械等方面的知識），可能需要專門成立一個專項問題解決團隊，以全面解決此問題，直到各專業方向的問題解決到位，回歸驗證完成，此Bug方能關閉。站在Bug的生命周期角度分析，一個Bug由被發現的起點，走到被關閉的終點，才是一個合理的、完整的過程，如圖2-2所示。但是要達到這一層，很可能有一大部分的工作已完全脫離了純軟件測試層面的工作，可是測試的最終目標不就是給用戶一個高質量、信得過的產品嗎？我們需要有這樣的大氣胸懷，才能把產品的測試工作做得更深遠、更寬闊。

接下來結合案例對圍著Bug轉的三個階段分別進行介紹。

圖2-2 Bug 生命周期曲線閉環圖

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

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

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

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

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

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

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

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

圖2-3已發現Bug為核心的測試機制

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

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

圖2-4 測試與項目管理要素關系圖

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

小貼士：

1、做正確的事與正確地做事

2、做正確的事出發點是企業利益最大化，而不是站在個人和小團體的立場去做事，也不是怕承擔責任，把事推給別人。要求我們在眾多的可能性中選擇，辨別出什么是正確的，什么是最直接、最可行的做事方式和方法，把企業效益最大化作為辦事的標準。

3、正確地做事，是驅動具體做事的人員如何按照領導的意見去做事，而不去考慮是否符合企業效益最大化的原則。

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

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

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

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

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

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

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

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

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

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

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

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

測試的第三重境界：挑戰零缺陷

孔子說“人無遠慮，必有近憂”，用在軟件測試上，是什么意思呢？可以這樣理解，如果我們不從發生問題的根源上解決問題，認為測試僅僅是找Bug，千方百計找Bug，覺得Bug總是找不完，意識中就會陷入“永無天日”的狀態。然而，有小部分測試人員還真希望軟件存在多一些問題（唯恐天下不亂），這樣可以多提交Bug，認為業績比沒有提交多少Bug肯定要好。無獨有偶，有小部分開發人員也把自己犯下的程序錯誤視為理所當然，甚至還有個別人會戲虐地說“軟件如果沒有Bug的話，測試人員不就失業了”。這好像在唱一出雙簧戲。軟件開發的整個過程中，Bug是理所當然要存在的，是這樣嗎？軟件工程中軟件危機的根源問題只能通過找到Bug的手段來控制嗎？

實際上，我們都很清楚，任何一個Bug的產生都是有來源的，來源包括需求的設計、軟件的設計（含代碼的編寫）等。相對于前端的設計，測試是事后的驗證，是一種“堵”漏洞的措施。然而，在實際工作中，時間與成本并不允許我們去堵住所有的Bug。日本質量大師田口玄一說得好“質量是設計出來的，而不是測試出來的”。如果我們能變被動為主動，在設計之前，就做好設計的防患措施，為設計高質量的軟件打下堅實的基礎，這便是本節打算向讀者介紹的測試的第三重境界：挑戰零缺陷。

1、缺陷的防與堵

幾乎在每次面試測試工程師時，筆者都會問一個這樣的問題：“你所負責測試過的模塊，是否存在漏測的情況”，幾乎每個應聘者都回答說“有”。面對復雜的軟件，紛繁復雜的運行環境，在有限時間內進行的測試活動，做到真正的零Bug是 不可能的，也是不現實的。但這些都不是理由，所有的測試活動是有目的的商業活動，每個公司有自己測試通過的一套標準或原則。雖然漏測不可避免，但并不是說 漏測是一種正?，F象或應該的現象，出現的漏測問題如果超出公司所能接受的原則，就屬于不正常的現象，很有必要進行漏測分析。進行漏測分析活動（需要特別注 意的是它絕不是對漏測人員的批斗會），它的主要目的是通過分析過去的教訓，找出問題的根源，分析測試中哪個環節工作存在缺失，以拿出規避的可操作的措施出來。

測試人員進行漏測分析時，免不了對問題進行追本溯源。軟件是由開發人員設計出來的，所以漏測分析活動少不了開發人員在場，甚至有時還會涉及需求設計人員。關于漏測分析的追本溯源，這里有一個關于開發與測試之間的工作關系像修筑堤壩一樣的有趣比喻，如圖2?11所示。開發人員設計軟件就像修筑一道堤壩，如果堤壩在結構上存在問題，當洪水沖擊時，可能不只是局部的泄漏，而是直接的決堤，猶如軟件的崩潰。高高的堤壩，難免會存在漏水的小洞，或滲水的小孔，就好像軟件中存在的小Bug。越是在堤壩基部的漏水或滲水問題越難發現，解決的代價也越大。

在設計時要把結構建牢，不存在漏洞當然更好，這是一種防范。如果超越防范界線，把設計帶出的大洞小孔遺留到測試環節，它只好拿著各種放大鏡（使用各種方法）來檢測，以網羅各種深深淺淺、大大小小的問題，最后通過“打補丁”的方式，堵住堤壩上的“百孔千瘡”。

圖2-5缺陷的防堵與堤壩的防堵形象理解示意圖

2、缺陷的防堵

在對缺陷的防與堵方面，測試是發現問題的中間角色，告訴開發人員哪里漏水或滲水了。防與堵的工作是由建堤者來做的。當然，防是主動的，堵是被動的，主動變為被動后，中間經歷了資源與時間的投入，誠然即使是同一個Bug，它們的代價也是完全不一樣的。這種堵越在后面，影響越大，代價也就越大，如圖2-6所示（摘自《代碼大全》）是一個根據缺陷出現的階段來增加測試成本的例子。

圖2-6 根據缺陷的引入和檢測時間，修正同一缺陷所需的平均成本

如上圖2-6所示為在需求階段引入的一個缺陷。如果立即發現了此問題，修改成本只需要1美元，但如果在系統測試階段發現它，修改成本就增加了10倍。更為嚴重的是，如果在版本發布后用戶端發現了此問題，則需付出10倍以上甚至是100倍的代價。缺陷在系統中的時間越長，解決它的代價就越大，因為時間越長，開發與測試人員修改的成本就越高，還將影響大面積的用戶端升級。

原文轉自：http://www.uml.org.cn/Test/201306184.asp