《 軟體測試價值提升之路》——第1章 Chapter 1 他山之石 1.1 測試困局

本節書摘來自華章出版社《軟體測試價值提升之路》一書中的第1章，第1.1節，作者：楊曉慧編著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

引　　子

測試工作是否有價值，這似乎是一個不值得讨論的問題，因為幾乎所有的軟體公司都有測試團隊，既然一個以盈利為目的的組織，舍得為了測試進行投資，那麼測試工作就一定是有價值的。

但是另一方面，無論是從業界了解的情況，還是從我們測試團隊自身看，測試工程師轉行的比例都高于同級别的開發工程師和系統工程師，這些轉行的測試工程師在新的職業道路上大多獲得了更高職位、更好的發展。這說明他們在測試崗位上的發展受阻，并非由于自身的素質和能力造成的，很可能是由于工作的價值沒有得到肯定。

測試的工作大多數是屬于破壞性的，通過對産品的各種攻擊操作，檢驗産品是否符合需要。而軟體設計、開發工作是建設性的，主導了産品從無到有的生産過程。公司的盈利最直接的原因就是建設性的工作成果—産品，能成功銷售。是以，由于這種工作性質，測試确實是一個相對難以做出價值的職業。

一方面研發對測試的投資期望得到價值回報，另一方面測試已經做出的工作價值沒有得到充分認可。這個局如何破？這就是本書接下來将要讨論的内容。

測試這個職業從誕生之日起，對于其價值的探索就從未停止過，随着軟體技術的發展和軟體應用範圍的擴充，一方面，測試實作傳統的價值遇到了新的挑戰；另一方面，研發對測試價值也有了新的期望。

他山之石可以攻玉，在讨論測試存在的價值之前，先看看測試價值走過的路，以及在優秀的軟體公司裡，測試人員都承擔哪些職責，他們的做法可以給接下來的價值讨論帶來哪些啟示。

1.1　測試困局

在我的工作中，經常會聽到測試經理訴苦說工作難做。測試經理經常面對來自客戶、産品經理、研發經理，甚至測試内部的質疑：

産品在客戶那裡出了問題，客戶問：測試究竟能不能保證品質？

産品上市延遲了，研發經理問：究竟要花多少時間做測試？

産品架構優化、改變開發模式、采用新技術提升了開發效率，系統工程師問：測試難道就沒有新方法同步提高效率？

項目做完了，發現項目中打雜的事情多數是測試頂上，決策的時候測試沒有話語權？

職位評定時，測試工程師問：好像每年遞交的任職申請中改變的隻有項目清單，難道這些年就是不斷的重複？

測試工作看上去就是：看不到産出、說不清投入、顯不出能力（或者說是能力沒有進化）。

測試面對來自各方的對工作價值的質疑時，常常這樣“反擊”：

測試不是産出bug嗎？對不起，測試産出的bug已經改掉了，我曾經和幾個測試的同僚合作開發過自動化工具，我負責開發的子產品中有一個是通信子產品，有一次一位同僚說：hi，你做的通信子產品好牛啊，從來沒有出過問題。當我回憶起這個場景時，我了解了為什麼發現bug不容易被記住。如果開發工程師寫的代碼被調用、被拷貝，做的功能被使用時，他們在設計、實作上精心的考慮，是會被人反複看到、贊歎的。bug呢？如果發現的bug是考慮了新的要素，并且和一些陳年頑疾有關；或者發現的一個特别的bug，在後來的特性中又出現了，那麼測試工程師對測試設計的精心考慮才會被贊歎。但是這樣的機會顯然不多。

這個版本發現了1452個缺陷？對不起，這個數字意味着什麼？是表示産品品質差？測試水準高？測試做得太多了？或者其他什麼意思？

