大型项目的接口自动化实践记录-前言
一、项目背景
先介绍下背景,脱离背景上来就直接应该怎么怎么做自动化都是耍流氓(当然能让领导给足够的资源做,那就无所谓):
1、内部项目:主要是保证产品功能的准确性,安全、性能属于可以逐步优化的点。
2、技术陈旧:10几年的项目了,因此技术比较旧,前后端未分离(很多功能是后端直接返回html、xml,接口文档难整理)。
3、项目庞大:高度定制化满足各个事业部的需求,因此系统体量大,千表级别,需要验证的内容极多,同体量的内部系统,据了解测试人员近20个。
4、项目特征:复杂的大表单(如订单新增表单,字段数150+,涉及多层嵌套的明细,平均要10分钟构造一条)、长业务链(如订单->收款计划->账单-->收款,模块间重度依赖,长的业务链会涉及到7-8个大模块,每个模块间又有多个接口关联)
5、团队情况:开发:15,测试:5,这个比例按理来说还好,但是因为项目前7年没有测试,后面才逐渐补充,测试中有两个是新招的。
二、做自动化的目的
1、减少日常测试工作
从前面的背景介绍中可以看出,测试新功能,测试人手够;但是要补前七年的坑,则测试人手严重不足。因此首要考虑是做一定程度自动化,减少日常测试工作,以腾出人力去填坑,这里的自动化指的不是自动化测试,只是自动化,包括接口的实现但先不校验、数据库数据快速复用、系统日志自动获取等。
2、校验核心老功能
核心的老功能是每次测试首先要保证的点,而这块因为新功能的引入又很容易被动到,因此这块需要做下自动化测试。
3、减少开发内测、用户外测时间
前两点是在测试内部的优化点,而减少开发内测、用户外测的时间,则是要把测试团队的成果给其他团队使用(其他团队使用并认可你团队的成果,最能证明你的行之有效)。
4、在流程上做优化,提前发现BUG,使工程整体工期缩短。
三、自动化方案选择
1、做哪些自动化
1)接口自动化:校验后端+DB存储,主要通过接口请求,校验数据库存储与预期一致。因为很多接口涉及到多表存储,如订单新增接口,字段数150+,涉及到10+表,校验其数据的存储是否准确,是否有字段丢失,关联关系是否正确很重要。
2)数据库自动化:数据的查询、插入
3)服务器交互:获取系统日志、mysql日志,备份、导入数据库表、库
4)查询平台:因为系统是长业务链,因此主要是提供各个业务链节点的可用数据,给测试、开发、用户使用,以减少构造数据的时间。
5)UI自动化:因为人手严重不足,因此这块基本不考虑。
2、技术选择
1)抓包工具:fiddler
2)接口、数据库、服务器交互部分:Robotframework+相关库,考虑人手不足且团队人员没有相关基础,因此入门相对简单但是可拓展性强,各种库完善,报告良好,又可以与jenkins等很好结合的Robotframework,就成了非常好的选择。
3)没有现成库的:python封装成Robotframework可用方法
4)数据库表获取:shell脚本+Robotframework-SSH部分
5)查询平台:python+flask
四、自动化实现
内容较多,实现在后面分篇记录。
目前已经实现:
1)营销订单新增:日常测试频繁使用,每次减少10min构造时间,且可以快速复制已有的复杂数据,用于定位问题等;同时该模块核心case200+,每个版本回归可减少2000+min时间,且数据维护工作量极低,手工测试后记录即可。类似场景的大小模块实现多个。
2)工作流自动化测试:以最少的case遍历所有分支,每个case减少时间:数据构造+工作流审批耗时,约6-7min。
PS:另外实现自动审批(非自动化测试):构造一条数据后,自动获取当前节点,自动审批至通过。
3)二级业务链节点自动化,如分摊配置,依赖订单的数据:单个case手工需要10min,另外需要加订单构造10min,核心case50+。日常测试频繁使用,每次减少20min构造时间,同营销合同新签,可以快速复制已有的数据,用于定位问题等;每个版本回归可减少1000+min时间。
4)解耦业务链,二级业务链节点自动化时,不需要再马上先做一级业务链节点新增。
5)提供查询平台,自动化生成的可用数据在平台展示,测试、开发测试时可以快速获取。
内容是边实践边记录,内容比较粗糙,欢迎感兴趣的大佬们指教沟通
也欢迎新手一起来灵感的触碰(思路比实现更重要,我们也是在一边思考方案一边实践,不少思路也是团队内没有基础的提供的,与其花好多money培训,不如自学在实际项目中实践)
作者:慢慢走的测试
出处:https://www.cnblogs.com/walkingtester/
交流群:636090586(备注博客园)
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
如果喜欢我的文章,请关注我的公众号