軟件質量不是測出來的，但為什么又有這么多測試工程師為了質量而工作？測試是一個成本部門，測試創造的價值是什么？研發的模式在不斷地變化，測試的定位如何不斷去定義，未來的測試又會是什么形態？今天，阿里巴巴高級測試開發專家傲野總結了對未來測試形態的一些思考，希望對正在做測試的同學有所啟發。

前言

從社會發展上來說，各領域的分工越來越細。但從技術部門的發展上來看，測試和開發的角色卻是在不斷融合，背后的原因是什么？是互聯網迭代的速度越來越快促成的多角色融合，還是因為技術（特別是質量技術）先進生產力在逐漸取代落后的生產力？

在回答這些問題之前，我們先來回顧“測試工程師”作為一個職能或者個體在過去的發展歷程：

• 10年前，最初級的測試產出工件是比較一次性的，比如項目中寫的文本型測試用例，基本在項目發布后就廢棄了。
• 那個時期測試工作的進階是方法論，比如能夠把測試用例的設計方法，項目流程管理講得頭頭是道已經是高階了。
• 有一些技術能力的測試同學，投身于自動化腳本的編寫。自動化在“軟件”測試時代和互聯網初期，是真正的硬核能力。

但這樣的測試模式和效率都是非常低的，顯然無法支撐互聯網無快不破的浪潮。2010年以后，在頭部企業的測試團隊發生了一系列的變革，快速地從上述的這些初級能力，擴大到以 CI/CD 為驅動的技術體系，并最終推動了測試技術產品化進程，形成一個較為清晰的測試平臺發展脈絡。

在這個將近十年的周期中，由于測試工具、平臺的不斷創新，測試團隊得到了一個突破性的發展。但工具作為傳統測試模式的輔助手段，仍然會遇到突破的瓶頸。比如，從全球來看質量也發生了一定的分支：

• 一種是不斷堅持平臺化的發展路徑：項目質量是基礎，不斷孵化出各類的效能平臺，解決的問題也從傳統的質量領域本身，往研發各環節拓展。有些大型的企業也開始沉淀了通用的研發協同平臺（研發流水線）。
• 一種是從內往外突破：比如 Google 的 SRE 團隊，以純技術的手段，打造一個內建且自洽的質量體系（傳統以證偽為理論依據的是一個外建的質量體系）。[1]

這兩者的方向和目標，是有一定的重合的，比如有些公司以測試負責線下，SRE 負責線上進行區分。但如果從質量這個大的目標來看，未來的成功畫面應該是：“質量和效率的結合”和“外建與自洽的結合”。因為只有這樣，才能打造一個真正完整的技術質量生態。

實時質量

也是基于上述的一些思考和實踐，我們在2017年底提出了“實時質量”的概念。“它不是一個具體的測試技術產品，而是一種面向未來解決質量問題的方法和手段。”

它的主要特性是：運行含測試，實時可反饋。

為什么要往這個方向發展？

隨著技術的不斷創新和交付模式的不斷改變，對于測試團隊來說，需要盡快地從交付型質量往實時質量方向進行轉移。傳統的交付型質量，把測試作為一道道關卡，以任務的方式布防在開發提測、項目發布時。這種方式存在不同角色之間的過多交互，只能起到單點的質量保障。而實時質量的目標是：將質量手段以模塊、組件乃至系統化的方式嵌入到業務型應用中，形成實時保障質量的能力。未來開發和測試人員之間的合作（或者就不區分開發測試了），不僅僅是人與人之間的協同，更多是雙方分別為完成“業務特性服務的代碼”和為完成”業務質量服務的代碼“而相互配合，并形成系統級的依賴關系。在提供的這些質量系統上，我們希望公司內部的各種角色都能成為質量的操作者。只在做到這些，我們才可能將測試工作真正從面向過程到面向對象。

圖示：理想的測試工作方式

實時質量的架構

