這是我購(gòu)買(mǎi)的"極客時(shí)間"上的一套課程的筆記，總共52講，定期對(duì)其中的內(nèi)容做一筆記，鞏固學(xué)習(xí)內(nèi)容。
23 知其然知其所以然：聊聊API自動(dòng)化測(cè)試框架的前世今生
早期的基于Postman的API測(cè)試
主要問(wèn)題：
- 頻繁執(zhí)行大量測(cè)試用例時(shí)，基于界面的API測(cè)試比較笨拙。
- 難以與CI/CD流水線集成。
基于Postman和Newman的API測(cè)試
對(duì)于需要連續(xù)調(diào)用多個(gè)API并且有參數(shù)傳遞的情況，這并不是理想的測(cè)試方案。
基于代碼的API測(cè)試
小型企業(yè)，會(huì)選用成熟的API測(cè)試框架。
中大型企業(yè)，一般會(huì)自己開(kāi)發(fā)更適合自身業(yè)務(wù)的API測(cè)試框架。
這種根據(jù)公司業(yè)務(wù)上下文開(kāi)發(fā)實(shí)現(xiàn)的 API 測(cè)試框架，在使用上有很多優(yōu)點(diǎn)，而且靈活性也很好，主要體現(xiàn)在以下幾個(gè)方面：
- 可以靈活支持多個(gè) API 的順序調(diào)用，方便數(shù)據(jù)在多個(gè) API 之間傳遞，即上一個(gè) API 調(diào)用返回結(jié)果中的某個(gè)字段值可以作為后續(xù) API 調(diào)用的輸入?yún)?shù)；
- 方便在 API 調(diào)用之前或者之后執(zhí)行額外的任意操作，可以在調(diào)用前執(zhí)行數(shù)據(jù)準(zhǔn)備操作，可以在調(diào)用后執(zhí)行現(xiàn)場(chǎng)清理工作等；
- 可以很方便地支持?jǐn)?shù)據(jù)驅(qū)動(dòng)測(cè)試，這里的數(shù)據(jù)驅(qū)動(dòng)測(cè)試概念和 GUI 測(cè)試中的數(shù)據(jù)驅(qū)動(dòng)測(cè)試完全相同，也就是可以將測(cè)試數(shù)據(jù)和測(cè)試代碼分離解耦；
- 由于直接采用了代碼實(shí)現(xiàn)，所以可以更靈活地處理測(cè)試驗(yàn)證的斷言（Assert）；
- 原生支持命令行的測(cè)試執(zhí)行方式，可以方便地和 CI/CD 工具做集成。
然后作者提供了一個(gè)偽代碼示例來(lái)說(shuō)明，可以去看原文。
自動(dòng)生成API測(cè)試代碼
Postman 工具本身已經(jīng)支持將 Collection 轉(zhuǎn)化成測(cè)試代碼，但如果直接使用這個(gè)功能的話，還有兩個(gè)問(wèn)題需要解決：
- 測(cè)試中的斷言（assert）部分不會(huì)生成代碼，也就是說(shuō)測(cè)試代碼的生成只支持發(fā)起 request 的部分，而不會(huì)自動(dòng)生成測(cè)試驗(yàn)證點(diǎn)的代碼；
- 很多中大型互聯(lián)網(wǎng)企業(yè)都是使用自己開(kāi)發(fā)的 API 測(cè)試框架，那么測(cè)試代碼的實(shí)現(xiàn)就會(huì)和自研 API 測(cè)試框架綁定在一起，顯然 Postman 并不支持這類(lèi)代碼的自動(dòng)生成。
鑒于以上兩點(diǎn)，理想的做法是自己實(shí)現(xiàn)一個(gè)代碼生成工具，這個(gè)工具的輸入是 Postman 中 Collection 的 JSON 文件，輸出是基于自研 API 框架的測(cè)試代碼，而且同時(shí)會(huì)把測(cè)試的斷言一并轉(zhuǎn)化為代碼。
作者也提供了相應(yīng)的例子，不再贅述。
Response結(jié)果發(fā)生變化時(shí)的自動(dòng)識(shí)別
問(wèn)題：到底應(yīng)該驗(yàn)證API返回結(jié)果中的哪些字段？
不可能對(duì)返回結(jié)果中的每一個(gè)字段都寫(xiě)assert。
而API測(cè)試中，有一個(gè)很重要的概念是向后兼容。是指，發(fā)布的新API版本應(yīng)該能夠兼容老版本的API。
因此，需要找到一個(gè)方法，既可以不對(duì)所有的response字段都去寫(xiě)assert，又可以監(jiān)測(cè)到response的結(jié)構(gòu)以及沒(méi)有寫(xiě)assert的字段值的變化。
于是，誕生了“Response結(jié)果變化時(shí)的自動(dòng)識(shí)別”技術(shù)。也就是說(shuō)，即使沒(méi)有針對(duì)每個(gè)Response字段都去寫(xiě)assert，仍然可以識(shí)別出哪些Response字段發(fā)生了變化。
思路：在API測(cè)試框架中引入一個(gè)內(nèi)建數(shù)據(jù)庫(kù)，推薦非關(guān)系型數(shù)據(jù)庫(kù)（比如MongoDB），然后用這個(gè)數(shù)據(jù)庫(kù)記錄每次調(diào)用的request和Response的組合，當(dāng)下次發(fā)送相同的request時(shí)，API測(cè)試框架就會(huì)自動(dòng)和上次的Response做差異檢測(cè)，對(duì)于有變化的字段給出告警。
那么對(duì)于每次API調(diào)用都不同的字段，比如token、session ID、時(shí)間戳等，可以通過(guò)規(guī)則配置設(shè)立一個(gè)“白名單列表”，把動(dòng)態(tài)值的字段排除在外。
【心得】
最有用的是Response結(jié)果發(fā)生變化時(shí)的自動(dòng)識(shí)別這塊??！自己在項(xiàng)目中遇到過(guò)類(lèi)似的問(wèn)題，雖然采取了一定的措施，但是沒(méi)有想到作者這個(gè)解決方案。準(zhǔn)備順著作者的思路捋一捋，看看如何具體實(shí)現(xiàn)。