那測試提升了品質啊？其實作在針對品質的提升，通常的共識是，因為有更好的開發工具、更好的程式設計語言、更好的軟體重新開機和恢複機制、更好的分層隔離架構、更好的測試工具……而在這一路上，測試工程師本身的貢獻少得可憐。說到開發工具，測試工程師很少使用這些工具，與這些工具的開發和測試就更沒有關系了；說到開發語言，大部分測試工程師甚至做不到精通一門程式設計語言，更不要說開發過一款語言了；說到更好的軟體重新開機和恢複機制，這主要是架構和設計模式的演進，跟測試關系很小；說到測試工具，大部分測試工程師在使用這些工具，但是并不參與工具的開發和推廣。是以很少有公司把品質的改善歸功于測試的價值。

為什麼要測試有産出？測試不是藍軍嗎？不是把紅軍攻下來就是成績嗎？随着軟體架構的演進、軟體應用的普及，對開發和測試的這個紅藍軍的隐喻已經過時了，過去主流的軟體是用于軍工、航天、通信核心層、工業設計（autocad）、管理、财務等，這些軟體是針對企業的需要，一旦出問題影響也比較大，常常伴随無法承擔的經濟或人身損失。現在的軟體已經滲透到各行各業，滲透到日常生活，使用者也是老幼婦孺都有，由于基礎架構的改變以及産品成本結構的變化，軟體中的很多缺陷不再會造成無法挽回的損失。這時候測試還死守藍軍的定位已經不合時宜。

不僅僅是對于bug價值的了解和紅藍軍的隐喻不合時宜，一些測試領域認為理所當然的“準則”也一樣不合時宜：

能證明有問題，不能證明沒問題。測試可以顯示缺陷的存在，可以減少産品中存在未被發現缺陷的可能性，但由于窮盡測試是不可能的，是以即使在測試中沒有發現缺陷，也不能證明産品已經沒有缺陷。這是一句完全正确的“廢話”，即使客戶同意這個觀點，他也會質疑：為什麼這個缺陷沒有被發現，明明是在正常使用情況下就暴露出的缺陷，并不需要“窮盡”測試。

品質是設計出來的，不是測試出來的：産品能夠達到什麼樣的品質，在架構、設計方案确定後，就已經決定了，不可能通過測試活動，讓産品品質有本質的提升。這句話雖然道出了一個事實，但是聽起來更像一個逃避責任的借口。測試之是以存在，就是因為人是會犯錯的，研發團隊更希望測試能夠在錯誤發生的時候就被發現并證明這個錯誤，而不是到了最後一切都已經定型了才說這個産品不行。

是以，測試之是以遭遇到當下的困境和質疑，很大一部分原因，就是測試的價值定位，以及在這個價值之下的思維邏輯需要跟上軟體發展的步伐。

為解決這個困局人們采取的做法大概有2類：

1）老闆說什麼我做什麼。研發經理說客戶缺陷太多了，你們要加強測試設計能力啊，于是測試工程師把測試方案越寫越細，用例越積越多，盡管知道這些手段根本就沒法保證缺陷必然被發現，但是多走點路大概踩到牛屎的幾率高一些吧。研發經理說測試周期太長了，要搞自動化啊，于是測試工程師引進工具，把自動化率越做越高，盡管早已發現，自動化對測試效率其實沒啥貢獻。研發經理說為啥缺陷那麼晚發現，你們要參與到前端去啊 ，于是測試工程師參與需求和設計評審，盡管大部分人是打着評審的旗号提前學習了一下特性。測試隻知道按研發經理支的招去做了，卻根本沒有關心研發經理想解決什麼問題。這種思路會是什麼結果呢？問題依舊，因為這些意見根本就是外行指揮内行，最後在困局中越陷越深。

2）主動尋求新的測試價值。通過在産品測試過程中獲得的資料，利用對産品的深入掌握，對測試的深入了解，來拓展新的職能，例如：主導産品的名額改進，在代碼管理和釋出平台（ci、沙箱、灰階）中内建品質标準，主導産品內建，主導使用者體驗分析，用驗收用例執行個體化客戶需求，主管驗收測試活動等。

我認為後者是更有前途的思路，但是現在走在這條路上的還是一些先鋒，屬于個别人的英雄主義冒險。我希望用我的綿薄之力，使這方面的創見越來越多，最後實作對測試這個職業的新的價值定位。