傲野：如果測試沒有夢想，那跟鹹魚有什麼區別？

前言

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

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

• 10年前，最初級的測試產出工件是比較一次性的，比如專案中寫的文字型測試用例，基本在專案釋出後就廢棄了。

• 那個時期測試工作的進階是方法論，比如能夠把測試用例的設計方法，專案流程管理講得頭頭是道已經是高階了。

• 有一些技術能力的測試同學，投身於自動化指令碼的編寫。自動化在“軟體”測試時代和網際網路初期，是真正的硬核能力。

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

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

• 一種是不斷堅持平臺化的發展路徑：專案質量是基礎，不斷孵化出各類的效能平臺，解決的問題也從傳統的質量領域本身，往研發各環節擴充。有些大型的企業也開始沉澱了通用的研發協同平臺（研發流水線）。

• 一種是從內往外突破：比如 Google 的 SRE 團隊，以純技術的手段，打造一個內建且自洽的質量體系（傳統以證偽為理論依據的是一個外建的質量體系）。[1]

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

實時質量

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

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

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

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

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

實時質量的架構

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

圖示：實時質量架構

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

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

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

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

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

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

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

總共分兩步：

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

2. 把以上測試元件，通過訊息的方式跟運營頁面釋出系統對接。

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

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

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

還有基於演算法能力的識別能力：

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

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

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

資料和演算法是實時質量的核心

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

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

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

★ 案例：Captain 全域實時資料校驗

圖示：資料對比框架【示意】

它具備的一些能力：

1. 嚴格的安全策略。

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

3. 多樣的資料獲取方式：目前平臺支援多種資料獲取方式：單庫單表查詢、單庫多表聯表查詢、分庫分表查詢、跨庫的多表的聯表查詢。

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

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

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

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

★ 測試的邊界在哪裡？

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

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

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

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

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

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

實時質量未來規劃

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

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

圖示：測試未來的發展

後記

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

“在阿里這幾年的感受是，開發做的事越來越多，設計、測試、運維、交付等工作都由開發來做。導致崗位間的互相監督制約不夠；一個蘿蔔一個坑，一個坑一般只有一個蘿蔔，導致同應用同崗位之間的交流、協作不多。崗位中傳幫帶，互相 review 機制不夠；開發壓力重，為了拿業務目標，在沒有監督制約的環境下，很多基礎事情的優先順序被放低。因此，建議不要迷信系統的監督，系統有覆蓋不到的地方，有過時的地方，有能繞過去的地方。不要放棄崗位間的監督，幾十年的軟體工程發展出各個崗位，有其自身的價值和門檻，一味的賦能開放，最後會變成什麼都不精。至少測試、開發兩個崗位要分離。”
阿里內部論壇

做測試總還是要有點夢想的，如果對我們做的事情有興趣。

歡迎加入我們： batu.hjj@alibaba-inc.com
微信：http_home