軟件質(zhì)量不是測(cè)出來的，但為什么又有這么多測(cè)試工程師為了質(zhì)量而工作？測(cè)試是一個(gè)成本部門，測(cè)試創(chuàng)造的價(jià)值是什么？研發(fā)的模式在不斷地變化，測(cè)試的定位如何不斷去定義，未來的測(cè)試又會(huì)是什么形態(tài)？今天，阿里巴巴高級(jí)測(cè)試開發(fā)專家傲野總結(jié)了對(duì)未來測(cè)試形態(tài)的一些思考，希望對(duì)正在做測(cè)試的同學(xué)有所啟發(fā)。

前言

從社會(huì)發(fā)展上來說，各領(lǐng)域的分工越來越細(xì)。但從技術(shù)部門的發(fā)展上來看，測(cè)試和開發(fā)的角色卻是在不斷融合，背后的原因是什么？是互聯(lián)網(wǎng)迭代的速度越來越快促成的多角色融合，還是因?yàn)榧夹g(shù)（特別是質(zhì)量技術(shù)）先進(jìn)生產(chǎn)力在逐漸取代落后的生產(chǎn)力？

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

• 10年前，最初級(jí)的測(cè)試產(chǎn)出工件是比較一次性的，比如項(xiàng)目中寫的文本型測(cè)試用例，基本在項(xiàng)目發(fā)布后就廢棄了。
• 那個(gè)時(shí)期測(cè)試工作的進(jìn)階是方法論，比如能夠把測(cè)試用例的設(shè)計(jì)方法，項(xiàng)目流程管理講得頭頭是道已經(jīng)是高階了。
• 有一些技術(shù)能力的測(cè)試同學(xué)，投身于自動(dòng)化腳本的編寫。自動(dòng)化在“軟件”測(cè)試時(shí)代和互聯(lián)網(wǎng)初期，是真正的硬核能力。

但這樣的測(cè)試模式和效率都是非常低的，顯然無法支撐互聯(lián)網(wǎng)無快不破的浪潮。2010年以后，在頭部企業(yè)的測(cè)試團(tuán)隊(duì)發(fā)生了一系列的變革，快速地從上述的這些初級(jí)能力，擴(kuò)大到以 CI/CD 為驅(qū)動(dòng)的技術(shù)體系，并最終推動(dòng)了測(cè)試技術(shù)產(chǎn)品化進(jìn)程，形成一個(gè)較為清晰的測(cè)試平臺(tái)發(fā)展脈絡(luò)。

在這個(gè)將近十年的周期中，由于測(cè)試工具、平臺(tái)的不斷創(chuàng)新，測(cè)試團(tuán)隊(duì)得到了一個(gè)突破性的發(fā)展。但工具作為傳統(tǒng)測(cè)試模式的輔助手段，仍然會(huì)遇到突破的瓶頸。比如，從全球來看質(zhì)量也發(fā)生了一定的分支：

• 一種是不斷堅(jiān)持平臺(tái)化的發(fā)展路徑：項(xiàng)目質(zhì)量是基礎(chǔ)，不斷孵化出各類的效能平臺(tái)，解決的問題也從傳統(tǒng)的質(zhì)量領(lǐng)域本身，往研發(fā)各環(huán)節(jié)拓展。有些大型的企業(yè)也開始沉淀了通用的研發(fā)協(xié)同平臺(tái)（研發(fā)流水線）。
• 一種是從內(nèi)往外突破：比如 Google 的 SRE 團(tuán)隊(duì)，以純技術(shù)的手段，打造一個(gè)內(nèi)建且自洽的質(zhì)量體系（傳統(tǒng)以證偽為理論依據(jù)的是一個(gè)外建的質(zhì)量體系）。[1]

這兩者的方向和目標(biāo)，是有一定的重合的，比如有些公司以測(cè)試負(fù)責(zé)線下，SRE 負(fù)責(zé)線上進(jìn)行區(qū)分。但如果從質(zhì)量這個(gè)大的目標(biāo)來看，未來的成功畫面應(yīng)該是：“質(zhì)量和效率的結(jié)合”和“外建與自洽的結(jié)合”。因?yàn)橹挥羞@樣，才能打造一個(gè)真正完整的技術(shù)質(zhì)量生態(tài)。

實(shí)時(shí)質(zhì)量

也是基于上述的一些思考和實(shí)踐，我們?cè)?017年底提出了“實(shí)時(shí)質(zhì)量”的概念。“它不是一個(gè)具體的測(cè)試技術(shù)產(chǎn)品，而是一種面向未來解決質(zhì)量問題的方法和手段。”

它的主要特性是：運(yùn)行含測(cè)試，實(shí)時(shí)可反饋。

為什么要往這個(gè)方向發(fā)展？