要做到質量的實時反饋和面向對象測試，這意味著我們的測試方法和協同方式發生了較為根本性的變化。我們需要以一個合適的方式參與到業務應用中，與此同時我們還需要把測試的各種能力封裝成一個個服務，而不是現在的工具。工具終究是需要人來操作的，而我們希望未來測試任務的主體是機器、算法。測試人員只構建測試服務，而不參與測試過程，這也是最符合測試開發 Test Development Engineer 的 job design 。

圖示：實時質量架構

那測試到底還需不需要做功能測試？可能在很長一段時間內仍然是需要的，但那一定只是日常工作中很小一部分。

實時質量是基于現有測試能力改造

我們在推進一個新的方向時，盡量不要去推翻重來。如果要面向未來，實時質量必須是可以向下兼容的，因為只是這樣才能繼承現有的測試沉淀，也才能被團隊中的測試人員所接受和支持。只有自己不斷進化才符合自然規律。所以我們需要更多強調對現有測試能力的改造，而避免另起爐灶。以下用運營頁面測試的實時質量改造作為一個案例。

案例：運營頁面的實時質量改造

作為電商域的同學對于運營頁面應該非常熟悉，在之前也非常痛恨。比如：

“CBU的一次大促，運營人員至少需要配置千級以上的活動頁面，而每一個頁面上又包含幾百上千個商品等活動元素，平均一個頁面需要5到10分鐘的人肉檢測，同時運營和測試人員需要不斷就測試標準和 Bug 來回討論、提交。一次大促下來，我們至少需要十幾人/日的測試資源才能保證會場的正確性。”

這個過程很痛苦，運營人員需要不斷去找對應的測試同學協同，幸福感很差。而測試人員來說，這些頁面的測試更多是一個重復勞動，一個黑盒。能力也得不到什么成長。我們如何對它來進行實時質量的改造呢？

總共分兩步：

我們對傳統的測試體系進行了改造。把以往通過人工測試的各個測試點，通過自動化的方式來實現。比如基于 DOM 樹制定一系列規則，例如403這些的錯誤都可以被很好地掃描出來。同時，針對于一些無法通過規則排查的問題，我們運用了算法能力。例如空坑檢測，一致性檢測等。

把以上測試組件，通過消息的方式跟運營頁面發布系統對接。

它的系統依賴關系是如下的：

圖示：運營頁面檢測系統依賴圖【示意】

同時針對于不同的業務場景，我們開發了不同的頁面檢測能力，比如針對于 DOM 樹的頁面檢查：

還有基于算法能力的識別能力：

通過上述的改造后，對于運營人員發布頁面以及頁面的測試就極簡化為三步一站式的能力。從以往運營、測試、開發之間的來回交接，變成了運營跟系統之間的交互。不僅提升了運營人員的頁面搭建體驗，也極大地提升了測試的效率。

在某次運行中活動中實際的執行結果【示意圖】：

以上的過程和結果數據，也充分體現了“運行含測試，實時可反饋”的價值。

數據和算法是實時質量的核心

測試出現以來，我們一直習慣于代碼邏輯類的測試，但數據一直都是測試很重要的生產材料。因為人肉執行任務的局限性，我們發明了等價類和邊界值等測試理論和方法來用盡可能少的成本來盡可能多的驗證問題。但一方面算法的不斷應用，每一個數據都可能存在個性化的業務表達，我們可能無法找到一個通用的預期結果較驗（還是會有一些通用的預期結果的，比如非空判斷和區間等，但這類的預期不能很好地做業務判斷）。因此，我們也需要用數據和算法能力來武裝自己。

在以數據驅動的業務發展進程中，我們的測試主體已經從簡單的代碼轉變為數據+算法。或者說，業務對質量的核心述求，已經從簡單的頁面錯誤、代碼 BUG 到數據的準確性、算法的有效性（我老板在每次大促前，都要再三叮囑我數據不能錯）。如何來感知質量風險，以及捕獲各類的異常？那必須先把數據、流量、監控來做收口，同時提升測試工具在大數據分析上的能力。

