1、为什么做接口自动化？有什么考虑和收益？

质量和效率两方面：

效率：

是否节约了时间成本？

节约了时间成本：节省了回归测试的时间，手工需要多久，自动化需要多久

没有节约时间成本：时间成本PK重要程度

质量：

结合业务的难点、痛点去做，做完有什么成果

编写成本、维护成本

结合当前业务

接口变动是否频繁、多久变动一次

2、说一说接口自动化的应用场景

场景一：

在接口/功能提测后，编写自动化测试case。

测试环境：case覆盖全面

线上环境：测试过程中，沉淀出来比较经典的case，用作线上巡检。

通过给case打标签来区分测试/线上环境

场景二：

自动化case只应用在测试环境。线上监控用的不是接口自动化，生产环境有专门的实时监控报警系统

3、什么时候写接口自动化

场景一：

接口提测之前，对着接口文档写接口自动化case，开发提测的时候执行自动化，一般作为准入，放在CICD，在功能测试阶段就要完善自动化case，具体看公司要求。

场景二：

在测试过程中写接口自动化case

4、自动化case 有哪些痛点？

编写成本、
便捷性、
维护成本、
覆盖率、
做了自动化测试，线上还有bug
误报率：case执行失败了，但并不是bug引起的。肯能是网络、环境
稳定性（最重要）：稳定的运行、
报警策略：
随着case量的增加，维护成本与执行成本增加

随着case量的增加，维护成本与执行成本增加：

解决办法：

多线程并发

a、本身框架/系统是否支持多线程并发（如testNG、pytest本身支持多线程并发）

b、多线程时是否会有引起数据问题

稳定性：

因为环境问题/网络/接口变动，导致case报错。

网路问题：

加入重试机制，失败之后加入一个think时间，过几秒再重试。（或者我们有必要每条失败的case都要重试吗？） pytest框架，自带重试功能

迭代接口发生修改：

流程上解决：如每个迭代开发及时同步修改了哪些接口

技术上解决：做一个APi变化的快速感知。开发修改了接口文档，及时推送给相关测试。

报警策略：

在不同重要程度的case上打报警标签。这条case执行失败了，触发报警。

根据重要程度不同，这里做一个报警机制，如失败三次，再触发报警。（频繁的报警也不太好）

目前的自动化为业务带来了哪些收益：

准入标准
冒烟
拦截率

准入标准：开发提测的时候，先执行我们这些case，case通过了再提测。

拦截率：某个case失败了，重试多少次之后，发出报警。

作用在冒烟的主流程case上

作用在线上巡检

如何做接口自动化？

分析业务不同纬度的特点，设计适合自己业务的接口框架。

业务复杂度：

横向：如APi数目较多，比如有几千个接口，但是每个接口的请求参数并不复杂，且内部逻辑比较简单。

纵向：如API数目并不多，但是每个接口内部逻辑纵向比较深，比如一个接口从发起请求，到走完一个流程，要走很多的模块，落地很多的数据，做很多的逻辑判断。

横向纵向均有：。。。

业务测试难度：

偏简单型：基本靠点页面或者操作app就可以完成98%的业务逻辑。

偏复杂型：就算把页面拆了，每个按钮点几遍，业务的覆盖也就能覆盖住5%。页面的功能测试不能覆盖全部大部分的业务，此时就是需要接口自动化在接口层面来覆盖更多的业务场景。

例如：佣金宝、同花顺：页面复杂，但是后台逻辑不复杂。

例如：嘀嘀打车、美团外卖：页面简单、但是内部逻辑复杂

业务依赖程度：

对内部组件依赖较多：如passport、实名服务、用户中心、id生成器、mq组件、动态配置服务，服务注册中心

对外部依赖：如金融类业务，特点就是几乎所有功能都是跟外部机构和银行交互，这类业务与社交聊天的业务相差太多。

业务特点：

场景较多：如完成一次外卖订餐，需要选择、进店、获取优惠规则，选择商品，加入购物车，下单，下单确认回调给用户，支付、接单、分配骑手、骑手接单、骑手路线、骑手接单、骑手送单、骑手确认接单、用户确认、评价、超期订单自动结束、商家分账、商家结算、商家提现，商家与平台对账。

场景较少：如发布帖子

确定边界：

定义清楚，到底要做哪些业务，解决哪些实际问题，目标要清晰、明确。

结合以上业务摸底，结合特点明确要落地在哪些特点之上，不同特点，设计出来的框架完全不同。

框架不要做通用框架，越是适用各种不同的场景，实际越是不适用，要针对自己当前的业务来设计。