隨著技術(shù)的不斷創(chuàng)新和交付模式的不斷改變，對(duì)于測(cè)試團(tuán)隊(duì)來說，需要盡快地從交付型質(zhì)量往實(shí)時(shí)質(zhì)量方向進(jìn)行轉(zhuǎn)移。傳統(tǒng)的交付型質(zhì)量，把測(cè)試作為一道道關(guān)卡，以任務(wù)的方式布防在開發(fā)提測(cè)、項(xiàng)目發(fā)布時(shí)。這種方式存在不同角色之間的過多交互，只能起到單點(diǎn)的質(zhì)量保障。而實(shí)時(shí)質(zhì)量的目標(biāo)是：將質(zhì)量手段以模塊、組件乃至系統(tǒng)化的方式嵌入到業(yè)務(wù)型應(yīng)用中，形成實(shí)時(shí)保障質(zhì)量的能力。未來開發(fā)和測(cè)試人員之間的合作（或者就不區(qū)分開發(fā)測(cè)試了），不僅僅是人與人之間的協(xié)同，更多是雙方分別為完成“業(yè)務(wù)特性服務(wù)的代碼”和為完成”業(yè)務(wù)質(zhì)量服務(wù)的代碼“而相互配合，并形成系統(tǒng)級(jí)的依賴關(guān)系。在提供的這些質(zhì)量系統(tǒng)上，我們希望公司內(nèi)部的各種角色都能成為質(zhì)量的操作者。只在做到這些，我們才可能將測(cè)試工作真正從面向過程到面向?qū)ο蟆?/p>

圖示：理想的測(cè)試工作方式

實(shí)時(shí)質(zhì)量的架構(gòu)

要做到質(zhì)量的實(shí)時(shí)反饋和面向?qū)ο鬁y(cè)試，這意味著我們的測(cè)試方法和協(xié)同方式發(fā)生了較為根本性的變化。我們需要以一個(gè)合適的方式參與到業(yè)務(wù)應(yīng)用中，與此同時(shí)我們還需要把測(cè)試的各種能力封裝成一個(gè)個(gè)服務(wù)，而不是現(xiàn)在的工具。工具終究是需要人來操作的，而我們希望未來測(cè)試任務(wù)的主體是機(jī)器、算法。測(cè)試人員只構(gòu)建測(cè)試服務(wù)，而不參與測(cè)試過程，這也是最符合測(cè)試開發(fā) Test Development Engineer 的 job design 。

圖示：實(shí)時(shí)質(zhì)量架構(gòu)

那測(cè)試到底還需不需要做功能測(cè)試？可能在很長(zhǎng)一段時(shí)間內(nèi)仍然是需要的，但那一定只是日常工作中很小一部分。

實(shí)時(shí)質(zhì)量是基于現(xiàn)有測(cè)試能力改造

我們?cè)谕七M(jìn)一個(gè)新的方向時(shí)，盡量不要去推翻重來。如果要面向未來，實(shí)時(shí)質(zhì)量必須是可以向下兼容的，因?yàn)橹皇沁@樣才能繼承現(xiàn)有的測(cè)試沉淀，也才能被團(tuán)隊(duì)中的測(cè)試人員所接受和支持。只有自己不斷進(jìn)化才符合自然規(guī)律。所以我們需要更多強(qiáng)調(diào)對(duì)現(xiàn)有測(cè)試能力的改造，而避免另起爐灶。以下用運(yùn)營(yíng)頁面測(cè)試的實(shí)時(shí)質(zhì)量改造作為一個(gè)案例。

案例：運(yùn)營(yíng)頁面的實(shí)時(shí)質(zhì)量改造

作為電商域的同學(xué)對(duì)于運(yùn)營(yíng)頁面應(yīng)該非常熟悉，在之前也非常痛恨。比如：

“CBU的一次大促，運(yùn)營(yíng)人員至少需要配置千級(jí)以上的活動(dòng)頁面，而每一個(gè)頁面上又包含幾百上千個(gè)商品等活動(dòng)元素，平均一個(gè)頁面需要5到10分鐘的人肉檢測(cè)，同時(shí)運(yùn)營(yíng)和測(cè)試人員需要不斷就測(cè)試標(biāo)準(zhǔn)和 Bug 來回討論、提交。一次大促下來，我們至少需要十幾人/日的測(cè)試資源才能保證會(huì)場(chǎng)的正確性。”

這個(gè)過程很痛苦，運(yùn)營(yíng)人員需要不斷去找對(duì)應(yīng)的測(cè)試同學(xué)協(xié)同，幸福感很差。而測(cè)試人員來說，這些頁面的測(cè)試更多是一個(gè)重復(fù)勞動(dòng)，一個(gè)黑盒。能力也得不到什么成長(zhǎng)。我們?nèi)绾螌?duì)它來進(jìn)行實(shí)時(shí)質(zhì)量的改造呢？

