接口测试-工作心得记录四（多接口调用和对应数据库表的创建,修改）

背景：刚发一个版本有点时间去写的东西，顺道把下个版本的用到的测试脚本准备一下。先说一下大体内容吧，我司准备做一个活动来拉注册，流程是用户A分享给自己的朋友用户B,B在平台注册成功、发帖并审核成功后用户A会得到相应的优惠券。看着很简单但这里面涉及到注册，完善公司资料，资质审核\公司资质审核，发帖共4个环节，下面就一步步说。

1.注册

注册呢我刚开始想着走注册接口，但是注册想要获取验证码一个会有一个图形验证码的环节，这个解析不了。后来又想加个验证码白名单直接注册成功，虽然好用但是需要RD修改代码。最近服务端RD任务太重了，我琢磨一个办法就是直接在user表生成一条数据用来完成注册环节。并且了解到注册不会涉及到其他表只是往user表写入一条数据。想写首先要判断这个手机号在user表中是否已经存在过，先查询表，如果user表没有就写入一条数据。因为后续还会有修改数据库的操作，所以就准备一个数据库操作类用来存放各种creat，update表的操作，这样以后其他脚本用到的时候直接import使用就行了。

首先第一步查询user表，代码如下：


这里面之所以返回true和false是因为后面其他操作要根据这个接口对应不同操作，这里有一个小坑就是orm查询的时候之所以用.all()不用.one()是应为如果没有查
到.one()方法 会抛异常这样我还需要捕获在做处理，这样很麻烦干脆.all()查询全部，all()返回的是一个列表所以根据长度判断，如果0表示没有该电话，非0就
是有（test环境有可能会出现 mobile重复的情况）。

创建一条user表新数据，想创建肯定是需要知道该表的最大主键ID，然后MAX+1就是我们插入主键ID。如图：


这里面ormSurface是对应ORM映射类的名字，这样以后其他非user表想要获取maxid也可以直接调用该方法获取。

就是创建一个新的user数据，如图：


ps：我刚发现这个方法没有字段说明，有好多时候写着就忘了，回头补一下，user表创建一条没啥可说的，写就行了。
2.完善公司资料
上面说的这些其实就完成了注册一个事。因为我负责是商户端，发帖肯定要完善公司资料，这也是注册必须要走的流程。可能有人会说不就是在company表创建一条数据嘛，直接写一条呗，我刚开始也是这么想的后来和服务端rd沟通发现，这里面不仅仅是创建一条company表数据这么简单，服务端会请求基础服务建立各种权限关系要不然这些数据就是垃圾数据了会在以后测试环境造成账号各种问题，请求接口还可以保证数据的完整性，

既然是请求接口那就没啥可说的了就正常构建post请求，执行就可以了，但是这里面我遇到了一个小坑，就是cookie。简单说一下我司header和cookie的作用。header中header["access_token"]是为了保证http的请求来自合法的客户端，客户端加密后得到的字符串传给服务端，服务端成功解析后才会给你返回结果。说白了就是一个身份标示，你想请求数据首先我的认识你。如图就是抓包获取的header：


cookie就是web常说的登录态，cookie包含userid这样其他请求就不用上传userid了，也很安全。当然想拿到cookie肯定是登录成功服务端response中获取的。requests库有一个获取cookie的方法。最好就是专门写一个请求login方法，返回cookie这样用起来也很方便。如图：


说完了header和cookie说一下遇到的坑，cookie肯定每次构建post/get请求都需要添加，我的这个方法的参数mobile有默认值，我在调用的时候没有给mobile重新复制服务端目前没有校验user和company是否有关联关系，就是说新注册一个电话A然后请求完善资料接口把电话B的userid传过去了，我再用电话A去company表去查，一直都没有创建。当时就崩溃了我起初以为是接口调用有问题但是状态码都是200没有问题啊，查了好久后来去问rd是不是test环境接口有问题，因为线上好用的，也不是。一下午毛线没找到后来rd说是不是你的cookie有问题啊，我打印了一下看userid和我新注册A不一致，在后面就发现getcookie方法参数mobile没有赋值，小坑有遇到可以自己排查一下。如图：


3.资质和公司信息审核
完善了公司资料后面就需要触发资质和公司审核逻辑，思路是先请求资质接口，然后在资质表找到该记录update对应字段为审核通过状态。公司信息思路同理。

有一个小小问题，请求接口后不要直接去改库有可能会出现找不到的情况，和写ui一样先sleep(5)秒，QA写测试脚本我觉得具体是跑20s还是40s没啥区别，最重要的还是好维护和稳定好用。写一个资质类用来专门书写各种资质相关的方法，操作数据库的还是写在数据库操作类里面，如图：




4.发帖
其实这个发帖脚本之前在测试别的功能的时候已经写好了，直接用就好了，体力活，就是把能提出来的东西拿出来写一个基类用来继承这样整体看起来会简单点，并且可以根据需要支持发送多个帖子，有时候客户端rd需要测试因为我司的客户端是没有数据库权限的，所以呢我们需要配合rd造数据，用的最多的就是发帖,发帖再根据需要更改帖子的状态。脚本如图：


整体到这里小模块都写好了，剩下的就是拼装一下运行就ok了。目前我感觉还是把功能根据需要进行拆分，功能属性相同的放到一起这样导入的思路很清晰，用起来很方便。最后上一个拼好的供大家参考一下，如图：