基于這些思考，我們構建了全域實時數據校驗能力，是一款通過實時獲取線上 DB 中的海量業務數據，完成業務數據校驗、質量風險感知的產品。

案例：Captain 全域實時數據校驗

圖示：數據對比框架【示意】

它具備的一些能力：

嚴格的安全策略。

實時獲取線上數據：通過強大的數據支持能力，平臺可以在無損線上數據庫表的前提下，通過 SQL 查詢獲取線上 DB 中的真實業務數據，且做到了實時獲取，通過數據可以進行完善健壯的數據校驗，從根本上提高對于業務的把控。

多樣的數據獲取方式：目前平臺支持多種數據獲取方式：單庫單表查詢、單庫多表聯表查詢、分庫分表查詢、跨庫的多表的聯表查詢。

多種比對方式支持，比如跨庫查詢和聯表查詢等等。

最主要，它可以用一套腳本無損地支持測試環境、灰度、生產環境等。讓線下測試的所有經驗可以得到復用和沉淀。（我們內部調侃說，這才是帶著測試的靈魂的，而其他的很多產品都只是一個面向開發的工具）

在前期解決數據一致性，對賬等常用的基本需求上，我們可以依賴于這些數據和測試的服務，展開更多的業務形態。

實時質量需要不斷突破測試的邊界

測試的邊界在哪里？

過去有人告訴我，不能去修改業務應用的代碼，只能讓在盒子外面或者調用的方式來測試。還有人說，我們只開發工具，不能接觸任何的業務。現在這些都在逐漸模糊，大家努力一起，讓測試的很多活動，從簡單的功能測試，往研發工具和業務質量等或前或后地遷移。

在過去的一兩年，我們團隊也已經慢慢承接了更多的職責，有些甚至于是直接服務于客服、運營和產品人員的。我認為，一支強的團隊一定是不斷走在突破原來工作邊界的道路上。沒有什么是一成不變的。

但每個職能團隊都是有自己的核心價值的，而至于哪些應該由測試來做，哪些由開發做。我們的標準是：判斷這件事情是更為了“讓技術更有品質”還是“讓技術創造新商業”？（“讓技術更有品質”是我們團隊的使命，“讓技術拓展業務邊界”是開發團隊的目標）

以下雖然是幾年前的例子，但也很好的體現了我們在邊界的突破，以及如何用實時質量的思想來開裝自己，創造提交 BUG 以外更多的價值。

案例：Offer 360提升客服端實時質量能力

商品鏈路復雜，線上問題排查難度大，之前開發每天平均投入2-3個小時處理線上問題，但實際上大部分的問題都是正常業務邏輯，并且可以讓客滿或者技術支持自助查詢的。因此，我們通過提供實時查詢錯誤日志以及 debug 信息的服務，把用戶反饋問題的排查，開放給客服。幫助他們第一時間解決用戶的問題。

實時質量未來規劃

實時質量是一種思想，我覺得它未來是可以跨越在當前兩種不同的發展分支上的。

測試這么多年來一直被弱化，我也看到集團很多優秀的測試 leader 轉型開發、產品。如果我們還不多些思考，多些探索。如果做測試都還沒有夢想，那跟咸魚有什么區別？

圖示：測試未來的發展

后記

上周在內部的論壇上看到一個開發專家的留言，還是挺有感觸的。我們一直以來都在強調測試能力不斷演進，強調開發能力，但測試的初心不能丟。我們在工具、測試能力上不斷改進，但是從人和組織的角度上來看，在追求最高效的同時，我們是需要一定的組織設計來形成崗位間的相互監督。這也是在測試1.0階段開始，測試被賦予的一種職責。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的如果测试没有梦想，那跟咸鱼有什么区别？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。