网站开发工作分解结构的树形图,中文网站域名,网站平台建设项目书,亚马逊新店投广告是免费的吗前言
去年换了一个新部门#xff0c;看了下当前的自动化用例的情况#xff0c;发现存在三类性能问题#xff1a;
本地调试运行时等待时间较长#xff0c;就算是一个简单的case#xff0c;执行时间都需要1分钟以上单用例执行时间比较长#xff0c;部分用例执行时间超过2…前言
去年换了一个新部门看了下当前的自动化用例的情况发现存在三类性能问题
本地调试运行时等待时间较长就算是一个简单的case执行时间都需要1分钟以上单用例执行时间比较长部分用例执行时间超过2分钟集成到CI中运行时执行时间较长
对于上述三个问题花时间进行了一定程度的优化总结如下
优化本地调试时间
通过调试可以发现一个需要执行660ms的case在执行前的初始化工作就需要消耗约1分半钟那么就需要思考下能否减少这部分初始化时间了。 公司用的自动化框架是基于AbstractTestNGSpringContextTests的框架。AbstractTestNGSpringContextTests是一个spring集成testNg的工具可以通过ApplicationContext加载bean。ApplicationContext实现的默认行为就是在启动服务器时将所有bean提前进行实例化。提前实例化意味着作为初始化过程的一部分applicationContext实例会创建并配置所有的bean。
如果是作为一个spring服务在启动时将bean提前进行实例化然后可以处理所有的请求这样的做法是很合理的。但是作为本地调试更关注是自己case运行时所需要的bean是否实例化而不需要将所有bean进行实例化。
查阅了下spring相关文档发现可以引入lazy-init来告诉ApplicationContext按需加载bean。 配置方式有两种
default-lazy-init参数其配置形式如下beans default-lazy-inittrue /beans lazy-init参数其配置形式如下bean idstu lazy-init“true”/bean
配置完成后运行了一下发现并没有速度上的提升原因是之前编写时将大部分的bean的初始化放在了测试用例里的基类里面导致启动时认为这些bean都需要初始化。 这说明要让lazy-init生效提高单用例的启动速度那就要尽可能少的使用不需要的bean需要做一定改造
将service/DAO初始化挪到测试用例里面。去除不需要的多余的service/DAO。
按照上面的思路对用例进行了优化可以将用例的初始化时间精简到30秒左右。 单用例执行时间的优化
为什么会出现很多的用例执行时间超过2分钟呢做了一些分析和调试后主要有几个原因
业务决定了服务之间很多是通过消息的方式进行传递存在异步调用所以需要等待再进行后续执行为了用例的稳定性往往设置了过大的sleep time。一些数据准备和初始化操作不合理无谓的耗时。
下面来看几个案例
在beforeclass里面都会有一段初始化数据的操作先调接口查询数据是否存在不存在则进行初始化导致每运行一个测试用例类都需要做一次对应操作。 实际上这些数据初始化完后可以一直被使用不需要多次检查可以优化的地方是用个静态变量判断数据已初始化的话就不检查或者将该操作设置为跑一次用例集只运行一次。
大量使用了sleep做等待如果操作需要等待1s左右才生效那么用sleep往往需要sleep2秒所以sleep一般会造成50%左右的性能浪费。 引入异步校验工具Awaitility对原有代码进行改写。
Awaitility的基本的语法为
pollInterval执行间隔pollDelay等待多久开始执行atMoast执行的超时时间until- 执行其中的语句直到返回true或超时 这样的写法比较优雅简介如果判断执行完成可以提前结束等待避免时间浪费。
提高并发
当优化了单用例的运行时间后虽然对总体自动化集成测试的运行速度有一定帮助但当用例越来越多的时候时间也会变得无法忍受能想到的一个办法是增加用例的并发。
用例能够并发执行的前提是用例之间具有隔离性一个用例的执行不会影响另一个用例的执行比如我在店铺A下单和在店铺B下单这两个用例就不会有干扰又比如我在店铺A创建商品和我在店铺A下单也不会有影响。 所以考虑用例并发的时候需要先针对自己的业务特性进行一定程度的分组隔离。
在我们的案例中考虑对店铺进行分组用例并发用到的并发基本机制是testNG paralleltests/class thread-count“N。 在实际执行中分组的实施也会有两种模式按case的纬度还是按照类的纬度 1.使用店铺id分组进行并发使用group店铺id 维度 优点任意维度扩展 缺点每个case需要加group 2.把不同测试类按店铺id分组使用package/class维度 优点改动简单 缺点需要每个测试类只使用一个店铺id缺乏扩展性需要频繁改动配置文件
最后选择了按case纬度因为现存的用例并未很好的按店铺id进行组织比较散乱使用类的纬度改动较大。 使用了两个并发以后性能提升明显时间从547s-270s。 最后
解决了一部分性能问题后尤其是提高了用例并发以后对用例稳定性也更高了。
和开发写代码需要考虑异常和容错处理一样测试人员在自动化设计、实施等各阶段都需要考虑用例的稳定性问题 减少外部依赖。如果执行过程需要依赖其他系统的接口那么其他系统发生了变更或故障就会影响自身用例的进行。可以考虑通过预先生成的数据来替代调用外部接口生成数据在用例中使用。第三方接口的调用可以考虑mock
。预置数据代替创建过程。由于操作越多稳定性越低使用预置数据而不是实时生成它速度更快稳定性更高。使用不同维度进行隔离。通过隔离用例执行失败的脏数据就不会影响其他用例。调优超时、等待时间。线上超时时间设置的比较短测试环境的机器配置不如线上需要适时调大超时和等待时间来保证接口调用不会超时。防御式编程。编写测试代码时不能假设数据已存在或者没有脏数据残留所以预先的判断和清理很重要比如检查到数据缺失就实时修复、用例运行之前考虑清除临时数据等。定位并解决不稳定的问题。有时候偶现用例失败可以考虑给被测应用增加日志同时持续多次运行用例多次如 testNg 里增加threadPoolSize1, invocationCount50来复现问题最终解决问题。
