這一兩年我面試過不少測試崗位的候選人幾乎每個人簡歷上都寫著“熟悉自動化測試”可細(xì)問下去能把手里的框架講明白的并不多。這不能全怪個人自動化測試的門檻不在工具本身而在你能不能把一個框架真正用起來、用好。今天我想聊聊 Pytest這個在 Python 自動化測試圈子里被用得最多、也最值得花時間掌握的測試框架。Pytest 之所以能在 unittest、nose 等一堆老牌框架里殺出重圍靠的不是花哨的功能而是它對“測試”這件事的理解足夠樸素測試就是普通函數(shù)加斷言寫起來沒有任何心理負(fù)擔(dān)。但等你真正深入進去又會發(fā)現(xiàn)它背后藏著一套非常強大的插件機制和夾具系統(tǒng)。這篇文章我會從框架選型聊到接口自動化、UI 自動化的實際落地全程帶例子、帶參數(shù)、帶踩坑記錄希望能幫正在學(xué)自動化測試或者準(zhǔn)備搭建測試框架的朋友少走點彎路。1. 為什么是 Pytest自動化測試框架選型背后的考量1.1 從手工測試到自動化測試框架到底解決什么問題很多人對測試框架有一個誤解以為框架的價值就是“能跑用例”。其實手工測試也能跑用例你寫一百個 if 判斷也一樣能出結(jié)果。框架真正解決的是三個問題可維護性、可讀性、可擴展性。先聊可維護性。沒有框架的時代測試代碼長什么樣通常是一個腳本從頭跑到尾數(shù)據(jù)、步驟、斷言全塞在一起。改一個需求你得從頭到尾捋一遍代碼生怕哪里邏輯被帶偏。而 Pytest 這種框架強制你把測試拆成一個個獨立的用例函數(shù)每個函數(shù)只干一件事互不干擾改起來就是“啃個雞腿”的功夫。再聊可讀性。Pytest 把斷言簡化成了 Python 原生的assert語句用例寫出來跟白話文一樣。比如你要校驗接口返回的 code 是 200直接寫assert resp.status_code 200就行任何人來看都能秒懂這條用例在測什么。這比 unittest 那套assertEqual寫法要清爽太多了。最后是可擴展性。Pytest 從設(shè)計之初就留好了插件的口子你可以在不修改框架源碼的前提下通過 conftest.py 和 fixture 機制把登錄態(tài)、數(shù)據(jù)庫連接、測試數(shù)據(jù)準(zhǔn)備這些公共邏輯全部抽離出來。這種“把重復(fù)勞動交給框架把精力留給業(yè)務(wù)”的思路才是自動化測試能長期跑下去的根基。1.2 Pytest 與 unittest、Robot Framework 的選型對比學(xué)習(xí)自動化測試的人一定會遇到“框架選擇困難癥”。我的建議很直接Python 生態(tài)里做接口自動化和 UI 自動化Pytest 是第一梯隊的選擇幾乎沒有之一。為了讓你信服把幾個常用的框架放在同一張表里對比一下對比維度PytestunittestRobot Framework用例編寫方式普通函數(shù) assert類 斷言方法表格關(guān)鍵字驅(qū)動學(xué)習(xí)曲線平緩會 Python 基礎(chǔ)就能上手平緩但代碼冗余陡峭關(guān)鍵字語法需要額外學(xué)習(xí)參數(shù)化支持內(nèi)建 pytest.mark.parametrize功能強大需要額外封裝通過模板和參數(shù)文件實現(xiàn)插件生態(tài)非常豐富xdist、rerun、allure 等生態(tài)一般擴展能力弱有庫和關(guān)鍵字但靈活度低斷言失敗信息非常詳細(xì)自動對比期望值和實際值提示相對簡單依賴關(guān)鍵字實現(xiàn)信息有限適合場景接口、UI、單元測試通吃簡單單元測試、老項目維護測試團隊非技術(shù)背景偏多這里面最關(guān)鍵的一個差距是參數(shù)化。接口測試十有八九是數(shù)據(jù)驅(qū)動的場景同一套邏輯要跑幾十組輸入輸出。unittest 做參數(shù)化要么循環(huán)套循環(huán)要么寫一堆子類代碼難看得很。Pytest 直接用pytest.mark.parametrize裝飾器就能搞定參數(shù)列表一目了然失敗時還能精確定位到是哪一組數(shù)據(jù)出了問題。這個體驗上的差距你在實際工程里跑兩天就能感受出來。2. Pytest 核心機制拆解從安裝到第一個測試用例2.1 環(huán)境準(zhǔn)備與安裝Pytest 的安裝非常省心Python 3.7 以上的環(huán)境直接跑一條命令pip install pytest裝完驗證一下版本確認(rèn)環(huán)境沒有問題pytest --version我習(xí)慣在虛擬環(huán)境里裝避免把系統(tǒng) Python 搞亂了。用 venv 或者 conda 的都行這不是什么復(fù)雜的操作但能避免很多后面才爆出來的依賴沖突。如果你的項目里已經(jīng)用了 requirements.txt直接往里面加一行pytest8.x.x鎖定版本團隊協(xié)作時大家環(huán)境一致排查問題會省不少事。如果你的 Python 環(huán)境里既有 unittest 又有 pytest裝完之后默認(rèn)執(zhí)行 pytest 命令是沒有沖突的兩個框架可以在同一個項目里并存。不過我不建議混著用測試體系最怕風(fēng)格不統(tǒng)一選一個就用到底。2.2 測試用例編寫規(guī)則與斷言技巧Pytest 對用例的識別有一套約定最核心的規(guī)則是測試文件命名為test_*.py或*_test.py測試函數(shù)命名為test_*測試類命名為Test*且類中沒有__init__方法按照這個規(guī)則寫Pytest 就能自動發(fā)現(xiàn)用例。一個最簡單的測試用例長這樣# test_demo.py def test_addition(): assert 1 1 2 def test_string_contains(): name pytest assert test in name寫斷言的時候有幾個小技巧是新手容易忽略的。先看字符串?dāng)嘌匀绻阆胄ｒ炞址锇硞€子串直接assert test in name即可但如果斷言失敗Pytest 只會告訴你assert test in pytttt不會告訴你到底哪里不一樣。想要更詳細(xì)的失敗信息可以用assert test in name, 期望 name 中包含 test實際值是 {name}把上下文信息打印出來。再來看異常斷言。如果你在測試一個函數(shù)它應(yīng)該在某個條件下拋出ValueError直接這么寫import pytest def divide(a, b): if b 0: raise ValueError(除數(shù)不能為 0) return a / b def test_divide_by_zero(): with pytest.raises(ValueError, match除數(shù)不能為 0): divide(10, 0)這種寫法比你用 try-except 包一層再自己做判斷要干凈得多而且pytest.raises的match參數(shù)還能幫你校驗異常信息里是否有特定關(guān)鍵詞配合正則表達(dá)式用非常強大。2.3 用例運行與收集機制運行測試用例的命令幾行就能說清# 運行當(dāng)前目錄下所有用例 pytest # 運行指定文件 pytest test_demo.py # 運行指定文件中的指定函數(shù) pytest test_demo.py::test_addition # 按關(guān)鍵字篩選用例 pytest -k addition or contains # 顯示詳細(xì)輸出 pytest -v這里-k參數(shù)特別適合調(diào)試階段。比如我今天只改了登錄相關(guān)的邏輯想快速跑一遍所有登錄相關(guān)用例直接pytest -k login就夠了不用傻乎乎地跑全量用例。另外配合-x參數(shù)可以讓用例在第一次失敗時立刻停止適合在本地快速排查問題時用而--maxfail2則允許第一次失敗后繼續(xù)跑最多收集到第 2 個失敗才停下。關(guān)于用例收集機制有個點必須提Pytest 默認(rèn)會遞歸搜索當(dāng)前目錄下所有符合條件的文件。如果你的項目里某些目錄不需要跑測試比如build、venv這類一定要記得在pytest.ini里用norecursedirs把它排除掉否則你每次跑測試都會被一堆無關(guān)文件拖慢速度嚴(yán)重的時候還會因為導(dǎo)入錯誤導(dǎo)致整個測試會話崩潰。我的pytest.ini一般長這樣[pytest] testpaths tests norecursedirs venv build dist .git3. fixture 機制詳解Pytest 的靈魂功能3.1 fixture 基礎(chǔ)用裝飾器管理測試前后置如果說 Pytest 只能讓你記住一個功能那一定是 fixture。fixture 說白了就是測試用例的前置條件和后置清理但它的設(shè)計比 unittest 的 setUp/tearDown 靈活太多。先看一個最基礎(chǔ)的用法。假設(shè)每個測試用例執(zhí)行前都需要創(chuàng)建一個臨時數(shù)據(jù)庫連接測試完關(guān)閉這個連接import pytest pytest.fixture def db_connection(): # 前置操作創(chuàng)建連接 conn create_database_connection() yield conn # 后置操作關(guān)閉連接 conn.close() def test_query_user(db_connection): user db_connection.query(SELECT * FROM users WHERE id1) assert user is not None注意這里的關(guān)鍵詞是yield。yield之前的代碼就是前置操作yield之后的代碼就是后置清理。為什么用yield而不是return因為yield能讓你在測試用例跑完之后繼續(xù)執(zhí)行清理邏輯。這比 unittest 的tearDown單獨寫一個方法要清晰得多前后置邏輯離得近一眼就能看懂。3.2 conftest.py 與作用域控制fixture 寫在哪、怎么共享這是很多新手容易繞暈的地方。Pytest 的規(guī)則是conftest.py文件里的 fixture 可以被同目錄及其子目錄下的所有測試文件使用。所以一般項目里會把公共 fixture 放在測試根目錄下的conftest.py中。fixture 的scope參數(shù)控制它的生命周期一共有 5 種scope 取值生命周期適用場景function每個測試函數(shù)執(zhí)行前創(chuàng)建執(zhí)行后銷毀默認(rèn)值最安全一般都用它class每個測試類只執(zhí)行一次類級共享資源module每個測試模塊只執(zhí)行一次模塊級共享資源package每個測試包只執(zhí)行一次包級共享資源session整個測試會話只執(zhí)行一次登錄 token、全局配置等我舉一個具體的例子接口測試中的登錄 token。如果每個用例都重新登錄一遍不僅浪費時間還可能被服務(wù)器的防刷機制給攔截。這時候把scope設(shè)為session整個測試過程只登錄一次所有用例共用同一個 tokenimport pytest import requests pytest.fixture(scopesession) def auth_token(): resp requests.post(https://api.example.com/login, json{ username: admin, password: 123456 }) assert resp.status_code 200 return resp.json()[token]這里有一個非常關(guān)鍵的經(jīng)驗scopesession的 fixture 一旦返回了可變對象比如字典、列表不同測試用例之間可能會互相污染數(shù)據(jù)。我踩過這個坑有一個全局配置字典在 A 用例里被改了B 用例跑的時候直接報錯。后來我養(yǎng)成一個習(xí)慣session 級別的 fixture 盡量返回不可變數(shù)據(jù)或者每次使用時做一次深拷貝。3.3 fixture 實戰(zhàn)接口自動化中的登錄態(tài)管理在一個真正的接口自動化項目里fixture 怎么用才叫“優(yōu)雅”我給大家拆一個完整流程。假設(shè)被測系統(tǒng)的所有接口都需要先登錄拿到 token然后請求頭里帶上Authorization字段。公共的邏輯應(yīng)該這樣設(shè)計# conftest.py import pytest import requests pytest.fixture(scopesession) def base_url(): return https://api.example.com pytest.fixture(scopesession) def auth_token(base_url): resp requests.post(f{base_url}/login, json{ username: admin, password: 123456 }) assert resp.status_code 200 return resp.json()[token] pytest.fixture() def api_client(base_url, auth_token): session requests.Session() session.headers.update({ Authorization: fBearer {auth_token}, Content-Type: application/json }) return session這樣設(shè)計的好處是層次清晰base_url管環(huán)境地址auth_token管登錄狀態(tài)api_client管請求會話。測試用例里只需要傳入api_client參數(shù)直接發(fā)起請求就行不用關(guān)心登錄和 token 是怎么來的# test_user_api.py def test_get_user_info(api_client, base_url): resp api_client.get(f{base_url}/user/1) assert resp.status_code 200 assert resp.json()[code] 0這種“依賴注入”的思路才是 Pytest fixture 的精髓所在。測試函數(shù)不關(guān)心依賴從哪來只關(guān)心自己需要什么。這比在測試代碼里手動調(diào)用setup_method去初始化請求對象要干凈得多配合 conftest.py 的層級管理復(fù)雜的測試工程也能保持整潔。4. 參數(shù)化與數(shù)據(jù)驅(qū)動讓測試代碼量減少一半4.1 參數(shù)化的基礎(chǔ)用法接口測試中最典型的場景就是同一個接口輸入不同的參數(shù)組合驗證返回結(jié)果是否符合預(yù)期。如果你不用參數(shù)化代碼會長這樣def test_login_success(): assert login(admin, 123456)[code] 0 def test_login_wrong_password(): assert login(admin, wrong)[code] 1001 def test_login_user_not_exist(): assert login(nobody, 123456)[code] 1002三條用例邏輯完全一樣只是數(shù)據(jù)不同。用參數(shù)化重構(gòu)之后import pytest pytest.mark.parametrize(username,password,expected_code, [ (admin, 123456, 0), (admin, wrong, 1001), (nobody, 123456, 1002), ]) def test_login(username, password, expected_code): resp login(username, password) assert resp[code] expected_code一份代碼三組數(shù)據(jù)邏輯只寫一遍。新增用例只需要往列表里加一組元組維護成本直線下降。如果某組數(shù)據(jù)斷言失敗Pytest 會非常清楚地告訴你是哪一組參數(shù)出了問題定位效率高到飛起。4.2 參數(shù)化與 fixture 結(jié)合的高級用法參數(shù)化雖然好用但有的時候會出現(xiàn)一個棘手的問題如果參數(shù)里需要包含 fixture 的返回值怎么辦比如我想對不同的用戶身份做權(quán)限校驗測試而用戶 token 來自 fixture。直接混著傳參是不行的因為 Pytest 無法在parametrize裝飾器里動態(tài)獲取 fixture 的值。有兩個解決思路。第一種是直接用 fixture 的params參數(shù)pytest.fixture(params[ {role: admin, permission: delete}, {role: user, permission: view}, ]) def user_with_permission(request): return request.param這樣 fixture 會自動根據(jù)params里的每一條數(shù)據(jù)執(zhí)行一次測試用例也就自動多跑了幾遍。第二種思路是借助pytest.fixture加getfixturevalue的動態(tài)引用更靈活但寫法也復(fù)雜一些。不過實際項目里用第一種就夠了能把 90% 的“參數(shù)與依賴混合”場景解決掉。還有一個參數(shù)化的小技巧給參數(shù)命名時用元組的解包方式來寫代碼可讀性會好很多。比如上面的寫法username,password,expected_code一眼就能看出參數(shù)含義比param1,param2,param3這種命名要有價值得多。另外遇到特別多數(shù)據(jù)的場景建議把參數(shù)列表單獨抽取到一個data.py模塊或 JSON/YAML 文件里測試代碼保持干凈測試數(shù)據(jù)方便維護。這也是數(shù)據(jù)驅(qū)動測試的核心思想——測試邏輯是固定的數(shù)據(jù)是可以隨時替換的。5. 斷言、標(biāo)記與插件生態(tài)5.1 標(biāo)記機制跳過、預(yù)期失敗與自定義分組Pytest 的標(biāo)記mark機制是管理大規(guī)模測試用例的重要工具。最常見的三個標(biāo)記是skip、xfail和custom。skip用于跳過某些用例。比如某個接口還在開發(fā)中或者只對特定環(huán)境生效直接跳過pytest.mark.skip(reason接口尚未開發(fā)完成) def test_new_api(): pass pytest.mark.skipif(sys.version_info (3, 8), reason需要 Python 3.8) def test_new_feature(): passxfail表示這個用例預(yù)計會失敗。比如你發(fā)現(xiàn)了一個已知 bug但還沒修復(fù)測試用例跑的時候會報錯你不想讓整條測試記錄變成失敗可以用xfail標(biāo)記。跑完之后Pytest 會統(tǒng)計成“預(yù)期失敗”一旦某天 bug 修復(fù)了這個用例反而通過Pytest 還會用“XPASS”提醒你這個 bug 已經(jīng)解決了該把標(biāo)記去掉了。自定義標(biāo)記能幫你給用例分組。比如接口測試?yán)飬^(qū)分冒煙測試和全量回歸pytest.mark.smoke def test_login(): pass pytest.mark.regression def test_payment(): pass運行的時候用pytest -m smoke只跑冒煙用例pytest -m regression只跑回歸用例。這個機制在 CI 流水線里特別有價值。不過要注意自定義標(biāo)記在使用前需要在pytest.ini里注冊否則會有警告提示。我的做法是統(tǒng)一在配置里維護一個標(biāo)記清單[pytest] markers smoke: 冒煙測試用例 regression: 回歸測試用例 p1: 優(yōu)先級 P1 p2: 優(yōu)先級 P25.2 常用插件組合Allure 報告、多線程與失敗重跑Pytest 的生態(tài)是它最強大的武器之一。我挑幾個項目里一定會用到的插件展開講講。第一個是pytest-xdist用來做分布式執(zhí)行。一條命令就能把用例平均分發(fā)到多個 CPU 進程上并行跑pip install pytest-xdist pytest -n 4-n 4表示開 4 個進程。如果你的用例里有共享資源比如寫同一個測試數(shù)據(jù)庫并行執(zhí)行可能會互相干擾。這時候就要規(guī)劃好數(shù)據(jù)隔離方案。我的習(xí)慣是每個測試進程連接不同的 schema或者用唯一前綴的測試數(shù)據(jù)避免沖突。第二個是pytest-rerunfailures專門處理不穩(wěn)定用例。UI 測試?yán)锝?jīng)常遇到網(wǎng)絡(luò)抖動、元素加載慢導(dǎo)致的偶發(fā)失敗這種用例手動跑能過自動跑就掛用重跑機制能減少很多噪音pip install pytest-rerunfailures pytest --reruns 3 --reruns-delay 2這里--reruns 3是失敗后重試 3 次--reruns-delay 2是每次重試前等待 2 秒。要注意的是不要什么都依賴重跑如果一條用例重跑 3 次還是掛那大概率是真實 bug不能靠重跑把問題掩蓋掉。第三個是allure-pytest生成顏值和實用性兼?zhèn)涞臏y試報告pip install allure-pytest pytest --alluredir./allure-results allure generate ./allure-results -o ./allure-reportAllure 報告能展示每個用例的步驟、參數(shù)、附帶的截圖、日志還能統(tǒng)計歷史趨勢。對接口自動化和 UI 自動化項目來說Allure 報告基本就是標(biāo)配。接入的方式很簡單在 conftest.py 里定義一個 fixture來自動為每個用例捕獲執(zhí)行信息import allure import pytest pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: # 失敗時自動附加截圖UI 測試場景 if driver in item.funcargs: driver item.funcargs[driver] allure.attach(driver.get_screenshot_as_png(), namescreenshot, attachment_typeallure.attachment_type.PNG)這個寫法的邏輯在 UI 自動化測試中很常用能在用例失敗時把瀏覽器截圖自動掛到 Allure 報告里排查問題會輕松很多。6. 接口自動化測試實戰(zhàn)從請求封裝到 CI 集成6.1 測試分層接口測試項目目錄結(jié)構(gòu)設(shè)計很多項目做接口自動化最大的問題不是寫不出用例而是寫著寫著就變成一鍋粥了。200 個用例全堆在幾個文件里改一個接口字段要翻半天代碼。所以我一直強調(diào)先設(shè)計目錄結(jié)構(gòu)再寫測試代碼。我常用的接口自動化項目結(jié)構(gòu)如下api_test_project/ ├── config/ │ ├── __init__.py │ ├── settings.py # 環(huán)境配置、全局變量 │ └── data.yaml # 測試數(shù)據(jù) ├── common/ │ ├── __init__.py │ ├── request_utils.py # 請求封裝 │ ├── logger.py # 日志模塊 │ └── assert_utils.py # 斷言工具 ├── testcases/ │ ├── __init__.py │ ├── test_user_api.py │ └── test_order_api.py ├── conftest.py # 公共 fixture ├── pytest.ini └── requirements.txt關(guān)鍵點在于把配置、公共方法、測試用例三個層面徹底分開。配置變了不碰用例代碼公共方法升級不影響單個用例用例本身只關(guān)心業(yè)務(wù)邏輯和斷言。這樣的結(jié)構(gòu)在項目規(guī)模擴大后維護成本才不會失控。6.2 請求封裝與斷言工具類基于requests庫我做了一層簡單的封裝。不是為了“過度設(shè)計”而是為了方便統(tǒng)一處理請求日志、超時重試和異常捕獲# common/request_utils.py import requests import time import logging logger logging.getLogger(__name__) class RequestUtils: def __init__(self, base_url, tokenNone): self.base_url base_url self.session requests.Session() if token: self.session.headers.update({Authorization: fBearer {token}}) def request(self, method, path, **kwargs): url f{self.base_url}{path} kwargs.setdefault(timeout, 10) for attempt in range(3): try: logger.info(f請求: {method} {url} 參數(shù): {kwargs}) response self.session.request(method, url, **kwargs) logger.info(f響應(yīng): {response.status_code} {response.text[:500]}) return response except requests.exceptions.Timeout: if attempt 2: raise time.sleep(2)這里有個實測得來的經(jīng)驗接口請求超時時間不要太長5 到 10 秒足夠。設(shè)個 30 秒超時一旦接口出問題測試一直掛在那里整個回歸排隊排到天荒地老。timeout10配合 3 次重試既能容忍偶發(fā)的網(wǎng)絡(luò)抖動又不至于在接口真的掛了的時候無限等下去。斷言這塊針對接口常見的 JSON 返回我封裝了一個簡單的斷言工具# common/assert_utils.py def assert_code(resp_json, expected_code): assert resp_json.get(code) expected_code, \ fcode 期望 {expected_code}, 實際 {resp_json.get(code)}, 響應(yīng): {resp_json} def assert_msg(resp_json, expected_msg): assert resp_json.get(msg) expected_msg, \ fmsg 期望 {expected_msg}, 實際 {resp_json.get(msg)}, 響應(yīng): {resp_json}封裝不是目的減少重復(fù)、提升失敗信息的可讀性才是目的。斷言失敗時一眼要能看到接口返回了什么東西、和期望值差在哪這樣才能快速定位問題。6.3 結(jié)合 Pytest 的完整接口測試用例把上面的模塊組合起來一個標(biāo)準(zhǔn)化的接口測試用例是這樣的# testcases/test_user_api.py import allure import pytest from common.request_utils import RequestUtils from common.assert_utils import assert_code allure.feature(用戶模塊) class TestUserAPI: allure.story(獲取用戶信息) pytest.mark.parametrize(user_id,expected_code, [ (1, 0), (99999, 1004), ]) def test_get_user_info(self, api_client, user_id, expected_code): resp api_client.get(f/user/{user_id}) assert resp.status_code 200 assert_code(resp.json(), expected_code) allure.story(更新用戶信息) def test_update_user(self, api_client): payload {nickname: 新名字} resp api_client.put(/user/1, jsonpayload) assert resp.status_code 200 assert_code(resp.json(), 0)這里的api_clientfixture 在前面已經(jīng)定義好了它在 session 級別登錄獲取 token然后封裝好請求對象。測試用例本身非?！案蓛簟弊x起來就是一條業(yè)務(wù)描述加上關(guān)鍵斷言的展開。整條鏈路跑起來的效果是登錄一次所有用例復(fù)用同一個會話數(shù)據(jù)驅(qū)動管理各種輸入組合Allure 報告里記錄每一步的請求響應(yīng)。6.4 CI/CD 集成與郵件報告接口自動化不接入 CI價值至少打五折。定時手動跑一次測試跟每次代碼提交后自動跑一遍完全不是一個概念。接入方式很簡單我用 GitHub Actions 做一個示例name: API Test on: push: branches: [main] schedule: - cron: 0 2 * * * jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-pythonv4 with: python-version: 3.10 - run: pip install -r requirements.txt - run: pytest tests -n 4 --alluredirallure-results - uses: actions/upload-artifactv3 if: always() with: name: allure-results path: allure-results這個流水線會在每次主分支代碼推送后自動運行同時每天凌晨 2 點跑一次定時回歸。測試結(jié)果通過 Allure 插件生成報告即使用例失敗上傳的 allure-results 也能讓你回溯到具體的失敗請求和響應(yīng)。接入 CI 之后自動化測試才真正變成了團隊的質(zhì)量防線而不是個人電腦上的一個腳本。7. UI 自動化測試實戰(zhàn)Playwright Pytest 的高效協(xié)作7.1 UI 自動化到底難在哪做 UI 自動化的同學(xué)應(yīng)該都有體會UI 用例最大的敵人不是代碼邏輯而是“不穩(wěn)定”。同樣的用例昨天能過今天掛本地能過 CI 上掛唯一能確定的就是它隨時可能掛。導(dǎo)致不穩(wěn)定的原因無非這幾個元素定位不穩(wěn)定、頁面加載耗時不確定、測試環(huán)境影響。Pytest 本身并不能解決 UI 自動化的穩(wěn)定性問題但它的 fixture 機制和插件生態(tài)能把這種不穩(wěn)定性控制在一個可接受的范圍內(nèi)。Playwright 是目前 UI 自動化工具里做得比較出色的一款它和 Pytest 的配合度非常高。安裝也比較簡單pip install playwright playwright install chromium7.2 基于 Pytest 的 Playwright fixture 設(shè)計頁面自動化測試最關(guān)鍵的一個 fixture 是瀏覽器實例。我的設(shè)計思路是每個測試函數(shù)都用獨立的瀏覽器上下文保證用例之間的數(shù)據(jù)完全隔離但瀏覽器內(nèi)核只需要啟動一次# conftest.py import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopesession) def browser(): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) yield browser pytest.fixture() def page(browser): context browser.new_context() page context.new_page() yield page context.close()這里browser是 session 級別整個測試過程只啟動一次瀏覽器引擎page是函數(shù)級別每條用例都有自己獨立的頁面上下文互不干擾。這種設(shè)計既保證了執(zhí)行效率不用每條用例都重新啟動瀏覽器又保證了用例隔離性頁面狀態(tài)不串。配合 Pytest 的pytest-rerunfailures我可以給 UI 用例加上兩層保護第一層是顯式等待和智能定位第二層是失敗后的自動重試。但這里要特別強調(diào)重試次數(shù)不要設(shè)置太多2 到 3 次足夠。如果一個用例重試 3 次還是失敗那大概率是真 bug該報警就報警不能讓重試機制把問題無限吞掉。7.3 UI 自動化中的元素定位與斷言技巧Playwright 的定位器 API 比傳統(tǒng)的 xpath 寫起來更直觀而且自帶等待機制。比如def test_login_page(page): page.goto(https://example.com/login) page.get_by_label(用戶名).fill(admin) page.get_by_placeholder(請輸入密碼).fill(123456) page.get_by_role(button, name登錄).click() page.wait_for_url(**/dashboard) assert page.title() 控制臺這里wait_for_url是很關(guān)鍵的一步。點完登錄按鈕后頁面要跳轉(zhuǎn)如果立即斷言 URL很可能還是舊的地址。用wait_for_url會讓頁面跳轉(zhuǎn)完成后才繼續(xù)執(zhí)行比硬編碼time.sleep(3)要可靠得多而且執(zhí)行速度更快——頁面 0.5 秒跳轉(zhuǎn)完就繼續(xù)了不用白白等 3 秒。關(guān)于元素定位我有一個長期踩坑總結(jié)的經(jīng)驗優(yōu)先用文本和角色定位get_by_role、get_by_text其次用 label 和 placeholder最后才考慮 CSS 和 XPath。因為 UI 開發(fā)改代碼時最穩(wěn)定的往往是元素的文本內(nèi)容和語義角色最不穩(wěn)定的是 CSS 類名和嵌套層級。這個道理在寫 UI 自動化時越早明白越好。8. 常見問題與排查技巧實錄8.1 典型問題速查表問題現(xiàn)象可能原因解決辦法執(zhí)行 pytest 但提示沒有收集到用例文件命名不是 test_.py或函數(shù)名不是 test_檢查文件和函數(shù)命名用pytest --collect-only查看收集結(jié)果fixture 報錯 “fixture not found”conftest.py 路徑不對或者 fixture 名稱拼寫錯誤把 conftest.py 放在正確層級用pytest --fixtures查看可用 fixture參數(shù)化用例失敗報錯信息不明確參數(shù)列表性能問題或數(shù)據(jù)格式不對先單獨執(zhí)行該參數(shù)組合定位用-v查看完整參數(shù)信息并行執(zhí)行時用例互相影響共享了數(shù)據(jù)庫、文件或全局變量每個進程使用獨立數(shù)據(jù)避免修改全局狀態(tài)UI 用例偶發(fā)失敗本地能過 CI 掛元素加載慢、頁面渲染不穩(wěn)使用顯式等待失敗重試 2~3 次檢查是否為網(wǎng)絡(luò)環(huán)境差異斷言失敗后看不到期望值和實際值斷言寫得太簡單用自定義斷言消息用 Allure 報告附加上下文8.2 我踩過的 4 個高頻坑第一個坑是 conftest.py 的層級放錯了。有一次我把一個 session 級別的 fixture 放在某個子目錄的 conftest.py 里結(jié)果其他目錄的用例全部報“fixture not found”。排查了半天才意識到 fixture 的可見范圍是包含其所在目錄及其子目錄的兄弟目錄根本看不到。后來我養(yǎng)成了習(xí)慣公共 fixture 一律放在測試根目錄的 conftest.py子目錄只放該模塊特有的 fixture。第二個坑是 fixture 返回的可變對象被用例修改了。有一個用例里對 fixture 返回的列表執(zhí)行了append操作后面運行的用例發(fā)現(xiàn)列表里多了一條數(shù)據(jù)斷言掛得很冤。從那以后我對 session 級別的 fixture 特別小心凡是返回可變對象的要么返回不可變版本要么在每個用例里 copy 一份再操作。第三個坑是參數(shù)化組合爆炸。一開始圖省事把三個參數(shù)的所有組合都列在parametrize列表里20 個參數(shù)組合直接讓測試時間翻了 3 倍。后來我學(xué)會了在測試數(shù)據(jù)里做篩選冒煙測試環(huán)境只跑關(guān)鍵組合全量回歸才跑完整數(shù)據(jù)組合用標(biāo)記機制分流執(zhí)行時間立刻降下來了。第四個坑很隱蔽是編碼問題。Windows 環(huán)境下跑 pytest用例里包含中文斷言時控制臺輸出亂碼或直接報 UnicodeDecodeError。后來在pytest.ini里加了一行配置就解決了[pytest] addopts -p no:cacheprovider這行配置的作用是關(guān)閉 pytest 的緩存插件通過插件層面的跳過來繞開某些 Windows 環(huán)境下的編碼陷阱。具體來說這個插件在某些場景下會對測試文件的緩存與寫入產(chǎn)生影響尤其在控制臺代碼頁不是 UTF-8 時容易引發(fā)亂碼問題關(guān)閉掉之后清爽很多。如果你在 Linux 或 macOS 上開發(fā)基本不會遇到這個坑但 Windows 用戶一定要記住這個配置。9. 學(xué)習(xí)路徑與擴展方向建議9.1 從 Pytest 走向自動化測試全棧Pytest 是自動化測試的一個入口但不是終點。我的建議是先夯實基礎(chǔ)再往外擴展?；A(chǔ)階段要掌握 Python 語法、requests 庫、Pytest 核心功能、數(shù)據(jù)驅(qū)動、接口測試基本流程。這階段大概需要 4 到 6 周每天花 1 到 2 小時實操是能比較扎實完成的。進階階段可以往幾個方向拓展一是接 CI/CD把測試工程接入 Jenkins 或 GitHub Actions理解整個研發(fā)交付鏈路二是做自定義插件比如寫一個 Pytest 插件來自動統(tǒng)計用例耗時、自動生成測試報告三是往性能測試和安全測試方向延伸這時候 Pytest 依然可以用它不只是功能測試的專屬工具。給大家一條我自己的學(xué)習(xí)路徑參考先寫 50 條接口用例覆蓋 get/post/put/delete 四種方法掌握參數(shù)化和 fixture把工程結(jié)構(gòu)規(guī)范化引入 Allure 報告接上 Jenkins 定時任務(wù)再學(xué) Playwright 或 Selenium把核心用戶路徑做成 UI 自動化用例回頭重構(gòu)公共方法抽出數(shù)據(jù)驅(qū)動框架寫自定義斷言和工具庫嘗試用 pytest-xdist 做分布式執(zhí)行優(yōu)化整套測試工程執(zhí)行效率每個階段都要實際跑出效果來別在課程視頻上停留太久動手寫過代碼才算真正掌握。9.2 一個經(jīng)驗如何讓團隊接受自動化測試最后想聊一個技術(shù)之外的問題。很多測試同學(xué)學(xué)會 Pytest 后在團隊里推自動化測試卻遇到阻力開發(fā)覺得測試腳本沒用領(lǐng)導(dǎo)覺得投入產(chǎn)出不高。我的體會是自動化測試的落地不只是技術(shù)活更是管理活。從 Pytest 的視角看你需要讓報告會說話。Allure 報告里的用例通過率、失敗分布、執(zhí)行耗時能直觀地告訴團隊目前的質(zhì)量狀況和風(fēng)險點。先把一兩個核心模塊的自動化做起來用真實的數(shù)據(jù)證明它能發(fā)現(xiàn)多少 bug、節(jié)省多少回歸時間再逐漸擴大范圍比一上來就鋪開全量自動化要穩(wěn)妥得多。說實話Pytest 本身值得寫的東西太多一篇文章不可能面面俱到。我盡量把從選型到實戰(zhàn)、從接口到 UI、從本地調(diào)試到 CI 集成的完整路徑串了一遍也希望各位能在自己的項目中把這些經(jīng)驗落地驗證一遍。代碼寫多了自然會有手感坑踩多了自然會有經(jīng)驗。自動化測試這條路入門不需要太高的天賦但持續(xù)走下去一定會有豐厚的回報。