网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
只做白盒测试不做接口测试，无法将代码的整个逻辑理顺；
6、debug：debug执行、
三、接口测试策略
根据接口文档，构造不同的参数组合，各种正常/异常的参数，然后组装请求发送服务端，最后进行返回结果的判断。但是对线上系统会有极大的风险，因为随着业务的越来越复杂，很多测试点是接口文档所描述不到的。
根据代码梳理的结果来画流程图/时序图，然后根据时序图上的各个点来构造各种正常/异常的测试场景进行接口测试，这样才能更为完善的进行接口测试，减小线上的风险。
时序图：序列图、循序图，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，可以直观的传达系统内外的交互过程。我们可以简单的举个例子：
程序从入口进来，先做了什么逻辑判断和处理；
处理完成后进行入库，入库的数据是什么，关键的状态是什么；
入库的数据哪些字段是我们要去检查的，状态是如何变更的；
缓存的key是什么，缓存失败的策略又是什么；
如何设计接口测试，微信扫描二维码支付：
发起支付请求：
构造相同订单，基于并发或者多线程请求被测服务；
超时；
其它异常；
微信server回调pay接口生成预支付订单：
回调多次，是否能保证只生成一笔订单
回调失败，内部又如何处理
返回未知异常
返回已知异常
接口测试一定要先把代码的逻辑梳理清楚。如果只从接口文档的描述来做接口测试，我们对这些后台处理逻辑不清楚，那么这些测试点就会被遗漏，把所有风险都遗留在了线上。
四、接口自动化测试：
1、分析功能及接口的优先级别
实施前，首先应该明确自动化测试的目标，可以从以下几个维度考虑：
功能维度
业务维度
流量维度
风险维度
黄金流程维度
我们需要从以上五个方面去考虑需要做接口自动化测试的接口有哪些，然后就能够梳理出各接口及业务的级别（P0、P1、P2）
基于以上分析，我们就定义接口测试的策略，是要做单接口的还是模块级甚至是系统级的接口测试，又或者是三者都要做。
场景及–单接口
模块级–只在模块内，预下单-提交订单–确认支付
系统级–整个业务流程-订单-支付-网关-回调
定义自动化达成目标
定义好自动化测试的策略后，然后需要定义自动化测试要达成的目标。例如：
核心接口覆盖率50%
黄金流程覆盖率normal级别case，场景级40%
框架建设
基本诉求：case规范要求、case量级预估、现状：系统变更频繁程度、业务接入的快慢程度、当前资源投入情况、变更的倾向性
实现：common_env --工具+环境
dao + client --MySQL、Redis、dubbo、HTTP
Core–测试用例能力扩展、执行前、执行后、参数处理等
gen–自动生成代码
manager–case管理，报告输出等等
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
/bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
5388
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