總共分兩步：

我們對(duì)傳統(tǒng)的測(cè)試體系進(jìn)行了改造。把以往通過人工測(cè)試的各個(gè)測(cè)試點(diǎn)，通過自動(dòng)化的方式來實(shí)現(xiàn)。比如基于 DOM 樹制定一系列規(guī)則，例如403這些的錯(cuò)誤都可以被很好地掃描出來。同時(shí)，針對(duì)于一些無法通過規(guī)則排查的問題，我們運(yùn)用了算法能力。例如空坑檢測(cè)，一致性檢測(cè)等。

把以上測(cè)試組件，通過消息的方式跟運(yùn)營(yíng)頁面發(fā)布系統(tǒng)對(duì)接。

它的系統(tǒng)依賴關(guān)系是如下的：

圖示：運(yùn)營(yíng)頁面檢測(cè)系統(tǒng)依賴圖【示意】

同時(shí)針對(duì)于不同的業(yè)務(wù)場(chǎng)景，我們開發(fā)了不同的頁面檢測(cè)能力，比如針對(duì)于 DOM 樹的頁面檢查：

還有基于算法能力的識(shí)別能力：

通過上述的改造后，對(duì)于運(yùn)營(yíng)人員發(fā)布頁面以及頁面的測(cè)試就極簡(jiǎn)化為三步一站式的能力。從以往運(yùn)營(yíng)、測(cè)試、開發(fā)之間的來回交接，變成了運(yùn)營(yíng)跟系統(tǒng)之間的交互。不僅提升了運(yùn)營(yíng)人員的頁面搭建體驗(yàn)，也極大地提升了測(cè)試的效率。

在某次運(yùn)行中活動(dòng)中實(shí)際的執(zhí)行結(jié)果【示意圖】：

以上的過程和結(jié)果數(shù)據(jù)，也充分體現(xiàn)了“運(yùn)行含測(cè)試，實(shí)時(shí)可反饋”的價(jià)值。

數(shù)據(jù)和算法是實(shí)時(shí)質(zhì)量的核心

測(cè)試出現(xiàn)以來，我們一直習(xí)慣于代碼邏輯類的測(cè)試，但數(shù)據(jù)一直都是測(cè)試很重要的生產(chǎn)材料。因?yàn)槿巳鈭?zhí)行任務(wù)的局限性，我們發(fā)明了等價(jià)類和邊界值等測(cè)試?yán)碚摵头椒▉碛帽M可能少的成本來盡可能多的驗(yàn)證問題。但一方面算法的不斷應(yīng)用，每一個(gè)數(shù)據(jù)都可能存在個(gè)性化的業(yè)務(wù)表達(dá)，我們可能無法找到一個(gè)通用的預(yù)期結(jié)果較驗(yàn)（還是會(huì)有一些通用的預(yù)期結(jié)果的，比如非空判斷和區(qū)間等，但這類的預(yù)期不能很好地做業(yè)務(wù)判斷）。因此，我們也需要用數(shù)據(jù)和算法能力來武裝自己。

在以數(shù)據(jù)驅(qū)動(dòng)的業(yè)務(wù)發(fā)展進(jìn)程中，我們的測(cè)試主體已經(jīng)從簡(jiǎn)單的代碼轉(zhuǎn)變?yōu)閿?shù)據(jù)+算法。或者說，業(yè)務(wù)對(duì)質(zhì)量的核心述求，已經(jīng)從簡(jiǎn)單的頁面錯(cuò)誤、代碼 BUG 到數(shù)據(jù)的準(zhǔn)確性、算法的有效性（我老板在每次大促前，都要再三叮囑我數(shù)據(jù)不能錯(cuò)）。如何來感知質(zhì)量風(fēng)險(xiǎn)，以及捕獲各類的異常？那必須先把數(shù)據(jù)、流量、監(jiān)控來做收口，同時(shí)提升測(cè)試工具在大數(shù)據(jù)分析上的能力。

基于這些思考，我們構(gòu)建了全域?qū)崟r(shí)數(shù)據(jù)校驗(yàn)?zāi)芰?#xff0c;是一款通過實(shí)時(shí)獲取線上 DB 中的海量業(yè)務(wù)數(shù)據(jù)，完成業(yè)務(wù)數(shù)據(jù)校驗(yàn)、質(zhì)量風(fēng)險(xiǎn)感知的產(chǎn)品。

案例：Captain 全域?qū)崟r(shí)數(shù)據(jù)校驗(yàn)

圖示：數(shù)據(jù)對(duì)比框架【示意】

它具備的一些能力：

嚴(yán)格的安全策略。

