背景:
一、在敏捷研发流程里进行持续交付,不管是研发、测试小伙伴们对质量都要贡献自己的力量,尤其是测试同学,并发多个需求测试,在整个团队资源固定的前提下,测试资源成为交付的瓶颈。
二、接口测试背景:
开发 - 在公司研发脚手架里会集成 Swagger 类似的在线 APi 管理平台,如果传统的,一般是 word/execl 线下留存的文档;
测试- 1)基于在线 APi 管理平台、jemeter,postman 等工具来完成接口测试任务;2)基于接口测试平台,去填充接口测试案例
接口测试难度: 接口测试分为参数和业务逻辑验证,参数越多,验证的复杂度环比就会上升,对测试来说,有很大的复杂度,尤其是庞大的微服务下业务接口,让测试没有精力去维护,完善接口测试脚本
方案:测试圈里开始发起测试左移和右移的观点,我也非常同意这种思路。
今天分享下测试左移 - 接口测试左移如何展开,针对背景中描述的两块内容,我们提炼下,接口测试如果降低测试成本,要做哪些事情,谁负责去完善 ;
目前分工:
1、接口测试方案设计 -- 开发
2、接口测试定义 -- 开发
3、接口测试用例编写 -- 测试
4、接口测试用例执行 -- 测试
5、接口测试脚本编写/接口测试平台维护;--测试
6、接口测试回归;--测试;
左移后:
1、接口测试方案设计 -- 开发
2、接口测试定义 -- 开发
3、接口测试用例编写 -- 测试/开发
4、接口测试用例执行 -- 开发
5、接口测试脚本编写/接口测试平台维护;--开发编写、测试 check
6、接口测试回归;--开发
抛一个问题: 怎么支撑开发去完成一个接口测试呢?
1、敏捷团队去引导
2、测试框架支撑;
具体怎么操作:
提交发布流程:
测试接口标记
测试接口展示
以上流程,测试研发团队需要做哪些工作:
1、开发接口测试脚手架: 包含接口测试用例脚本自动生成;
2、测试脚本集成发布流程;
3、测试平台聚合可视化: 覆盖率,回归等等;
接口测试用例脚本生成下个时间再分享......
以上是个人观点,有任何疑问欢迎指正!!!