1. 為什么非要把測(cè)試往左推先說個(gè)我早年踩過的坑。那時(shí)候我在某公司做一個(gè)后臺(tái)管理系統(tǒng)開發(fā)周期排了六周測(cè)試時(shí)間只剩最后三天。前五周測(cè)試同學(xué)基本閑著等代碼全部提測(cè)之后一上來就發(fā)現(xiàn)十幾個(gè) P0 級(jí)問題數(shù)據(jù)庫字段對(duì)不上、接口參數(shù)傳錯(cuò)、權(quán)限邏輯漏了一整塊。開發(fā)連夜趕工修 bug修完一個(gè)又帶出一個(gè)最后項(xiàng)目延期兩周上線上線當(dāng)天線上又出故障全員緊急回滾。那個(gè)月整個(gè)團(tuán)隊(duì)都在救火復(fù)盤的時(shí)候大家沉默了很久——問題明明可以在早期用很小的代價(jià)避免。這就是典型的“測(cè)試右移”走到極端之后的窘境所有質(zhì)量風(fēng)險(xiǎn)都積壓到交付末端最后一棒扛下所有壓力。而“測(cè)試左移”做的事情恰恰是把這些風(fēng)險(xiǎn)分?jǐn)偟綇男枨蟮介_發(fā)的每一個(gè)環(huán)節(jié)里讓問題在離它產(chǎn)生源頭最近的地方被攔住。測(cè)試左移Shift-Left Testing的核心邏輯一句話就能講透測(cè)試不是軟件做完之后才開始的動(dòng)作而是從需求萌芽、設(shè)計(jì)成型、代碼落地的過程中就持續(xù)介入的質(zhì)量活動(dòng)。傳統(tǒng)的 V 模型里測(cè)試被放在了開發(fā)完成之后對(duì)應(yīng)著需求、設(shè)計(jì)、編碼逐級(jí)驗(yàn)證左移之后測(cè)試活動(dòng)和開發(fā)活動(dòng)平行推進(jìn)甚至先于開發(fā)啟動(dòng)。為什么這么做因?yàn)槿毕菪迯?fù)成本隨發(fā)現(xiàn)時(shí)間呈指數(shù)級(jí)增長(zhǎng)。需求階段發(fā)現(xiàn)一個(gè)邏輯漏洞改的是一頁文檔幾分鐘的事設(shè)計(jì)階段發(fā)現(xiàn)要調(diào)整架構(gòu)方案可能影響多個(gè)模塊編碼階段發(fā)現(xiàn)要在代碼里補(bǔ)邏輯改動(dòng)量和回歸范圍就大了等到上線后用戶反饋才發(fā)現(xiàn)那就是事故要走緊急修復(fù)流程影響的是整個(gè)產(chǎn)品的口碑。我在行業(yè)內(nèi)測(cè)過不少項(xiàng)目有個(gè)數(shù)據(jù)大家只會(huì)在內(nèi)部提同樣的一個(gè)缺陷在需求階段發(fā)現(xiàn)和上線后發(fā)現(xiàn)的修復(fù)成本差距通常在三五十倍以上。這不是夸張因?yàn)樯暇€后的問題不只是改代碼還要走發(fā)布、監(jiān)控、回滾、用戶安撫、輿情處理這一整套流程隱形成本很難量化。所以這篇文章想聊的就是三件事測(cè)試左移具體怎么做、每一步有哪些實(shí)操細(xì)節(jié)和容易踩的坑、以及從團(tuán)隊(duì)協(xié)同角度如何讓這個(gè)機(jī)制真正轉(zhuǎn)起來。無論你是測(cè)試工程師、開發(fā)工程師還是技術(shù)負(fù)責(zé)人這套方法論都能直接用在項(xiàng)目里。2. 測(cè)試左移的核心思路與四層介入模型2.1 從“事后驗(yàn)證”到“全程質(zhì)量”傳統(tǒng)測(cè)試思維本質(zhì)上是“驗(yàn)證思維”——代碼寫完我看看你做得對(duì)不對(duì)。左移測(cè)試的本質(zhì)是“質(zhì)量?jī)?nèi)建思維”——從一開始就讓質(zhì)量問題沒有機(jī)會(huì)混進(jìn)代碼里。這兩種思維差異體現(xiàn)在日常動(dòng)作上。傳統(tǒng)模式下測(cè)試同學(xué)拿到提測(cè)包開始點(diǎn)界面、查接口、對(duì)需求文檔左移模式下測(cè)試同學(xué)在需求評(píng)審會(huì)上就會(huì)追問“這個(gè)狀態(tài)流轉(zhuǎn)的邊界條件是什么”“如果用戶連續(xù)點(diǎn)擊兩次會(huì)發(fā)生什么”“這批數(shù)據(jù)量達(dá)到十萬級(jí)的時(shí)候接口性能還能不能撐住”。開發(fā)還沒寫代碼測(cè)試已經(jīng)把最容易出錯(cuò)的地方標(biāo)出來了。這不是要求測(cè)試變成需求分析師或架構(gòu)師而是要求測(cè)試具備“基于風(fēng)險(xiǎn)的質(zhì)量視角”。也就是在事情發(fā)生之前就能識(shí)別出哪些地方容易出現(xiàn)問題然后推動(dòng)團(tuán)隊(duì)在源頭避免它。我見過很多團(tuán)隊(duì)把左移理解成“測(cè)試提前看看需求文檔”這其實(shí)只做了一層皮。真正的左移介入的深度是分層的我把它總結(jié)為一個(gè)四層介入模型對(duì)應(yīng)項(xiàng)目推進(jìn)的不同階段。2.2 四層介入模型需求、設(shè)計(jì)、編碼、環(huán)境第一層是需求分析層。測(cè)試在這個(gè)階段要做的不是“讀文檔”而是“審邏輯”。需求文檔里每個(gè)功能點(diǎn)都要問出至少三組問題功能在什么條件下觸發(fā)異常情況下怎么表現(xiàn)用戶操作邊界是什么這三組問題能篩掉大量“需求漏斗”里的模糊地帶。某次做一個(gè)訂單導(dǎo)出功能開發(fā)看了需求文檔覺得很簡(jiǎn)單就是一個(gè)按鈕點(diǎn)一下導(dǎo)出 Excel。測(cè)試在評(píng)審會(huì)上追問導(dǎo)出上限多少條一百萬條的時(shí)候是同步導(dǎo)出還是異步生成導(dǎo)出的文件命名規(guī)則是什么是否存在并發(fā)導(dǎo)出的鎖定問題需求方當(dāng)場(chǎng)愣住了因?yàn)楫a(chǎn)品文檔里只寫了“支持導(dǎo)出”其他什么都沒定義。如果這些問題等到開發(fā)完了再發(fā)現(xiàn)那整個(gè)導(dǎo)出模塊的架構(gòu)都可能推翻重來。第二層是設(shè)計(jì)評(píng)審層。測(cè)試要參與技術(shù)方案評(píng)審關(guān)注系統(tǒng)架構(gòu)、接口設(shè)計(jì)、數(shù)據(jù)模型。很多人覺得這是開發(fā)的事但測(cè)試在這個(gè)階段的價(jià)值在于從“可測(cè)性”角度提出意見——比如某個(gè)接口的返回結(jié)構(gòu)是不是包含足夠的狀態(tài)信息、某個(gè)模塊是否預(yù)留了測(cè)試開關(guān)、日志體系是否覆蓋了關(guān)鍵鏈路。第三層是編碼實(shí)現(xiàn)層。這個(gè)階段測(cè)試的介入方式是代碼評(píng)審、靜態(tài)分析、單元測(cè)試覆蓋率監(jiān)控以及最重要的——在開發(fā)自測(cè)階段就給出“自測(cè)清單”。讓開發(fā)在提測(cè)之前先按照測(cè)試設(shè)計(jì)的路徑把核心流程走一遍把能自己發(fā)現(xiàn)的問題消滅在提測(cè)之前。第四層是測(cè)試環(huán)境層。這是測(cè)試左移里最容易被忽略、又最容易出問題的一層。很多團(tuán)隊(duì)左移推進(jìn)不下去不是因?yàn)闇y(cè)試不努力而是環(huán)境問題把測(cè)試卡死了——數(shù)據(jù)不對(duì)、接口不通、依賴服務(wù)起不來測(cè)試想提前介入也無從下手。所以左移必須包含“環(huán)境左移”也就是在開發(fā)編碼階段測(cè)試環(huán)境就要搭建完成并且數(shù)據(jù)準(zhǔn)備、服務(wù)依賴都要提前就緒。這四層不是互相獨(dú)立的而是層層遞進(jìn)、逐步具體化的過程。前一層的質(zhì)量問題如果沒有攔截住就會(huì)流到下一層修復(fù)成本隨之上升。而左移做的事情就是在每一層都設(shè)立攔截點(diǎn)。3. 實(shí)操細(xì)節(jié)每一層具體怎么介入3.1 需求階段的“可測(cè)性評(píng)審”需求階段是左移成本最低、收益最大的入口但也是很多團(tuán)隊(duì)做得最敷衍的入口。大多數(shù)團(tuán)隊(duì)的“測(cè)試介入需求”就是測(cè)試組長(zhǎng)去參加一下需求宣講會(huì)聽產(chǎn)品講一遍然后就沒有然后了。要做實(shí)這塊需要把動(dòng)作標(biāo)準(zhǔn)化。我自己的做法是建立一張“可測(cè)性評(píng)審清單”每一次需求評(píng)審會(huì)都拿這張清單逐項(xiàng)過。清單分四個(gè)維度完整性需求是否覆蓋了正常流程、異常流程、邊界場(chǎng)景比如“上傳文件”這個(gè)功能是否有格式限制、大小限制、空文件處理邏輯一致性需求文檔中的術(shù)語、狀態(tài)、角色定義是否統(tǒng)一不同模塊之間的數(shù)據(jù)流轉(zhuǎn)是否閉環(huán)可驗(yàn)證性驗(yàn)收標(biāo)準(zhǔn)是否明確什么樣的結(jié)果算“通過”比如“響應(yīng)要快”這就是不可驗(yàn)證的改成“接口響應(yīng)時(shí)間在 200ms 以內(nèi)成功率不低于 99.9%”才是可驗(yàn)證的。依賴性這個(gè)功能依賴哪些外部系統(tǒng)、依賴的數(shù)據(jù)是否就緒這套清單看著簡(jiǎn)單實(shí)際執(zhí)行的時(shí)候價(jià)值很大。因?yàn)榇蠖鄶?shù)需求文檔天然存在模糊地帶而測(cè)試是唯一會(huì)逐字逐句去較真“這個(gè)描述到底是什么意思”的角色。開發(fā)通常會(huì)假設(shè)需求一定會(huì)說清楚產(chǎn)品通常會(huì)假設(shè)大家都能理解只有測(cè)試真正把模糊處暴露到陽光下。操作層面有個(gè)小技巧需求評(píng)審會(huì)別只開一次。第一輪評(píng)審結(jié)束后把測(cè)試提出的問題整理成清單發(fā)給產(chǎn)品約定第二輪評(píng)審逐個(gè)確認(rèn)關(guān)閉。一次評(píng)審就過是幻想大多數(shù)需求至少要兩到三輪才能真正達(dá)到可開發(fā)狀態(tài)。3.2 設(shè)計(jì)階段的“可測(cè)性設(shè)計(jì)”進(jìn)入設(shè)計(jì)階段后測(cè)試的介入方式是參加技術(shù)方案評(píng)審但要從測(cè)試視角提出問題。這些問題的核心指向是這個(gè)設(shè)計(jì)好不好測(cè)舉個(gè)例子。有一個(gè)支付回調(diào)接口開發(fā)的設(shè)計(jì)是回調(diào)過來后處理業(yè)務(wù)邏輯返回成功即可。從開發(fā)角度看邏輯很簡(jiǎn)潔。但測(cè)試介入后發(fā)現(xiàn)回調(diào)失敗時(shí)是否需要支持手動(dòng)補(bǔ)償接口是否有冪等機(jī)制日志里有沒有打印完整的回調(diào)報(bào)文這些問題不解決測(cè)試只能黑盒盲測(cè)出了問題也查不到根因。所以設(shè)計(jì)評(píng)審的測(cè)試視角我總結(jié)為三個(gè)“必須”必須可觀測(cè)關(guān)鍵鏈路有日志、有監(jiān)控指標(biāo)、有追蹤標(biāo)識(shí)。線上出問題時(shí)能不能快速定位到某一筆請(qǐng)求的完整鏈路必須可控制系統(tǒng)是否有功能開關(guān)、Mock 點(diǎn)、測(cè)試樁需要模擬第三方超時(shí)、返回異常時(shí)是否不依賴真實(shí)外部系統(tǒng)必須可驗(yàn)證接口的返回結(jié)構(gòu)、狀態(tài)碼、錯(cuò)誤信息是否有明確的定義自動(dòng)化用例斷言什么才算通過這里要注意測(cè)試在方案評(píng)審中不要越界去“幫開發(fā)設(shè)計(jì)”。你的職責(zé)是提出可測(cè)性需求而不是替開發(fā)決定怎么實(shí)現(xiàn)。比如你可以指出“這個(gè)模塊如果走異步處理測(cè)試時(shí)怎么確認(rèn)處理結(jié)果”但不需要自己去設(shè)計(jì)異步隊(duì)列的實(shí)現(xiàn)方案。3.3 編碼階段的“質(zhì)量?jī)?nèi)建”編碼階段的左移最有杠桿效應(yīng)的動(dòng)作有兩個(gè)代碼評(píng)審和開發(fā)自測(cè)清單。代碼評(píng)審不只是開發(fā)之間的事測(cè)試參與代碼評(píng)審的收益比很多人想象中高。測(cè)試不一定能從代碼邏輯層面發(fā)現(xiàn)所有問題但能從“用例覆蓋”角度提出盲區(qū)你新增了一個(gè) if 分支這個(gè)分支的測(cè)試用例在哪里你改了接口的參數(shù)校驗(yàn)原來那個(gè)參數(shù)為空的用例還能不能過開發(fā)自測(cè)清單是我這些年強(qiáng)烈推薦每個(gè)團(tuán)隊(duì)都做的東西。傳統(tǒng)流程里開發(fā)提測(cè)后測(cè)試發(fā)現(xiàn)一堆低級(jí)問題——頁面跳轉(zhuǎn)錯(cuò)誤、按鈕點(diǎn)了沒反應(yīng)、數(shù)據(jù)沒刷新、邊界值不處理。這些問題開發(fā)其實(shí)只要自己跑一遍就能發(fā)現(xiàn)但因?yàn)闆]有明確要求開發(fā)往往只是“編譯通過、能啟動(dòng)、接口通”就提測(cè)了。自測(cè)清單本質(zhì)上把測(cè)試執(zhí)行的核心用例前置給了開發(fā)讓開發(fā)在提測(cè)前先自測(cè)一遍。這份清單不需要很長(zhǎng)二三十條核心冒煙用例就夠。關(guān)鍵標(biāo)準(zhǔn)是清單里的用例全部通過才允許發(fā)起提測(cè)。這一步能在入口攔截掉 50% 以上的低級(jí)缺陷極大節(jié)省測(cè)試輪次。靜態(tài)分析和單元測(cè)試覆蓋率是這個(gè)階段的輔助手段不需要追求覆蓋率數(shù)字好看而是把覆蓋率用來發(fā)現(xiàn)“哪些核心模塊沒有被測(cè)試到”作為補(bǔ)充用例設(shè)計(jì)的輸入。3.4 環(huán)境階段的“左移前提”我再單獨(dú)強(qiáng)調(diào)一下測(cè)試環(huán)境因?yàn)檫@是很多團(tuán)隊(duì)左移落地失敗的直接原因。測(cè)試想在需求階段介入、想在開發(fā)階段介入但代碼寫好之后發(fā)現(xiàn)測(cè)試環(huán)境根本跑不起來——這在前端項(xiàng)目里尤其常見聯(lián)調(diào)環(huán)境不穩(wěn)定、Mock 數(shù)據(jù)不完整、本地跑起來缺配置。環(huán)境左移的核心要求是在開發(fā)編碼進(jìn)入后半段時(shí)測(cè)試環(huán)境的建設(shè)和數(shù)據(jù)準(zhǔn)備就同步啟動(dòng)。測(cè)試人員要在開發(fā)提測(cè)之前完成環(huán)境連通性驗(yàn)證、基礎(chǔ)數(shù)據(jù)準(zhǔn)備、依賴服務(wù)檢查。這樣提測(cè)包一到測(cè)試可以直接進(jìn)入用例執(zhí)行而不是花兩三天先修環(huán)境。環(huán)境問題還涉及一個(gè)長(zhǎng)期主義層面的事測(cè)試環(huán)境的穩(wěn)定性要靠平臺(tái)化來解決。如果每次部署都要手動(dòng)操作、每次數(shù)據(jù)都要手動(dòng)造那這個(gè)環(huán)境永遠(yuǎn)不可能穩(wěn)定。比較好的做法是環(huán)境配置代碼化用腳本一鍵完成環(huán)境初始化和數(shù)據(jù)初始化讓環(huán)境的準(zhǔn)備變成一條命令的事。4. 推進(jìn)過程中常見的阻力與應(yīng)對(duì)方案4.1 團(tuán)隊(duì)阻力測(cè)試“越權(quán)”的邊界在哪里推左移的時(shí)候最常見的阻力來自開發(fā)團(tuán)隊(duì)。測(cè)試在需求評(píng)審會(huì)上不斷追問、在代碼評(píng)審里提出意見有些開發(fā)會(huì)覺得很煩——“需求這么清楚你們?cè)趺催€問個(gè)不停”“這點(diǎn)小事也要管”應(yīng)對(duì)這個(gè)阻力靠的不是爭(zhēng)論而是數(shù)據(jù)。把測(cè)試左移攔截下來的問題做一個(gè)簡(jiǎn)單的統(tǒng)計(jì)需求階段發(fā)現(xiàn)了哪些會(huì)導(dǎo)致開發(fā)返工的問題、編碼階段自測(cè)清單攔截了多少低級(jí)缺陷、每個(gè)問題的修復(fù)耗時(shí)是多少。出幾次數(shù)據(jù)之后開發(fā)就會(huì)明白這些追問不是在找麻煩而是在幫他們節(jié)省返工時(shí)間。另外一個(gè)邊界感問題也要說清楚。測(cè)試在需求階段提意見但最終需求是否變更決定權(quán)在產(chǎn)品測(cè)試在代碼評(píng)審提建議但最終代碼是否修改決定權(quán)在開發(fā)。測(cè)試的角色是“提出風(fēng)險(xiǎn)”而不是“拍板決策”。這個(gè)邊界一旦模糊協(xié)作關(guān)系就會(huì)變得緊張。4.2 流程阻力沒有入口測(cè)試想介入也無從下手很多測(cè)試想主動(dòng)左移但發(fā)現(xiàn)流程上根本沒有入口。需求評(píng)審會(huì)不叫測(cè)試、技術(shù)方案評(píng)審不叫測(cè)試、代碼評(píng)審是開發(fā)內(nèi)部的事。這其實(shí)是流程設(shè)計(jì)的問題不是測(cè)試能力的問題。要把左移落地首先要修改流程定義需求評(píng)審必須有測(cè)試角色參加并且測(cè)試對(duì)需求的可測(cè)性有否決權(quán)——可測(cè)性不達(dá)標(biāo)的條目不開工技術(shù)方案評(píng)審要預(yù)留可測(cè)性評(píng)審環(huán)節(jié)提測(cè)流程增加自測(cè)檢查門禁。這些流程定義看起來只是“寫進(jìn)規(guī)范”實(shí)際執(zhí)行起來是文化層面的改變它確立了測(cè)試在質(zhì)量活動(dòng)中的位置不再是末端接收方而是全程參與者。4.3 能力阻力測(cè)試自己不敢介入還有一種阻力來自測(cè)試團(tuán)隊(duì)本身。很多測(cè)試不是不想左移而是不敢。長(zhǎng)期在末端執(zhí)行黑盒用例突然被要求去參加需求評(píng)審、討論技術(shù)方案心里發(fā)虛是正常的。應(yīng)對(duì)方式是分階段提升。先做需求階段的清單化介入——拿著現(xiàn)成的可測(cè)性評(píng)審清單逐項(xiàng)打勾不需要高深的業(yè)務(wù)理解也能發(fā)現(xiàn)問題再逐步參與技術(shù)評(píng)審從“測(cè)試環(huán)境準(zhǔn)備、日志追蹤、測(cè)試開關(guān)”這類可測(cè)性角度切入最后再往上游走參與需求分析和業(yè)務(wù)規(guī)則梳理。能力是實(shí)踐中長(zhǎng)出來的不是培訓(xùn)課聽出來的。5. 從試點(diǎn)到制度化左移推廣的三年經(jīng)驗(yàn)測(cè)試左移真正推動(dòng)起來不能指望一次宣貫加一份文檔就自然生效。它是一套帶行為改變的工程機(jī)制需要設(shè)計(jì)好節(jié)奏先在小范圍做出可信樣板再逐步擴(kuò)開。我的建議路線分三個(gè)里程碑。第一個(gè)里程碑是“一個(gè)項(xiàng)目試點(diǎn)”。選一個(gè)規(guī)模適中、業(yè)務(wù)復(fù)雜度可控、團(tuán)隊(duì)配合意愿高的項(xiàng)目把需求階段的可測(cè)性評(píng)審、開發(fā)自測(cè)清單、測(cè)試環(huán)境左移這三件事做起來。試點(diǎn)項(xiàng)目的目標(biāo)不是把左移做到完美而是產(chǎn)出一份可信的對(duì)比數(shù)據(jù)和同類型歷史項(xiàng)目相比提測(cè)后缺陷數(shù)下降了多少、測(cè)試周期縮短了多少、上線后的線上問題減少了多少。第二個(gè)里程碑是“推廣到同一業(yè)務(wù)線”。有了試點(diǎn)數(shù)據(jù)推廣就有了說服力。同一個(gè)業(yè)務(wù)線上的其他項(xiàng)目組看到數(shù)據(jù)會(huì)主動(dòng)來問“你們?cè)趺醋龅摹薄@時(shí)候再輸出一套標(biāo)準(zhǔn)化模板可測(cè)性評(píng)審清單模板、開發(fā)自測(cè)清單模板、環(huán)境準(zhǔn)備清單模板。標(biāo)準(zhǔn)化模板是推廣的關(guān)鍵因?yàn)橹挥邪炎笠苿?dòng)作變成可復(fù)制的工具團(tuán)隊(duì)才能不依賴個(gè)別測(cè)試的個(gè)人能力。第三個(gè)里程碑是“制度化約束”。把左移動(dòng)作固化到研發(fā)流程的強(qiáng)制節(jié)點(diǎn)里沒有測(cè)試簽字的需求條目不允許進(jìn)入開發(fā)排期自測(cè)清單未通過的代碼分支不允許發(fā)起提測(cè)合并。這一步會(huì)因?yàn)閺?qiáng)制而帶來短期陣痛但只有走到這一步左移才真正成為團(tuán)隊(duì)的默認(rèn)工作方式。從小范圍試點(diǎn)到制度化約束我自己的經(jīng)驗(yàn)是大概需要三個(gè)月的導(dǎo)入期加一個(gè)季度的固化期。期間會(huì)遇到各種反復(fù)——項(xiàng)目忙了、上線時(shí)間緊了左移動(dòng)作又開始流于形式。這時(shí)候負(fù)責(zé)人要做的不是指責(zé)而是定期回去看數(shù)據(jù)把“按左移方式做事”和“項(xiàng)目質(zhì)量指標(biāo)變好”之間的因果關(guān)系反復(fù)講清楚。6. 自動(dòng)化如何配合測(cè)試左移左移不只是流程和人的事工具和自動(dòng)化必須跟上。沒有自動(dòng)化支撐左移的很多環(huán)節(jié)會(huì)變成空談。舉幾個(gè)關(guān)鍵點(diǎn)。需求階段的規(guī)則校驗(yàn)可以自動(dòng)化。把可測(cè)性評(píng)審清單里的部分檢查項(xiàng)做成自動(dòng)化規(guī)則比如掃描需求文檔中是否包含“快、好、穩(wěn)”這類不可驗(yàn)證的模糊描述詞是否有明確的驗(yàn)收標(biāo)準(zhǔn)字段。雖然不是所有檢查都能自動(dòng)完成但能用簡(jiǎn)單規(guī)則攔下一部分明顯不符合要求的條目。接口測(cè)試的自動(dòng)化要前置到設(shè)計(jì)階段。接口定義一旦確定就可以基于接口文檔生成接口級(jí)自動(dòng)化用例。這些用例在開發(fā)實(shí)現(xiàn)過程中持續(xù)跑每提交一次代碼就回歸一次。接口自動(dòng)化做扎實(shí)之后很多集成階段才能發(fā)現(xiàn)的問題在編碼階段就被自動(dòng)化用例捕捉到了。開發(fā)自測(cè)清單的自動(dòng)化程度也很關(guān)鍵。如果是純手動(dòng)清單開發(fā)執(zhí)行意愿會(huì)隨時(shí)間快速衰減。好的做法是把清單沉淀成自動(dòng)化冒煙測(cè)試集合開發(fā)提測(cè)前只需要執(zhí)行一條命令、跑一個(gè)流水線任務(wù)十幾分鐘內(nèi)自動(dòng)完成核心鏈路驗(yàn)證并輸出報(bào)告。很多團(tuán)隊(duì)問我要不要為了左移專門采購工具我的觀點(diǎn)是工具不必一步到位先把流程跑通再逐步用自動(dòng)化替代手工。工具的服務(wù)對(duì)象是流程流程不清晰買再貴的平臺(tái)也是閑置。7. 沒有專職測(cè)試的團(tuán)隊(duì)怎么做左移現(xiàn)實(shí)中還有一種團(tuán)隊(duì)情況很常見沒有專職測(cè)試開發(fā)自測(cè)為主頂多配一個(gè)測(cè)試兼產(chǎn)品或兼職測(cè)試。這種團(tuán)隊(duì)怎么做左移其實(shí)左移強(qiáng)調(diào)的“盡早介入”在資源不足時(shí)反而更重要因?yàn)槟┒速|(zhì)量保證的力量本來就弱前面再不管后面必然失控。具體建議從兩個(gè)動(dòng)作切入。第一把需求階段評(píng)審做成強(qiáng)制前置動(dòng)作。哪怕沒有專職測(cè)試開發(fā)也要在需求評(píng)審會(huì)上把自己當(dāng)成一個(gè)“吹毛求疵的用戶”把需求文檔中的模糊點(diǎn)全部標(biāo)注出來逐個(gè)確認(rèn)。這其實(shí)就是測(cè)試思維的應(yīng)用。第二建立主干流程冒煙自測(cè)集合。把項(xiàng)目最關(guān)鍵的用戶主流程串起來做成自動(dòng)化腳本每次提測(cè)前必須跑通。這個(gè)集合不需要覆蓋全部功能只需要覆蓋“如果這里壞了用戶就沒法用了”的核心路徑。沒有專職測(cè)試的團(tuán)隊(duì)左移核心思路是“把質(zhì)量?jī)?nèi)置進(jìn)開發(fā)的日常動(dòng)作”而不是新增一堆流程增加負(fù)擔(dān)。設(shè)計(jì)的任何左移機(jī)制都要考慮開發(fā)是否愿意持續(xù)執(zhí)行——如果一個(gè)動(dòng)作執(zhí)行起來很麻煩、收益又不直觀兩周就會(huì)被人悄悄放棄。8. 左移之后線上還是出了問題怎么辦前面說的都是如何在源頭防問題但工程領(lǐng)域的殘酷現(xiàn)實(shí)是不管左移做得多到位線上問題仍然會(huì)出。區(qū)別在于左移做得好線上問題的數(shù)量和嚴(yán)重程度都會(huì)大幅下降以及出問題時(shí)團(tuán)隊(duì)處理和定位的速度也會(huì)更快。這里要說清楚一個(gè)容易產(chǎn)生的誤解左移不等于不需要右移。測(cè)試右移——包括線上監(jiān)控、日志分析、用戶行為追蹤、生產(chǎn)環(huán)境驗(yàn)證——和左移是互補(bǔ)關(guān)系。左移負(fù)責(zé)從源頭減少問題右移負(fù)責(zé)在線上兜底、快速發(fā)現(xiàn)殘留問題。一個(gè)成熟的測(cè)試體系是兩端同時(shí)發(fā)力。所以做左移的時(shí)候不要忽略線上監(jiān)控和告警體系的建設(shè)。我在前面提到設(shè)計(jì)階段的“三個(gè)必須”——可觀測(cè)、可控制、可驗(yàn)證——其中可觀測(cè)很大程度就是為右移服務(wù)的。日志記錄是否完整、監(jiān)控指標(biāo)是否覆蓋關(guān)鍵路徑、分布式追蹤是否打通這些在設(shè)計(jì)階段就決定了線上出問題時(shí)你能否快速定位。9. 最后的一些經(jīng)驗(yàn)和心得前面把方法講了七七八八最后想補(bǔ)充幾條更偏個(gè)人經(jīng)驗(yàn)的體會(huì)。第一左移推進(jìn)中一定要有人扮演“持續(xù)的推動(dòng)者”。這個(gè)角色可以是測(cè)試負(fù)責(zé)人也可以是技術(shù) leader但不能是“大家共同負(fù)責(zé)”——一旦負(fù)責(zé)變成無人負(fù)責(zé)左移動(dòng)作三個(gè)月后就會(huì)退回原樣。第二數(shù)據(jù)是左移最好的說客。但要注意統(tǒng)計(jì)口徑的統(tǒng)一。比如“需求階段攔截的缺陷數(shù)”需要開發(fā)和測(cè)試對(duì)“這算不算缺陷”達(dá)成一致的定義再統(tǒng)計(jì)否則后面會(huì)產(chǎn)生大量爭(zhēng)論把推動(dòng)精力耗散掉。第三不要追求一步到位。左移不是一刀切把重型測(cè)試流程加到所有項(xiàng)目上而是按風(fēng)險(xiǎn)分層管理核心業(yè)務(wù)、資金相關(guān)、用戶量大的模塊做深度左移內(nèi)部工具、低風(fēng)險(xiǎn)頁面做輕度左移。資源永遠(yuǎn)是有限的左移的價(jià)值不是把每一條用例都跑在最前面而是把最值得的質(zhì)量活動(dòng)放到最合適的時(shí)間點(diǎn)上去執(zhí)行。第四左移對(duì)測(cè)試個(gè)人成長(zhǎng)的影響其實(shí)很大。長(zhǎng)期做末端驗(yàn)證的測(cè)試對(duì)業(yè)務(wù)的理解停留在表面技術(shù)上也容易邊緣化。真正參與左移之后你要懂業(yè)務(wù)邏輯、要能和技術(shù)方案對(duì)話、要能用自動(dòng)化和工具化解風(fēng)險(xiǎn)——這些能力積累下來測(cè)試的價(jià)值邊界會(huì)打開很多。從我自己的職業(yè)經(jīng)歷看左移是測(cè)試從執(zhí)行者走向質(zhì)量專家的關(guān)鍵路徑。測(cè)試左移這件事聽起來是一個(gè)方法論做起來是一系列動(dòng)作的集合多問一次需求評(píng)審會(huì)上的問題、多準(zhǔn)備一份開發(fā)自測(cè)清單、多參與一輪技術(shù)方案的可測(cè)性評(píng)審、多提前兩天準(zhǔn)備好測(cè)試環(huán)境。每一件事單獨(dú)看都不宏大但串起來之后整個(gè)團(tuán)隊(duì)的研發(fā)質(zhì)量文化會(huì)發(fā)生質(zhì)變。最后一個(gè)真實(shí)感受每次項(xiàng)目順利上線、并且連續(xù)幾周沒有線上故障時(shí)回頭看測(cè)試左移推動(dòng)的那些“小動(dòng)作”我都會(huì)覺得當(dāng)初這點(diǎn)麻煩太值了。