測試的三重境界

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

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

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

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

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

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

「衣帶漸寬終不悔，爲伊消得人憔悴」。

「衆裏尋他千百度，驀然回首，那人卻在燈火闌珊處」。

細細思量，感受它們之間亦有殊途同歸之處。

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

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

第三重「衆裏尋他千百度，驀 然回首，那人卻在燈火闌珊處」。這一階段是指通過不斷磨鍊，屢次的失敗，某一時刻突然靈犀一點，領悟真諦，發現本身想要的東西原來就在本身的身邊或領悟後 的內心。在旁人看來，他的「驀然回首」是如何偶然而幸運，但其背後的用功之勤、平時的積累之深，又豈是常人所能堅持，所能想象的呢？這時候，世俗目標是否 已經達到已再也不重要，重要的是靈魂的解放和心靈的歸屬。對應圍着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在《軟件測試的藝術》一書中提到：

一、軟件測試的目的就是儘早發現Bug。

二、一個成功的測試就是發現了至今爲止還沒有發現的Bug的測試。

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

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

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

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

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

軟件測試團隊是整個項目團隊你們庭中的成員之一，在軟件質量上把關，要儘量早、儘量多地發現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較多，而項目又須要短 時間把版本穩定下來，一般的作法是加人。然而加入的新兵須要一段時間的熟悉期，必要時還須要老兵來帶，這自己又會影響到老兵的工做。另一些性能測試、自動化測試工做也只有等版本穩定後纔會有更好的效果。

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

孔子說「人無遠慮，必有近憂」，用在軟件測試上，是什麼意思呢？ 能夠這樣理解，若是咱們不從發生問題的根源上解決問題，認爲測試僅僅是找Bug，想方設法找Bug，以爲Bug老是找不完，意識中就會陷入「永無天日」的 狀態。然而，有小部分測試人員還真但願軟件存在多一些問題（惟恐天下不亂），這樣能夠多提交Bug，認爲業績比沒有提交多少Bug確定要好。無獨有偶，有 小部分開發人員也把本身犯下的程序錯誤視爲理所固然，甚至還有個別人會戲虐地說「軟件若是沒有Bug的話，測試人員不就失業了」。這好像在唱一出雙簧戲。 軟件開發的整個過程當中，Bug是理所固然要存在的，是這樣嗎？軟件工程中軟件危機的根源問題只能經過找到Bug的手段來控制嗎？

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

一、缺陷的防與堵

幾乎在每次面試測試工程師時，筆者都會問一個這樣的問題：「你所負責測試過的模塊，是否存在漏測的狀況」，幾乎每一個應聘者都回答說「有」。面對複雜的軟件，紛繁複雜的運行環境，在有限時間內進行的測試活動，作到真正的零Bug是 不可能的，也是不現實的。但這些都不是理由，全部的測試活動是有目的的商業活動，每一個公司有本身測試經過的一套標準或原則。雖然漏測不可避免，但並非說 漏測是一種正常現象或應該的現象，出現的漏測問題若是超出公司所能接受的原則，就屬於不正常的現象，頗有必要進行漏測分析。進行漏測分析活動（須要特別注 意的是它毫不是對漏測人員的批鬥會），它的主要目的是經過分析過去的教訓，找出問題的根源，分析測試中哪一個環節工做存在缺失，以拿出規避的可操做的措施出來。

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

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

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

二、缺陷的防堵

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

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

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