簡介一份測試開發(fā)崗位的實習報告完整記錄了實習生參與運輸網(wǎng)站安全項目上線的全過程。報告從實習目的與背景講起詳細展開需求評審、需求分析、測試計劃、用例設計、測試環(huán)境搭建、執(zhí)行測試、BUG跟蹤、測試報告八個核心環(huán)節(jié)并梳理了白盒/黑盒/灰盒、靜態(tài)/動態(tài)、單元/集成/系統(tǒng)等測試方法分類以及BUG提交單的構成要素和實操壓力測試案例。適合軟件測試初學者、計算機專業(yè)學生及準備測試開發(fā)實習的人群參考。資源為單個doc文檔共1個文件壓縮包大小24KB目前已有442人學習下載。內容結構完整包含真實項目測試流程、壓力測試中Linux文件句柄限制的排錯思路等能為讀者提供測試開發(fā)崗位的實際工作認知和實習報告撰寫參考。1. 壓力測試從 1000 到 90000測試開發(fā)實習里最能打的一段調優(yōu)經(jīng)歷第一天上手壓力測試我以為把客戶端連接數(shù)開到 10 萬就能測出服務器上限。結果客戶端跑起來不到兩秒連接數(shù)停在 1000 出頭不再上漲——不是服務器扛不住并發(fā)而是 Linux 默認只給當前用戶開了 1024 個文件描述符扣掉標準輸入輸出和服務端監(jiān)聽 socket 占用的那十來個真正能分給客戶端連接的只剩 1014 個。測試開發(fā)崗位的第一個完整任務就是把這 1014 個連接一路調到 9 萬多。這篇文章把這段經(jīng)歷完整拆開從測試全流程、Bug 單怎么寫到壓力測試里文件描述符、端口范圍、TIME_WAIT 三層限制的逐級突破最后落到 pytest 自動化登錄測試的落地方式。想做測試開發(fā)的新手可以跟著走一遍寫過一段時間用例的人也能在參數(shù)細節(jié)里翻到一些值得對照的東西。2. 測試開發(fā)日常工作流需求評審、用例設計到 Bug 單落地的關鍵細節(jié)2.1 測試流程八階段每個階段回答什么問題產(chǎn)出什么正式接手壓測之前先跟著測試主管完整走了一遍運輸網(wǎng)站上線前的測試流程。看起來是八個階段但每個階段其實都在回答一個具體問題產(chǎn)物也不只是文檔而是下一階段的輸入。把這個問題和產(chǎn)出物對齊流程才不會變成形式。階段要回答的問題核心產(chǎn)出需求評審需求文檔是否自洽有沒有描述不清或互相矛盾的地方評審結論與問題清單需求分析目標系統(tǒng)必須完成哪些工作范圍邊界在哪功能清單、需求分析說明測試計劃需要多少人力、設備時間怎么排功能點如何劃分測試計劃、資源排期用例設計哪些輸入組合能覆蓋功能點和邊界條件測試用例集測試環(huán)境軟件、硬件、網(wǎng)絡、測試數(shù)據(jù)、工具是否滿足測試要求環(huán)境檢查單、環(huán)境配置基線執(zhí)行測試按用例跑程序實際結果和預期是否一致缺陷記錄、測試執(zhí)行結果Bug 跟蹤提交的缺陷是否修復修復有沒有引入新問題回歸結果、Bug 關閉記錄測試報告當前版本質量是否達到上線標準測試報告、缺陷分析這個表格里的順序不能亂尤其是需求評審和需求分析很多人會把它們合并成“看一下需求”但評審的核心是“找問題”分析的核心是“定范圍”。當時在運輸網(wǎng)站這個項目上需求評審階段就發(fā)現(xiàn)一處業(yè)務規(guī)則描述前后矛盾——用戶修改密碼后舊 token 是否立即失效文檔里寫了兩種結論。如果這個矛盾沒有在評審階段暴露后面用例設計、執(zhí)行、回歸全部都會跟著返工。每個階段把上階段的產(chǎn)出當作輸入問題越早發(fā)現(xiàn)返工成本越低。2.2 測試方法選型白盒、黑盒、灰盒與階段劃分怎么對應實踐測試方法從不同視角有不同的分類方式但落到日常測試開發(fā)工作里選型邏輯比記憶分類本身更重要。從是否關心軟件內部結構來看白盒測試要讀代碼、分析邏輯路徑一般由開發(fā)人員自己做的單元測試覆蓋黑盒測試完全不看內部實現(xiàn)只驗證輸入輸出是否符合需求是功能測試和系統(tǒng)測試最常用的方式灰盒測試介于兩者之間關注接口報文、數(shù)據(jù)流不關心內部具體實現(xiàn)——接口自動化測試基本都屬于這一類。從是否執(zhí)行代碼的角度靜態(tài)測試靠代碼評審和靜態(tài)掃描工具做動態(tài)測試靠真正運行程序做。按開發(fā)階段劃分的單元、集成、確認、系統(tǒng)、驗收、回歸這六類日常工作里接觸最多的是系統(tǒng)測試和回歸測試。在運輸網(wǎng)站這個項目里主營業(yè)務的登錄、訂單、運單查詢走的是黑盒功能測試接口自動化接近灰盒視角安全相關專項測試則要結合系統(tǒng)配置、權限矩陣做系統(tǒng)級驗證。選型的關鍵不是哪種方法更高級而是被測對象處于什么階段、缺陷最容易藏在哪一層。一般情況下業(yè)務功能層面的缺陷用黑盒用例就能暴露接口層的字段校驗和異常處理要靠灰盒接口用例兜底涉及性能和安全的部分才需要專門的壓測與安全測試介入。2.3 用例設計實操從需求拆功能點到邊界數(shù)據(jù)用例設計是測試執(zhí)行前最重要的手工活。當時在主管指導下做登錄模塊用例時用的是一套很樸素的步驟后來發(fā)現(xiàn)這套步驟放到任何業(yè)務模塊都通用。第一從需求文檔里提取功能點。登錄模塊的功能點是正確用戶名和密碼可以登錄、錯誤密碼拒絕登錄、不存在用戶拒絕登錄、空用戶名和空密碼提示必填。第二按功能點拆正常場景和異常場景。正常場景走通主流程異常場景覆蓋提示信息是否準確、系統(tǒng)是否報錯而不是崩潰。第三補充邊界和權限場景。比如密碼長度上下限、用戶名是否區(qū)分大小寫、連續(xù)登錄失敗后是否有鎖定策略。第四把環(huán)境相關的前提寫進前置條件。比如本地數(shù)據(jù)庫是否存在對應測試賬號、是否需要先清空登錄鎖定記錄。這套步驟的關鍵在于“先列功能點再設計數(shù)據(jù)”而不是拿著需求文本直接寫用例。功能點列的越全測試數(shù)據(jù)的針對性越強。用例設計完一定要評審評審時開發(fā)會從實現(xiàn)角度指出一些不可能出現(xiàn)的輸入產(chǎn)品會從業(yè)務角度補充一些真實用戶會做的操作兩輪評審下來遺漏率會明顯下降。2.4 一份定位不靠問的 Bug 單要素與判斷標準實習期間最受用的一句話是優(yōu)秀的 Bug 單開發(fā)不用跑來問測試就能知道怎么重現(xiàn)。判斷一個 Bug 單是否合格不是看描述寫了多少字而是看開發(fā)拿到單子之后能否不依賴任何口述獨立復現(xiàn)問題并理解影響范圍。一份完整的 Bug 單至少要覆蓋 12 類信息所屬系統(tǒng)、發(fā)現(xiàn)的版本、所屬模塊、提交人、錯誤類型、重現(xiàn)概率、嚴重級別、優(yōu)先級、標題、Bug 單號、Bug 內容、附件。其中最容易敷衍的是標題和重現(xiàn)步驟常見錯誤是直接把測試用例的名字復制一遍比如“登錄模塊測試001失敗”這種標題對定位沒有任何幫助。合格的標題應該一句話說清“什么功能在什么條件下出了什么問題”例如“修改密碼后舊 token 仍可訪問訂單接口”。下面是一個可以直接套用的示例字段示例內容所屬系統(tǒng)運輸網(wǎng)站-客戶管理模塊發(fā)現(xiàn)的版本V1.2.3所屬模塊登錄認證錯誤類型代碼錯誤重現(xiàn)概率必現(xiàn)嚴重級別嚴重優(yōu)先級高標題修改密碼后舊 token 仍可請求訂單接口重現(xiàn)步驟1. 登錄獲取 token 2. 修改密碼 3. 攜帶舊 token 請求訂單列表預期結果返回 401要求重新登錄實際結果返回 200 和訂單列表數(shù)據(jù)附件舊 token 請求日志、接口響應截圖提交 Bug 時盡量附上截圖并做標注操作過程說明清楚。字不如圖描述半天的文本信息量可能不如一張帶紅框標注的截圖。重現(xiàn)概率、嚴重級別、優(yōu)先級三個字段要分開填重現(xiàn)概率描述穩(wěn)定性嚴重級別描述對用戶的影響程度優(yōu)先級描述修復的緊迫性。比如一個只在特定瀏覽器出現(xiàn)的頁面布局錯位嚴重級別是“一般”優(yōu)先級可以是“低”但一個會導致用戶訂單數(shù)據(jù)錯亂的場景即使出現(xiàn)概率是“小概率”嚴重級別也必須是“嚴重”優(yōu)先級要提到“高”。填這三個字段時想的不是“這個 bug 多嚴重”而是“如果我是項目負責人看到這張單子會先安排誰處理”。3. TCP 連接壓力測試的三層限制ulimit、端口范圍與 TIME_WAIT 內核參數(shù)3.1 壓測目標與初始現(xiàn)象默認只能建立 1014 個連接壓力測試是進入公司后獨立完成的第一個完整測試任務。被測系統(tǒng)是基于 TCP/IP 的 C/S 架構服務端監(jiān)聽固定端口客戶端通過循環(huán)不斷發(fā)起連接請求目標是驗證服務器最多能響應多少個并發(fā)客戶端連接。每成功建立一個客戶端連接服務端就維護一個連接計數(shù)。用客戶端腳本把目標并發(fā)數(shù)開到 10 萬后連接數(shù)到 1000 出頭就停住了。用ulimit -n查看發(fā)現(xiàn)當前用戶最多同時打開 1024 個文件。Linux 下一切皆文件socket 也是文件描述符的一種每建立一個 TCP 連接就要消耗一個文件描述符1024 個文件描述符扣掉標準輸入、標準輸出、標準錯誤、服務端監(jiān)聽 socket 等固有占用可用的連接名額只剩 1014 個。這就是壓測上不去的第一層瓶頸。3.2 第一層限制文件描述符與 limits.conf文件描述符限制分軟限制和硬限制兩層。軟限制是當前會話內可以隨時調低或調高的值硬限制是軟限制可以到達的上限。直接執(zhí)行ulimit -n 100000會失敗因為修改后的數(shù)值超過了硬限制這是 Linux 防止普通用戶無限消耗系統(tǒng)資源的一道閘門。正確的修改方式是編輯/etc/security/limits.conf給指定用戶配置 nofile 的軟硬限制# 編輯 /etc/security/limits.conf追加以下兩行 # 第一列是用戶名第二列是限制類型第三列是資源項目第四列是數(shù)值 speng soft nofile 100000 speng hard nofile 100000軟限制和硬限制要一起放開只調 soft 不調 hard后續(xù)進程運行中如果嘗試再次提升軟限制仍然會被硬限制擋住。修改后需要重新登錄會話同時要確認/etc/pam.d/login里有session required pam_limits.so這一行否則登錄會話不會去讀取 limits.conf 的配置。這個文件決定的是用戶在登錄階段能不能獲得配置的限額很多人改完 limits.conf 發(fā)現(xiàn)ulimit -n沒變就是漏了 pam 模塊。3.3 第二層限制fs.file-max 與本地端口范圍文件描述符放開之后繼續(xù)壓測仍然遠遠達不到 10 萬而且結果不穩(wěn)定。此時用cat /proc/sys/fs/file-max查看系統(tǒng)級最大文件數(shù)發(fā)現(xiàn)數(shù)值只有一萬多。這個值是根據(jù)內核參數(shù)和硬件資源計算出來的系統(tǒng)級硬上限是所有進程加起來的文件描述符總量不是單個用戶的限制。它受內存影響同一個環(huán)境下不同機器的值可能差很多不能用機器 A 的數(shù)值去倒推機器 B 的容量。繼續(xù)往上走還會遇到端口范圍限制。TCP 連接的四元組是“源 IP、源端口、目標 IP、目標端口”壓測客戶端作為主動連接方每建立一個連接都要占用一個本地端口。端口號只有 16 位最大只能是 65535Linux 默認的本地端口范圍通常是 32768 到 60999可用端口數(shù)有限連接數(shù)自然上不去。修改/etc/sysctl.conf擴大本地端口范圍# 編輯 /etc/sysctl.conf追加 net.ipv4.ip_local_port_range 1024 65535 # 執(zhí)行 sysctl -p 使配置生效1024 以下為特權端口一般不改動65535 是 16 位端口號的上限所以最大只能配置到這個值。修改后理論上能承擔的并發(fā)連接從兩三萬擴展到六萬多但實測仍然達不到 10 萬而且結果時高時低。到這里已經(jīng)能明確判斷問題不在連接數(shù)量的初始配額而在連接的生命周期管理上。3.4 第三層限制TIME_WAIT 堆積與內核參數(shù)用 netstat 統(tǒng)計當前 TCP/IP 連接狀態(tài)分布命令是netstat -an | awk /^tcp/{s[$NF]} END {for(a in s) print a, s[a]}輸出里 TIME_WAIT 數(shù)量非常多。TIME_WAIT 是主動關閉連接的一方在收到對端 FIN 后進入的狀態(tài)默認要等待 2 個 MSL最大報文段生存時間通常是 60 秒左右。壓測場景下客戶端每建一個連接就斷開大量連接短時間進入 TIME_WAIT舊的連接還沒釋放完新的連接已經(jīng)占不到端口和連接表項了。這才是連接數(shù)上不去的根本原因。在 /etc/sysctl.conf 里追加一組連接回收相關的內核參數(shù)# 開啟 TIME_WAIT socket 重用允許將其用于新的 TCP 連接 net.ipv4.tcp_tw_reuse 1 # 開啟 TIME_WAIT socket 快速回收內核 4.12 后已移除新環(huán)境勿用 net.ipv4.tcp_tw_recycle 0 # 縮短 TIME_WAIT 等待時間這里設置為 5 秒 net.ipv4.tcp_fin_timeout 5 # 加大 SYN 隊列長度容納更多等待連接的請求 net.ipv4.tcp_max_syn_backlog 8192這里有一個容易踩的坑原文資料里寫的net.ipv4.tcp_tw_fin_timewait參數(shù)名是錯的內核里對應的是net.ipv4.tcp_fin_timeout直接照抄舊參數(shù)名sysctl -p會報“沒有這個鍵”。另一個坑是tcp_tw_recycle它在 Linux 4.12 版本已經(jīng)被移除而且它在 NAT 環(huán)境下開啟會導致隨機丟包讓部分用戶連接異?！，F(xiàn)在的新環(huán)境不要開 recycle用tcp_tw_reuse配合縮短tcp_fin_timeout就夠用。當年在實習環(huán)境里開啟后確實大幅回收了 TIME_WAIT但那是舊內核下的行為換成生產(chǎn)環(huán)境不能照搬。調優(yōu)之后重新執(zhí)行壓測連接數(shù)從一萬多穩(wěn)步上升到 9 萬多接近預設的 10 萬目標。整個鏈路整理下來是這樣一個遞進關系限制層級關鍵配置生效方式常見坑文件描述符ulimit -n / limits.conf重新登錄、pam_limits.so只改 soft 不改 hard或漏掉 pam 模塊系統(tǒng)文件數(shù)fs.file-max內核自動計算系統(tǒng)級上限受硬件資源影響端口范圍ip_local_port_rangesysctl -p16 位上限最大只能 65535連接回收tcp_tw_reuse / tcp_fin_timeoutsysctl -ptw fin 參數(shù)名易寫錯recycle 新內核已移除3.5 客戶端壓測腳本循環(huán)建連與并發(fā)控制調優(yōu)過程中用到的壓測腳本并不復雜核心就是循環(huán)建連加并發(fā)控制。用 Python 的 socket 和 threading 就可以完成# load_test.py import socket import threading import time target_ip 192.168.1.100 # 被測服務端地址 target_port 8080 # 被測服務端端口 target_count 100000 # 目標連接總數(shù) success 0 # 成功連接計數(shù) lock threading.Lock() # 線程安全計數(shù)器 def connect_once(): global success try: s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(3) s.connect((target_ip, target_port)) with lock: success 1 time.sleep(600) # 保持連接讓服務端維持并發(fā)數(shù)量 except Exception as e: print(str(e)[:80]) # 只打印錯誤片段避免刷屏 threads [] for i in range(target_count): t threading.Thread(targetconnect_once) t.start() threads.append(t) time.sleep(0.001) # 減緩建連速率避免客戶端句柄瞬間耗盡 for t in threads: t.join() print(success:, success)connect_once里每個線程建立一個 socket 連接成功后保持連接不釋放這樣服務端的并發(fā)連接數(shù)才會持續(xù)累計。time.sleep(0.001)控制建連速率毫秒級間隔可以讓連接請求更接近生產(chǎn)環(huán)境的真實到達模式避免瞬間打滿客戶端自身資源導致誤判。計數(shù)用 lock 保護因為多線程下對 success 的并發(fā)寫會導致計數(shù)丟失。注意客戶端自身也有文件描述符上限如果目標是 10 萬連接單機客戶端不一定能扛住常見做法是拆成多臺壓測機分布式執(zhí)行或者用協(xié)程替代線程降低客戶端資源占用。4. pytest 自動化測試實現(xiàn)fixture 前置處理與 parametrize 參數(shù)化登錄用例4.1 為什么是 pytestfixture、參數(shù)化和斷言機制壓力測試解決的是“服務器能扛多少”的問題自動化測試解決的是“每次改版后這些功能還能不能跑通”的問題。公司自動化測試選了 pytest 框架原因集中在三點fixture 可以復用測試前置邏輯parametrize 可以天然生成用例組合斷言直接使用 Python 原生 assert不需要額外學習一套斷言 API。比起 unittest 的類繼承結構pytest 函數(shù)式的組織方式對測試開發(fā)更友好寫起來也短很多。4.2 fixture執(zhí)行前的準備和執(zhí)行后的清理fixture 用來處理“執(zhí)行測試前需要做的事”和“執(zhí)行測試后需要收尾的事”。登錄測試場景里每個用例執(zhí)行前需要清理掉上次登錄失敗留下的鎖定記錄用例執(zhí)行后需要把環(huán)境復位避免影響下一個用例。這兩件事在 pytest 里用一個 fixture 就能完成# test_login.py 中的 fixture 定義 import pytest from login import login # 被測函數(shù)實際項目中對應登錄接口封裝 pytest.fixture def clean_login_lock(): # 用例執(zhí)行前清空登錄失敗鎖定記錄 print(clean login lock records) yield # yield 之前是前置yield 之后是清理 # 用例執(zhí)行后復位環(huán)境 print(reset environment)yield 之前的代碼在用例執(zhí)行前運行yield 之后的代碼在用例結束后運行不管用例通過還是失敗清理代碼都會執(zhí)行。這一點比在用例里手動寫 try/finally 干凈很多。如果多個測試文件都需要這個 fixture就把它放到 conftest.py 里pytest 會自動發(fā)現(xiàn)不需要顯式 import。4.3 parametrize 參數(shù)化登錄用例組合與 ids 可讀化登錄測試的特點是同一個入口、多組輸入數(shù)據(jù)。用 mark.parametrize 把用例數(shù)據(jù)抽出來一組參數(shù)就是一條用例不需要為每個輸入組合寫一個測試函數(shù)。參數(shù)化配合 ids 可以讓每條用例在測試報告中顯示為可讀的名稱方便定位是哪組數(shù)據(jù)掛在哪個用例上# test_login.py pytest.mark.parametrize( username, password, expected_code, [ (admin, admin123, 0), # 正確憑證預期成功 (admin, wrong, 1), # 密碼錯誤預期拒絕 (guest, guest123, 1), # 無權限用戶預期拒絕 (, , 1), # 空用戶名和密碼預期提示必填 ], ids[correct, wrong-password, no-permission, empty-fields] ) def test_login(clean_login_lock, username, password, expected_code): result login(username, password) assert result[code] expected_codeparametrize 第一個參數(shù)是參數(shù)字段名第二個參數(shù)是數(shù)據(jù)列表ids 負責給每個組合起名。執(zhí)行時 pytest 會把 username、password、expected_code 三組值注入到測試函數(shù)里每組數(shù)據(jù)生成一條獨立用例。fixture 參數(shù)放在 parametrize 參數(shù)之前pytest 會自動先執(zhí)行 fixture 再執(zhí)行用例。實際項目中 login 函數(shù)通常替換為 requests.post 調登錄接口返回值從字典變成了接口響應但測試結構完全一致。4.4 運行與結果解讀在項目目錄下執(zhí)行pytest test_login.py -v-v 參數(shù)輸出每條用例的詳細執(zhí)行結果可以看到類似下面的輸出test_login.py::test_login[correct] PASSED test_login.py::test_login[wrong-password] PASSED test_login.py::test_login[no-permission] PASSED test_login.py::test_login[empty-fields] PASSED方括號里的內容就是 ids 設置的名字。如果某條用例失敗pytest 會把 assert 前后的實際值和預期值直接對比展示出來不用加額外的日志就能看到是哪里不匹配。這里有個細節(jié)parametrize 里如果數(shù)據(jù)量很大比如要跑幾十組賬號密碼組合ids 不寫也可以pytest 會自動用參數(shù)值做標識但參數(shù)值包含特殊字符時會很難讀所以 ids 建議在用例矩陣固定后統(tǒng)一補充。5. 壓測與回歸的工程化技巧環(huán)境體檢腳本、JVM 內存防 OOM 與 Jenkins 接入5.1 壓測前環(huán)境體檢腳本壓測調優(yōu)踩過的坑第二次就不該用試錯方式再走一遍。把三類限制和連接狀態(tài)統(tǒng)計寫成一個體檢腳本壓測前先跑一遍確認每一項都處于放開狀態(tài)效率會比邊壓測邊查高很多#!/bin/bash # 壓測前體檢逐項打印資源限制和連接狀態(tài) echo 當前進程文件描述符上限 ulimit -n echo 系統(tǒng)級文件描述符上限 cat /proc/sys/fs/file-max echo 本地端口范圍 cat /proc/sys/net/ipv4/ip_local_port_range echo 連接回收相關內核參數(shù) sysctl net.ipv4.tcp_tw_reuse net.ipv4.tcp_fin_timeout net.ipv4.tcp_max_syn_backlog 2/dev/null echo 目標端口連接狀態(tài)分布 netstat -an | grep :8080 | awk {print $6} | sort | uniq -c最后一行統(tǒng)計目標端口當前 TCP 狀態(tài)分布用sort | uniq -c做分組計數(shù)可以直接看到 ESTABLISHED 和 TIME_WAIT 的數(shù)量級。判斷邏輯很簡單TIME_WAIT 數(shù)量持續(xù)增長說明回收參數(shù)沒生效ulimit 值低于預期說明 limits.conf 或 pam 配置不對端口范圍最大值小于 65535說明 sysctl.conf 沒有加載成功。5.2 壓測客戶端的 JVM 內存配置與 OOM壓測過程中服務端會不斷優(yōu)化但客戶端自身也會成為瓶頸。如果壓測工具是基于 JVM 的比如 Gatling 或自研的 Java 壓測客戶端高并發(fā)下最容易出現(xiàn)的是堆內存溢出和頻繁 Full GC。每個 socket 連接在 JVM 內部對應著對象和緩沖區(qū)連接數(shù)上來之后堆內存占用會快速膨脹。開發(fā)測試階段就合理設置 JVM 運行內存能提前避免這類 OOM 問題java -Xms2g -Xmx4g -XX:UseG1GC -XX:MaxDirectMemorySize1g -jar load-client.jar-Xms 和 -Xmx 控制堆內存的初始值和最大值壓測工具建議把兩者設置為相同值避免運行中動態(tài)擴容引發(fā)停頓。-XX:MaxDirectMemorySize 限制堆外直接內存NIO 場景下 socket 讀寫緩沖走的是直接內存這個值太小同樣會拋 OOM。還要注意給操作系統(tǒng)預留余量堆內存加直接內存不要超過物理內存的 70%否則內存換出會直接拉高壓測延遲測出來的數(shù)據(jù)失真。5.3 把 pytest 用例接進 Jenkins 做發(fā)版回歸壓測確認容量自動化測試守住功能兩者最終要在持續(xù)集成里匯合。Jenkins 的構建任務里加一個執(zhí)行 shell 的構建步驟跑pytest test_login.py -v --junitxmlreport.xmlpytest 會把結果輸出成 JUnit 格式的 XMLJenkins 再配一個 JUnit 插件把 XML 解析成趨勢圖每次發(fā)版前自動跑一遍登錄用例。用例少的時候這個流程看不出優(yōu)勢但用例集到幾百條之后手動回歸一次要一兩個小時Jenkins 自動跑只需要幾分鐘而且每次代碼提交都能觸發(fā)不用等人想起來才執(zhí)行。本文還有配套的精品資源點擊獲取