这个工具你照着操作一遍，应该就能够使用Cypres进行最基本的API测试了；再根据实际情况丰富一下，应该就成为你自己的工具了。
这个工具来源的背景是：
- 项目上的一个产品购买流程，购买过程中依赖另一个团队登录模块的功能。但是呢，这个团队往往会在你不知情的情况下，把登录模式改了（这里就不纠结是不是因为业务需求而产生的改动了），时不时变成双认证模式（给你的邮箱或者手机发一个6位数字的code）。测试嘛，你知道的，输入的一些邮箱啊，手机号啊，很多时候都是假的，怎么可能查到相应的认证code。
- 然后呢，slack里各种@对方的人，反复聊“这里又出现双认证了 -> 改动是业务需求的吗 -> 是代码改坏导致的吗 -> 是测试需要，临时改了配置吗 -> 麻烦帮助改好（或者改回去吧）-> 下回有变动能给我们只知会一声不 -> 谢谢啊（不太情愿地）”。
- 我们的BA经常来找我：“我用我账号，一直出来这个双认证，你能试试你的看有没有吗？”。其实，他只是为了新feature，想去下游flow截张图，但是经常逃不过双认证这一劫……然后就又要返回上述聊天模式聊一遍……
（故事情节写多了，主要怕以后我也忘了为什么要写这个工具……）
不想看上边罗里吧嗦的描述的同学，可以直接移步下边的内容！
我把整个购买流程过程中涉及到的API，调用API的时机，以及他们之间的关系捋了一遍，基本的流程是：
用户是否注册校验 (是否有guid返回) ->
登录（guid有value返回的时候）或注册（guid返回null的时候）->
创建联系人信息（这里需要用到guid，会生成一个CONTACT_ID）->
创建使用人信息（这里需要用到CONTACT_ID，生成CLIENT_ID）->
创建支付信息（这里需要用到CONTACT_ID和CLIENT_ID，生成PAYMENTPROFILE_ID）->
创建订单（这里需要用到guid和CLIENT_ID，生成PRODUCT_ID和ORDER_ID）
这个过程中所有生成的信息，我都给它保存到一个文本里，因为可以通过任意一个在数据库里查到相关信息。
下边进入正题，结构是什么？一些关键的地方是如何处理的？
-
fixtures文件夹
无论是request url里需要的params，还是request里要用到的body，都放这里了，格式均为Json。
fixtures里的json文件名
Json里的内容，要用啥，就写啥。
json文件里的内容示例 -
integration文件夹
测试用例。
测试用例文件
解读一下用例里边稍微特殊一点的地方（按红色标号顺序）。
- 这里想自动生成一些自定义部分的value，用了faker来实现；同时，在名字里加上了当前时间，用来表明是什么时间创建的，用了JavaScript日期处理库类（moment.js）来达到目的。
- 这里填写的是在fixtures文件夹里定义的.json文件名称。
- 这里将
/signup的一个返回值定义为变量guid，后续会用到。 - 这里使用了之前拿到的
guid，使用方法为this.guid。 - 这里将
/contacts的返回值id定义为变量contact_id，后续会用到。 - 在
/accounts里使用了之前拿到的contact_id，使用方法为直接调用contact_id。
为什么都是调用响应数据，4用this.guid，而6直接用contact_id呢？
-- 4是使用.as() 别名保存响应数据，可以在共享测试上下文中使用，使用方法为this.xxx。
-- 6是使用关联接口的返回响应数据，直接调用就行。
-
common文件夹
util.js里写了个保存数据的方法，用来存放用例执行过程中生成的重要信息（主要是想通过这些信息，在相应的系统或者数据库里查找对应数据）。
执行之后会生成一个名叫message.txt的文件。
util.js -
scripts文件夹
包含一个执行测试的文件。
整个场景区分老用户和新用户，integration文件夹里的测试用例用existingUser和nonExistingUser来区分，执行的时候通过传入userType定位到对应的integration文件夹里的测试文件。
测试用例文件
run.js -
cypress.json
没有太特殊的配置。
cypress.json -
package.json
主要是一些执行命令的定义。
package.json 执行命令
npm run new-user-purchase
npm run existing-user-purchase
（这里多说一句，如果你想用npm run purchase，你需要在run.js里加个逻辑判断，即process.env.userType为空时，spec的value是什么，否则会报错。）-
message.txt
这里边的数据，可以支持在相应的系统或者数据库里查询任何想查的信息。
message.txt
最后
其实这个工具不难，就是依据API之间的逻辑关系，给它凑到一块儿，同时还发现，直接通过API走这套流程尽然不需要二次认证。（即使需要的话，我想我们可以通过创建一个专门用于自动化的二次认证code，条条大路通罗马，总能想到解决的办法~）
后来想想，这个工具可以有多个用途：
- 解决BA的后顾之忧。
- 抛开测试其本身功能的话，可以帮助快速创建测试数据，用于测试基于它的其他功能，比通过页面完成整个过程要来的快。
- 加一些校验在里边的话，还可以作为接口自动化测试，用作smoke test或者regression test均可。
