阿裡妹導讀：軟體品質不是測出來的，但為什麼又有這麼多測試工程師為了品質而工作？測試是一個成本部門，測試創造的價值是什麼？研發的模式在不斷地變化，測試的定位如何不斷去定義，未來的測試又會是什麼形态？今天，阿裡巴巴進階測試開發專家傲野總結了對未來測試形态的一些思考，希望對正在做測試的同學有所啟發。
前言
從社會發展上來說，各領域的分工越來越細。但從技術部門的發展上來看，測試和開發的角色卻是在不斷融合，背後的原因是什麼？是網際網路疊代的速度越來越快促成的多角色融合，還是因為技術（特别是品質技術）先進生産力在逐漸取代落後的生産力？
在回答這些問題之前，我們先來回顧“測試工程師”作為一個職能或者個體在過去的發展曆程：
- 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階段開始，測試被賦予的一種職責。
原文釋出時間為： 2019-06-11
本文作者： 傲野
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。