接口自动化实战设计思路，想法及疑问（一）

各位粉丝朋友们大家好，最近在学习研究接口自动化测试时，在设计思路和实践过程中，碰到了很多问题，再不断的优化和调整，这过程中产生了很多疑问和不解，并与很多测试的朋友进行交流想法，但是各自想法意见偏差较大，所以我初次整理了几个问题分享给大家，想听听大家的设计思路和想法：

一、接口自动化中，列表类功能如何做断言比较合理？

1、断言接口响应的code、msg、响应时长

2、断言响应的关键字段值

3、关键字段值与sql查询出来的预期值做比对

二、接口自动化中，表单提交类功能如何断言？

1、断言接口响应的code、msg、响应时长

2、接口的传参字段值和提交后，入库更新后字段值做比对

三、接口自动化中，前置和数据清理大家会做吗？如果不做数据清理，每次跑自动化时，不清楚账号处于哪个进度，每个用例开始时都要判断下，这样会很麻烦？

一般我会做前置数据清理和后置数据清理，因为不能确定账号当前处于什么进度，假如我想跑实名认证成功用例，测试账号某天已经实名认证过了，但是当我跑实名认证用例时，目前并不知道测试账号的进度情况，这时接口提示已经绑定过了，导致了跑的用例不是我想要的，所以每个接口用例用例跑之前和跑之后都清理下产生的数据，保证了账号的可重复使用

四、接口自动化中，场景自动化测试和单接口自动化测试的区别是什么？

1、单接口自动化注重接口的健壮性，使用测试方法对接口进行测试的，接口之间相互独立，关联性不大

2、场景自动化注重业务流程，将有业务关联流程的接口串起来，保证了业务的正确性，如果1个接口失败，整个场景就算失败了

五、接口自动化中，前置数据依赖，大家是如何处理的？

1、用sql构造前置数据，前提是你对业务非常数据，业务关联的相关表字段非常数据，这样才能确保sql构造的数据准备，当前用例才可以正常进行

2、调用相关接口获取依赖值

六、接口自动化中，前置业务依赖，大家是如何处理的？

1、用sql构造前置数据，前提是你对业务非常数据，业务关联的相关表字段非常数据，这样才能确保sql构造的数据准备，当前用例才可以正常进行

2、单独封装前置依赖接口，这样的话处理会非常复杂点，比如一个项目，必须进行登录、实名认证、绑定银行卡，才可以进行充值、提现操作，这样如果我们进行充值或提现用例测试时，就需要调登录-实名认证-绑卡接口，然后在可以正常进行，这里逻辑处理稍复杂些，目前正常尝试这种方法

七、前置功能依赖，sql处理好点还是调前置接口好点？

根据实际项目中的具体case灵活运用，各有利弊，调api生成数据能够保证数据准确性，而且执行效率高，而业务较为复杂的情况下，需要调用多个前置api，这样处理就较为复杂；但不是所有数据创建都有对应的api，这时候只能通过sql构造前置数据了，使用sql构造数据前提是业务和业务关系到的表需要非常熟悉，sql操作的话能够直接通过数据库操作，在短时间内生成批量数据，但是后期如果sql语句变化时，维护成本比较高。