基于Cypress的一个API小工具

这个工具你照着操作一遍，应该就能够使用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文件夹
  测试用例。
  

  测试用例文件

解读一下用例里边稍微特殊一点的地方（按红色标号顺序）。

测试用例文件里的内容

1. 这里想自动生成一些自定义部分的value，用了faker来实现；同时，在名字里加上了当前时间，用来表明是什么时间创建的，用了JavaScript日期处理库类（moment.js）来达到目的。
2. 这里填写的是在fixtures文件夹里定义的.json文件名称。
3. 这里将/signup的一个返回值定义为变量guid，后续会用到。
4. 这里使用了之前拿到的guid，使用方法为this.guid。
5. 这里将/contacts的返回值id定义为变量contact_id，后续会用到。
6. 在/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，条条大路通罗马，总能想到解决的办法~）

后来想想，这个工具可以有多个用途：

1. 解决BA的后顾之忧。
2. 抛开测试其本身功能的话，可以帮助快速创建测试数据，用于测试基于它的其他功能，比通过页面完成整个过程要来的快。
3. 加一些校验在里边的话，还可以作为接口自动化测试，用作smoke test或者regression test均可。