實(shí)時(shí)獲取線上數(shù)據(jù)：通過強(qiáng)大的數(shù)據(jù)支持能力，平臺(tái)可以在無損線上數(shù)據(jù)庫表的前提下，通過 SQL 查詢獲取線上 DB 中的真實(shí)業(yè)務(wù)數(shù)據(jù)，且做到了實(shí)時(shí)獲取，通過數(shù)據(jù)可以進(jìn)行完善健壯的數(shù)據(jù)校驗(yàn)，從根本上提高對(duì)于業(yè)務(wù)的把控。

多樣的數(shù)據(jù)獲取方式：目前平臺(tái)支持多種數(shù)據(jù)獲取方式：單庫單表查詢、單庫多表聯(lián)表查詢、分庫分表查詢、跨庫的多表的聯(lián)表查詢。

多種比對(duì)方式支持，比如跨庫查詢和聯(lián)表查詢等等。

最主要，它可以用一套腳本無損地支持測(cè)試環(huán)境、灰度、生產(chǎn)環(huán)境等。讓線下測(cè)試的所有經(jīng)驗(yàn)可以得到復(fù)用和沉淀。（我們內(nèi)部調(diào)侃說，這才是帶著測(cè)試的靈魂的，而其他的很多產(chǎn)品都只是一個(gè)面向開發(fā)的工具）

在前期解決數(shù)據(jù)一致性，對(duì)賬等常用的基本需求上，我們可以依賴于這些數(shù)據(jù)和測(cè)試的服務(wù)，展開更多的業(yè)務(wù)形態(tài)。

實(shí)時(shí)質(zhì)量需要不斷突破測(cè)試的邊界

測(cè)試的邊界在哪里？

過去有人告訴我，不能去修改業(yè)務(wù)應(yīng)用的代碼，只能讓在盒子外面或者調(diào)用的方式來測(cè)試。還有人說，我們只開發(fā)工具，不能接觸任何的業(yè)務(wù)。現(xiàn)在這些都在逐漸模糊，大家努力一起，讓測(cè)試的很多活動(dòng)，從簡(jiǎn)單的功能測(cè)試，往研發(fā)工具和業(yè)務(wù)質(zhì)量等或前或后地遷移。

在過去的一兩年，我們團(tuán)隊(duì)也已經(jīng)慢慢承接了更多的職責(zé)，有些甚至于是直接服務(wù)于客服、運(yùn)營(yíng)和產(chǎn)品人員的。我認(rèn)為，一支強(qiáng)的團(tuán)隊(duì)一定是不斷走在突破原來工作邊界的道路上。沒有什么是一成不變的。

但每個(gè)職能團(tuán)隊(duì)都是有自己的核心價(jià)值的，而至于哪些應(yīng)該由測(cè)試來做，哪些由開發(fā)做。我們的標(biāo)準(zhǔn)是：判斷這件事情是更為了“讓技術(shù)更有品質(zhì)”還是“讓技術(shù)創(chuàng)造新商業(yè)”？（“讓技術(shù)更有品質(zhì)”是我們團(tuán)隊(duì)的使命，“讓技術(shù)拓展業(yè)務(wù)邊界”是開發(fā)團(tuán)隊(duì)的目標(biāo)）

以下雖然是幾年前的例子，但也很好的體現(xiàn)了我們?cè)谶吔绲耐黄?#xff0c;以及如何用實(shí)時(shí)質(zhì)量的思想來開裝自己，創(chuàng)造提交 BUG 以外更多的價(jià)值。

案例：Offer 360提升客服端實(shí)時(shí)質(zhì)量能力

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

實(shí)時(shí)質(zhì)量未來規(guī)劃

實(shí)時(shí)質(zhì)量是一種思想，我覺得它未來是可以跨越在當(dāng)前兩種不同的發(fā)展分支上的。

測(cè)試這么多年來一直被弱化，我也看到集團(tuán)很多優(yōu)秀的測(cè)試 leader 轉(zhuǎn)型開發(fā)、產(chǎn)品。如果我們還不多些思考，多些探索。如果做測(cè)試都還沒有夢(mèng)想，那跟咸魚有什么區(qū)別？

圖示：測(cè)試未來的發(fā)展

后記

上周在內(nèi)部的論壇上看到一個(gè)開發(fā)專家的留言，還是挺有感觸的。我們一直以來都在強(qiáng)調(diào)測(cè)試能力不斷演進(jìn)，強(qiáng)調(diào)開發(fā)能力，但測(cè)試的初心不能丟。我們?cè)诠ぞ摺y(cè)試能力上不斷改進(jìn)，但是從人和組織的角度上來看，在追求最高效的同時(shí)，我們是需要一定的組織設(shè)計(jì)來形成崗位間的相互監(jiān)督。這也是在測(cè)試1.0階段開始，測(cè)試被賦予的一種職責(zé)。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。