化實(shí)戰(zhàn)：RestAssured+TestNG+Allure構(gòu)建博客系統(tǒng)測(cè)試框架)
做了小半年博客接口自動(dòng)化從零搭了一套 Java RestAssured TestNG Allure 的工程中間踩的坑比寫的用例還多。這篇東西不聊虛的直接把整個(gè)實(shí)戰(zhàn)過程拆開講怎么選型、怎么設(shè)計(jì)用例、怎么處理依賴數(shù)據(jù)、怎么接 CI 定時(shí)跑最后把常見問題也一并整理了。博客系統(tǒng)是我見過最適合練手接口自動(dòng)化的業(yè)務(wù)場(chǎng)景沒有之一。用戶、文章、評(píng)論、標(biāo)簽、分類這些模塊互相關(guān)聯(lián)接口數(shù)量適中既有基礎(chǔ) CRUD又有帶鑒權(quán)的復(fù)雜操作還有分頁、搜索、權(quán)限校驗(yàn)這些典型邏輯。把這套系統(tǒng)的接口自動(dòng)化做透了換到任何業(yè)務(wù)系統(tǒng)都不會(huì)慌。1. 項(xiàng)目拆解為什么博客系統(tǒng)是練接口自動(dòng)化的好靶場(chǎng)1.1 被測(cè)系統(tǒng)的模塊與核心鏈路先說我選定的博客系統(tǒng)采用了前后端分離的架構(gòu)后端是 Spring Boot 構(gòu)建的 RESTful API前端獨(dú)立部署測(cè)試只針對(duì)后端的接口層。這種架構(gòu)方式其實(shí)比單體傳統(tǒng) Web 應(yīng)用更適合做接口自動(dòng)化因?yàn)樗薪换ザ纪ㄟ^ HTTP JSON 完成天然就是為接口測(cè)試設(shè)計(jì)的。博客系統(tǒng)的核心模塊可以拆成這幾個(gè)用戶模塊注冊(cè)、登錄、獲取個(gè)人信息、更新資料、修改密碼文章模塊創(chuàng)建文章、編輯文章、刪除文章、文章列表分頁、文章詳情評(píng)論模塊發(fā)表評(píng)論、刪除評(píng)論、評(píng)論列表標(biāo)簽與分類模塊創(chuàng)建標(biāo)簽、查詢標(biāo)簽、按分類篩選文章文件上傳模塊圖片上傳主要用于文章封面模塊之間不是孤立的存在明顯的依賴關(guān)系用戶先注冊(cè)登錄拿到 Token才能創(chuàng)建文章文章創(chuàng)建成功后才能往這篇文章下面發(fā)表評(píng)論標(biāo)簽要在文章創(chuàng)建時(shí)綁定。這種依賴鏈路恰恰是接口自動(dòng)化測(cè)試設(shè)計(jì)中最需要注意的地方它決定了測(cè)試用例的執(zhí)行順序和數(shù)據(jù)準(zhǔn)備方式。1.2 接口自動(dòng)化要解決的問題不只是“能通不通”很多人做接口自動(dòng)化只停留在“調(diào)通接口斷言狀態(tài)碼是 200”這個(gè)層面。這個(gè)階段只能叫接口冒煙測(cè)試價(jià)值很有限。真正有意義的接口自動(dòng)化至少要覆蓋三個(gè)層次的問題功能正確性、業(yè)務(wù)規(guī)則、數(shù)據(jù)一致性。功能正確性就是最基礎(chǔ)的請(qǐng)求參數(shù)組合正確接口返回預(yù)期的數(shù)據(jù)結(jié)構(gòu)正常流程能走通。業(yè)務(wù)規(guī)則會(huì)更復(fù)雜一點(diǎn)未登錄用戶不能創(chuàng)建文章、不能刪除別人的評(píng)論、文章標(biāo)題超過長(zhǎng)度限制會(huì)被截?cái)嗷蚓芙^、評(píng)論內(nèi)容為空會(huì)被攔截。這些規(guī)則分布在接口的各個(gè)處理邏輯里必須通過用例設(shè)計(jì)去覆蓋。數(shù)據(jù)一致性是很多人忽略的創(chuàng)建一篇文章之后列表接口能查到、數(shù)據(jù)庫里的記錄數(shù)和接口返回的 total 值一致、修改用戶昵稱后文章作者名同步更新。這些跨接口、跨模塊的數(shù)據(jù)關(guān)聯(lián)問題只靠“狀態(tài)碼 200”根本發(fā)現(xiàn)不了必須做數(shù)據(jù)庫層的校驗(yàn)。1.3 技術(shù)選型為什么選了 Java RestAssured TestNG這是我第一次在做選型對(duì)比時(shí)列了一張表最終敲定 Java RestAssured TestNG 這套組合。對(duì)比維度RestAssuredHttpClientOkHttpPython Requests接口語義表達(dá)非常好DSL風(fēng)格貼近HTTP自然語言一般模板代碼多較好好斷言能力內(nèi)置JSONPath/Hamcrest斷言鏈?zhǔn)絻?yōu)雅需要自己封裝需要自己封裝需借助 pytest 插件數(shù)據(jù)驅(qū)動(dòng)配合 TestNG DataProvider 很順暢同樣可配合 TestNG同樣可配合 TestNGpytest 參數(shù)化也可以團(tuán)隊(duì)技術(shù)棧與后端Java一致排障成本低Java原生Java原生需另外維護(hù)Python環(huán)境報(bào)告生態(tài)完美集成 Allure集成 Allure 需少量適配同上也可以但稍麻煩選 RestAssured 最關(guān)鍵的一點(diǎn)是它的 API 設(shè)計(jì)邏輯和 HTTP 本身是一致的請(qǐng)求路徑、查詢參數(shù)、請(qǐng)求頭、請(qǐng)求體、響應(yīng)體每個(gè)環(huán)節(jié)都有對(duì)應(yīng)的 DSL 語法寫出來的代碼幾乎可以當(dāng)作接口文檔來讀。它內(nèi)置的 JSONPath 讓響應(yīng)體字段提取變得極其簡(jiǎn)單再配合 Hamcrest 的斷言風(fēng)格一個(gè)接口的完整校驗(yàn)可以濃縮在幾行代碼里完成。TestNG 的數(shù)據(jù)驅(qū)動(dòng)能力和并發(fā)控制是選它的核心理由。接口自動(dòng)化的用例往往是海量的參數(shù)組合驗(yàn)證如果每個(gè)參數(shù)組合都寫一條用例方法代碼會(huì)膨脹到?jīng)]法維護(hù)。DataProvider 功能可以把測(cè)試數(shù)據(jù)從測(cè)試邏輯中完全剝離出來數(shù)據(jù)放在外部文件里用例方法本身只有一套。TestNG 的并發(fā)執(zhí)行機(jī)制也讓后期跑全量用例時(shí)節(jié)省大量時(shí)間普通的 JUnit 在這方面要弱一些。2. 環(huán)境準(zhǔn)備與工程骨架搭建2.1 本地起一個(gè)干凈的博客系統(tǒng)環(huán)境做接口自動(dòng)化環(huán)境隔離是第一原則。我堅(jiān)持用一套獨(dú)立的測(cè)試環(huán)境絕不在開發(fā)環(huán)境上跑自動(dòng)化用例因?yàn)樽詣?dòng)化會(huì)產(chǎn)生大量測(cè)試數(shù)據(jù)會(huì)干擾開發(fā)調(diào)試反過來開發(fā)的改動(dòng)也會(huì)隨時(shí)讓自動(dòng)化用例崩掉。具體操作上在本地用 Docker 起了一個(gè) MySQL 實(shí)例把博客系統(tǒng)的數(shù)據(jù)庫腳本導(dǎo)入進(jìn)去然后直接本地跑起 Spring Boot 服務(wù)。接口地址統(tǒng)一走h(yuǎn)ttp://localhost:8080/api環(huán)境配置放在獨(dú)立的配置文件中和正式庫完全隔離。數(shù)據(jù)庫的表結(jié)構(gòu)雖然不用全背下來但核心的表一定要清楚users、articles、comments、tags、article_tag 關(guān)聯(lián)表。因?yàn)楹竺孀鰯嘌詴r(shí)我需要去查數(shù)據(jù)庫驗(yàn)證數(shù)據(jù)是否真的寫進(jìn)去了需要執(zhí)行 SELECT 語句核心表的字段結(jié)構(gòu)必須足夠熟悉。比如 articles 表里的 status 字段含義、deleted 字段做軟刪除的設(shè)計(jì)都會(huì)直接影響斷言查詢語句的寫法。2.2 Maven 工程目錄與依賴落地工程采用標(biāo)準(zhǔn)的 Maven 多模塊結(jié)構(gòu)但初期其實(shí)單模塊就夠用。我用單個(gè) Maven 工程包名按業(yè)務(wù)分層這樣結(jié)構(gòu)最清晰blog-api-test/ ├── pom.xml ├── src/test/java/ │ ├── com.blog.test/ │ │ ├── base/ # 測(cè)試基類、全局配置 │ │ ├── client/ # API封裝層每個(gè)模塊一個(gè)Client │ │ ├── case/ # 測(cè)試用例層 │ │ ├── model/ # 請(qǐng)求/響應(yīng)數(shù)據(jù)模型 │ │ ├── util/ # 工具類、數(shù)據(jù)庫連接工具 │ │ └── data/ # 測(cè)試數(shù)據(jù)準(zhǔn)備與清理 └── src/test/resources/ ├── config.yaml # 環(huán)境配置 ├── data/ # 測(cè)試數(shù)據(jù)文件 └── testng.xml # TestNG套件配置這個(gè)包結(jié)構(gòu)非常重要的一點(diǎn)是把“用例層”和“操作層”分開。用例層只描述測(cè)試邏輯準(zhǔn)備數(shù)據(jù)→調(diào)用接口→斷言結(jié)果。操作層封裝了具體 HTTP 請(qǐng)求的發(fā)送細(xì)節(jié)。這樣換來一個(gè)直接收益當(dāng)接口地址或參數(shù)名變動(dòng)時(shí)只需要改 Client 封裝層用例層一行都不用動(dòng)。我見過太多人把所有請(qǐng)求邏輯寫在用例方法里接口一變幾十條用例全要改。pom.xml 里核心依賴就四個(gè)RestAssured、TestNG、Allure 適配包、MySQL 驅(qū)動(dòng)另外加一個(gè) snakeyaml 用來解析配置文件dependencies dependency groupIdio.rest-assured/groupId artifactIdrest-assured/artifactId version5.4.0/version scopetest/scope /dependency dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version7.8.0/version scopetest/scope /dependency dependency groupIdio.qameta.allure/groupId artifactIdallure-testng/artifactId version2.24.0/version scopetest/scope /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scopetest/scope /dependency dependency groupIdorg.yaml/groupId artifactIdsnakeyaml/artifactId version2.2/version scopetest/scope /dependency /dependencies2.3 配置分層環(huán)境地址、賬號(hào)、數(shù)據(jù)庫連接怎么管配置文件用了 YAML 格式核心思路是“環(huán)境隔離、配置集中、敏感信息不硬編碼”。我把所有環(huán)境相關(guān)信息集中到一個(gè) config.yaml 里代碼中不出現(xiàn)任何硬編碼的環(huán)境地址和賬號(hào)口令。env: base_url: http://localhost:8080/api blog: admin: username: test_admin password: Test12345 normal_user: username: test_user_01 password: Test67890 db: host: localhost port: 3306 database: blog_test username: blog_test password: Test12345通過一個(gè) ConfigLoader 工具類來讀取這個(gè) YAML在測(cè)試基類中一次性加載到靜態(tài)變量中。這里值得多說一句每個(gè)測(cè)試賬號(hào)的密碼不要用真實(shí)生產(chǎn)密碼也不要用過于簡(jiǎn)單的弱口令因?yàn)樽詣?dòng)化用例會(huì)反復(fù)登錄、反復(fù)修改數(shù)據(jù)賬號(hào)數(shù)據(jù)的穩(wěn)定性直接影響測(cè)試可靠性。關(guān)鍵經(jīng)驗(yàn)環(huán)境配置統(tǒng)一集中在 config.yaml 中好處是換環(huán)境時(shí)只改一個(gè)文件不用改任何測(cè)試代碼。我花了不少時(shí)間硬編碼后來環(huán)境和代碼分離后切換測(cè)試環(huán)境從一小時(shí)縮短到一條命令。3. 用例設(shè)計(jì)把博客業(yè)務(wù)拆成可自動(dòng)化的測(cè)試場(chǎng)景3.1 業(yè)務(wù)鏈路梳理與用例優(yōu)先級(jí)劃分寫用例之前我先把博客系統(tǒng)的核心業(yè)務(wù)鏈路畫出來用文字描述從用戶的視角走一遍完整流程注冊(cè)新用戶→登錄→查看首頁文章列表→查看文章詳情→創(chuàng)建文章→修改文章→發(fā)表評(píng)論→查看評(píng)論→刪除評(píng)論→刪除文章→退出登錄。這條主鏈路覆蓋了系統(tǒng)最核心的功能優(yōu)先級(jí)最高任何一次接口改動(dòng)都優(yōu)先保證這條鏈路是通的。第二優(yōu)先級(jí)是權(quán)限和邊界用例未登錄創(chuàng)建文章、未登錄刪除評(píng)論、普通用戶刪除他人文章、重復(fù)用戶名注冊(cè)、空標(biāo)題創(chuàng)建文章、超長(zhǎng)內(nèi)容評(píng)論、分頁參數(shù)非法取值等。這類用例的價(jià)值在于不是驗(yàn)證“功能能跑通”而是驗(yàn)證“系統(tǒng)在異常輸入下是否頂?shù)米 薄５谌齼?yōu)先級(jí)才是數(shù)據(jù)維度的校驗(yàn)數(shù)據(jù)庫落庫數(shù)據(jù)是否與接口返回一致、列表總數(shù)是否正確、評(píng)論數(shù)統(tǒng)計(jì)是否正確、文章軟刪除后列表是否還顯示。自動(dòng)化測(cè)試需要數(shù)據(jù)庫層面校驗(yàn)時(shí)我會(huì)在用例中把 SQL 校驗(yàn)和接口響應(yīng)校驗(yàn)放在一起形成“接口數(shù)據(jù)庫”雙重?cái)嘌浴?.2 登錄鑒權(quán)與統(tǒng)一 Token 管理登錄是幾乎所有接口的前置條件Token 管理做不好后續(xù)用例全部受影響。博客系統(tǒng)采用的是 JWT 方案登錄成功后返回 Token后續(xù)請(qǐng)求在 request header 中攜帶Authorization: Bearer token。我用一個(gè)全局 TokenManager 來處理所有與鑒權(quán)相關(guān)的邏輯核心思路是每個(gè)測(cè)試賬號(hào)的 Token 只獲取一次之后進(jìn)入全局緩存用同一個(gè) Token 跑完全部用例絕不每個(gè)用例都重新登錄。這樣做的原因很簡(jiǎn)單——登錄接口也有成本和延遲每個(gè)用例都登錄一遍會(huì)讓整體執(zhí)行時(shí)間翻倍而且頻繁登錄可能觸發(fā)系統(tǒng)限流。public class TokenManager { private static MapString, String tokenCache new ConcurrentHashMap(); public static String getToken(String username, String password) { String cached tokenCache.get(username); if (cached ! null !isTokenExpired(cached)) { return cached; } String newToken doLogin(username, password); tokenCache.put(username, newToken); return newToken; } private static String doLogin(String username, String password) { return given() .contentType(ContentType.JSON) .body({\username\:\ username \,\password\:\ password \}) .post(/auth/login) .then() .statusCode(200) .extract().path(data.token); } }Token 過期是個(gè)很實(shí)際的問題。JWT 一般有有效期如果 Token 過期后面的用例會(huì)集體報(bào) 401。在框架層我做了兩個(gè)兜底方案第一是 Token 即將過期前會(huì)自動(dòng)重新獲取在獲取時(shí)判斷剩余有效期第二是在斷言層加邏輯如果收到 401 響應(yīng)就重新登錄后再重試一次該請(qǐng)求。實(shí)際跑下來后后一個(gè)方案更簡(jiǎn)單有效前一個(gè)需要解析 JWT 內(nèi)容增加復(fù)雜度但收益不大。3.3 四層斷言狀態(tài)碼、業(yè)務(wù)碼、字段、數(shù)據(jù)庫接口自動(dòng)化測(cè)試決不能在斷言上任性只斷言一個(gè) HTTP 狀態(tài)碼遠(yuǎn)不夠。經(jīng)過這個(gè)項(xiàng)目我把斷言拆成了四層每一層都有明確用途第一層是 HTTP 狀態(tài)碼斷言它只能證明“網(wǎng)絡(luò)層面請(qǐng)求成功/失敗”比如 200 表示服務(wù)器沒有返回 500但不代表業(yè)務(wù)邏輯正確。第二層是業(yè)務(wù)狀態(tài)碼斷言博客系統(tǒng)接口會(huì)返回業(yè)務(wù)碼例如code: 0表示成功、code: 1001表示參數(shù)錯(cuò)誤、code: 1003表示無權(quán)限。這層比 HTTP 狀態(tài)碼更接近業(yè)務(wù)實(shí)際。第三層是核心字段斷言驗(yàn)證返回的 JSON 中關(guān)鍵字段的值是否符合預(yù)期比如創(chuàng)建文章后返回的articleId不為空、列表第一篇文章的標(biāo)題與提交一致。第四層是數(shù)據(jù)庫斷言直接查詢數(shù)據(jù)庫驗(yàn)證數(shù)據(jù)確實(shí)被正確寫入或修改。下面是一個(gè)典型的四層斷言的完整用例場(chǎng)景是“登錄成功后獲取用戶信息”Test(description 登錄成功后獲取當(dāng)前用戶信息) public void testGetCurrentUserInfo() { String token TokenManager.getToken(ADMIN_USERNAME, ADMIN_PASSWORD); given() .header(Authorization, Bearer token) .when() .get(/user/profile) .then() .statusCode(200) // 第一層HTTP狀態(tài)碼 .body(code, equalTo(0)) // 第二層業(yè)務(wù)碼 .body(data.username, equalTo(test_admin)) // 第三層核心字段 .body(data.email, matchesPattern(..\\..)); }數(shù)據(jù)庫斷言我用了 JDBC 連接工具類核心方法是執(zhí)行傳入的 SQL 并返回結(jié)果然后在用例中斷言數(shù)據(jù)庫查詢結(jié)果。例如創(chuàng)建文章成功后查詢數(shù)據(jù)庫確認(rèn) article 表里多了一條對(duì)應(yīng)記錄且 status 字段為正常狀態(tài)。注意事項(xiàng)數(shù)據(jù)庫斷言不能每一條用例都加否則執(zhí)行效率會(huì)明顯下降。我的原則是“涉及寫操作的核心用例加數(shù)據(jù)庫斷言”讀操作的用例重點(diǎn)做字段校驗(yàn)就夠了。把數(shù)據(jù)庫校驗(yàn)放在創(chuàng)建、更新、刪除這三類操作上性價(jià)比最高。4. 框架落地封裝、數(shù)據(jù)驅(qū)動(dòng)與報(bào)告4.1 API Client 封裝讓用例代碼真正可讀在這個(gè)項(xiàng)目里我體會(huì)最深的是“封裝不是裝飾而是工程化的命脈”。如果不做任何封裝所有接口調(diào)用邏輯平鋪在用例里寫起來非常爽但維護(hù)起來完全是災(zāi)難。換一個(gè)接口地址要翻遍幾十個(gè)用例去改。我按照業(yè)務(wù)模塊劃分了 Client 類每個(gè) Client 負(fù)責(zé)一個(gè)模塊的所有接口操作。以 ArticlesClient 為例它封裝了博客文章模塊的所有接口public class ArticlesClient { private static final String BASE /articles; public static Response createArticle(String token, String title, String content, ListInteger tagIds) { return given() .header(Authorization, Bearer token) .contentType(ContentType.JSON) .body(buildCreateBody(title, content, tagIds)) .post(BASE); } public static Response getArticleList(int page, int size, String keyword) { return given() .queryParam(page, page) .queryParam(size, size) .queryParam(keyword, keyword) .get(BASE /list); } public static Response getArticleDetail(int articleId) { return given().get(BASE / articleId); } public static Response updateArticle(String token, int articleId, String title, String content) { MapString, Object body new HashMap(); body.put(title, title); body.put(content, content); return given() .header(Authorization, Bearer token) .contentType(ContentType.JSON) .body(body) .put(BASE / articleId); } }封裝后的用例層代碼像在讀一篇測(cè)試文檔邏輯一目了然。舉個(gè)例子創(chuàng)建文章并驗(yàn)證的基本用例是這樣的Test(description 創(chuàng)建文章成功后返回文章ID) public void testCreateArticleSuccess() { Response response ArticlesClient.createArticle( TokenManager.getToken(ADMIN_USERNAME, ADMIN_PASSWORD), 自動(dòng)化測(cè)試文章-標(biāo)題, 自動(dòng)化測(cè)試文章-正文內(nèi)容, Arrays.asList(1, 2) ); response.then().statusCode(200).body(code, equalTo(0)); int articleId response.jsonPath().getInt(data.articleId); Assert.assertTrue(articleId 0, 創(chuàng)建文章返回ID應(yīng)該大于0); }這里注意Client 層的方法返回的是 Response 對(duì)象這個(gè)設(shè)計(jì)是有意為之。好處是讓用例層自己決定要做什么斷言和提取什么數(shù)據(jù)Client 層不做過于貼身的斷言保持了靈活性。曾經(jīng)我把斷言也寫進(jìn)了 Client 層后來發(fā)現(xiàn)不同的用例對(duì)同一個(gè)接口斷言的側(cè)重點(diǎn)完全不同塞在一起的代碼反而別扭。4.2 測(cè)試數(shù)據(jù)驅(qū)動(dòng)數(shù)據(jù)準(zhǔn)備與清理閉環(huán)接口自動(dòng)化的測(cè)試數(shù)據(jù)管理是整個(gè)項(xiàng)目成敗的關(guān)鍵也是我覺得最難啃的骨頭。沒有系統(tǒng)化的數(shù)據(jù)管理用例跑幾次之后就互相污染今天能過明天就崩。我的方案分兩部分?jǐn)?shù)據(jù)準(zhǔn)備和數(shù)據(jù)清理。數(shù)據(jù)準(zhǔn)備用兩種方式一種是 TestNG 的 DataProvider適用于參數(shù)化的用例另一種是專門的 TestDataFactory在用例執(zhí)行前通過調(diào)用接口創(chuàng)建所需的數(shù)據(jù)。一個(gè)典型的場(chǎng)景是“創(chuàng)建文章接口的參數(shù)化校驗(yàn)”要求覆蓋標(biāo)題為空、標(biāo)題超長(zhǎng)、內(nèi)容為空、標(biāo)簽不存在、正常提交等多個(gè)參數(shù)組合。我用 DataProvider 把這些數(shù)據(jù)抽到 JSON 文件中[ {title: , content: 內(nèi)容, tagIds: [1], expectCode: 1001, desc: 標(biāo)題為空}, {title: 超長(zhǎng)標(biāo)題 a.repeat(300), content: 內(nèi)容, tagIds: [1], expectCode: 1001, desc: 標(biāo)題超長(zhǎng)}, {title: 正常標(biāo)題, content: , tagIds: [1], expectCode: 1001, desc: 內(nèi)容為空}, {title: 正常標(biāo)題, content: 內(nèi)容, tagIds: [99999], expectCode: 1002, desc: 標(biāo)簽不存在}, {title: 正常標(biāo)題-演示, content: 演示內(nèi)容, tagIds: [1, 2], expectCode: 0, desc: 正常提交} ]配合 DataProvider 加載 JSON一條用例方法秒變五條用例邏輯而且數(shù)據(jù)放在外部文件維護(hù)人員不需要懂代碼就能增刪用例數(shù)據(jù)。數(shù)據(jù)清理這一塊我踩過的坑最深。剛開始沒做清理同一批測(cè)試數(shù)據(jù)反復(fù)創(chuàng)建數(shù)據(jù)庫積累了幾千條“自動(dòng)化測(cè)試文章”垃圾數(shù)據(jù)讓后面的列表用例 total 斷言永遠(yuǎn)對(duì)不上排查起來極其痛苦。后來定了鐵律每個(gè)用到的測(cè)試數(shù)據(jù)都必須在測(cè)試結(jié)束后清掉清理方式首選調(diào)接口刪除接口刪不到的直接 SQL 刪除。4.3 Allure 報(bào)告接入與失敗用例定位報(bào)告選 Allure因?yàn)樗跍y(cè)試領(lǐng)域基本屬于事實(shí)標(biāo)準(zhǔn)。接入主要通過依賴和監(jiān)聽器實(shí)現(xiàn)用一步配置好 Listeners 注解把 TestNG 的執(zhí)行結(jié)果自動(dòng)接入 Allure 引擎。真正讓 Allure 報(bào)告好用的訣竅是在用例中主動(dòng)加入步驟信息。在關(guān)鍵操作前用Allure.step()標(biāo)注操作步驟斷言失敗時(shí)報(bào)告里就能看到精確的操作路徑Test(description 更新文章成功后數(shù)據(jù)庫字段被修改) public void testUpdateArticleUpdatesDatabase() { Allure.step(創(chuàng)建一篇測(cè)試文章作為前置數(shù)據(jù)); int articleId TestDataFactory.createArticle(原始標(biāo)題, 原始內(nèi)容); Allure.step(調(diào)用更新接口修改文章標(biāo)題); Response updateResp ArticlesClient.updateArticle(getToken(), articleId, 新標(biāo)題, 原始內(nèi)容); updateResp.then().statusCode(200); Allure.step(查詢數(shù)據(jù)庫驗(yàn)證標(biāo)題已更新); String dbTitle DbUtil.queryOne(SELECT title FROM articles WHERE id articleId); Assert.assertEquals(dbTitle, 新標(biāo)題); }這樣一來每次失敗用例的排查都非常輕松。打開 Allure 報(bào)告左邊是完整步驟樹哪一步失敗一目了然失敗時(shí)還會(huì)自動(dòng)截取響應(yīng)體和請(qǐng)求體。協(xié)同排查問題時(shí)直接把 Allure 報(bào)告鏈接發(fā)給開發(fā)比在聊天窗口里貼一大段日志高效很多。5. 持續(xù)集成讓接口測(cè)試定時(shí)自動(dòng)跑5.1 用 GitHub Actions 跑自動(dòng)化用例接口自動(dòng)化必須與 CI 結(jié)合才有長(zhǎng)期價(jià)值不能只在本地跑完看一眼就完了。我把博客接口自動(dòng)化工程托管到 GitHub 私有倉(cāng)庫用 GitHub Actions 做持續(xù)集成每次代碼推送自動(dòng)觸發(fā)測(cè)試執(zhí)行。workflow 配置文件的思路不復(fù)雜拉代碼、裝 JDK、跑 Maven 命令、上傳 Allure 報(bào)告、推送結(jié)果通知。核心配置大概是這樣name: Blog API Test CI on: push: branches: [ main ] schedule: - cron: 0 2 * * * # 每天凌晨2點(diǎn)定時(shí)跑 jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up JDK 17 uses: actions/setup-javav3 with: java-version: 17 distribution: temurin - name: Run API tests run: mvn clean test - name: Upload Allure Report uses: actions/upload-artifactv3 with: name: allure-report path: target/allure-results這里值得說清楚的是schedule定時(shí)的價(jià)值。接口自動(dòng)化的主要作用不是守著開發(fā)提交代碼時(shí)跑一遍而是發(fā)現(xiàn)“系統(tǒng)悄悄變了”的問題。數(shù)據(jù)庫連接池耗盡、第三方依賴臨時(shí)掛掉、定時(shí)任務(wù)導(dǎo)致的臟數(shù)據(jù)這些沒有代碼變更也會(huì)發(fā)生的問題正是定時(shí)任務(wù)能發(fā)現(xiàn)的。我個(gè)人把定時(shí)執(zhí)行時(shí)間定在凌晨 2 點(diǎn)原因是這個(gè)時(shí)段業(yè)務(wù)流量低、數(shù)據(jù)庫負(fù)載小如果測(cè)試失敗大概率是代碼或環(huán)境問題而不是偶發(fā)流量干擾。5.2 并發(fā)執(zhí)行、失敗重試與穩(wěn)定性策略用例數(shù)量漲到 100 條以后串行執(zhí)行時(shí)間會(huì)變得非常長(zhǎng)。我在 TestNG 層面啟用了并發(fā)執(zhí)行配置了線程池可以讓執(zhí)行時(shí)間壓縮一半以上。!DOCTYPE suite SYSTEM http://testng.org/testng-1.0.dtd suite nameBlogApiTestSuite parallelmethods thread-count4 test nameBlogApiTests packages package namecom.blog.test.case/ /packages /test /suite并發(fā)執(zhí)行有一個(gè)反直覺的坑測(cè)試數(shù)據(jù)也會(huì)并發(fā)沖突。比如多個(gè)用例同時(shí)在創(chuàng)建文章用于校驗(yàn)列表接口的第一篇文章標(biāo)題就會(huì)互相影響。針對(duì)這個(gè)問題我做了兩件事一是并發(fā)用例間共享的數(shù)據(jù)用獨(dú)立前綴區(qū)分例如“auto_test_并發(fā)標(biāo)識(shí)_當(dāng)前時(shí)間戳”二是核心鏈路的用例串行執(zhí)行只有純查詢類和數(shù)據(jù)隔離良好的用例并發(fā)。失敗重試也很重要。接口測(cè)試跑在真實(shí)環(huán)境上偶發(fā)超時(shí)、連接中斷都會(huì)導(dǎo)致用例失敗但這類失敗不代表系統(tǒng)有 bug。我在框架中寫了一個(gè) RetryListener針對(duì)“連接超時(shí)”“讀超時(shí)”“500 臨時(shí)錯(cuò)誤”這幾類異常做自動(dòng)重試配置了每次最多重試兩次。如果重試后還是失敗基本可以確認(rèn)是系統(tǒng)真實(shí)問題。關(guān)鍵提醒重試機(jī)制只對(duì)“非確定性失敗”有效像斷言失敗這種確定性失敗不能重試重試只會(huì)掩蓋真實(shí)缺陷。我的實(shí)現(xiàn)是只針對(duì)特定異常類型重試而不是盲目重跑所有失敗用例。6. 常見問題與排查技巧實(shí)錄6.1 我踩過的坑與排查思路整個(gè)項(xiàng)目做下來積累了不少“血淚教訓(xùn)”挑幾個(gè)最典型的分享出來這些坑基本每個(gè)人做接口自動(dòng)化都會(huì)遇到。第一個(gè)坑是測(cè)試數(shù)據(jù)沒有清理這個(gè)前面已經(jīng)提過。最開始跑了兩天數(shù)據(jù)庫里的測(cè)試文章堆成了山。后來建立了“前置創(chuàng)建→用例執(zhí)行→后置清理”的標(biāo)準(zhǔn)流程并且數(shù)據(jù)清理必須用和用例創(chuàng)建方式對(duì)應(yīng)的方式接口能刪的走接口接口刪不到的用 SQL。同時(shí)定期做全庫清掃把歷史殘留的垃圾測(cè)試數(shù)據(jù)一次性清理掉。第二個(gè)坑是 Token 過期的隱蔽問題。JWT Token 有效期設(shè)置的是 2 小時(shí)剛開始用例跑得快時(shí)沒問題后來并發(fā)執(zhí)行時(shí)間拉長(zhǎng)部分用例執(zhí)行時(shí) Token 已經(jīng)過期出現(xiàn)一批莫名其妙的 401 失敗。排查時(shí)看日志才發(fā)現(xiàn)是同一個(gè) Token 在 2 小時(shí)前獲取的后續(xù)用例一直復(fù)用。解決辦法是 TokenManager 中加入有效期檢查并增加 401 自動(dòng)重登重試的兜底邏輯。第三個(gè)坑是響應(yīng)中的時(shí)間戳字段斷言。創(chuàng)建文章接口返回的createTime是毫秒時(shí)間戳每次執(zhí)行都不一樣導(dǎo)致斷言 JSON 時(shí)無法用固定值校驗(yàn)。這類動(dòng)態(tài)字段的策略是只斷言“存在但不為空”或者斷言格式正確而不是斷言具體值。如果一定要斷言范圍就用當(dāng)前時(shí)間前后偏移來校驗(yàn)createTime應(yīng)該在請(qǐng)求發(fā)出前后幾秒內(nèi)。第四個(gè)坑是同學(xué)最容易被坑的接口文檔和實(shí)際行為不一致。文檔寫的是DELETE /articles/{id}實(shí)際接口可能需要加查詢參數(shù)?forcetrue才能徹底刪除文章否則只是軟刪。這提醒我一件事接口自動(dòng)化用例必須基于真實(shí)接口行為寫不能照搬文檔第一次調(diào)試時(shí)先手工調(diào)一遍接口再落用例。6.2 失敗用例快速定位的五步法做了大量用例之后總結(jié)出了一套快速定位失敗用例的方法排查速度提升非常明顯第一步先在 Allure 報(bào)告里看失敗發(fā)生在哪一步。如果失敗步驟是“創(chuàng)建前置數(shù)據(jù)”說明是前置問題和被測(cè)接口本身無關(guān)。第二步看失敗類型是什么斷言失敗是業(yè)務(wù)邏輯問題異常是環(huán)境或者框架問題。第三步打開失敗時(shí)的請(qǐng)求體和響應(yīng)體對(duì)比文檔和要求看是否是參數(shù)傳錯(cuò)或響應(yīng)格式變化。第四步如果是數(shù)據(jù)庫斷言失敗直接執(zhí)行對(duì)應(yīng)的 SQL看數(shù)據(jù)庫實(shí)際數(shù)據(jù)和預(yù)期之間的差異。第五步把這幾個(gè)信息組合起來基本就能判斷失敗原因是業(yè)務(wù)改動(dòng)、數(shù)據(jù)污染還是框架 bug。這個(gè)方法支撐了這套自動(dòng)化用例幾個(gè)月穩(wěn)定運(yùn)行以來的所有問題排查。團(tuán)隊(duì)里同事遇到失敗用例直接按這個(gè)順序查完80% 的情況不再需要問我。關(guān)于這套博客接口自動(dòng)化測(cè)試工程我最后再說一個(gè)自己的體會(huì)真正讓自動(dòng)化有價(jià)值的不是自動(dòng)化本身而是它能持續(xù)地告訴你“系統(tǒng)現(xiàn)在到底行不行”。測(cè)試數(shù)據(jù)的管理、框架封裝的邊界、對(duì)待重試和并發(fā)的心態(tài)這些都是在這個(gè)項(xiàng)目里逐步建立的工程方法。踩坑不可怕怕的是踩完了不總結(jié)那才是真的白做。這套工程跑起來之后我最大的感受是它已經(jīng)成為團(tuán)隊(duì)把控系統(tǒng)質(zhì)量的重要一環(huán)希望這篇實(shí)戰(zhàn)記錄也能幫你少走些彎路。 Java接口自動(dòng)化實(shí)戰(zhàn)：RestAssured+TestNG+Allure構(gòu)建博客系統(tǒng)測(cè)試框架
做了小半年博客接口自動(dòng)化從零搭了一套 Java RestAssured TestNG Allure 的工程中間踩的坑比寫的用例還多。這篇東西不聊虛的直接把整個(gè)實(shí)戰(zhàn)過程拆開講怎么選型、怎么設(shè)計(jì)用例、怎么處理依賴數(shù)據(jù)、怎么接 CI 定時(shí)跑最后把常見問題也一并整理了。博客系統(tǒng)是我見過最適合練手接口自動(dòng)化的業(yè)務(wù)場(chǎng)景沒有之一。用戶、文章、評(píng)論、標(biāo)簽、分類這些模塊互相關(guān)聯(lián)接口數(shù)量適中既有基礎(chǔ) CRUD又有帶鑒權(quán)的復(fù)雜操作還有分頁、搜索、權(quán)限校驗(yàn)這些典型邏輯。把這套系統(tǒng)的接口自動(dòng)化做透了換到任何業(yè)務(wù)系統(tǒng)都不會(huì)慌。1. 項(xiàng)目拆解為什么博客系統(tǒng)是練接口自動(dòng)化的好靶場(chǎng)1.1 被測(cè)系統(tǒng)的模塊與核心鏈路先說我選定的博客系統(tǒng)采用了前后端分離的架構(gòu)后端是 Spring Boot 構(gòu)建的 RESTful API前端獨(dú)立部署測(cè)試只針對(duì)后端的接口層。這種架構(gòu)方式其實(shí)比單體傳統(tǒng) Web 應(yīng)用更適合做接口自動(dòng)化因?yàn)樗薪换ザ纪ㄟ^ HTTP JSON 完成天然就是為接口測(cè)試設(shè)計(jì)的。博客系統(tǒng)的核心模塊可以拆成這幾個(gè)用戶模塊注冊(cè)、登錄、獲取個(gè)人信息、更新資料、修改密碼文章模塊創(chuàng)建文章、編輯文章、刪除文章、文章列表分頁、文章詳情評(píng)論模塊發(fā)表評(píng)論、刪除評(píng)論、評(píng)論列表標(biāo)簽與分類模塊創(chuàng)建標(biāo)簽、查詢標(biāo)簽、按分類篩選文章文件上傳模塊圖片上傳主要用于文章封面模塊之間不是孤立的存在明顯的依賴關(guān)系用戶先注冊(cè)登錄拿到 Token才能創(chuàng)建文章文章創(chuàng)建成功后才能往這篇文章下面發(fā)表評(píng)論標(biāo)簽要在文章創(chuàng)建時(shí)綁定。這種依賴鏈路恰恰是接口自動(dòng)化測(cè)試設(shè)計(jì)中最需要注意的地方它決定了測(cè)試用例的執(zhí)行順序和數(shù)據(jù)準(zhǔn)備方式。1.2 接口自動(dòng)化要解決的問題不只是“能通不通”很多人做接口自動(dòng)化只停留在“調(diào)通接口斷言狀態(tài)碼是 200”這個(gè)層面。這個(gè)階段只能叫接口冒煙測(cè)試價(jià)值很有限。真正有意義的接口自動(dòng)化至少要覆蓋三個(gè)層次的問題功能正確性、業(yè)務(wù)規(guī)則、數(shù)據(jù)一致性。功能正確性就是最基礎(chǔ)的請(qǐng)求參數(shù)組合正確接口返回預(yù)期的數(shù)據(jù)結(jié)構(gòu)正常流程能走通。業(yè)務(wù)規(guī)則會(huì)更復(fù)雜一點(diǎn)未登錄用戶不能創(chuàng)建文章、不能刪除別人的評(píng)論、文章標(biāo)題超過長(zhǎng)度限制會(huì)被截?cái)嗷蚓芙^、評(píng)論內(nèi)容為空會(huì)被攔截。這些規(guī)則分布在接口的各個(gè)處理邏輯里必須通過用例設(shè)計(jì)去覆蓋。數(shù)據(jù)一致性是很多人忽略的創(chuàng)建一篇文章之后列表接口能查到、數(shù)據(jù)庫里的記錄數(shù)和接口返回的 total 值一致、修改用戶昵稱后文章作者名同步更新。這些跨接口、跨模塊的數(shù)據(jù)關(guān)聯(lián)問題只靠“狀態(tài)碼 200”根本發(fā)現(xiàn)不了必須做數(shù)據(jù)庫層的校驗(yàn)。1.3 技術(shù)選型為什么選了 Java RestAssured TestNG這是我第一次在做選型對(duì)比時(shí)列了一張表最終敲定 Java RestAssured TestNG 這套組合。對(duì)比維度RestAssuredHttpClientOkHttpPython Requests接口語義表達(dá)非常好DSL風(fēng)格貼近HTTP自然語言一般模板代碼多較好好斷言能力內(nèi)置JSONPath/Hamcrest斷言鏈?zhǔn)絻?yōu)雅需要自己封裝需要自己封裝需借助 pytest 插件數(shù)據(jù)驅(qū)動(dòng)配合 TestNG DataProvider 很順暢同樣可配合 TestNG同樣可配合 TestNGpytest 參數(shù)化也可以團(tuán)隊(duì)技術(shù)棧與后端Java一致排障成本低Java原生Java原生需另外維護(hù)Python環(huán)境報(bào)告生態(tài)完美集成 Allure集成 Allure 需少量適配同上也可以但稍麻煩選 RestAssured 最關(guān)鍵的一點(diǎn)是它的 API 設(shè)計(jì)邏輯和 HTTP 本身是一致的請(qǐng)求路徑、查詢參數(shù)、請(qǐng)求頭、請(qǐng)求體、響應(yīng)體每個(gè)環(huán)節(jié)都有對(duì)應(yīng)的 DSL 語法寫出來的代碼幾乎可以當(dāng)作接口文檔來讀。它內(nèi)置的 JSONPath 讓響應(yīng)體字段提取變得極其簡(jiǎn)單再配合 Hamcrest 的斷言風(fēng)格一個(gè)接口的完整校驗(yàn)可以濃縮在幾行代碼里完成。TestNG 的數(shù)據(jù)驅(qū)動(dòng)能力和并發(fā)控制是選它的核心理由。接口自動(dòng)化的用例往往是海量的參數(shù)組合驗(yàn)證如果每個(gè)參數(shù)組合都寫一條用例方法代碼會(huì)膨脹到?jīng)]法維護(hù)。DataProvider 功能可以把測(cè)試數(shù)據(jù)從測(cè)試邏輯中完全剝離出來數(shù)據(jù)放在外部文件里用例方法本身只有一套。TestNG 的并發(fā)執(zhí)行機(jī)制也讓后期跑全量用例時(shí)節(jié)省大量時(shí)間普通的 JUnit 在這方面要弱一些。2. 環(huán)境準(zhǔn)備與工程骨架搭建2.1 本地起一個(gè)干凈的博客系統(tǒng)環(huán)境做接口自動(dòng)化環(huán)境隔離是第一原則。我堅(jiān)持用一套獨(dú)立的測(cè)試環(huán)境絕不在開發(fā)環(huán)境上跑自動(dòng)化用例因?yàn)樽詣?dòng)化會(huì)產(chǎn)生大量測(cè)試數(shù)據(jù)會(huì)干擾開發(fā)調(diào)試反過來開發(fā)的改動(dòng)也會(huì)隨時(shí)讓自動(dòng)化用例崩掉。具體操作上在本地用 Docker 起了一個(gè) MySQL 實(shí)例把博客系統(tǒng)的數(shù)據(jù)庫腳本導(dǎo)入進(jìn)去然后直接本地跑起 Spring Boot 服務(wù)。接口地址統(tǒng)一走h(yuǎn)ttp://localhost:8080/api環(huán)境配置放在獨(dú)立的配置文件中和正式庫完全隔離。數(shù)據(jù)庫的表結(jié)構(gòu)雖然不用全背下來但核心的表一定要清楚users、articles、comments、tags、article_tag 關(guān)聯(lián)表。因?yàn)楹竺孀鰯嘌詴r(shí)我需要去查數(shù)據(jù)庫驗(yàn)證數(shù)據(jù)是否真的寫進(jìn)去了需要執(zhí)行 SELECT 語句核心表的字段結(jié)構(gòu)必須足夠熟悉。比如 articles 表里的 status 字段含義、deleted 字段做軟刪除的設(shè)計(jì)都會(huì)直接影響斷言查詢語句的寫法。2.2 Maven 工程目錄與依賴落地工程采用標(biāo)準(zhǔn)的 Maven 多模塊結(jié)構(gòu)但初期其實(shí)單模塊就夠用。我用單個(gè) Maven 工程包名按業(yè)務(wù)分層這樣結(jié)構(gòu)最清晰blog-api-test/ ├── pom.xml ├── src/test/java/ │ ├── com.blog.test/ │ │ ├── base/ # 測(cè)試基類、全局配置 │ │ ├── client/ # API封裝層每個(gè)模塊一個(gè)Client │ │ ├── case/ # 測(cè)試用例層 │ │ ├── model/ # 請(qǐng)求/響應(yīng)數(shù)據(jù)模型 │ │ ├── util/ # 工具類、數(shù)據(jù)庫連接工具 │ │ └── data/ # 測(cè)試數(shù)據(jù)準(zhǔn)備與清理 └── src/test/resources/ ├── config.yaml # 環(huán)境配置 ├── data/ # 測(cè)試數(shù)據(jù)文件 └── testng.xml # TestNG套件配置這個(gè)包結(jié)構(gòu)非常重要的一點(diǎn)是把“用例層”和“操作層”分開。用例層只描述測(cè)試邏輯準(zhǔn)備數(shù)據(jù)→調(diào)用接口→斷言結(jié)果。操作層封裝了具體 HTTP 請(qǐng)求的發(fā)送細(xì)節(jié)。這樣換來一個(gè)直接收益當(dāng)接口地址或參數(shù)名變動(dòng)時(shí)只需要改 Client 封裝層用例層一行都不用動(dòng)。我見過太多人把所有請(qǐng)求邏輯寫在用例方法里接口一變幾十條用例全要改。pom.xml 里核心依賴就四個(gè)RestAssured、TestNG、Allure 適配包、MySQL 驅(qū)動(dòng)另外加一個(gè) snakeyaml 用來解析配置文件dependencies dependency groupIdio.rest-assured/groupId artifactIdrest-assured/artifactId version5.4.0/version scopetest/scope /dependency dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version7.8.0/version scopetest/scope /dependency dependency groupIdio.qameta.allure/groupId artifactIdallure-testng/artifactId version2.24.0/version scopetest/scope /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scopetest/scope /dependency dependency groupIdorg.yaml/groupId artifactIdsnakeyaml/artifactId version2.2/version scopetest/scope /dependency /dependencies2.3 配置分層環(huán)境地址、賬號(hào)、數(shù)據(jù)庫連接怎么管配置文件用了 YAML 格式核心思路是“環(huán)境隔離、配置集中、敏感信息不硬編碼”。我把所有環(huán)境相關(guān)信息集中到一個(gè) config.yaml 里代碼中不出現(xiàn)任何硬編碼的環(huán)境地址和賬號(hào)口令。env: base_url: http://localhost:8080/api blog: admin: username: test_admin password: Test12345 normal_user: username: test_user_01 password: Test67890 db: host: localhost port: 3306 database: blog_test username: blog_test password: Test12345通過一個(gè) ConfigLoader 工具類來讀取這個(gè) YAML在測(cè)試基類中一次性加載到靜態(tài)變量中。這里值得多說一句每個(gè)測(cè)試賬號(hào)的密碼不要用真實(shí)生產(chǎn)密碼也不要用過于簡(jiǎn)單的弱口令因?yàn)樽詣?dòng)化用例會(huì)反復(fù)登錄、反復(fù)修改數(shù)據(jù)賬號(hào)數(shù)據(jù)的穩(wěn)定性直接影響測(cè)試可靠性。關(guān)鍵經(jīng)驗(yàn)環(huán)境配置統(tǒng)一集中在 config.yaml 中好處是換環(huán)境時(shí)只改一個(gè)文件不用改任何測(cè)試代碼。我花了不少時(shí)間硬編碼后來環(huán)境和代碼分離后切換測(cè)試環(huán)境從一小時(shí)縮短到一條命令。3. 用例設(shè)計(jì)把博客業(yè)務(wù)拆成可自動(dòng)化的測(cè)試場(chǎng)景3.1 業(yè)務(wù)鏈路梳理與用例優(yōu)先級(jí)劃分寫用例之前我先把博客系統(tǒng)的核心業(yè)務(wù)鏈路畫出來用文字描述從用戶的視角走一遍完整流程注冊(cè)新用戶→登錄→查看首頁文章列表→查看文章詳情→創(chuàng)建文章→修改文章→發(fā)表評(píng)論→查看評(píng)論→刪除評(píng)論→刪除文章→退出登錄。這條主鏈路覆蓋了系統(tǒng)最核心的功能優(yōu)先級(jí)最高任何一次接口改動(dòng)都優(yōu)先保證這條鏈路是通的。第二優(yōu)先級(jí)是權(quán)限和邊界用例未登錄創(chuàng)建文章、未登錄刪除評(píng)論、普通用戶刪除他人文章、重復(fù)用戶名注冊(cè)、空標(biāo)題創(chuàng)建文章、超長(zhǎng)內(nèi)容評(píng)論、分頁參數(shù)非法取值等。這類用例的價(jià)值在于不是驗(yàn)證“功能能跑通”而是驗(yàn)證“系統(tǒng)在異常輸入下是否頂?shù)米 薄５谌齼?yōu)先級(jí)才是數(shù)據(jù)維度的校驗(yàn)數(shù)據(jù)庫落庫數(shù)據(jù)是否與接口返回一致、列表總數(shù)是否正確、評(píng)論數(shù)統(tǒng)計(jì)是否正確、文章軟刪除后列表是否還顯示。自動(dòng)化測(cè)試需要數(shù)據(jù)庫層面校驗(yàn)時(shí)我會(huì)在用例中把 SQL 校驗(yàn)和接口響應(yīng)校驗(yàn)放在一起形成“接口數(shù)據(jù)庫”雙重?cái)嘌浴?.2 登錄鑒權(quán)與統(tǒng)一 Token 管理登錄是幾乎所有接口的前置條件Token 管理做不好后續(xù)用例全部受影響。博客系統(tǒng)采用的是 JWT 方案登錄成功后返回 Token后續(xù)請(qǐng)求在 request header 中攜帶Authorization: Bearer token。我用一個(gè)全局 TokenManager 來處理所有與鑒權(quán)相關(guān)的邏輯核心思路是每個(gè)測(cè)試賬號(hào)的 Token 只獲取一次之后進(jìn)入全局緩存用同一個(gè) Token 跑完全部用例絕不每個(gè)用例都重新登錄。這樣做的原因很簡(jiǎn)單——登錄接口也有成本和延遲每個(gè)用例都登錄一遍會(huì)讓整體執(zhí)行時(shí)間翻倍而且頻繁登錄可能觸發(fā)系統(tǒng)限流。public class TokenManager { private static MapString, String tokenCache new ConcurrentHashMap(); public static String getToken(String username, String password) { String cached tokenCache.get(username); if (cached ! null !isTokenExpired(cached)) { return cached; } String newToken doLogin(username, password); tokenCache.put(username, newToken); return newToken; } private static String doLogin(String username, String password) { return given() .contentType(ContentType.JSON) .body({\username\:\ username \,\password\:\ password \}) .post(/auth/login) .then() .statusCode(200) .extract().path(data.token); } }Token 過期是個(gè)很實(shí)際的問題。JWT 一般有有效期如果 Token 過期后面的用例會(huì)集體報(bào) 401。在框架層我做了兩個(gè)兜底方案第一是 Token 即將過期前會(huì)自動(dòng)重新獲取在獲取時(shí)判斷剩余有效期第二是在斷言層加邏輯如果收到 401 響應(yīng)就重新登錄后再重試一次該請(qǐng)求。實(shí)際跑下來后后一個(gè)方案更簡(jiǎn)單有效前一個(gè)需要解析 JWT 內(nèi)容增加復(fù)雜度但收益不大。3.3 四層斷言狀態(tài)碼、業(yè)務(wù)碼、字段、數(shù)據(jù)庫接口自動(dòng)化測(cè)試決不能在斷言上任性只斷言一個(gè) HTTP 狀態(tài)碼遠(yuǎn)不夠。經(jīng)過這個(gè)項(xiàng)目我把斷言拆成了四層每一層都有明確用途第一層是 HTTP 狀態(tài)碼斷言它只能證明“網(wǎng)絡(luò)層面請(qǐng)求成功/失敗”比如 200 表示服務(wù)器沒有返回 500但不代表業(yè)務(wù)邏輯正確。第二層是業(yè)務(wù)狀態(tài)碼斷言博客系統(tǒng)接口會(huì)返回業(yè)務(wù)碼例如code: 0表示成功、code: 1001表示參數(shù)錯(cuò)誤、code: 1003表示無權(quán)限。這層比 HTTP 狀態(tài)碼更接近業(yè)務(wù)實(shí)際。第三層是核心字段斷言驗(yàn)證返回的 JSON 中關(guān)鍵字段的值是否符合預(yù)期比如創(chuàng)建文章后返回的articleId不為空、列表第一篇文章的標(biāo)題與提交一致。第四層是數(shù)據(jù)庫斷言直接查詢數(shù)據(jù)庫驗(yàn)證數(shù)據(jù)確實(shí)被正確寫入或修改。下面是一個(gè)典型的四層斷言的完整用例場(chǎng)景是“登錄成功后獲取用戶信息”Test(description 登錄成功后獲取當(dāng)前用戶信息) public void testGetCurrentUserInfo() { String token TokenManager.getToken(ADMIN_USERNAME, ADMIN_PASSWORD); given() .header(Authorization, Bearer token) .when() .get(/user/profile) .then() .statusCode(200) // 第一層HTTP狀態(tài)碼 .body(code, equalTo(0)) // 第二層業(yè)務(wù)碼 .body(data.username, equalTo(test_admin)) // 第三層核心字段 .body(data.email, matchesPattern(..\\..)); }數(shù)據(jù)庫斷言我用了 JDBC 連接工具類核心方法是執(zhí)行傳入的 SQL 并返回結(jié)果然后在用例中斷言數(shù)據(jù)庫查詢結(jié)果。例如創(chuàng)建文章成功后查詢數(shù)據(jù)庫確認(rèn) article 表里多了一條對(duì)應(yīng)記錄且 status 字段為正常狀態(tài)。注意事項(xiàng)數(shù)據(jù)庫斷言不能每一條用例都加否則執(zhí)行效率會(huì)明顯下降。我的原則是“涉及寫操作的核心用例加數(shù)據(jù)庫斷言”讀操作的用例重點(diǎn)做字段校驗(yàn)就夠了。把數(shù)據(jù)庫校驗(yàn)放在創(chuàng)建、更新、刪除這三類操作上性價(jià)比最高。4. 框架落地封裝、數(shù)據(jù)驅(qū)動(dòng)與報(bào)告4.1 API Client 封裝讓用例代碼真正可讀在這個(gè)項(xiàng)目里我體會(huì)最深的是“封裝不是裝飾而是工程化的命脈”。如果不做任何封裝所有接口調(diào)用邏輯平鋪在用例里寫起來非常爽但維護(hù)起來完全是災(zāi)難。換一個(gè)接口地址要翻遍幾十個(gè)用例去改。我按照業(yè)務(wù)模塊劃分了 Client 類每個(gè) Client 負(fù)責(zé)一個(gè)模塊的所有接口操作。以 ArticlesClient 為例它封裝了博客文章模塊的所有接口public class ArticlesClient { private static final String BASE /articles; public static Response createArticle(String token, String title, String content, ListInteger tagIds) { return given() .header(Authorization, Bearer token) .contentType(ContentType.JSON) .body(buildCreateBody(title, content, tagIds)) .post(BASE); } public static Response getArticleList(int page, int size, String keyword) { return given() .queryParam(page, page) .queryParam(size, size) .queryParam(keyword, keyword) .get(BASE /list); } public static Response getArticleDetail(int articleId) { return given().get(BASE / articleId); } public static Response updateArticle(String token, int articleId, String title, String content) { MapString, Object body new HashMap(); body.put(title, title); body.put(content, content); return given() .header(Authorization, Bearer token) .contentType(ContentType.JSON) .body(body) .put(BASE / articleId); } }封裝后的用例層代碼像在讀一篇測(cè)試文檔邏輯一目了然。舉個(gè)例子創(chuàng)建文章并驗(yàn)證的基本用例是這樣的Test(description 創(chuàng)建文章成功后返回文章ID) public void testCreateArticleSuccess() { Response response ArticlesClient.createArticle( TokenManager.getToken(ADMIN_USERNAME, ADMIN_PASSWORD), 自動(dòng)化測(cè)試文章-標(biāo)題, 自動(dòng)化測(cè)試文章-正文內(nèi)容, Arrays.asList(1, 2) ); response.then().statusCode(200).body(code, equalTo(0)); int articleId response.jsonPath().getInt(data.articleId); Assert.assertTrue(articleId 0, 創(chuàng)建文章返回ID應(yīng)該大于0); }這里注意Client 層的方法返回的是 Response 對(duì)象這個(gè)設(shè)計(jì)是有意為之。好處是讓用例層自己決定要做什么斷言和提取什么數(shù)據(jù)Client 層不做過于貼身的斷言保持了靈活性。曾經(jīng)我把斷言也寫進(jìn)了 Client 層后來發(fā)現(xiàn)不同的用例對(duì)同一個(gè)接口斷言的側(cè)重點(diǎn)完全不同塞在一起的代碼反而別扭。4.2 測(cè)試數(shù)據(jù)驅(qū)動(dòng)數(shù)據(jù)準(zhǔn)備與清理閉環(huán)接口自動(dòng)化的測(cè)試數(shù)據(jù)管理是整個(gè)項(xiàng)目成敗的關(guān)鍵也是我覺得最難啃的骨頭。沒有系統(tǒng)化的數(shù)據(jù)管理用例跑幾次之后就互相污染今天能過明天就崩。我的方案分兩部分?jǐn)?shù)據(jù)準(zhǔn)備和數(shù)據(jù)清理。數(shù)據(jù)準(zhǔn)備用兩種方式一種是 TestNG 的 DataProvider適用于參數(shù)化的用例另一種是專門的 TestDataFactory在用例執(zhí)行前通過調(diào)用接口創(chuàng)建所需的數(shù)據(jù)。一個(gè)典型的場(chǎng)景是“創(chuàng)建文章接口的參數(shù)化校驗(yàn)”要求覆蓋標(biāo)題為空、標(biāo)題超長(zhǎng)、內(nèi)容為空、標(biāo)簽不存在、正常提交等多個(gè)參數(shù)組合。我用 DataProvider 把這些數(shù)據(jù)抽到 JSON 文件中[ {title: , content: 內(nèi)容, tagIds: [1], expectCode: 1001, desc: 標(biāo)題為空}, {title: 超長(zhǎng)標(biāo)題 a.repeat(300), content: 內(nèi)容, tagIds: [1], expectCode: 1001, desc: 標(biāo)題超長(zhǎng)}, {title: 正常標(biāo)題, content: , tagIds: [1], expectCode: 1001, desc: 內(nèi)容為空}, {title: 正常標(biāo)題, content: 內(nèi)容, tagIds: [99999], expectCode: 1002, desc: 標(biāo)簽不存在}, {title: 正常標(biāo)題-演示, content: 演示內(nèi)容, tagIds: [1, 2], expectCode: 0, desc: 正常提交} ]配合 DataProvider 加載 JSON一條用例方法秒變五條用例邏輯而且數(shù)據(jù)放在外部文件維護(hù)人員不需要懂代碼就能增刪用例數(shù)據(jù)。數(shù)據(jù)清理這一塊我踩過的坑最深。剛開始沒做清理同一批測(cè)試數(shù)據(jù)反復(fù)創(chuàng)建數(shù)據(jù)庫積累了幾千條“自動(dòng)化測(cè)試文章”垃圾數(shù)據(jù)讓后面的列表用例 total 斷言永遠(yuǎn)對(duì)不上排查起來極其痛苦。后來定了鐵律每個(gè)用到的測(cè)試數(shù)據(jù)都必須在測(cè)試結(jié)束后清掉清理方式首選調(diào)接口刪除接口刪不到的直接 SQL 刪除。4.3 Allure 報(bào)告接入與失敗用例定位報(bào)告選 Allure因?yàn)樗跍y(cè)試領(lǐng)域基本屬于事實(shí)標(biāo)準(zhǔn)。接入主要通過依賴和監(jiān)聽器實(shí)現(xiàn)用一步配置好 Listeners 注解把 TestNG 的執(zhí)行結(jié)果自動(dòng)接入 Allure 引擎。真正讓 Allure 報(bào)告好用的訣竅是在用例中主動(dòng)加入步驟信息。在關(guān)鍵操作前用Allure.step()標(biāo)注操作步驟斷言失敗時(shí)報(bào)告里就能看到精確的操作路徑Test(description 更新文章成功后數(shù)據(jù)庫字段被修改) public void testUpdateArticleUpdatesDatabase() { Allure.step(創(chuàng)建一篇測(cè)試文章作為前置數(shù)據(jù)); int articleId TestDataFactory.createArticle(原始標(biāo)題, 原始內(nèi)容); Allure.step(調(diào)用更新接口修改文章標(biāo)題); Response updateResp ArticlesClient.updateArticle(getToken(), articleId, 新標(biāo)題, 原始內(nèi)容); updateResp.then().statusCode(200); Allure.step(查詢數(shù)據(jù)庫驗(yàn)證標(biāo)題已更新); String dbTitle DbUtil.queryOne(SELECT title FROM articles WHERE id articleId); Assert.assertEquals(dbTitle, 新標(biāo)題); }這樣一來每次失敗用例的排查都非常輕松。打開 Allure 報(bào)告左邊是完整步驟樹哪一步失敗一目了然失敗時(shí)還會(huì)自動(dòng)截取響應(yīng)體和請(qǐng)求體。協(xié)同排查問題時(shí)直接把 Allure 報(bào)告鏈接發(fā)給開發(fā)比在聊天窗口里貼一大段日志高效很多。5. 持續(xù)集成讓接口測(cè)試定時(shí)自動(dòng)跑5.1 用 GitHub Actions 跑自動(dòng)化用例接口自動(dòng)化必須與 CI 結(jié)合才有長(zhǎng)期價(jià)值不能只在本地跑完看一眼就完了。我把博客接口自動(dòng)化工程托管到 GitHub 私有倉(cāng)庫用 GitHub Actions 做持續(xù)集成每次代碼推送自動(dòng)觸發(fā)測(cè)試執(zhí)行。workflow 配置文件的思路不復(fù)雜拉代碼、裝 JDK、跑 Maven 命令、上傳 Allure 報(bào)告、推送結(jié)果通知。核心配置大概是這樣name: Blog API Test CI on: push: branches: [ main ] schedule: - cron: 0 2 * * * # 每天凌晨2點(diǎn)定時(shí)跑 jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up JDK 17 uses: actions/setup-javav3 with: java-version: 17 distribution: temurin - name: Run API tests run: mvn clean test - name: Upload Allure Report uses: actions/upload-artifactv3 with: name: allure-report path: target/allure-results這里值得說清楚的是schedule定時(shí)的價(jià)值。接口自動(dòng)化的主要作用不是守著開發(fā)提交代碼時(shí)跑一遍而是發(fā)現(xiàn)“系統(tǒng)悄悄變了”的問題。數(shù)據(jù)庫連接池耗盡、第三方依賴臨時(shí)掛掉、定時(shí)任務(wù)導(dǎo)致的臟數(shù)據(jù)這些沒有代碼變更也會(huì)發(fā)生的問題正是定時(shí)任務(wù)能發(fā)現(xiàn)的。我個(gè)人把定時(shí)執(zhí)行時(shí)間定在凌晨 2 點(diǎn)原因是這個(gè)時(shí)段業(yè)務(wù)流量低、數(shù)據(jù)庫負(fù)載小如果測(cè)試失敗大概率是代碼或環(huán)境問題而不是偶發(fā)流量干擾。5.2 并發(fā)執(zhí)行、失敗重試與穩(wěn)定性策略用例數(shù)量漲到 100 條以后串行執(zhí)行時(shí)間會(huì)變得非常長(zhǎng)。我在 TestNG 層面啟用了并發(fā)執(zhí)行配置了線程池可以讓執(zhí)行時(shí)間壓縮一半以上。!DOCTYPE suite SYSTEM http://testng.org/testng-1.0.dtd suite nameBlogApiTestSuite parallelmethods thread-count4 test nameBlogApiTests packages package namecom.blog.test.case/ /packages /test /suite并發(fā)執(zhí)行有一個(gè)反直覺的坑測(cè)試數(shù)據(jù)也會(huì)并發(fā)沖突。比如多個(gè)用例同時(shí)在創(chuàng)建文章用于校驗(yàn)列表接口的第一篇文章標(biāo)題就會(huì)互相影響。針對(duì)這個(gè)問題我做了兩件事一是并發(fā)用例間共享的數(shù)據(jù)用獨(dú)立前綴區(qū)分例如“auto_test_并發(fā)標(biāo)識(shí)_當(dāng)前時(shí)間戳”二是核心鏈路的用例串行執(zhí)行只有純查詢類和數(shù)據(jù)隔離良好的用例并發(fā)。失敗重試也很重要。接口測(cè)試跑在真實(shí)環(huán)境上偶發(fā)超時(shí)、連接中斷都會(huì)導(dǎo)致用例失敗但這類失敗不代表系統(tǒng)有 bug。我在框架中寫了一個(gè) RetryListener針對(duì)“連接超時(shí)”“讀超時(shí)”“500 臨時(shí)錯(cuò)誤”這幾類異常做自動(dòng)重試配置了每次最多重試兩次。如果重試后還是失敗基本可以確認(rèn)是系統(tǒng)真實(shí)問題。關(guān)鍵提醒重試機(jī)制只對(duì)“非確定性失敗”有效像斷言失敗這種確定性失敗不能重試重試只會(huì)掩蓋真實(shí)缺陷。我的實(shí)現(xiàn)是只針對(duì)特定異常類型重試而不是盲目重跑所有失敗用例。6. 常見問題與排查技巧實(shí)錄6.1 我踩過的坑與排查思路整個(gè)項(xiàng)目做下來積累了不少“血淚教訓(xùn)”挑幾個(gè)最典型的分享出來這些坑基本每個(gè)人做接口自動(dòng)化都會(huì)遇到。第一個(gè)坑是測(cè)試數(shù)據(jù)沒有清理這個(gè)前面已經(jīng)提過。最開始跑了兩天數(shù)據(jù)庫里的測(cè)試文章堆成了山。后來建立了“前置創(chuàng)建→用例執(zhí)行→后置清理”的標(biāo)準(zhǔn)流程并且數(shù)據(jù)清理必須用和用例創(chuàng)建方式對(duì)應(yīng)的方式接口能刪的走接口接口刪不到的用 SQL。同時(shí)定期做全庫清掃把歷史殘留的垃圾測(cè)試數(shù)據(jù)一次性清理掉。第二個(gè)坑是 Token 過期的隱蔽問題。JWT Token 有效期設(shè)置的是 2 小時(shí)剛開始用例跑得快時(shí)沒問題后來并發(fā)執(zhí)行時(shí)間拉長(zhǎng)部分用例執(zhí)行時(shí) Token 已經(jīng)過期出現(xiàn)一批莫名其妙的 401 失敗。排查時(shí)看日志才發(fā)現(xiàn)是同一個(gè) Token 在 2 小時(shí)前獲取的后續(xù)用例一直復(fù)用。解決辦法是 TokenManager 中加入有效期檢查并增加 401 自動(dòng)重登重試的兜底邏輯。第三個(gè)坑是響應(yīng)中的時(shí)間戳字段斷言。創(chuàng)建文章接口返回的createTime是毫秒時(shí)間戳每次執(zhí)行都不一樣導(dǎo)致斷言 JSON 時(shí)無法用固定值校驗(yàn)。這類動(dòng)態(tài)字段的策略是只斷言“存在但不為空”或者斷言格式正確而不是斷言具體值。如果一定要斷言范圍就用當(dāng)前時(shí)間前后偏移來校驗(yàn)createTime應(yīng)該在請(qǐng)求發(fā)出前后幾秒內(nèi)。第四個(gè)坑是同學(xué)最容易被坑的接口文檔和實(shí)際行為不一致。文檔寫的是DELETE /articles/{id}實(shí)際接口可能需要加查詢參數(shù)?forcetrue才能徹底刪除文章否則只是軟刪。這提醒我一件事接口自動(dòng)化用例必須基于真實(shí)接口行為寫不能照搬文檔第一次調(diào)試時(shí)先手工調(diào)一遍接口再落用例。6.2 失敗用例快速定位的五步法做了大量用例之后總結(jié)出了一套快速定位失敗用例的方法排查速度提升非常明顯第一步先在 Allure 報(bào)告里看失敗發(fā)生在哪一步。如果失敗步驟是“創(chuàng)建前置數(shù)據(jù)”說明是前置問題和被測(cè)接口本身無關(guān)。第二步看失敗類型是什么斷言失敗是業(yè)務(wù)邏輯問題異常是環(huán)境或者框架問題。第三步打開失敗時(shí)的請(qǐng)求體和響應(yīng)體對(duì)比文檔和要求看是否是參數(shù)傳錯(cuò)或響應(yīng)格式變化。第四步如果是數(shù)據(jù)庫斷言失敗直接執(zhí)行對(duì)應(yīng)的 SQL看數(shù)據(jù)庫實(shí)際數(shù)據(jù)和預(yù)期之間的差異。第五步把這幾個(gè)信息組合起來基本就能判斷失敗原因是業(yè)務(wù)改動(dòng)、數(shù)據(jù)污染還是框架 bug。這個(gè)方法支撐了這套自動(dòng)化用例幾個(gè)月穩(wěn)定運(yùn)行以來的所有問題排查。團(tuán)隊(duì)里同事遇到失敗用例直接按這個(gè)順序查完80% 的情況不再需要問我。關(guān)于這套博客接口自動(dòng)化測(cè)試工程我最后再說一個(gè)自己的體會(huì)真正讓自動(dòng)化有價(jià)值的不是自動(dòng)化本身而是它能持續(xù)地告訴你“系統(tǒng)現(xiàn)在到底行不行”。測(cè)試數(shù)據(jù)的管理、框架封裝的邊界、對(duì)待重試和并發(fā)的心態(tài)這些都是在這個(gè)項(xiàng)目里逐步建立的工程方法。踩坑不可怕怕的是踩完了不總結(jié)那才是真的白做。這套工程跑起來之后我最大的感受是它已經(jīng)成為團(tuán)隊(duì)把控系統(tǒng)質(zhì)量的重要一環(huán)希望這篇實(shí)戰(zhàn)記錄也能幫你少走些彎路。