做工具时，首先调研组内有没有实现的，其他部门有没有现成的工具，再看业界有没有可以用的工具，然后整合，输出一个具备业务特点的东西，定制化的框架/工具。

在给别人说自己做的框架/工具时，都有一个前置条件，先介绍我们的业务是xx，所以当时有xx这样的问题，所以我的框架做了这样的xx

不要说框架的时候，感觉这个框架能放到任何公司任何业务，那这个就是0分。

设计：

内部真实实现：

先做出来，后续慢慢迭代。考虑投入产出比

面对晋升/面试：

业务特点->内外部差异和现状/摸底->业务定制化输出->架构设计->实际效果->数据说话

二、junit接口自动化框架（二次开发）-1_傲娇的喵酱的博客-CSDN博客

一、关于接口自动化的思考相关推荐

接口测试自动化的思考与总结
目录前言服务端接口测试介绍什么是服务端? 什么是接口? 什么是接口测试? 为什么要做接口测试? 如何做接口测试? 接口测试自动化介绍什么是接口测试自动化? 为什么要做接口测试自动化? 接口测试 ...
分享|涨薪必备的Python接口自动化测试资源技能一键get
终于回归正常工作节奏重新拾起去年的摊子 Q1已经过去三分之二应该有不少人去去去去年春节立下的Flag 至今还没实现而今年2020年-- 好像或许可能也实现不了偶尔会看到有测试盆友抱怨领导明 ...
接口自动化场景用例——对象嵌套对象
以前写多接口场景用例的时候,基本上一个测试类里只包含我的接口用例要调用的方法,如果有需要调用其他方法都是写到通用里.本次我尝试把我的接口用例要调用的其他的解析的方法也写在我的测试类里,感觉看起来也挺舒 ...
pytest文档73-pytest+yaml实现接口自动化框架之用例参数关联
前言使用 yaml 文件写测试用例的时候,如何在 yaml 文件的测试用例里面实现参数关联? 这是很多做自动化测试的小伙伴经常思考的一个问题. 接着前面的pytest+yaml 文件实现接口自动化框 ...
python接口自动化实战(框架)_python接口自动化框架实战
python接口测试的原理,就不解释了,百度一大堆. 先看目录,可能这个框架比较简单,但是麻雀虽小五脏俱全. 各个文件夹下的文件如下: 一.理清思路我这个自动化框架要实现什么 1.从excel里面提 ...
全方面了解接口自动化，看完还不会你锤我
一.自动化分类 (1)接口自动化 python/java+requests+unittest框架来实现 python/java+RF(RobotFramework)框架来实现--对于编程要求不高 (2 ...
全栈搭建接口自动化之接口开发（四）
一.前言前面我们把Jenkins环境.开发环境都搭建好了,现在是不是开始可以写代码了,of course,lets do it! 二.实战开始看到网上的教学都喜欢拿登录.注册做demo,这次小弟就 ...
python接口自动化5-Json数据处理
前言有些post的请求参数是json格式的,这个前面第二篇post请求里面提到过,需要导入json模块处理. 一般常见的接口返回数据也是json格式的,我们在做判断时候,往往只需要提取其中几个关键的 ...
浅谈python+requests接口自动化框架
为什么要做接口自动化框架 1.业务与配置的分离 2.数据与程序的分离:数据的变更不影响程序 3.有日志功能,实现无人值守 4.自动发送测试报告 5.不懂编程的测试人员也可以进行测试正常接口测试的流程 ...

一、关于接口自动化的思考

1、为什么做接口自动化？有什么考虑和收益？

2、说一说接口自动化的应用场景

3、什么时候写接口自动化

4、自动化case 有哪些痛点？

随着case量的增加，维护成本与执行成本增加：

稳定性：

报警策略：

目前的自动化为业务带来了哪些收益：

如何做接口自动化？

业务复杂度：

业务测试难度：

业务依赖程度：

业务特点：

确定边界：

设计：

内部真实实现：

面对晋升/面试：

一、关于接口自动化的思考相关推荐

最新文章

热门文章

一、关于接口自动化的思考

1、为什么做接口自动化？有什么考虑和收益？

2、说一说接口自动化的应用场景

3、什么时候写接口自动化

4、自动化case 有哪些痛点？

随着case量的增加，维护成本与执行成本增加：

稳定性：

报警策略：

目前的自动化为业务带来了哪些收益：

如何做接口自动化？

业务复杂度：

业务测试难度：

业务依赖 程度：

业务特点：

确定边界：

设计：

内部真实实现：

面对晋升/面试：

一、关于接口自动化的思考相关推荐

最新文章

热门文章

业务依赖程度：