記得在半年前，我在Infoq寫了一篇“開發要不要自己做測試？怎麼做？”的文章，當時引發了很多開發人員以及測試人員的激烈討論，那篇文章的主旨是介紹如何通過工程效能團隊來賦能開發人員自己進行高效率高質量的軟件測試，文中介紹了Google、Facebook 和 eBay 等一線互聯網公司正在推行的“沒有專職測試，測試工作由開發人員完成（簡稱去QE化）”的全新模式，並從工具鏈的視角介紹了測試即服務（Test as a Service）的全局架構。
那麼今天的這篇文章，我會從另外一個視角再來聊聊互聯網領域“幹掉”測試這個話題，只不過這次要討論的話題會更尖銳、更敏感，不再是“幹掉專職測試人員，讓開發人員自己做測試”，而是儘量“偷工減料”少做測試，甚至壓根不做測試的話題。哇塞，這聽起來是不是有點離經叛道，有違大衆長久以來的價值觀。別急，且聽我慢慢道來。
軟件測試的本質目的
首先，我們來看一下軟件測試的本質目的是什麼，你可能會不假思索地告訴我說是爲了保證軟件產品的質量。那我會繼續問你，保證軟件產品質量的目的又是什麼，你可能稍加思索後會說是爲了讓大部分軟件用戶滿意，給用戶遞交價值。完全正確，其實這纔是軟件測試的本質目的所在。這就有點像你去問一個女生你爲什麼不吃飯，她會告訴你她的目的是減肥，但仔細一想，減肥真的是不吃飯的目的嗎，其實真正的目的應該是“變得更漂亮”，明白了這層利害關係後，你會發現爲了“變得更漂亮”的方法就有很多選擇了，不吃飯減肥只是其中之一。
恰好“夠用”的質量
那麼怎麼才能使用戶對軟件滿意呢？這裏有兩種截然不同的思路，一個是通過海量的測試盡最大努力保證軟件中沒有任何缺陷，由於測試本身的不可窮盡性，顯然這種做法的代價是及其巨大的；另一種思路是隻測試用戶所有可能會使用的軟件功能，其他的都不測試，也就是說只提供一個恰好能夠滿足用戶需求的軟件產品，這種情況下，軟件的研發代價是比較低的。
對於企業，如果產品本身不是與人生命息息相關或者金融相關的，你覺得企業會選擇哪個思路？
從經濟學的角度出發，一定是後者。也就是說一個“好的”軟件產品並不是一個完完全全無任何缺陷的產品，而是一個其質量屬性剛好滿足用戶需求的產品，也就是說不追求完美的質量，而是追求恰好“夠用”的質量，恰好夠用的質量的另一種表述是軟件產品在用戶使用的整個生命週期中不會發生問題，或者即使發生問題，但帶來風險和損失也足夠小，但並不是說軟件本身沒有任何問題。企業從經濟學的角度來講需要以科學的手段來尋求缺陷風險和研發成本之間的動態平衡。
基於風險驅動的“偷工減料”測試策略
鑑於上述的思想的驅動，現在很多互聯網產品在確定測試範圍的時候，通常會通過日誌數據來分析軟件系統的歷史使用行爲，並根據功能的使用頻度來決定測試的優先級，那些被大量使用的功能一定會全面測試，而那些不經常使用的功能只會做基本的測試，而那些很少使用的功能在進度壓力較大的情況下就會放棄測試。這就是所謂的基於風險驅動的測試策略。
用戶使用頻度越高，說明這部分功能更能夠爲用戶帶來價值，當這部分功能出問題的時候，產生的風險也就越大，那麼這部分功能無疑就是需要重點測試的對象。而那些很少使用的軟件功能或者場景，就成爲了測試中“偷工減料”的對象。需要強調的是，這裏的偷工減料是打了引號的，不是說真的偷工減料，而是指在有足夠數據支持的前提下以風險驅動的方式合理縮小測試範圍。
基於風險驅動的測試策略在微服務測試中的應用
如果我們將基於風險驅動的測試策略應用與微服務架構的測試，就形成了基於消費者契約的API測試策略，而這一測試策略的核心思想就是強調只測試那些有實際使用場景的API調用，如果沒有使用場景的API調用就可以壓根不做測試。
爲了讓你更好地理解這種目前微服務架構下非常行之有效的測試策略，我畫了下面的圖
圖1：Service A、Service B和Service T的關係圖
圖中的Service A、Service B和Service T是一個系統中的三個微服務，其中Service T是被測試對象，可見Service T的消費者（也就是使用者）一共有兩個，分別是Service A和Service B。如果按照傳統的API測試策略，當我們需要測試Service T的時候，我們就需要找到所有可能的參數組合依次來對Service T進行調用，同時結合Service T的代碼覆蓋率來進一步補充遺漏的測試用例，這樣做就會導致測試用例數量很多，工作量過大。那麼基於風險驅動的消費者契約API測試是怎麼做的呢？
首先Service T作爲服務的提供者，它的使用者在這裏是確定的，就只有Service A和Service B，如果能夠把Service A和Service B對Service T的所有可能的調用方式都測試到，那麼就一定可以保證Service T的質量，即使如果存在某些Service T的其他調用會有問題，那也不會影響整個系統的功能，原因是系統中沒有其他Service會以可能出錯的調用方式來調用Service T。這樣就以“偷工減料”的方式減少了測試範圍，但同時又能夠保證軟件的質量，可見，這種方式在工程實踐中是具有很大實用價值的。至於如何纔能有效抓取Service T的完整契約，可以參考我的新書《測試工程師全棧技術進階與實踐》第五章中“微服務模式下API測試”的內容，技術細節就不在這裏展開了。
不做測試直接上線的實際案例
上面我們講了互聯網產品測試過程中如何“少做”測試的實際例子，那麼接下來我們再來看看互聯網產品測試中更極端的場景：如何不做測試或者只做很少測試的實際案例。什麼，不做測試就敢上線發佈，如果你是工作在傳統軟件企業的工程師，這聽起來簡直就是天方夜譚，完全是想“刪庫跑路”的節湊啊！但是在互聯網企業，這種極端的做法還是有其存在價值的，最開始的時候，這種不測試或者只做很少量測試就立馬上線發佈的做法是被競爭對手逼出來的，後來卻漸漸發現這種方式也有其可取之處，尤其是想以最快的方式發佈新功能的時候。
我們來試想一個商業競爭的場景，假定某電商網站A發佈了爲期三天的家電促銷活動，併爲此上線了新的活動頁面以及相關優惠券的功能，那麼另外一個電商網站B爲了與其競爭（網站B如果不參與這個競爭，那麼這段時間以及後續一段時間內的流量很可能就被網站A搶走了），就必須在很短的時間內設計開發並上線能夠與網站A相競爭的類似優惠功能。由於網站A是有備而來，所以網站A的功能在上線發佈之前已經做了充分的測試，但是網站B就很被動了，網站B必須在很短的時間內開發出類似的優惠活動功能，如果開發完成後的測試還需要佔用較多的時間，那麼在商業上就會更被動。
爲此，網站B會在這種逼不得已的情況下，採用不測試或者只做很少的測試就上線發佈的策略，但這個發佈的過程會採用灰度發佈策略來降低未經充分測試的軟件直接上線的風險。具體的做法是這樣的：
-
從應用服務器集羣中選擇任意一臺服務器(比如圖2中的Node N)，然後從負載均衡器中將其註銷。
-
然後將這臺服務器的軟件升級到最新的未經過測試的軟件版本。
-
接着，將這臺服務器註冊到負載均衡器中，並且通過配置負載均衡器，只讓這臺具有新軟件版本的服務器接收萬分之一的流量。也就是說，只有很少一部分的用戶會訪問到新的軟件版本。
-
在接下來大概10-30分鐘的時間裏，密切監控這臺具有新軟件的服務器各項指標以及後臺的業務日誌。這段時間，相當於在使用真實的用戶行爲在對新的軟件版本進行測試。
-
如果服務器各項指標正常，後臺日誌也沒有監測到任何異常，那麼說明新的軟件版本沒有問題，接下來就可以部署更多的服務器。如果發現有問題，那麼此時就需要立即回滾有問題的新軟件版本，但是幸運的是，即使發現有問題，實際受影響的用戶也是極少數，同時還準確找到了軟件的缺陷。
-
如果沒問題，就會將新的軟件版本部署到更多的服務器上，直到應用服務器集羣中所有服務器都部署了新版本。
![]()
圖2：應用服務器集羣灰度發佈示意圖
總結一下，上述過程實際上利用了灰度發佈，在風險可控的情況下，直接利用了真實的用戶流量來對新的軟件版本進行了測試，因此省去了研發階段的測試工作量，並且加速了發佈的速度。這個就是不做測試的一個極端案例。
由上面的兩個例子我們可以發現，在那種場景下采用那種測試策略，完全取決於“發生問題時帶來的風險（經濟損失）”，“後期問題暴露後修復問題的代價”以及“前期研發過程中投入的測試成本”三者之間的博弈。同時，產品架構設計（微服務或者服務網格等）和DevOps實踐（灰度發佈等）也爲測試策略的最優選取提供了更多的可能性。
另外，除了測試策略這種從源頭上的優化，在測試設計和執行層面還有很多我們需要面對問題，並在此基礎上又很多值得優化的內容以及執行方法上的微創新，其中涉及測試執行環境準備的最佳實踐，測試數據準備的最佳實踐，從源頭保證軟件質量的代碼級測試，以及性能測試與調優的最佳實踐，如果你對這一系列的主題感興趣，可以關注我的新書《測試工程師全棧技術進階與實踐》，必定讓你有所收穫。
如何購買？
《測試工程師全棧技術進階與實戰》這本書，目前已經在極客時間商城獨家首發
點擊購買：《測試工程師全棧技術進階與實踐》
你能獲得什麼？
- 深入理解GUI自動化測試的核心原理，能夠獨立完成GUI自動化測試策略設計，將高效率、低維護成本的測試用例設計思路帶入到你的實際工作中。
- 掌握API測試工具的基本原理和測試方法，能夠在實際微服務項目中應用契約測試方法。
- 掌握移動應用的測試技術與方法，能夠將傳統的軟件測試方法熟練應用到移動應用的測試，同時掌握移動應用的專項測試方法。
- 掌握代碼級軟件測試的基本方法和技術，深入理解代碼級測試的方法論和工具體系，能夠獨立進行單元測試的設計，並能應對代碼級測試過程中的典型技術難點。
- 深入理解性能測試的全局知識體系，能夠獨立開展前端以及後端的性能測試，並且能夠基於不同目的設計有針對性的性能測試場景，同時掌握主流性能測試工具的使用方法，並且對目前互聯網體系下的大規模性能壓測有基本的認識。
- 掌握測試數據準備的最佳實踐，能夠應對企業級軟件測試過程中對於測試數據的各種要求和挑戰，並且理解業界領先的測試數據平臺架構與設計思路。
- 深入理解測試基礎架構建設的必要性和實施方法，從技術層面深入理解測試基礎架構的設計方案以及和DevOps以及CI/CD的無縫集成。
- 理解當下軟件測試領域的熱門技術和新方法，主要涉及的探索式測試、測試驅動開發、精準測試、滲透測試、基於模型的測試（MBT）以及人工智能（AI）在測試領域的應用等話題。
- 梳理了測試技術人員必須掌握的大型互聯網架構的核心知識體系，剖析了大型網站技術架構模式，深入講述大型互聯網架構設計的核心原理與發展歷程，從高性能、高可用、伸縮性
- 可擴展性等四個維度對大型網站架構進行了有針對性地深度剖析，彌補了測試工程師相比開發工程師以及架構師之間知識結構上的短板。
限時購買福利
1.首發優惠價¥ 69， 原價¥ 79；
2.支付時輸入優惠口令：ceshis ， 在已有的優惠基礎上再減¥5，到手價¥64，截止7月10日24 點。 戳此購>>>
圖書目錄
