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