做測試這些年接觸過的項(xiàng)目從幾萬行的內(nèi)部工具到百萬級用戶量的商業(yè)系統(tǒng)都有面試過不少測試工程師也帶過多條業(yè)務(wù)線的質(zhì)量保障團(tuán)隊(duì)。每次聊到測試分類很多人第一反應(yīng)就是單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試但真到了實(shí)際項(xiàng)目里光靠這一套是遠(yuǎn)遠(yuǎn)不夠的。接上一篇測試分類上繼續(xù)聊。上篇講的是按測試技術(shù)黑盒、白盒、灰盒和按測試目的功能、性能、安全、兼容性等兩個維度來切分測試。這篇把剩下四個維度一次說透測試階段、測試執(zhí)行方式、測試組織方式、測試地域?qū)傩?。這四個維度更像是從什么時候測、誰去測、怎么組織人、在哪個環(huán)境測的角度看測試跟程序員日常協(xié)作、排期、提測流程都強(qiáng)相關(guān)也是很多測試方案里最容易含糊的地方。1. 按測試階段分類一條完整交付鏈上的分工階段分類是所有測試工程師最先接觸的知識點(diǎn)但很多人只是記住了名詞并沒有理解每個階段真正要解決什么問題。我個人的理解是按階段分類本質(zhì)上是把質(zhì)量驗(yàn)證這件事拆成了若干個關(guān)卡每道關(guān)卡都有明確的進(jìn)入條件和出口標(biāo)準(zhǔn)。1.1 單元測試代碼層面的第一道防線單元測試的對象是代碼中最小的可驗(yàn)證單元通常是一個函數(shù)、一個方法或者一個類。為什么它必須存在因?yàn)樵皆绨l(fā)現(xiàn)缺陷修復(fù)成本越低。這是測試界一條鐵律成本曲線大致是單元測試階段發(fā)現(xiàn)并修復(fù)bug消耗1個單位成本集成測試階段可能要3-5個單位系統(tǒng)測試階段要10個單位等上線后線上事故來推動修復(fù)20個單位都打不住。單元測試由誰做基本是開發(fā)自己。測試人員在這個階段的參與方式通常是評審測試用例設(shè)計、抽查覆蓋率和推動補(bǔ)充邊界用例。我自己帶團(tuán)隊(duì)時測試工程師有一種很好的介入方式就是開發(fā)寫完單測后測試幫著review用例設(shè)計專門挑一些開發(fā)想不到但實(shí)際很容易踩的輸入組合比如空指針、超長字符串、并發(fā)調(diào)用、時間邊界。單測怎么才算合格業(yè)界常用的指標(biāo)是行覆蓋率、分支覆蓋率。我個人建議至少盯分支覆蓋率而不是只看行覆蓋率行覆蓋只說明代碼被執(zhí)行到了分支覆蓋才能證明不同邏輯路徑都被驗(yàn)證過。比如一個if (age 18 isVip)的判斷行覆蓋率100%可能是只測了true true的happy path另外三個分支全是漏的。1.2 集成測試模塊之間才是事故高發(fā)區(qū)集成測試是階段鏈條上最容易被低估的一環(huán)。很多人覺得每個模塊單測都過了組合起來問題不大恰恰是這種想法讓無數(shù)項(xiàng)目在聯(lián)調(diào)階段翻車。模塊之間的接口約定、數(shù)據(jù)格式、異常處理方式、調(diào)用時序單測根本覆蓋不到只有集成測試能暴露這些問題。集成策略我見過三種自底向上、自頂向下、三明治式混合式。自底向上先測葉子模塊然后逐步向上組合優(yōu)點(diǎn)是對底層邏輯驗(yàn)證充分缺點(diǎn)是頂層核心業(yè)務(wù)流最后才串起來自頂向下先測主流程骨架用樁模塊Stub代替尚未實(shí)現(xiàn)的底層適合遵循分層架構(gòu)、主流程明確的系統(tǒng)三明治式則是兩頭同時推進(jìn)中間用樁和驅(qū)動銜接適合大型系統(tǒng)分多階段集成的場景。接口測試是集成測試?yán)镒詈诵牡膬?nèi)容。只要模塊之間走HTTP、RPC、消息隊(duì)列接口的入?yún)⑿ｒ?yàn)、返回值結(jié)構(gòu)、超時處理、異常碼語義都必須有明確約定并在集成階段驗(yàn)證。我踩過一個很典型的坑兩個模塊的團(tuán)隊(duì)各自理解為超時時間5秒A團(tuán)隊(duì)從發(fā)出請求開始算B團(tuán)隊(duì)從連接建立后開始算結(jié)果高峰期接口頻頻報警排查了很久才發(fā)現(xiàn)是5秒的定義不統(tǒng)一。這種問題不實(shí)測根本暴露不出來。1.3 系統(tǒng)測試站在用戶視角審視整個產(chǎn)品到了系統(tǒng)測試階段測試對象是一個完整、集成好的系統(tǒng)測試人員要完全站在用戶視角驗(yàn)證系統(tǒng)是否滿足需求規(guī)格說明中定義的功能和非功能指標(biāo)。這個階段不再關(guān)心內(nèi)部模塊怎么實(shí)現(xiàn)只關(guān)心對外表現(xiàn)。系統(tǒng)測試的覆蓋面非常廣功能測試要跑完整業(yè)務(wù)鏈路性能測試要驗(yàn)證吞吐量、響應(yīng)時間、資源占用安全測試要檢查越權(quán)訪問、注入類風(fēng)險、敏感信息泄露兼容性測試要在不同瀏覽器、系統(tǒng)、設(shè)備上運(yùn)行。這里有一個常見誤區(qū)就是系統(tǒng)測試只當(dāng)作功能測試的放大版實(shí)際上非功能測試恰恰是這個階段的重頭戲很多質(zhì)量事故都發(fā)生在性能和安全層面而不是普通功能層面。系統(tǒng)測試的環(huán)境也很有講究最佳實(shí)踐是盡量貼近生產(chǎn)環(huán)境相同的服務(wù)器配置、相同的網(wǎng)絡(luò)拓?fù)?、相同的中間件版本。甚至在容器化普及的今天推薦直接用與生產(chǎn)一致的基礎(chǔ)鏡像、一致的資源限制配置來部署測試環(huán)境否則容易出現(xiàn)測試環(huán)境一切正常生產(chǎn)環(huán)境上線就崩的情況。1.4 驗(yàn)收測試給用戶一個放心按鈕驗(yàn)收測試是交付前的最后一道關(guān)卡目標(biāo)很直接確認(rèn)系統(tǒng)符合用戶的預(yù)期能夠讓用戶接受。它和系統(tǒng)測試的最大區(qū)別在于系統(tǒng)測試驗(yàn)證的是需求文檔里寫的對不對、有沒有實(shí)現(xiàn)驗(yàn)收測試驗(yàn)證的是用戶真正用起來順不順手、能不能接受。Alpha測試和Beta測試是驗(yàn)收階段最常見的形式。Alpha測試由內(nèi)部人員在模擬真實(shí)環(huán)境的條件下進(jìn)行Beta測試則邀請真實(shí)用戶在自己環(huán)境中使用并反饋問題。移動App常見的灰度發(fā)布內(nèi)測渠道本質(zhì)上就是一種持續(xù)化的Beta測試形態(tài)。用戶驗(yàn)收測試UATUser Acceptance Testing還有一個很實(shí)際的功能它是最容易發(fā)現(xiàn)需求理解偏差的階段。我之前做過一個ERP項(xiàng)目需求文檔里寫支持批量審核開發(fā)理解為可以勾選多張單據(jù)一起審核但業(yè)務(wù)方的真實(shí)含義是按部門維度審核該部門下所有單。系統(tǒng)測試階段沒人發(fā)現(xiàn)到UAT時業(yè)務(wù)人員一操作就知道不對。這類偏差靠測試用例很難提前發(fā)現(xiàn)只能通過盡早讓用戶參與驗(yàn)證來降低風(fēng)險。所以現(xiàn)在很多敏捷團(tuán)隊(duì)把驗(yàn)收標(biāo)準(zhǔn)Acceptance Criteria寫在每個用戶故事里讓BA、開發(fā)、測試、用戶代表共同確認(rèn)就是為了把這個風(fēng)險前置。1.5 階段之間的關(guān)系與重點(diǎn)對比很多人把階段測試?yán)斫獬梢粋€瀑布式流程實(shí)際上在現(xiàn)代研發(fā)模式下這些階段的界限越來越模糊。敏捷團(tuán)隊(duì)的做法是每個迭代內(nèi)部都包含單元測試、集成測試、系統(tǒng)測試驗(yàn)收測試則以迭代評審的形式持續(xù)進(jìn)行。但無論如何各階段的本質(zhì)目標(biāo)和質(zhì)量要求是不能打折扣的。測試階段主要對象執(zhí)行者發(fā)現(xiàn)問題類型進(jìn)入條件單元測試函數(shù)/方法/類開發(fā)人員邏輯錯誤、邊界問題代碼編譯通過集成測試模塊間接口/交互測試開發(fā)接口不匹配、時序問題相關(guān)模塊單測通過系統(tǒng)測試完整系統(tǒng)專業(yè)測試功能缺失、性能瓶頸、安全隱患系統(tǒng)集成部署完成驗(yàn)收測試用戶場景用戶/業(yè)務(wù)代表需求偏差、體驗(yàn)問題系統(tǒng)測試通過、缺陷收斂2. 按測試執(zhí)行方式分類手動與自動的節(jié)奏感按執(zhí)行方式來劃分測試可以分為手動測試和自動化測試。而在具體執(zhí)行模式上又區(qū)分出冒煙測試、回歸測試、探索性測試、全量回歸、老化測試等。這里最典型的問題是團(tuán)隊(duì)對要不要自動化的判斷經(jīng)常走極端要么什么都想自動化要么覺得自動化成本太高直接放棄。2.1 手動測試經(jīng)驗(yàn)和直覺的價值不可替代手動測試要做的核心工作是根據(jù)測試用例由測試人員一步步操作系統(tǒng)觀察實(shí)際結(jié)果是否與預(yù)期一致。它的優(yōu)勢在于靈活性和洞察力人類可以在操作過程中發(fā)現(xiàn)一些用例設(shè)計時沒有預(yù)想到的異常比如一個按鈕的位置遮擋、某個文案在特定分辨率下?lián)Q行錯亂、操作節(jié)奏過快時的雙擊重復(fù)提交等。很多團(tuán)隊(duì)在推行自動化后輕視手動測試這是不理性的。探索性測試Exploratory Testing幾乎只能是手動完成的它要求測試人員在學(xué)習(xí)系統(tǒng)的同時設(shè)計測試并隨著對系統(tǒng)的理解加深動態(tài)調(diào)整測試思路。優(yōu)秀的探索性測試能發(fā)現(xiàn)大量自動化腳本無法覆蓋的深層次問題。我覺得比較健康的做法是把手動測試精力集中在三類場景上——新功能的初步驗(yàn)證、探索性測試、UI和UE層面的體驗(yàn)檢查。而穩(wěn)定的、重復(fù)執(zhí)行的、數(shù)據(jù)準(zhǔn)備復(fù)雜的場景交給自動化。2.2 自動化測試讓回歸變得可持續(xù)自動化測試的核心價值在于可重復(fù)執(zhí)行和可頻繁執(zhí)行這也是回歸測試能夠持續(xù)運(yùn)行的基石?；貧w測試的目的不是發(fā)現(xiàn)新bug而是確認(rèn)新代碼沒有破壞既有功能隱藏的問題通常是模塊間耦合引起的比如A模塊改了請求參數(shù)格式B模塊消費(fèi)時沒有兼容全鏈路回歸才能暴露。自動化測試分為很多層級UI自動化、接口自動化、單元測試自動化其中性價比排序通常是單元測試 接口自動化 UI自動化。原因是越靠近代碼底層執(zhí)行速度越快、穩(wěn)定性越高、維護(hù)成本越低。UI自動化腳本一旦前端DOM結(jié)構(gòu)變化頻繁維護(hù)成本會居高不下很多團(tuán)隊(duì)最終倉庫里躺著一堆偶爾能過、偶爾失敗的廢腳本。我在團(tuán)隊(duì)里推自動化的經(jīng)驗(yàn)是先量化ROI。比如一個核心交易流程手動回歸一次需要4個人天改成自動化后每次執(zhí)行只需30分鐘人力釋放出來做更有創(chuàng)造性的探索測試。用這個賬去說服管理層才容易獲得預(yù)算和排期支持。2.3 冒煙測試與探索性測試快和深的不同取向冒煙測試Smoke Test來源于硬件行業(yè)——硬件設(shè)備通電后冒煙就說明有問題軟件領(lǐng)域借用這個概念指代對系統(tǒng)主流程做最快速的驗(yàn)證。每個版本提測后測試人員第一件事就是跑冒煙測試如果主流程都走不通直接把版本打回給開發(fā)沒必要進(jìn)入完整測試流程。冒煙測試的用例設(shè)計要求非常精簡通常控制在20-40條但必須覆蓋核心業(yè)務(wù)鏈路。探索性測試不依賴固定用例更依賴測試人員的經(jīng)驗(yàn)和對業(yè)務(wù)的理解。Charter測試章程是探索性測試中一個常用的工具它給測試人員一個明確的方向范圍比如從新用戶注冊到首次完成訂單的完整流程然后在這個范圍內(nèi)自由探索記錄下發(fā)現(xiàn)的問題、覆蓋的區(qū)域和可疑的風(fēng)險點(diǎn)。這個方法在時間緊、文檔不全的場景下尤其管用。2.4 新節(jié)奏設(shè)備老化測試全自動執(zhí)行腳本設(shè)備老化測試全自動執(zhí)行腳本是研發(fā)測試圈最近討論較多的關(guān)鍵詞尤其在IoT、智能硬件、視頻監(jiān)控、自助終端等場景中設(shè)備老化測試Aging Test / Burn-in Test非常重要。它的目標(biāo)是通過長時間連續(xù)運(yùn)行來驗(yàn)證設(shè)備在高負(fù)載、持續(xù)工作條件下的穩(wěn)定性暴露出間歇性故障、內(nèi)存泄漏、過熱、性能下降等短期測試發(fā)現(xiàn)不了的問題。我前兩年參與過一個智能門禁設(shè)備的測試項(xiàng)目老化測試原本是純?nèi)斯し绞綔y試人員每天定時去重啟設(shè)備、錄像、查看運(yùn)行日志團(tuán)隊(duì)里輪流排班經(jīng)常出現(xiàn)凌晨設(shè)備掛了沒人發(fā)現(xiàn)的情況。后來我推動做了一套全自動執(zhí)行腳本結(jié)構(gòu)大致是這樣#!/bin/bash # 設(shè)備老化測試自動化入口腳本 # 功能循環(huán)執(zhí)行業(yè)務(wù)用例、記錄設(shè)備狀態(tài)、采集日志、異常告警 TOTAL_CYCLES2000 CURRENT_CYCLE1 DEVICE_IP192.168.1.100 RESULT_DIR/data/aging_test_result while [ $CURRENT_CYCLE -le $TOTAL_CYCLES ]; do echo [$(date %Y-%m-%d %H:%M:%S)] 開始第 ${CURRENT_CYCLE} 輪 # 1. 檢查設(shè)備在線狀態(tài) ping -c 3 $DEVICE_IP /dev/null 21 if [ $? -ne 0 ]; then echo 設(shè)備離線 | tee -a $RESULT_DIR/device_offline.log # 觸發(fā)告警飛書/釘釘機(jī)器人 curl -X POST -H Content-Type: application/json \ -d {msg:設(shè)備離線, 循環(huán)輪次: $CURRENT_CYCLE} \ https://open.feishu.cn/open-apis/bot/v2/hook/xxx exit 1 fi # 2. 通過自動化平臺執(zhí)行核心業(yè)務(wù)用例人臉識別、開鎖、記錄上報 python3 run_business_cases.py --device $DEVICE_IP --round $CURRENT_CYCLE # 3. 采集設(shè)備狀態(tài)指標(biāo)CPU、內(nèi)存、溫度、磁盤 python3 collect_metrics.py --device $DEVICE_IP --output $RESULT_DIR/metrics_$CURRENT_CYCLE.json # 4. 定期清理日志防止舊數(shù)據(jù)影響后續(xù)測試 if [ $((CURRENT_CYCLE % 100)) -eq 0 ]; then ./cleanup_logs.sh $DEVICE_IP fi CURRENT_CYCLE$((CURRENT_CYCLE 1)) sleep 5 done echo 老化測試完成共執(zhí)行 ${TOTAL_CYCLES} 輪這套腳本運(yùn)行起來后配合一個簡單的看板每輪的結(jié)果、設(shè)備狀態(tài)指標(biāo)、失敗截圖全部自動匯總測試人員每天早上只需要看一眼報告異常自動觸發(fā)告警推送。原來需要3個人輪班盯的事情變成了一套持續(xù)跑數(shù)周的無人值守任務(wù)。腳本里有一個細(xì)節(jié)值得注意每100輪清理一次設(shè)備端日志因?yàn)槿罩敬疟P寫滿會導(dǎo)致設(shè)備異常這種基礎(chǔ)設(shè)施型故障會干擾老化結(jié)果分析必須提前規(guī)避。自動化老化測試的收益非常明顯。首先7x24小時運(yùn)行大幅壓縮了老化測試的項(xiàng)目時長其次腳本保證了每輪操作的統(tǒng)一性和數(shù)據(jù)可追溯性人工執(zhí)行時不同人的節(jié)奏差異、疲勞導(dǎo)致的漏操作都不存在了最后異常檢測和告警可以把故障時間點(diǎn)精確到秒級結(jié)合日志分析很容易定位到具體是哪個功能模塊在什么條件下崩潰。3. 按測試組織方式分類人與職責(zé)怎么搭配按組織方式來劃分測試討論的是誰來負(fù)責(zé)測試、測試團(tuán)隊(duì)如何和開發(fā)團(tuán)隊(duì)協(xié)作的問題。這個維度的分類在實(shí)際公司里決定了測試人員的處境和工作方式比想象中重要得多。3.1 開發(fā)自測與獨(dú)立測試團(tuán)隊(duì)兩種典型模式開發(fā)自測開發(fā)者測試模式下開發(fā)人員不僅要寫代碼還要對自己負(fù)責(zé)的功能模塊進(jìn)行測試。這種模式在小團(tuán)隊(duì)或者敏捷開發(fā)的早期階段很常見優(yōu)點(diǎn)是反饋快、沒有交接成本缺點(diǎn)也很明顯開發(fā)對代碼有慣性盲區(qū)很難跳出實(shí)現(xiàn)邏輯去思考使用場景而且自己寫代碼自己測傾向于驗(yàn)證程序是這樣運(yùn)行的而不是驗(yàn)證用戶需要的功能是否被正確實(shí)現(xiàn)。所以我一直強(qiáng)調(diào)即便開發(fā)自測做得再好專業(yè)測試的獨(dú)立視角也必不可少。獨(dú)立測試團(tuán)隊(duì)模式下測試人員獨(dú)立于開發(fā)團(tuán)隊(duì)之外有專門的測試負(fù)責(zé)人和獨(dú)立的匯報線。這種設(shè)計的核心優(yōu)勢是獨(dú)立性——測試人員不對功能開發(fā)進(jìn)度負(fù)責(zé)可以更客觀地提出這個版本質(zhì)量不達(dá)標(biāo)不能發(fā)布。在涉及金融、醫(yī)療、安全等領(lǐng)域的項(xiàng)目里獨(dú)立的測試團(tuán)隊(duì)基本是不可或缺的因?yàn)橘|(zhì)量兜底責(zé)任必須有人背不能讓開發(fā)既當(dāng)運(yùn)動員又當(dāng)裁判。3.2 嵌入式測試與矩陣式協(xié)作嵌入式測試和獨(dú)立測試并不是非此即彼現(xiàn)在更多公司采用的是嵌入式或叫內(nèi)嵌式測試模式測試人員物理上和開發(fā)團(tuán)隊(duì)坐在同一樓層、同一個迭代中但專業(yè)匯報線仍然歸屬于QA部門。好處是溝通成本低測試能第一時間了解需求變更同時因?yàn)閰R報線不在開發(fā)負(fù)責(zé)人手里出了質(zhì)量問題時敢于說不。矩陣式協(xié)作則是在大型項(xiàng)目中測試人員同時向項(xiàng)目經(jīng)理橫向和測試經(jīng)理縱向匯報。橫向保證項(xiàng)目目標(biāo)的達(dá)成縱向保證測試能力和行業(yè)規(guī)范的一致性。這種模式下測試人員的職業(yè)發(fā)展路徑更清晰通過測試經(jīng)理這條線可以獲得專業(yè)技能的持續(xù)提升而不是只局限于某一個業(yè)務(wù)項(xiàng)目。3.3 外包測試與離岸測試成本與管控的平衡外包測試在很多大型企業(yè)里非常普遍尤其是版本迭代頻繁、基礎(chǔ)回歸工作量大的項(xiàng)目。外包測試人員主要負(fù)責(zé)執(zhí)行類的工作比如按照用例執(zhí)行測試、提交bug、做回歸驗(yàn)證。采用外包時最關(guān)鍵的是把核心測試設(shè)計留在內(nèi)部團(tuán)隊(duì)手里外包只做執(zhí)行。我之前見過一些項(xiàng)目把測試設(shè)計也交給外包結(jié)果用例質(zhì)量參差不齊覆蓋面有明顯漏洞上線就出嚴(yán)重事故這個教訓(xùn)值得記住。離岸測試Offshore Testing通常是指在不同地域、不同時區(qū)的團(tuán)隊(duì)來執(zhí)行測試常見于跨國項(xiàng)目。離岸測試的核心價值是接力——開發(fā)團(tuán)隊(duì)在A時區(qū)晚上下班B時區(qū)的測試團(tuán)隊(duì)正好開始工作開發(fā)提交的版本可以被近實(shí)時驗(yàn)證整體交付周期大幅縮短。但離岸協(xié)作的挑戰(zhàn)也很突出最重要的是信息同步機(jī)制文檔必須足夠詳盡、變更通知必須及時、缺陷描述必須清晰到不需要追問就能復(fù)現(xiàn)的程度。3.4 不同組織模式如何選沒有絕對最好的組織方式只有最適合當(dāng)前項(xiàng)目條件的。我覺得可以按下表做一個快速判斷項(xiàng)目特征推薦模式原因快速試錯、節(jié)奏短嵌入式測試溝通成本低迭代響應(yīng)快高風(fēng)險、強(qiáng)合規(guī)獨(dú)立測試團(tuán)隊(duì)質(zhì)量判斷獨(dú)立性有保障海量回歸、成熟產(chǎn)品外包內(nèi)部設(shè)計成本可控核心能力內(nèi)聚跨國協(xié)作、7x24交付離岸測試多時區(qū)接力交付提速小團(tuán)隊(duì)、早期項(xiàng)目開發(fā)自測測試review資源有限靈活優(yōu)先4. 按測試地域分類一個容易被忽視的維度測試地域這個維度在很多測試入門資料里講得很少但實(shí)際工作中特別重要直接關(guān)系到產(chǎn)品能否在不同市場、不同環(huán)境下正常運(yùn)轉(zhuǎn)。4.1 國際化測試與本地化測試國際化測試I18N Testing關(guān)注的是產(chǎn)品架構(gòu)層面能不能支持不同語言、不同地區(qū)、不同文化習(xí)慣。它驗(yàn)證的是系統(tǒng)基礎(chǔ)設(shè)施比如字符編碼是否支持各種語言文字、日期時間和數(shù)字格式是否可配置、界面布局是否會因?yàn)槲淖珠L度變化而錯亂、時區(qū)切換是否準(zhǔn)確等。國際化做得好的產(chǎn)品不需要為每個目標(biāo)市場單獨(dú)開發(fā)一套系統(tǒng)。本地化測試L10N Testing則是在國際化基礎(chǔ)上驗(yàn)證某個特定區(qū)域版本的翻譯質(zhì)量、文化適配、法律法規(guī)合規(guī)性。舉個具體例子一個電商App要進(jìn)入德語市場國際化測試要保證系統(tǒng)架構(gòu)可以顯示德語字符、按照德國當(dāng)?shù)貢r間顯示促銷倒計時、金額格式正確本地化測試則要驗(yàn)證德語翻譯是否地道以及產(chǎn)品條款中是否需要添加德國法律要求的特定信息比如14天無理由退貨提示。這里我想強(qiáng)調(diào)一個高頻翻車點(diǎn)日期格式。不同地區(qū)的日期書寫習(xí)慣差異很大2024/09/06和06/09/2024這種差異很容易被國內(nèi)團(tuán)隊(duì)忽略但在國際市場上日期歧義會直接導(dǎo)致用戶誤解訂單時間或活動截止時間。測試設(shè)計時日期一定要考慮到不同地域的默認(rèn)格式偏好。4.2 多地域部署與跨地域數(shù)據(jù)合規(guī)測試另一種地域理解是產(chǎn)品的部署地域。很多系統(tǒng)要在不同區(qū)域的機(jī)房獨(dú)立部署比如主數(shù)據(jù)中心在境內(nèi)、業(yè)務(wù)覆蓋多地區(qū)的場景。多地域部署就帶來多地域測試的需求驗(yàn)證不同地域的域名解析、網(wǎng)絡(luò)鏈路質(zhì)量、各地機(jī)房版本的同步情況、異地容災(zāi)切換的可靠性。跨地域數(shù)據(jù)合規(guī)是這幾年非常熱的話題。不同市場對數(shù)據(jù)出境、隱私保護(hù)的要求差異極大測試人員在產(chǎn)品設(shè)計階段就應(yīng)該參與評審明確哪些數(shù)據(jù)只允許存在特定區(qū)域的機(jī)房哪些日志不能采集或不能集中存儲數(shù)據(jù)傳輸通道必須具備哪些加密和審計能力。這些合規(guī)要求最終都要落到測試用例里驗(yàn)證。4.3 分布式團(tuán)隊(duì)的遠(yuǎn)程測試實(shí)踐還有一種常見形態(tài)是團(tuán)隊(duì)分散在不同城市甚至不同國家測試環(huán)境也分布在不同地域。這種條件下測試執(zhí)行最大的痛點(diǎn)是網(wǎng)絡(luò)延遲和環(huán)境差異。我見過一個分布式團(tuán)隊(duì)的測試項(xiàng)目測試人員在本地的筆記本電腦上能正常復(fù)現(xiàn)一個支付流程但在統(tǒng)一測試環(huán)境里就復(fù)現(xiàn)不了最后定位到是本地hosts、緩存代理、外部API的沙箱環(huán)境不同導(dǎo)致的。這提醒我們分布式協(xié)作必須統(tǒng)一測試環(huán)境標(biāo)準(zhǔn)并且通過容器化或者鏡像封裝的方式保證每個成員本地的執(zhí)行環(huán)境和統(tǒng)一測試環(huán)境一致?？绲赜蚍植际綔y試還有一個比較實(shí)用的技巧就是把自動化測試的調(diào)度器部署在離被測環(huán)境最近的機(jī)房。自動化腳本本身不重但腳本和被測系統(tǒng)之間的網(wǎng)絡(luò)延遲、帶寬消耗是實(shí)打?qū)嵉脑摷记蓪?zhí)行時間和穩(wěn)定性都有顯著改善。另外跨團(tuán)隊(duì)共享的測試報告應(yīng)該盡早用在線看板來集中管理避免各區(qū)域團(tuán)隊(duì)各自維護(hù)一份Excel最后版本都對不上。5. 測試分類落地的三個教訓(xùn)與一套速查辦法講完了四個維度最后分享幾個實(shí)操中總結(jié)的教訓(xùn)。第一個教訓(xùn)是分類維度一定要混用別只按一個維度排計劃。一個合理的測試計劃至少會同時回答四個問題測什么層級階段、用什么手段技術(shù)、由誰執(zhí)行組織、在什么環(huán)境測地域。比如由獨(dú)立測試團(tuán)隊(duì)在預(yù)發(fā)布環(huán)境對新版本的系統(tǒng)測試階段執(zhí)行自動化回歸測試這一個句子就包含四個維度的信息。只按階段排測試計劃忽略了執(zhí)行方式、組織歸屬和環(huán)境差異計劃往往不夠完整。第二個教訓(xùn)是不要為了自動化而自動化。我見過有團(tuán)隊(duì)花大力氣把一套操作頻率很低的配置類流程做成了UI自動化每月就跑一次腳本在線性增長。反而最該自動化的每日構(gòu)建驗(yàn)證、核心交易回歸卻一直靠手工。合理的優(yōu)先級是穩(wěn)定的核心業(yè)務(wù)鏈路 回歸頻率高的流程 數(shù)據(jù)準(zhǔn)備復(fù)雜的場景 低頻彈性的流程。自動化是投入要算投入產(chǎn)出的賬。第三個教訓(xùn)是地域和本地化測試要在項(xiàng)目早期啟動不要拖到臨近發(fā)布才做。本地化不只是把翻譯文本換掉那么簡單字符截斷、布局錯位、日期格式、貨幣符號、從右往左排版這些都是典型的本地化問題越晚發(fā)現(xiàn)局面越被動甚至需要UI層返工。順便給一套實(shí)際項(xiàng)目里快速落地的速查辦法。排測試計劃時可以按這四步走第一步明確當(dāng)前交付處在哪個階段把該階段的出口標(biāo)準(zhǔn)列出來第二步確定哪些用例需要自動化執(zhí)行、哪些必須手動探索把冒煙用例優(yōu)先固定下來第三步確認(rèn)測試人力組織方式誰是負(fù)責(zé)人、誰有發(fā)布否決權(quán)第四步梳理目標(biāo)上線地域的環(huán)境差異項(xiàng)把本地化、跨區(qū)域鏈路的專項(xiàng)用例設(shè)計進(jìn)去。這套辦法在我們團(tuán)隊(duì)一直用基本不會出現(xiàn)測試范圍漏項(xiàng)的問題。測試分類本質(zhì)上不是背概念而是幫助團(tuán)隊(duì)建立一種多視角檢查質(zhì)量的思維習(xí)慣。不同分類維度是一面一面鏡子每一面都能照出不同種類的隱患。希望通過這篇文章能讓正在搭建測試體系的團(tuán)隊(duì)少走一些彎路。如果你在項(xiàng)目里遇到過特別難歸類的測試問題歡迎在評論區(qū)聊聊踩坑的經(jīng)驗(yàn)總是越交流越值錢。