pytest 的鉤子函數(shù)體系絕大多數(shù)測(cè)試開(kāi)發(fā)都用過(guò) pytest_runtest_logreport、pytest_terminal_summary 這類執(zhí)行期鉤子做用例統(tǒng)計(jì)、JUnit 報(bào)告、失敗重跑。但如果你要的數(shù)據(jù)是「這次到底收集到了哪些測(cè)試用例、命中哪些用例、參數(shù)化展開(kāi)后一共多少條」也就是在用例真正開(kāi)始跑之前就要拿到一份完整的命中清單執(zhí)行期鉤子就有點(diǎn)繞了跑完一條統(tǒng)計(jì)一條還得自己維護(hù)狀態(tài)被跳過(guò)和 setUp 階段失敗的用例還得小心別漏。這個(gè)需求的最佳切入點(diǎn)其實(shí)是 pytest_collection_finish。簡(jiǎn)單說(shuō)pytest_collection_finish 是 pytest 在「收集階段全部結(jié)束、執(zhí)行階段正式開(kāi)始之前」觸發(fā)的一個(gè)鉤子。你在這個(gè)鉤子里拿到的 session.items就是這一輪 pytest 命中所有篩選條件之后、即將執(zhí)行的完整用例集合。做測(cè)試平臺(tái)上報(bào)、精準(zhǔn)回歸范圍確認(rèn)、用例資產(chǎn)盤點(diǎn)、命中率分析用這個(gè)鉤子比在終端解析那行 “collected 123 items” 或統(tǒng)計(jì)執(zhí)行報(bào)告干凈得多。這篇我直接分享自己用這個(gè)鉤子的完整思路和踩坑記錄適合三類人正在寫內(nèi)部測(cè)試平臺(tái)、需要用例級(jí)清單上報(bào)的想統(tǒng)計(jì)參數(shù)化展開(kāi)后實(shí)際用例量、按標(biāo)記/文件/類維度做大盤的以及對(duì) pytest 收集機(jī)制本身好奇、想搞明白 collection 階段到底發(fā)生了什么的人。1. 先搞清楚 pytest 的 Collection 階段到底給了我們什么很多同學(xué)寫 pytest 插件上來(lái)就找執(zhí)行期鉤子其實(shí) pytest 的生命周期里收集階段才是最該插手的時(shí)機(jī)。我先把這個(gè)階段講透后面你寫鉤子會(huì)順手很多。1.1 Collection一個(gè)大篩子把測(cè)試文件變成用例對(duì)象pytest 啟動(dòng)之后并不是直接跑用例而是先進(jìn)入 collection 階段。這個(gè)階段會(huì)從 rootdir 開(kāi)始沿著目錄一層層往下掃描匹配 test_*.py 或 *test.py 文件再在每個(gè)測(cè)試文件里匹配以 test開(kāi)頭的函數(shù)、TestXxx 類里的 test_ 方法以及 pytest.mark.parametrize 展開(kāi)出來(lái)的參數(shù)組合。每一個(gè)最終匹配到的單元會(huì)被包裝成一個(gè) Item 對(duì)象。你可以把 collection 理解成一個(gè)大篩子第一步篩出所有“看起來(lái)像測(cè)試”的節(jié)點(diǎn)第二步再做命令行篩選比如 -k 表達(dá)式、-m 標(biāo)記表達(dá)式、--ignore 忽略路徑第三步給參數(shù)化用例做笛卡爾積展開(kāi)。等這些步驟全部走完留下來(lái)的就是“命中”的用例集合。你想想看我們說(shuō)的“收集測(cè)試命中用例數(shù)據(jù)”本質(zhì)上就是把篩子輸出端拿到的那一摞清單完整記錄下來(lái)。這里有個(gè)容易忽略的點(diǎn)參數(shù)化是在收集階段完成的。一個(gè)測(cè)試函數(shù)只要寫了 pytest.mark.parametrize 傳了 5 組參數(shù)收集之后就變成 5 條獨(dú)立的 itemnodeid 長(zhǎng)得不一樣執(zhí)行時(shí)也按 5 條獨(dú)立用例算。所以你在終端看到 “collected 120 items”往往是你寫代碼時(shí)數(shù)的 20 個(gè)測(cè)試函數(shù)被參數(shù)化一展開(kāi)就成了 120。這種數(shù)據(jù)只有收集階段才能準(zhǔn)確拿到跑到執(zhí)行期再數(shù)就得累死。1.2 收集鉤子全家桶三個(gè)鉤子怎么分工pytest 在收集階段暴露了不止一個(gè)鉤子想清楚分工才不會(huì)用錯(cuò)。我整理成表鉤子觸發(fā)粒度典型用途pytest_collectstart每個(gè) collector目錄/文件/類開(kāi)始收集時(shí)做收集進(jìn)度條、日志pytest_itemcollected每個(gè) item 成功生成時(shí)對(duì)單個(gè)用例打點(diǎn)、計(jì)數(shù)pytest_collection_modifyitems(session, config, items)全部 item 收集完畢、篩選完成后對(duì) items 列表做增刪改排序選擇/排序插件的地盤pytest_collection_finish(session)collection 完全收尾、執(zhí)行前讀取最終 items做大盤統(tǒng)計(jì)、上報(bào)、落地pytest_collectstart 和 pytest_itemcollected 是“過(guò)程性”鉤子粒度太碎。pytest_collection_modifyitems 和 pytest_collection_finish 是“結(jié)果性”鉤子都在收集結(jié)束后觸發(fā)差別在于順序modifyitems 在前finish 在后。換句話說(shuō)modifyitems 階段其他插件還可能對(duì)你手里的 items 動(dòng)手比如 pytest-randomly 在這里亂序比如你想在這里按優(yōu)先級(jí)篩掉一批用例到了 finish 階段集合已經(jīng)定了不適合再改只適合讀。1.3 為什么放棄執(zhí)行期鉤子選擇 collection 階段拿數(shù)據(jù)我最早做用例統(tǒng)計(jì)用的也是 pytest_runtest_logreport后來(lái)發(fā)現(xiàn)三個(gè)問(wèn)題第一執(zhí)行期鉤子只能拿到“已經(jīng)執(zhí)行出結(jié)果”的用例一個(gè)用例如果被 skipIf 跳過(guò)在 setup 階段就被攔截了你要統(tǒng)計(jì)“本輪全部命中用例”就怎么都數(shù)不全。第二收集階段能看到還沒(méi)開(kāi)始執(zhí)行的完整清單可以做預(yù)檢查——比如命中集為空、命中集和預(yù)期范圍不一致這在執(zhí)行前就該發(fā)現(xiàn)。第三執(zhí)行期數(shù)據(jù)往往帶著狀態(tài)passed、failed、error、skipped如果你只是想回答“這輪跑了哪些用例、一共多少、參數(shù)化規(guī)模多大”這樣的問(wèn)題這些狀態(tài)信息反而是噪音。所以我的經(jīng)驗(yàn)是凡是要“用例清單”的一律用 finish 鉤子凡是要“執(zhí)行結(jié)果”的才用執(zhí)行期鉤子。兩個(gè)切面的定位完全不同。2. 鉤子簽名與前置機(jī)制動(dòng)手前先讀懂這些細(xì)節(jié)光知道 finish 鉤子能拿到 session.items 還不夠簽名里藏著很多細(xì)節(jié)不看清楚寫出來(lái)的代碼脆弱得很。2.1 簽名與觸發(fā)時(shí)機(jī)順便理清 -k / -m 篩選的影響鉤子簽名非常簡(jiǎn)單def pytest_collection_finish(session: pytest.Session) - None: ...只有 session 一個(gè)參數(shù)。觸發(fā)時(shí)機(jī)是整個(gè)收集機(jī)制徹底結(jié)束后、pytest_runtestloop 開(kāi)始前。我用一句話記憶modifyitems 之后、執(zhí)行之前。這里有個(gè)很關(guān)鍵的語(yǔ)義觸發(fā)當(dāng)時(shí)session.items 已經(jīng)是經(jīng)過(guò)命令行篩選的最終命中集合。也就是說(shuō)你執(zhí)行 pytest -k test_login 時(shí)finish 鉤子里看到的 items 已經(jīng)只剩包含 test_login 的用例執(zhí)行 pytest -m p0 時(shí)items 已經(jīng)只剩帶 p0 標(biāo)記的用例。這不是壞事恰恰相反——「命中」二字本來(lái)就應(yīng)該是篩選后的結(jié)果。如果你想對(duì)比篩選前全量就另外用無(wú)篩選的 --collect-only 建立基線后面我會(huì)講這個(gè)做法。另一個(gè)容易被忽略的點(diǎn)即使你用了 -x失敗即停、-k 篩完一個(gè)不剩、或者收集階段出了一些非致命問(wèn)題這個(gè)鉤子照樣會(huì)觸發(fā)。所以這也是一個(gè)理想的“兜底檢查點(diǎn)”比如在這里判斷 len(session.items) 0直接打警告避免后面執(zhí)行階段空跑一趟才發(fā)現(xiàn)沒(méi)收集到用例。2.2 session.items 里每個(gè)元素都是什么session.items 是一個(gè)列表每個(gè)元素是 pytest.Item 的實(shí)例。你平時(shí)寫的測(cè)試函數(shù)收集之后最常見(jiàn)的類型是 pytest.Function但 pytest 也支持 doctest、自定義 collector所以代碼里別假設(shè)每個(gè) item 都有 module 或 cls。拿一個(gè)普通用例舉例item 身上這些屬性非常有用屬性說(shuō)明注意點(diǎn)nodeid唯一標(biāo)識(shí)如 test_demo.py::TestLogin::test_login_ok[case1]多級(jí)路徑 類 函數(shù) 參數(shù)name測(cè)試函數(shù)顯示名參數(shù)化時(shí)末尾可能帶 [參數(shù)id]originalname參數(shù)化前的原始函數(shù)名pytest 6.2 才有path / fspath文件路徑新版用 path舊版用 fspath最好做個(gè)兼容module所屬模塊對(duì)象doctest item 可能是 Nonecls所屬測(cè)試類模塊級(jí)函數(shù)沒(méi)有 clskeywords關(guān)鍵字字典包含類名、函數(shù)名、mark 名、參數(shù)名markers該 item 上的所有 mark可能包含自動(dòng)生成的 parametrize 標(biāo)記callspec參數(shù)化調(diào)用信息含 params 和 id沒(méi)有參數(shù)化的 item 沒(méi)有這個(gè)屬性location三元組 (文件路徑, 行號(hào), 名)定位用例很方便剛開(kāi)始用的時(shí)候我老想著把 item 整個(gè)丟進(jìn) JSON后來(lái)發(fā)現(xiàn) item 對(duì)象里包含大量不可序列化、還可能帶 fixture 實(shí)例的東西序列化幾乎必然翻車。正確姿勢(shì)是寫一個(gè)轉(zhuǎn)換函數(shù)只抽取你要的標(biāo)量字段。2.3 參數(shù)化用例的 nodeid 與 callspec 解析參數(shù)化用例的 nodeid 長(zhǎng)這樣tests/test_demo.py::TestCalc::test_add[a-b-1]nodeid 的本質(zhì)是用 :: 把模塊路徑、類名、測(cè)試函數(shù)名串聯(lián)起來(lái)末尾的 [a-b-1] 是參數(shù)組合標(biāo)識(shí)?？狱c(diǎn)在于參數(shù)內(nèi)容本身可能包含逗號(hào)、中文、甚至方括號(hào)你要是用 nodeid.rsplit([, 1) 暴力拆遇到參數(shù)值里帶左括號(hào)就炸了。我推薦用 callspec 來(lái)解析if hasattr(item, callspec): callspec item.callspec param_id getattr(callspec, id, ) params { k: repr(v) for k, v in getattr(callspec, params, {}).items() }callspec.id 是 pytest 根據(jù)參數(shù)值或你傳入的 ids 生成的參數(shù)組合標(biāo)識(shí)比你自己從 nodeid 里摳字符串靠譜得多。callspec.params 則是一個(gè) dictkey 是參數(shù)名value 是參數(shù)值。這里還要提個(gè)醒參數(shù)值可能是 fixture 實(shí)例、字典、甚至類對(duì)象直接扔進(jìn) JSON 必然報(bào)錯(cuò)所以上面代碼里我用了 repr()輸出到報(bào)告里至少還能看個(gè)大概。如果擔(dān)心參數(shù)里有密碼等敏感信息這里要么只保留 param_id要么在存儲(chǔ)前做脫敏。3. 實(shí)操把命中用例數(shù)據(jù)落地成可用數(shù)據(jù)理論鋪墊夠了下面直接上代碼。我會(huì)從一個(gè)最小 demo 開(kāi)始逐步擴(kuò)展到一個(gè)能直接用到生產(chǎn)環(huán)境的版本。3.1 最小實(shí)現(xiàn)先打印一份用例清單驗(yàn)證切面第一步在項(xiàng)目根目錄建一個(gè) conftest.py寫最簡(jiǎn)版本import pytest pytest.hookimpl(tryfirstTrue) def pytest_collection_finish(session): print(f\n[pytest_collection_finish] 共收集到 {len(session.items)} 條用例, flushTrue) for item in session.items: print( , item.nodeid, flushTrue)注意我加了 tryfirstTrue意思是如果還有其他插件也實(shí)現(xiàn)了這個(gè)鉤子我這個(gè)先跑。這里的意圖是盡快把命中清單打出來(lái)避免其他插件的耗時(shí)代碼拖慢輸出。跑一下pytest --collect-only -q如果 conftest.py 放對(duì)了位置你會(huì)在終端看到我們打印的用例清單。這一步驗(yàn)證完說(shuō)明鉤子本身已經(jīng)通了接下來(lái)所有邏輯都往這個(gè)函數(shù)里放。3.2 完整輸出把命中數(shù)據(jù)結(jié)構(gòu)化落地成 JSON打印到終端只適合臨時(shí)看真正做平臺(tái)上報(bào)、用例盤點(diǎn)得把數(shù)據(jù)落成結(jié)構(gòu)化文件。下面這個(gè)版本是我實(shí)際項(xiàng)目里改出來(lái)的可以直接抄import json from datetime import datetime from pathlib import Path import pytest def _safe_str(value): try: return str(value) except Exception: return unserializable def _item_to_dict(item): path str(getattr(item, path, None) or getattr(item, fspath, )) module getattr(item, module, None) d { nodeid: item.nodeid, name: getattr(item, originalname, item.name), path: path, module: getattr(module, __name__, None) if module else None, line: item.location[1] if getattr(item, location, None) else None, keywords: sorted(getattr(item, keywords, {}).keys()), markers: [m.name for m in item.iter_markers()], parametrized: hasattr(item, callspec), } if d[parametrized]: callspec item.callspec d[param_id] getattr(callspec, id, ) or d[params] { k: _safe_str(v) for k, v in getattr(callspec, params, {}).items() } return d pytest.hookimpl(tryfirstTrue) def pytest_collection_finish(session): payload { generated_at: datetime.now().isoformat(), command_args: list(getattr(session.config, args, [])), total: len(session.items), cases: [_item_to_dict(item) for item in session.items], } output_path Path(session.config.rootdir) / collection_report.json output_path.write_text( json.dumps(payload, ensure_asciiFalse, indent2), encodingutf-8, ) print( f[pytest_collection_finish] 已寫入 {output_path}共 {len(session.items)} 條命中用例, flushTrue, )這里有幾個(gè)細(xì)節(jié)值得說(shuō)ensure_asciiFalse 必須帶上否則 nodeid、參數(shù)里的中文全部變成 \uXXXX報(bào)告根本沒(méi)法看。path 屬性做了兼容新版本 pytest 用 item.path老版本用 item.fspath二選一寫死容易在升級(jí)后炸。item.location 三元組的第二項(xiàng)就是用例定義行號(hào)這個(gè)信息在排查用例命中錯(cuò)誤時(shí)極其好用。params 里用 _safe_str 包一層再奇怪的參數(shù)對(duì)象也不會(huì)讓 JSON 序列化崩潰。跑完之后 collection_report.json 會(huì)落在項(xiàng)目根目錄用 jq 或者隨便什么 JSON 工具都能查。這已經(jīng)能回答“這輪命中多少用例、每個(gè)用例在哪個(gè)文件哪一行、有沒(méi)有參數(shù)化”這類問(wèn)題了。3.3 做命中率與基線差異分析從“收集數(shù)據(jù)”到“分析數(shù)據(jù)”只有一份 JSON 還不夠很多時(shí)候我們想知道的是“命中率”。這個(gè)詞在精準(zhǔn)測(cè)試場(chǎng)景下非常常用假設(shè)整個(gè)產(chǎn)品全量用例庫(kù)有 5000 條這次回歸因?yàn)樾枨蠓秶拗浦辉撆芷渲械?800 條鉤子收集完一看實(shí)際命中了 750 條那命中率 93.75%剩下 50 條去哪了這就是精華所在。做法分兩步。第一步先不帶任何篩選執(zhí)行一次全量收集生成基線pytest --collect-only -q -p no:cacheprovider復(fù)用上面那個(gè)鉤子把 collection_report.json 的內(nèi)容當(dāng)作 baseline。接著我寫一個(gè)簡(jiǎn)化版的對(duì)比邏輯import json from pathlib import Path import pytest def _load_baseline(path: str collection_report.json) - dict: p Path(path) if not p.exists(): return {} return json.loads(p.read_text(encodingutf-8)) pytest.hookimpl(tryfirstTrue) def pytest_collection_finish(session): baseline _load_baseline() if not baseline: return baseline_ids {case[nodeid] for case in baseline.get(cases, [])} current_ids {item.nodeid for item in session.items} hit_ids current_ids baseline_ids new_ids current_ids - baseline_ids # 新增/不在基線里的用例 lost_ids baseline_ids - current_ids # 基線里有這輪沒(méi)命中的用例 hit_rate len(hit_ids) / len(baseline_ids) if baseline_ids else 0 print( f[命中分析] 基線 {len(baseline_ids)} 條本輪命中 {len(hit_ids)} 條 f命中率 {hit_rate:.2%}新增 {len(new_ids)} 條未命中 {len(lost_ids)} 條, flushTrue, )這個(gè)思路擴(kuò)展性很強(qiáng)。比如你想按優(yōu)先級(jí)分析就提前在全量基線里給每個(gè)用例打上 p0/p1/p2 標(biāo)記然后按標(biāo)記分別算命中率想按模塊分析就把 lost_ids 按文件路徑前綴分組直接定位漏測(cè)風(fēng)險(xiǎn)集中在哪里。我把這套邏輯接到內(nèi)部測(cè)試平臺(tái)之后最常用的其實(shí)不是總量命中率而是 p0 用例命中率——跑了一次回歸核心用例漏了一半平臺(tái)直接就飄紅比事后翻報(bào)告快多了。第 4 章我會(huì)展開(kāi)講幾個(gè)實(shí)戰(zhàn)場(chǎng)景先提醒一點(diǎn)基線文件本身會(huì)過(guò)期用例庫(kù)在持續(xù)變化建議每次發(fā)版前重新生成基線并且把基線生成動(dòng)作固化到 CI 流水線里別靠手敲命令。4. 進(jìn)階場(chǎng)景命中數(shù)據(jù)如何變成平臺(tái)能力數(shù)據(jù)弄到手之后怎么讓它真正產(chǎn)生價(jià)值我分享三個(gè)我實(shí)際做過(guò)的場(chǎng)景每個(gè)都對(duì)應(yīng)一種不同的業(yè)務(wù)訴求。4.1 場(chǎng)景一直接上報(bào)測(cè)試平臺(tái)實(shí)現(xiàn)用例清單回放內(nèi)部測(cè)試平臺(tái)往往有“測(cè)試記錄”功能想展示每條測(cè)試用例的執(zhí)行結(jié)果就得先知道這輪跑了哪些用例。很多人是在全部跑完后從 JUnit XML 里解析其實(shí)在 finish 鉤子里直接把命中清單上報(bào)給平臺(tái)平臺(tái)立刻就能生成一條“測(cè)試記錄”執(zhí)行結(jié)果跑完后再一輪 patch 上去整體體驗(yàn)會(huì)好很多。上報(bào)代碼也不復(fù)雜關(guān)鍵是要兜住異常import json import os import pytest def _report_to_platform(payload: dict): try: import requests api os.environ.get(TEST_PLATFORM_API, ) if not api: return resp requests.post(api, jsonpayload, timeout5) resp.raise_for_status() except Exception as exc: # noqa: BLE001 # 上報(bào)失敗絕不能影響 pytest 主流程 print(f[report] 上報(bào)失敗: {exc}, flushTrue) pytest.hookimpl(tryfirstTrue) def pytest_collection_finish(session): payload { run_id: os.environ.get(RUN_ID, local), total: len(session.items), case_ids: [item.nodeid for item in session.items], } _report_to_platform(payload)注意一個(gè)鐵律鉤子里做網(wǎng)絡(luò)請(qǐng)求必須 try/except 包住因?yàn)闇y(cè)試環(huán)境經(jīng)常斷網(wǎng)、內(nèi)網(wǎng)通不了、超時(shí)很久如果這些異常冒泡到 pytest 主流程整個(gè)測(cè)試都會(huì)被中斷這是絕對(duì)不能接受的。4.2 場(chǎng)景二精準(zhǔn)回歸的命中集校驗(yàn)精準(zhǔn)回歸大家應(yīng)該都懂開(kāi)發(fā)只改了某個(gè)模塊理論上只需要跑這個(gè)模塊相關(guān)的用例。但在改動(dòng)分析不靠譜的時(shí)候真正執(zhí)行范圍可能跟預(yù)期差很多。我在 CI 里加了一個(gè)校驗(yàn)環(huán)節(jié)依賴的就是 finish 鉤子。流程是MR/PR 里解析出受影響的源碼文件列表 - 通過(guò)路徑映射生成“預(yù)期命中用例集合” - 執(zhí)行 pytest - finish 鉤子收集實(shí)際命中集合 - 對(duì)比得到漏測(cè)集和新測(cè)集。漏測(cè)集里如果包含核心用例CI 直接報(bào)錯(cuò)阻塞合入。這個(gè)“預(yù)期命中集合”怎么生成不是本文重點(diǎn)但我可以給你一個(gè)簡(jiǎn)單可用的替代思路很多團(tuán)隊(duì)會(huì)給用例按模塊打標(biāo)記比如 pytest.mark.module_user。精準(zhǔn)回歸時(shí)執(zhí)行 pytest -m module_user or module_orderfinish 鉤子拿到的就是實(shí)際命中集合再跟改動(dòng)分析腳本預(yù)測(cè)的集合一對(duì)比誰(shuí)多誰(shuí)少一目了然。多做的用例雖然浪費(fèi)點(diǎn)資源但漏掉用例才是大問(wèn)題。4.3 場(chǎng)景三配合 pytest-xdist 匯總 worker 數(shù)據(jù)分布式執(zhí)行時(shí)數(shù)據(jù)匯總是個(gè)容易踩坑的點(diǎn)。pytest-xdist 的機(jī)制是 master 先做收集然后把收集到的 item 分發(fā)給各個(gè) worker 執(zhí)行worker 內(nèi)部一般不重復(fù)走完整的 collection 流程。所以穩(wěn)妥的做法是在 master 進(jìn)程的 finish 鉤子里拿全局命中數(shù)據(jù)落一個(gè)文件如果需要按 worker 維度統(tǒng)計(jì)再在 worker 側(cè)把各自執(zhí)行的 nodeid 寫日志最后合并。我在項(xiàng)目里的做法是兩階段先跑一次pytest --collect-only -q生成全局命中清單讓老板和平臺(tái)先看到范圍然后再正式跑分布式執(zhí)行。這樣即使執(zhí)行中途某個(gè) worker 掛了本輪“命中范圍”早就留下了快照復(fù)盤的時(shí)候不至于啥都沒(méi)了。這個(gè)思路比強(qiáng)行在 xdist worker 里匯總數(shù)據(jù)簡(jiǎn)單得多也更穩(wěn)。5. 常見(jiàn)問(wèn)題與排查實(shí)錄寫鉤子不難但真實(shí)環(huán)境里會(huì)碰到各種妖魔鬼怪。我把常遇到的坑和排查方法整理出來(lái)你對(duì)照著看能少走不少?gòu)澛贰?.1 鉤子沒(méi)觸發(fā)、重復(fù)觸發(fā)、print 被吞最基礎(chǔ)但最高頻的問(wèn)題是鉤子壓根沒(méi)觸發(fā)。先看 conftest.py 放對(duì)位置沒(méi)有——pytest 的 conftest 加載機(jī)制是分層級(jí)的只有放在 rootdir 或測(cè)試目錄的父級(jí)目錄里才會(huì)對(duì)目標(biāo)測(cè)試用例生效。你在某個(gè)子目錄的 conftest.py 里寫了鉤子但跑的是另一個(gè)目錄下的用例自然不觸發(fā)。其次是函數(shù)名拼寫。pytest 的鉤子是通過(guò) hookspec 名字匹配的少寫一個(gè)字母就靜默失效pytest 還不會(huì)報(bào)錯(cuò)。排查方法很簡(jiǎn)單臨時(shí)在鉤子第一行加一個(gè) print然后執(zhí)行pytest --collect-only -q能打印出來(lái)說(shuō)明鉤子生效了沒(méi)打印就是位置或者拼寫問(wèn)題。重復(fù)觸發(fā)則可能來(lái)自多份 conftest.py。如果測(cè)試目錄層級(jí)里有多層 conftest且每層都實(shí)現(xiàn)了同一鉤子pytest 會(huì)依次調(diào)用多個(gè)實(shí)現(xiàn)。大多數(shù)情況下這也是合法需求但如果你的本意是全局一份邏輯就要注意清理多余的 conftest或者用pytest.hookimpl(trylastTrue)之類的方式控制執(zhí)行順序。print 被吞的問(wèn)題也很常見(jiàn)。pytest 默認(rèn)對(duì)測(cè)試執(zhí)行過(guò)程的輸出捕獲collection 階段雖然在通常場(chǎng)景下認(rèn)為還在執(zhí)行捕獲邏輯之前但保險(xiǎn)起見(jiàn)所有調(diào)試 print 都加 flushTrue或者干脆直接寫到文件別依賴終端輸出。這是我踩過(guò)最多次的坑。5.2 item 屬性訪問(wèn)炸了怎么破最常見(jiàn)的是 AttributeError。比如你遍歷 session.items假設(shè)每個(gè) item 都有 module 屬性結(jié)果遇到 doctest 類型的 itemitem.module 是 None遇到 pytest 7 之前的版本item.path 不存在只有 item.fspath遇到自定義 collector 生成的 item可能連 callspec 都沒(méi)有。我總結(jié)下來(lái)的三條防御式寫法所有屬性訪問(wèn)都用 getattr(item, xxx, None) 給默認(rèn)值關(guān)鍵路徑用getattr(item, path, None) or getattr(item, fspath, )。判斷是否有參數(shù)化用 hasattr(item, callspec)不要靠 nodeid 里有沒(méi)有 [ 來(lái)猜。序列化前統(tǒng)一經(jīng)過(guò) _safe_str()參數(shù)值里可能塞了對(duì)象、函數(shù)、甚至 mock 實(shí)例repr 一下兜底。另外提一句item.location 在某些極端情況下也可能沒(méi)有訪問(wèn)前用 getattr(item, location, None) 判空。這些防御代碼看起來(lái)啰嗦但能幫你在 pytest 小版本升級(jí)時(shí)不炸。5.3 參數(shù)化解析與 JSON 序列化的坑如果不用 callspec 非要自己拆 nodeid遇到參數(shù)值里有中文逗號(hào)、空格、方括號(hào)你會(huì)得到一個(gè)又長(zhǎng)又亂的字符串。尤其參數(shù)值是(1, 2)這種元組的 reprpytest 會(huì)轉(zhuǎn)義很多字符你肉眼很難還原原始參數(shù)。所以再次強(qiáng)調(diào)解析參數(shù)化用 callspec。JSON 序列化那邊最常見(jiàn)的問(wèn)題是 params 里有一個(gè) requests.Session 對(duì)象或者 fixture 返回的連接對(duì)象json.dumps 直接拋 TypeError。我的 _safe_str 方案會(huì)把所有 value 變成字符串信息量雖然損失一點(diǎn)但報(bào)告文件永遠(yuǎn)能生成出來(lái)。如果擔(dān)心報(bào)告文件本身越來(lái)越大——全量收集 5000 條用例一個(gè) JSON 可能就 1~2MBCI 上多存幾份倒是沒(méi)啥但要記得把 collection_report.json 加進(jìn) .gitignore別污染代碼倉(cāng)庫(kù)。5.4 排查速查表我最后把經(jīng)驗(yàn)整理成一個(gè)表直接貼墻上用現(xiàn)象可能原因解法鉤子完全沒(méi)觸發(fā)conftest.py 位置不對(duì) / 函數(shù)名拼錯(cuò)先加 print 驗(yàn)證再查文件層級(jí)鉤子觸發(fā)多次多層 conftest 都有實(shí)現(xiàn)用 hookimpl 的 tryfirst/trylast 控制或減少 conftestitems 數(shù)量為 0-k/-m 篩得太狠 / 路徑不存在去掉篩選再收集對(duì)比或在這里打兜底警告item.module 為 Nonedoctest/自定義 itemgetattr 判空按 None 處理參數(shù)化解析亂自己拆 nodeid改用 item.callspecJSON 序列化報(bào)錯(cuò)參數(shù)值是對(duì)象遍歷前用 _safe_str 包裹上報(bào)失敗中斷測(cè)試網(wǎng)絡(luò)異常冒泡鉤子里所有網(wǎng)絡(luò)請(qǐng)求 try/exceptfinish 拿到的 items 與終端統(tǒng)計(jì)不一致其他插件在 modifyitems 階段改過(guò) items先執(zhí)行 modifyitems 再執(zhí)行 finish讀取時(shí)別修改6. 最后分享幾點(diǎn)真實(shí)心得鉤子本身寫起來(lái)很簡(jiǎn)單但要把這個(gè)切面真正用好我總結(jié)了幾條個(gè)人經(jīng)驗(yàn)希望對(duì)你有幫助。第一finish 鉤子里絕對(duì)不要修改 items。這個(gè)階段數(shù)據(jù)已經(jīng)定型你修改它也只是在內(nèi)存里改執(zhí)行階段到底用不用取決于 pytest 內(nèi)部的調(diào)度順序搞不好還能跟其他插件打架。想改用例集合請(qǐng)老老實(shí)實(shí)去 pytest_collection_modifyitems 里做那是官方設(shè)計(jì)好的“修改窗口”。第二別在 finish 里統(tǒng)計(jì)執(zhí)行結(jié)果。有人問(wèn)我能不能在這個(gè)鉤子里判斷用例通過(guò)多少、失敗多少做不到因?yàn)樗l(fā)生在執(zhí)行之前。你要執(zhí)行結(jié)果去用 pytest_terminal_summary 或者 report 相關(guān)鉤子各管一段才最清晰。第三我建議把這段邏輯收成一個(gè)小插件。比如做一個(gè) pip 可安裝的包內(nèi)部就一個(gè) conftest.py 和幾個(gè)工具函數(shù)通過(guò) entry_points 注冊(cè)到 pytest 里。這樣不用每個(gè)項(xiàng)目粘一份代碼升級(jí)邏輯只改一個(gè)地方CI 流水線里也能很干凈地復(fù)用。第四平時(shí)調(diào)試這套東西我常年配合pytest --collect-only -q使用。它不執(zhí)行用例但收集階段完整跑完finish 鉤子照樣觸發(fā)數(shù)據(jù)照樣落盤。這等于給了你一個(gè)“只盤點(diǎn)、不執(zhí)行”的開(kāi)關(guān)做用例庫(kù)大盤再合適不過(guò)。你甚至可以寫個(gè)定時(shí)任務(wù)每天夜里全量收集一次把命中數(shù)據(jù)歸檔慢慢就是一個(gè)很有價(jià)值的用例資產(chǎn)庫(kù)。