若是測試沒有夢想，那跟鹹魚有什麼區別？

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

前言

從社會發展上來講，各領域的分工愈來愈細。但從技術部門的發展上來看，測試和開發的角色倒是在不斷融合，背後的緣由是什麼？是互聯網迭代的速度愈來愈快促成的多角色融合，仍是由於技術（特別是質量技術）先進生產力在逐漸取代落後的生產力？

在回答這些問題以前，咱們先來回顧「測試工程師」做爲一個職能或者個體在過去的發展歷程：

• 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階段開始，測試被賦予的一種職責。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。