做測試的人估計都有過這種體驗一個回歸套件跑下來動輒一兩個小時界面用例走走停停接口用例一大半時間浪費在等待響應(yīng)上。眼看著CI流水線卡在測試這一環(huán)發(fā)版節(jié)奏被拖得死死的改個配置重跑一遍又是大半個上午。我自己剛帶自動化項目那會兒測試執(zhí)行時長甚至被老板單獨拉出來當(dāng)KPI盯過那種焦慮感相信不少同行都懂?！皟?yōu)化測試執(zhí)行速度”這件事聽起來像個專項治理工作實際上并不是單一手段就能解決的。它不是讓你把一個測試從30秒改成3秒那么簡單而是從用例設(shè)計、執(zhí)行策略、資源調(diào)度、環(huán)境數(shù)據(jù)到腳本實現(xiàn)的全鏈路提速。無論你是做Web自動化、App自動化、接口測試、硬件老化測試還是數(shù)據(jù)庫性能測試核心思路其實是相通的。這篇文章我會結(jié)合自己在自動化測試、硬件設(shè)備測試和數(shù)據(jù)庫慢查詢優(yōu)化幾個方向上的實操經(jīng)驗把提速的思路、方法、坑和排查手段一次性講清楚希望能給被測試速度困擾的人一些直接能用的參考。1. 先搞清楚測試到底慢在哪里很多人在優(yōu)化速度時容易犯一個錯誤上來就暴力加并發(fā)、換機器、上分布式,結(jié)果速度沒提多少測試穩(wěn)定性反而崩了。優(yōu)化之前最重要的一件事是先把測試執(zhí)行的耗時結(jié)構(gòu)摸清楚知道時間到底花在了哪兒。1.1 六大核心瓶頸分類我習(xí)慣把測試執(zhí)行慢的原因分為六類大多數(shù)項目都逃不出這幾個范疇用例冗余與重復(fù)執(zhí)行回歸集里塞了大量已經(jīng)覆蓋過或邏輯重復(fù)的用例明明改了個登錄頁的文案卻要跑全量的下單支付流程。串行執(zhí)行方式默認一條路走到黑一個用例跑完才跑下一個完全沒利用多核CPU的并行能力。等待時間浪費代碼里頻繁使用固定sleep界面元素還沒出來就等5秒響應(yīng)只要1秒就白白浪費了4秒。這是UI自動化最典型的時間黑洞。環(huán)境與數(shù)據(jù)準備成本每個用例都要重新造數(shù)據(jù)、重啟服務(wù)、重置狀態(tài)前置時間比用例本身還長。外部依賴延遲接口響應(yīng)慢、數(shù)據(jù)庫查詢慢、第三方服務(wù)不穩(wěn)定導(dǎo)致測試跟著被拖慢。硬件與資源瓶頸跑測試的機器CPU、內(nèi)存、磁盤IO不足多個任務(wù)搶資源整體運行效率下降。1.2 先測量再動手給每段執(zhí)行時間做畫像加日志是第一步。無論用什么測試框架都要確保每一條用例、每一個關(guān)鍵步驟有耗時記錄。以Python的pytest為例可以通過pytest-timeout設(shè)置用例超時時間通過pytest-html或allure報告查看用例級耗時。我常用的一種方式是寫一個簡單的conftest.py鉤子函數(shù)在用例執(zhí)行前后記錄時間戳并把結(jié)果輸出到一個結(jié)構(gòu)化日志文件里# conftest.py import time import json import os def pytest_runtest_makereport(item, call): ...更簡單直接的做法是直接在CI腳本里對測試命令包一層time比如time pytest tests/ -v --tbshort --quiet跑完之后把生成的allure報告按用例耗時排序一眼就能看出哪些是“重量級”用例。我習(xí)慣把用例耗時大于等于10秒的單獨標記出來逐條分析慢在哪里。你會發(fā)現(xiàn)真正拖垮整個測試套件的往往就是那20%的耗時大戶。1.3 用數(shù)據(jù)定優(yōu)先級別信感覺拿到耗時分布后不要忙著優(yōu)化所有問題而是按“總耗時貢獻度”排序。一個用例跑5分鐘但只在冒煙測試里出現(xiàn)一次優(yōu)先級反而不如一個跑3秒但每日回歸出現(xiàn)500次的用例。具體統(tǒng)計方式就是總耗時貢獻度 單用例耗時 × 日均執(zhí)行次數(shù)。優(yōu)化時優(yōu)先處理貢獻度最高的幾項。我自己遇到過最典型的案例一個月度回歸套件里光是等待某個外部接口返回就占了總時長的60%把那段等待優(yōu)化掉之后整體時長直接砍半。這類比對了分析數(shù)據(jù)你會發(fā)現(xiàn)優(yōu)化的方向清晰很多而不是拿著感覺去亂改。2. 并行化改造提升速度的最大杠桿如果只能選一個優(yōu)化手段我強烈推薦并行執(zhí)行。大多數(shù)項目的測試速度瓶頸不是單條用例跑得慢而是用例之間串行排隊白白浪費了CPU多核能力。并行化改造是當(dāng)前收益最大、見效最快的方向。2.1 并行粒度怎么選進程、線程、容器還是分布式并行不是只有一種玩法不同場景適合不同粒度線程級并發(fā)適合IO密集型的接口測試。多個請求并發(fā)發(fā)出彼此不搶CPU用ThreadPoolExecutor或pytest-parallel就能簡單實現(xiàn)。進程級并行適合UI自動化等重計算場景。每個進程跑獨立的瀏覽器實例是pytest-xdist的典型用法。容器級并行每條用例或每個用例組跑在獨立容器里隔離性最好適合需要復(fù)雜環(huán)境依賴的執(zhí)行。分布式執(zhí)行適合超大規(guī)模用例集通過Selenium Grid、K8s Job等把用例分發(fā)到多臺機器上執(zhí)行。以接口測試為例如果只是單純發(fā)HTTP請求線程并發(fā)就夠了不需要上進程。但如果是UI自動化瀏覽器本身是個吃資源的程序線程并發(fā)還容易互相串狀態(tài)進程級并行更穩(wěn)妥。2.2 隔離才是并行的前提端口、數(shù)據(jù)、資源全隔離并行化最怕的不是慢而是用例之間的相互干擾。我踩過一個很深的坑剛開始并行跑UI自動化10個進程同時啟動結(jié)果有6個失敗原因全是端口沖突——Chrome的調(diào)試端口只有一個多個進程搶同一個端口自然崩。模塊化隔離要做三件事端口隔離每個測試進程分配獨立的服務(wù)端口、瀏覽器調(diào)試端口避免沖突。數(shù)據(jù)隔離每個并行任務(wù)使用獨立的測試賬號、獨立的數(shù)據(jù)庫記錄前綴避免數(shù)據(jù)互相覆蓋。資源隔離CI Runner上分配獨立的臨時目錄、獨立的輸出文件路徑避免文件寫入競爭。以pytest-xdist為例可以通過--distloadfile分配粒度讓同一個文件里的用例串行執(zhí)行、不同文件的用例并行執(zhí)行從根源上減少同一數(shù)據(jù)的競爭pytest tests/ -n 4 --distloadfile2.3 用 pytest-xdist 快速落地UI自動化并行如果你的自動化框架是Python Selenium或Appium用pytest-xdist是最快的并行方案。安裝后直接在運行命令里加上并行數(shù)即可pip install pytest-xdist pytest tests/ -n 4需要注意的是UI自動化并行并不是簡單加參數(shù)就完事。要讓用例真正并行得穩(wěn)還需要配合前面說的隔離策略。我常用的做法是在每個測試進程里定義一個獨立的瀏覽器實例并把下載目錄、用戶數(shù)據(jù)目錄都設(shè)置成進程獨立的臨時路徑# conftest.py import os import tempfile def get_driver(browser_typechrome): profile_dir tempfile.mkdtemp(prefixfchrome_profile_{os.getpid()}_) options.add_argument(f--user-data-dir{profile_dir}) ...這樣每個進程有獨立的瀏覽器配置不會互相打架。實際項目中我用4進程并行把一套原本45分鐘跑完的UI回歸用例壓縮到了12分鐘左右速度提升是肉眼可見的。2.4 并行數(shù)不是越大越好算一個合理的并發(fā)數(shù)并行數(shù)不是拍腦袋定的也不是越多越好。并發(fā)數(shù)過高會導(dǎo)致資源耗盡反而拖慢整體速度甚至引發(fā)大量隨機失敗。我習(xí)慣用一個簡單公式估算初始并發(fā)數(shù)并發(fā)數(shù) CPU核心數(shù) × (1 等待時間占比)如果一條用例的執(zhí)行時間里有70%在等待IO那并發(fā)數(shù)可以放得偏高比如CPU核心數(shù)的2到3倍如果是純計算型用例并發(fā)數(shù)控制在CPU核心數(shù)附近就夠了。跑完一輪后觀察各并發(fā)下的總耗時曲線找到拐點。當(dāng)并發(fā)從4升到8時總耗時明顯下降但8升到16時總耗時基本不變甚至變慢說明資源已經(jīng)飽和這個并發(fā)數(shù)就是當(dāng)前硬件條件下的上限了。3. 用例瘦身與精準回歸砍掉無效執(zhí)行時間并行化解決的是“同時跑多個”的問題用例自身的冗余和低效則是另一個大頭。很多測試套件之所以慢是因為里面混了大量沒必要在每次回歸中都執(zhí)行的用例。給用例做瘦身不僅能提速還能讓測試結(jié)果更可信。3.1 用例依賴別讓等待鏈條吃掉時間有些用例之間存在隱式依賴比如必須先登錄才能下單、必須先創(chuàng)建訂單才能查詢訂單。如果這種依賴是通過在用例里重新執(zhí)行前置步驟來實現(xiàn)的那每一條用例都在重復(fù)造輪子整體速度自然上不去。我處理依賴的思路是把通用的前置操作抽成Fixture或公共方法在會話級只執(zhí)行一次后面的用例全部復(fù)用結(jié)果。比如登錄操作只要Cookie沒失效完全可以讓整個測試會話共用一次登錄而不是每條用例都重新走一遍登錄接口。以pytest為例可以在conftest.py里定義一個session級別的fixture# conftest.py import pytest pytest.fixture(scopesession) def auth_token(): # 只執(zhí)行一次后續(xù)所有用例共用 token login_and_get_token() return token這樣把登錄從每條用例執(zhí)行改成整個會話執(zhí)行一次幾百條用例的耗時就能省下不少。3.2 基于代碼變更的增量回歸把全量回歸套件拆分成“必跑核心集”和“增量可選集”是很多團隊的常見實踐。每次代碼變更后只運行與變更相關(guān)的用例而不是無腦全量跑。實際項目中我會在CI配置里增加一個參數(shù)傳入本次變更涉及的模塊名自動篩選對應(yīng)模塊的測試文件pytest tests/ -k login or order or payment --tbshort更精細的做法是通過覆蓋率工具來分析代碼變更影響了哪些函數(shù)、哪些測試用例覆蓋了這些函數(shù)生成最小回歸集。雖然搭建這套機制需要一些成本但一旦建好每次提交的運行時間能從1小時降到5分鐘以內(nèi)非常值得投入。3.3 冒煙優(yōu)先分層跑測試測試用例按時間成本分層是保證快速反饋的最好方式L0冒煙集5分鐘內(nèi)跑完提交代碼后必跑只驗證核心鏈路是否通。L1核心回歸集20到30分鐘跑完合入主干前跑覆蓋所有關(guān)鍵業(yè)務(wù)流程。L2全量回歸集1小時以上每天定時跑一次或發(fā)版前跑覆蓋所有邊界和組合場景。這種做法能讓開發(fā)在提交代碼后快速得到反饋而不是等1小時才發(fā)現(xiàn)一塊核心功能被破壞。我自己在項目里把L0冒煙集精簡到12條用例覆蓋登錄、首頁、核心列表、關(guān)鍵流程閉環(huán)跑完大概4分鐘效率非常高。3.4 單個用例內(nèi)部的提速細節(jié)輪詢、超時、替代UI單條用例的執(zhí)行時間也是值得優(yōu)化的。UI自動化最經(jīng)典的優(yōu)化點有三個禁止裸sleep所有固定等待改成顯式等待等條件滿足就繼續(xù)。Selenium的WebDriverWait配合expected_conditions是最基礎(chǔ)也最有效的優(yōu)化from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit)) ).click()設(shè)置合理超時接口請求的超時時間要按實際響應(yīng)時間動態(tài)調(diào)整而不是一個固定的60秒兜底。合理的策略是設(shè)一個初始超時值失敗后按指數(shù)退避重試最多重試兩到三次而不是傻等。接口替代UI凡是接口能完成的操作就不要走UI。創(chuàng)建一個訂單的操作如果接口可以直接創(chuàng)建何必非要在頁面上一步步點數(shù)據(jù)準備階段走接口流程驗證階段才走UI兩條路結(jié)合速度能提升好幾倍。4. 環(huán)境與數(shù)據(jù)把前置時間從分鐘壓到秒級不少測試套件慢不是因為用例本身復(fù)雜而是前置條件準備耗時太長。每次跑測試前花幾分鐘初始化環(huán)境、構(gòu)建測試數(shù)據(jù)、重置設(shè)備狀態(tài)這種成本在單次執(zhí)行里看起來不算什么但頻率一高累積起來非常嚇人。4.1 環(huán)境預(yù)啟動與復(fù)用策略我曾經(jīng)在一個項目里每個測試進程啟動時都會重新拉起一整套服務(wù)啟動耗時將近2分鐘。后來改成環(huán)境預(yù)啟動在測試執(zhí)行前的setup階段統(tǒng)一拉起服務(wù)執(zhí)行結(jié)束后統(tǒng)一銷毀而不是每條用例重復(fù)啟停。對Docker化部署的測試環(huán)境預(yù)啟動的思路也非常有效。提前用docker-compose up -d把依賴服務(wù)全部拉起測試用例直接連接這些公共環(huán)境即可。省去每次重復(fù)初始化的時間尤其適合頻繁跑的回歸測試。另一種做法是把固定環(huán)境常駐。比如數(shù)據(jù)庫、Redis、消息隊列這些組件本身不需要每次測試都重建可以常駐測試環(huán)境只在需要驗證數(shù)據(jù)遷移或環(huán)境兼容性的場景下才重建。4.2 測試數(shù)據(jù)工廠與快照恢復(fù)在自動化測試里數(shù)據(jù)準備是最容易被低估的耗時項。每條用例都通過UI或者接口一步步創(chuàng)建數(shù)據(jù)慢且不穩(wěn)定更快的方案是在測試前直接用SQL或API在數(shù)據(jù)庫里插入數(shù)據(jù)用完后清理或恢復(fù)快照。我常用的數(shù)據(jù)層優(yōu)化方案用數(shù)據(jù)庫快照恢復(fù)執(zhí)行前打一個快照測試結(jié)束后恢復(fù)快照整個過程秒級完成。對于數(shù)據(jù)一致性要求高的場景這一步能省掉大量繁瑣的清理邏輯。用工廠函數(shù)批量造數(shù)據(jù)寫一個create_orders(n)的方法直接批量插入n條訂單數(shù)據(jù)相比逐條走創(chuàng)建接口速度提升是數(shù)量級的。以MySQL為例快速恢復(fù)數(shù)據(jù)可以用直接執(zhí)行SQL的方式插入但量級大的場景建議用更高效率的方式比如批量插入比逐條插入快很多。4.3 硬件資源優(yōu)化CPU、GPU、內(nèi)存、磁盤測試機本身的硬件配置也是執(zhí)行速度的重要變量。很多自動化項目跑得慢只是因為開發(fā)機或CI Runner的資源配置太低。幾個常見的硬件優(yōu)化方向CPU并行化之后多核CPU的價值會直接體現(xiàn)。盡量給CI Runner配備更多核心這是性價比最高的提速方式。內(nèi)存UI自動化跑多個瀏覽器實例每個瀏覽器占幾百MB內(nèi)存。內(nèi)存不足時系統(tǒng)會頻繁使用交換分區(qū)速度驟降。給Runner加到16GB或32GB內(nèi)存可以明顯緩解。磁盤測試過程會大量讀寫臨時文件、日志、截圖。機械硬盤和SSD的速度差距是數(shù)量級的優(yōu)先使用SSD最好是NVMe接口。GPU如果你的測試涉及圖像識別、3D渲染、目標檢測等場景GPU資源的分配就很關(guān)鍵。多GPU并行測試時要確保不同進程綁定不同的GPU否則會出現(xiàn)顯存競爭。在Linux環(huán)境下查看GPU狀態(tài)可以用nvidia-smi多GPU并行時通過環(huán)境變量或代碼指定每個進程使用的GPU設(shè)備編號避免沖突。4.4 日志與網(wǎng)絡(luò)開銷控制日志是隱藏的時間殺手。我見過一個項目測試用例里打了大量冗余的debug日志每個請求都打印完整的請求體用例數(shù)量一多光日志寫磁盤就占用了大量IO時間。優(yōu)化策略很簡單默認只保留info級別以上的日志需要排查問題時再臨時開啟debug。截圖也是同樣的思路只在失敗時截圖而不是每個步驟都截圖。日志輪轉(zhuǎn)也建議配置好避免長時間跑批把磁盤寫滿。網(wǎng)絡(luò)開銷方面核心思路是減少不必要的網(wǎng)絡(luò)交互。比如重復(fù)請求同一個接口可以考慮在會話內(nèi)做簡單的緩存大量小文件圖片上傳下載的場景可以合并成批量接口能用內(nèi)網(wǎng)地址訪問的測試環(huán)境不要通過外網(wǎng)域名訪問能明顯降低延遲。5. 三類典型測試提速實戰(zhàn)聊完通用方法論我拿三個真實場景做一次完整的實戰(zhàn)拆解。這三個場景分別對應(yīng)Web/App自動化、硬件設(shè)備老化測試、數(shù)據(jù)庫慢SQL優(yōu)化覆蓋面比較廣你可以對應(yīng)自己的業(yè)務(wù)去套用。5.1 Web/App自動化從45分鐘到9分鐘這是我自己做過的一個電商平臺Web自動化項目。優(yōu)化前整套回歸套件跑完需要45分鐘左右300多條用例串行執(zhí)行大量使用固定sleep測試數(shù)據(jù)也沒有隔離方案。優(yōu)化動作拆解替換所有固定sleep為顯式等待預(yù)計節(jié)約30%時間。引入pytest-xdist并行執(zhí)行4進程并發(fā)。把登錄操作改成session級fixture共享登錄態(tài)。添加測試數(shù)據(jù)工廠在數(shù)據(jù)庫中直接造訂單數(shù)據(jù)。失敗重試機制從每條用例重跑改成只重跑失敗用例。優(yōu)化效果是同一套300多條用例從45分鐘壓縮到9分鐘左右穩(wěn)定性不降反升隨機失敗率從10%降到了2%以下。關(guān)鍵心得并行化和等待優(yōu)化帶來的收益最大單靠這兩項就能省下50%以上的時間數(shù)據(jù)工廠的改造則讓用例之間的獨立性變強了為并行化提供了前提。5.2 設(shè)備老化測試全自動執(zhí)行腳本優(yōu)化硬件設(shè)備老化測試是另一種場景。設(shè)備需要連續(xù)運行幾小時甚至幾天反復(fù)執(zhí)行同一套操作觀察是否有死機、卡頓、重啟等問題。這類測試的時間瓶頸主要在于循環(huán)次數(shù)多、單次操作間隔長、日志量大。以嵌入式設(shè)備為例優(yōu)化前的老化腳本長這樣while true; do do_some_operation sleep 30 check_status echo $(date) operation done test.log done這種每秒都在寫日志、sleep時間固定的方式既浪費等待時間也會讓日志文件迅速膨脹最終拖慢整個系統(tǒng)。優(yōu)化思路把固定sleep改成條件等待比如等待某個進程運行結(jié)束或者某個端口返回預(yù)期結(jié)果。日志分級正常流程只記錄狀態(tài)變化和異常點不再每次操作都寫重復(fù)日志。檢查設(shè)備心跳的間隔時間按需調(diào)整不一定每次操作后都做全量檢查可以每隔N次做一次深度檢查。優(yōu)化后同樣的老化測試在相同時間內(nèi)能執(zhí)行更多輪次的循環(huán)覆蓋更充分日志體積從幾個GB降到了幾百MB。注意老化測試的核心是穩(wěn)定性覆蓋不能為了速度盲目壓縮操作之間的等待時間導(dǎo)致設(shè)備狀態(tài)未穩(wěn)定就進入下一步反而掩蓋了問題。等待時間的設(shè)置需要結(jié)合設(shè)備實際響應(yīng)時間來確定。5.3 慢SQL與數(shù)據(jù)庫測試優(yōu)化測試里如果涉及大量的數(shù)據(jù)庫查詢慢SQL會成為瓶頸。比如性能測試前需要準備幾萬條數(shù)據(jù)或者查詢腳本本身寫得低效跑一條用例要等幾秒甚至幾十秒。慢SQL的優(yōu)化原則我總結(jié)為三步先用EXPLAIN看執(zhí)行計劃確認查詢走了哪些索引、掃描了多少行。針對掃描行數(shù)過大的查詢加合適的索引對JOIN過多的查詢考慮拆分成多次查詢或優(yōu)化表結(jié)構(gòu)。對確實無法避免的大范圍查詢考慮引入緩存如Redis或預(yù)聚合表。以一條典型的訂單查詢?yōu)槔齋ELECT * FROM orders WHERE user_id 123 AND status PAID;如果user_id上沒有索引這條查詢會掃全表數(shù)據(jù)量一大就非常慢。優(yōu)化后建立聯(lián)合索引CREATE INDEX idx_user_status ON orders(user_id, status);單條查詢的時間往往能降一個數(shù)量級以上。在數(shù)據(jù)庫測試場景中另一個常見優(yōu)化點是連接復(fù)用。使用數(shù)據(jù)庫連接池避免每次查詢都新建連接、關(guān)閉連接。連接建立的開銷雖然不大但測試用例數(shù)量一多節(jié)省下來的時間就比較可觀了。6. 常見問題與排查技巧實錄優(yōu)化測試執(zhí)行速度的過程中一定會遇到各種意外狀況。我把最常見的幾個問題和對應(yīng)的排查思路整理出來供你對照參考。6.1 并行之后失敗率上升怎么辦這是并行化改造中最常遇到的問題。原本串行跑得好好的一并行就到處出問題常見的根因有三個共享數(shù)據(jù)沖突不同進程同時讀寫同一張表、同一個文件或同一個賬號數(shù)據(jù)。解決方法是給每個進程分配獨立的數(shù)據(jù)前綴或獨立的測試賬號。資源競爭耗盡并發(fā)數(shù)超過機器承受能力導(dǎo)致超時。解決方法是降低并發(fā)數(shù)先跑一輪觀察資源占用。單例資源重復(fù)初始化每個進程都試圖啟動同一個服務(wù)或占用同一個端口。解決方法是把共享服務(wù)的啟動放到所有并行進程的宿主機上而不是放在進程內(nèi)。排查時我習(xí)慣先看失敗用例的報錯信息判斷是資源沖突類還是超時類。如果是超時類優(yōu)先懷疑資源耗盡如果是斷言失敗或狀態(tài)錯亂大概率是數(shù)據(jù)隔離沒做好。6.2 等待時間優(yōu)化了還是慢問題出在哪很多人在把固定sleep改成顯式等待之后發(fā)現(xiàn)速度提升有限。這種情況通常意味著等待不是瓶頸而是被測系統(tǒng)本身的響應(yīng)就慢。此時要去查兩個方向被測服務(wù)端的性能比如接口響應(yīng)時間本身就要2秒測試端再優(yōu)化也無法突破這個底線。這時候要區(qū)分是測試腳本慢還是被測系統(tǒng)慢可以用日志或抓包確認。測試前置操作太慢比如每條用例啟動一個瀏覽器、重建一個用戶這些固定成本沒有優(yōu)化等待條件優(yōu)化得再好也沒用。建議在用例里給每個關(guān)鍵步驟打點計時把時間拆開看是步驟A慢還是步驟B慢而不是籠統(tǒng)地靠感覺判斷。6.3 偶發(fā)超時的隨機失敗排查偶發(fā)超時是最讓人頭疼的問題。用例單獨跑沒問題套件一起跑就隨機超時這次跑過了下次又掛了。排查思路按順序來先看是不是資源競爭CPU、內(nèi)存、網(wǎng)絡(luò)帶寬是否在某一段時間內(nèi)被別的任務(wù)占滿。在CI機器上可以用htop或top命令實時觀察。再看外部依賴的穩(wěn)定性比如測試環(huán)境里依賴的第三方服務(wù)不穩(wěn)定偶發(fā)變慢。可以在測試腳本里記錄請求耗時找出超時分布規(guī)律。最后檢查用例自身是否存在前一條用例的狀態(tài)殘留影響后一條用例導(dǎo)致偶發(fā)狀態(tài)不對。我的經(jīng)驗是偶發(fā)超時大多和資源競爭有關(guān)而不是用例本身寫錯。給關(guān)鍵用例加上適當(dāng)?shù)某瑫r重試機制可以在不影響速度的前提下提升穩(wěn)定性。6.4 常用排查命令與工具最后分享幾個我日常排查性能問題時必用的命令和工具工具/命令用途top / htop查看CPU、內(nèi)存實時占用排查資源瓶頸iotop查看磁盤IO占用排查日志寫入導(dǎo)致的IO瓶頸nvidia-smi查看多GPU占用情況確認GPU任務(wù)分配是否合理EXPLAINSQL查看SQL執(zhí)行計劃定位慢查詢原因pytest --durations5輸出耗時最長的5條用例快速定位耗時大戶pytest-timeout設(shè)置用例超時時間避免單條用例卡死拖垮整個套件allure報告按用例耗時、歷史趨勢分析整體執(zhí)行時間perf / py-spy對Python腳本進行性能剖析定位CPU密集函數(shù)這些工具不復(fù)雜但在排查速度問題時非常管用。優(yōu)化測試執(zhí)行速度本質(zhì)上是一個持續(xù)的循環(huán)量化、定位、優(yōu)化、驗證、復(fù)盤。每輪優(yōu)化完把耗時數(shù)據(jù)保存下來對比下一輪的優(yōu)化效果你會發(fā)現(xiàn)做得越久對系統(tǒng)的瓶頸理解越深后續(xù)優(yōu)化的判斷也會越來越準。我在實際項目中最大的體會是測試執(zhí)行速度優(yōu)化不是一次性的技術(shù)攻堅而是一個持續(xù)嵌入日常開發(fā)節(jié)奏的習(xí)慣。先量化再動手不靠感覺做優(yōu)化把這個流程跑順你的測試套件會越來越快CI流水線也會穩(wěn)定很多。希望這篇文章里整理的經(jīng)驗和踩坑記錄能幫你少走一些彎路。