有这么一种情况，后台管理系统带有一个开关，可以控制APP某项功能的展示。这种情况下，我们想要实现自动化，就要先请求后台接口更改状态，再请求APP的接口进行测试和验证。同时为了保证开关两种状态的切换，我们还需要从数据库中获取开关的状态，以此为根据更改后台管理系统的开关状态。那么这种情况下我们如何实现自动化呢？接下来一起研究一下详细的实现步骤吧！
第一部分：确认环境和接口信息
（1）mysql 下 server_control表（用于储存开关状态的表）数据如下：keyId代表开关的名称；status代表开关当前的状态，1位为开启，0为关闭。
mysql.png
（2）后台管理系统中开关控制位置修改开关状态的接口信息：
接口地址：api/server_control/save （post请求）
传参：（1）keyid 开关的ID （2）status 开关的状态
返回值：status 是否设置成功，0为失败 1为成功
（3）APP用于接收开关状态的接口信息：
接口地址：api/getServerControls（post请求）
传参：这里本来是有用户id，但是并没有什么影响所以假定此处没有传参即可。
返回值：one ： 0/1 开关一 ，0为关闭 1为开启
two : 0/1 开关二，0为关闭 1为开启
好了，这样基本的数据环境就准备好了。
第二部分：一边设计流程一边写自动化
（1）我们这里使用xmysql连接数据库，至于基本的安装使用这里不再详细介绍。
通过命令行直接输入命令
mysql -h 数据库地址 -u 用户名 -p 密码 -d 数据库名 -r 指定访问IP地址连接成功之后在postman新建一个GET请求：{{sqlUrl}}/api/server_control
通过get请求即可获取当前数据库server_control表中的数据，在tests中编写如下方法即可获取当前的数据。
var rpData = JSON.parse(responseBody); 效果如下图：
image.png
通过请求取出数据库数据判断当前keyId的值，数据格式为"keyId":status
例如 keyId为1的status为1 ；keyId为2的status为1（这个我自己写了个接口返回的并非真实数据库返回的格式，仅用参考）
数据库返回值.png
（2）因为两个status的值都为0，那么我们就设置相反状态环境变量，keyone 和 keytwo都为1，分别代表keyid为1的status值和keyid为2的status值。这两个值主要用户后台管理系统更改状态和APP接口的预期结果。
为啥我们要设置相反的值呢？
数据库查询出来的状态一定是当前APP和后台的状态，例如status都为0，那么我们根据这个值为环境变量设置为1，开关的状态肯定会从一种状态变成另一种状态，这样就实现了我们对接口功能使用的效果。
最终Mmysql接口tests中代码如下：
数据库接口最终代码.png
（3）根据测试的流程逻辑，下一个请求的接口应该是后台管理系统的接口，为了保证接口请求顺序准确性，我们在mysql的接口最后一行增加一个顺序控制，如下代码加入mysql接口的tests中：
postman.setNextRequest("这个是postman设置的接口名") //下一个请求的接口时后台管理系统的接口（4）接下来我们搞一下后台管理系统的代码，首先当前接口是api/server_control/save /keyId=1&status=0，传值中带有keyId，也就说每次请求接口只能更改其中一个开关的状态，但是我们有两个开关，所以我们需要请求两次；另外status的值也不是固定的，所以这两位置都设置成变量 ：分别为keyid（开关id）和status（开关状态值），即
api/server_control/save /keyId={{keyid}}&status={{status}}（5）因为变量在请求上，所以我们要在请求之前进行赋值，这个时候就用到了postman的Pre-requestScript功能，位置如图所示（接口请求之前会先执行此处）
Pre-requestScript.png
首先我们先实现一次接口的赋值和断言，在Pre-requestScript中新建变量并接收keyone的值用于本接口的status，因为keyone的值为keyId为1的对应的值，所以他的keyid就等于1，实际代码如下：
接口请求前的处理.png
（6）这样就实现了在接口请求前给接口的变量附上最新值的下过，然后我们就需要在tests中断言接口返回的status为1即可：
tests断言.png
（7）完成以上操作，我们只实现了一个开关的修改，那么完成两个开关的修改咋办呢？难道再请求一次？哈哈，如果那样的话就显得有点low了，接下来让我们一起修改代码实现请求两次的效果吧。
首先我们修改一下mysql的接口中tests中的代码，新建一个环境变量在如图所示的位置，用于重置循环次数。
新增用于循环的变量.png
然后在后台管理系统接口的pre-resquestScript模块修改代码，通过判断循环次数为接口传参（keyid和status）赋值：
根据循环次数赋值.png
接下来在tests中判断当前的循环次数，也就是loopC字段，如果loopC=1(代表只循环了一次)，那么设置再次请求当前接口：
获取当前的循环次数.png
通过上面的判断，代码运行会再次请求后台管理系统的接口，然后我们在Pre-requestScript中进行判断当前的loopC的值，如果为1，代表已经请求过一次，也就是说keyid为1的情况已经更改，我们还需要更改keyid为2的情况，那么我们就将2赋值给keyid，staus的值就是对应的keytwo的值：
判断loopC为2 的情况.png
最后我们在tests中判断loopC=2，两个开关都已经做了更改，这样我们就不需要再请求后台管理系统的接口，而是设置去请求APP的接口：
loopC为2 的判断.png
（8）最后一步，我们就要请求APP的接口进行最后的断言（成败在此一举）。
APP的接口api/getServerControls，返回值为one：1 ；two：1，我们直接在APP接口的tests中断言one和two的值是否与keyone和keytwo的相等即可：
APP断言.png
完成上面的步骤，就实现了数据库、后台管理系统和APP（用户操作系统）三端联动的接口自动化测试，整体内容不一定适合每一个人并且没有基础知识的介绍，属于纯实战项目，适合刚刚接触接口自动化，没有实际经验的小伙伴。基础知识只能满足你60%的学习需求，剩下的40%就要在实战中补足，我要做的就是补充你剩下的40%。OK，这次分享就到这里了，有什么疑问可以随时留言沟通，互相学习进步！
欢迎加入QQ群：547349021
小提示：群名虽然叫selenium+unittest，但是我们不限任何测试领域的沟通交流和学习，让我们一起补足缺失的40%吧！
