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