這個工具你照著操作一遍，應(yīng)該就能夠使用Cypres進(jìn)行最基本的API測試了；再根據(jù)實(shí)際情況豐富一下，應(yīng)該就成為你自己的工具了。
這個工具來源的背景是：
- 項(xiàng)目上的一個產(chǎn)品購買流程，購買過程中依賴另一個團(tuán)隊登錄模塊的功能。但是呢，這個團(tuán)隊往往會在你不知情的情況下，把登錄模式改了（這里就不糾結(jié)是不是因?yàn)闃I(yè)務(wù)需求而產(chǎn)生的改動了），時不時變成雙認(rèn)證模式（給你的郵箱或者手機(jī)發(fā)一個6位數(shù)字的code）。測試嘛，你知道的，輸入的一些郵箱啊，手機(jī)號啊，很多時候都是假的，怎么可能查到相應(yīng)的認(rèn)證code。
- 然后呢，slack里各種@對方的人，反復(fù)聊“這里又出現(xiàn)雙認(rèn)證了 -> 改動是業(yè)務(wù)需求的嗎 -> 是代碼改壞導(dǎo)致的嗎 -> 是測試需要，臨時改了配置嗎 -> 麻煩幫助改好（或者改回去吧）-> 下回有變動能給我們只知會一聲不 -> 謝謝啊（不太情愿地）”。
- 我們的BA經(jīng)常來找我：“我用我賬號，一直出來這個雙認(rèn)證，你能試試你的看有沒有嗎？”。其實(shí)，他只是為了新feature，想去下游flow截張圖，但是經(jīng)常逃不過雙認(rèn)證這一劫……然后就又要返回上述聊天模式聊一遍……
（故事情節(jié)寫多了，主要怕以后我也忘了為什么要寫這個工具……）
不想看上邊羅里吧嗦的描述的同學(xué)，可以直接移步下邊的內(nèi)容！
我把整個購買流程過程中涉及到的API，調(diào)用API的時機(jī)，以及他們之間的關(guān)系捋了一遍，基本的流程是：
用戶是否注冊校驗(yàn) (是否有guid返回) ->
登錄（guid有value返回的時候）或注冊（guid返回null的時候）->
創(chuàng)建聯(lián)系人信息（這里需要用到guid，會生成一個CONTACT_ID）->
創(chuàng)建使用人信息（這里需要用到CONTACT_ID，生成CLIENT_ID）->
創(chuàng)建支付信息（這里需要用到CONTACT_ID和CLIENT_ID，生成PAYMENTPROFILE_ID）->
創(chuàng)建訂單（這里需要用到guid和CLIENT_ID，生成PRODUCT_ID和ORDER_ID）
這個過程中所有生成的信息，我都給它保存到一個文本里，因?yàn)榭梢酝ㄟ^任意一個在數(shù)據(jù)庫里查到相關(guān)信息。
下邊進(jìn)入正題，結(jié)構(gòu)是什么？一些關(guān)鍵的地方是如何處理的？
-
fixtures文件夾
無論是request url里需要的params，還是request里要用到的body，都放這里了，格式均為Json。
fixtures里的json文件名
Json里的內(nèi)容，要用啥，就寫啥。
json文件里的內(nèi)容示例 -
integration文件夾
測試用例。
測試用例文件
解讀一下用例里邊稍微特殊一點(diǎn)的地方（按紅色標(biāo)號順序）。
- 這里想自動生成一些自定義部分的value，用了faker來實(shí)現(xiàn)；同時，在名字里加上了當(dāng)前時間，用來表明是什么時間創(chuàng)建的，用了JavaScript日期處理庫類（moment.js）來達(dá)到目的。
- 這里填寫的是在fixtures文件夾里定義的.json文件名稱。
- 這里將
/signup的一個返回值定義為變量guid，后續(xù)會用到。 - 這里使用了之前拿到的
guid，使用方法為this.guid。 - 這里將
/contacts的返回值id定義為變量contact_id，后續(xù)會用到。 - 在
/accounts里使用了之前拿到的contact_id，使用方法為直接調(diào)用contact_id。
為什么都是調(diào)用響應(yīng)數(shù)據(jù)，4用this.guid，而6直接用contact_id呢？
-- 4是使用.as() 別名保存響應(yīng)數(shù)據(jù)，可以在共享測試上下文中使用，使用方法為this.xxx。
-- 6是使用關(guān)聯(lián)接口的返回響應(yīng)數(shù)據(jù)，直接調(diào)用就行。
-
common文件夾
util.js里寫了個保存數(shù)據(jù)的方法，用來存放用例執(zhí)行過程中生成的重要信息（主要是想通過這些信息，在相應(yīng)的系統(tǒng)或者數(shù)據(jù)庫里查找對應(yīng)數(shù)據(jù)）。
執(zhí)行之后會生成一個名叫message.txt的文件。
util.js -
scripts文件夾
包含一個執(zhí)行測試的文件。
整個場景區(qū)分老用戶和新用戶，integration文件夾里的測試用例用existingUser和nonExistingUser來區(qū)分，執(zhí)行的時候通過傳入userType定位到對應(yīng)的integration文件夾里的測試文件。
測試用例文件
run.js -
cypress.json
沒有太特殊的配置。
cypress.json -
package.json
主要是一些執(zhí)行命令的定義。
package.json 執(zhí)行命令
npm run new-user-purchase
npm run existing-user-purchase
（這里多說一句，如果你想用npm run purchase，你需要在run.js里加個邏輯判斷，即process.env.userType為空時，spec的value是什么，否則會報錯。）-
message.txt
這里邊的數(shù)據(jù)，可以支持在相應(yīng)的系統(tǒng)或者數(shù)據(jù)庫里查詢?nèi)魏蜗氩榈男畔ⅰ?br>message.txt
最后
其實(shí)這個工具不難，就是依據(jù)API之間的邏輯關(guān)系，給它湊到一塊兒，同時還發(fā)現(xiàn)，直接通過API走這套流程盡然不需要二次認(rèn)證。（即使需要的話，我想我們可以通過創(chuàng)建一個專門用于自動化的二次認(rèn)證code，條條大路通羅馬，總能想到解決的辦法~）
后來想想，這個工具可以有多個用途：
- 解決BA的后顧之憂。
- 拋開測試其本身功能的話，可以幫助快速創(chuàng)建測試數(shù)據(jù)，用于測試基于它的其他功能，比通過頁面完成整個過程要來的快。
- 加一些校驗(yàn)在里邊的話，還可以作為接口自動化測試，用作smoke test或者regression test均可。
