阿里内部创新自动化测试工具开放啦

背景

  信息系统上线后通常会需要迭代升级甚至重构，如何保证被修改后系统原有业务的正确性非常重要。不复杂的业务系统通过一些常规的自动化测试工具加上人工测试可以解决，但对于业务十分复杂的系统，回归测试将变成一项浩大的工程。
  一个实际的例子：阿里巴巴作为一家以电商为核心的集团公司，交易系统和稳定性的重要性不言而喻。整个交易系统在多年的发展过程中，经历了很多业务的上下线，维护的人员也换了一波又一波，几乎没有人能梳理清楚其中的业务和代码。当它不得不面临一次全面升级的时候，其回归测试的困难度难以想象。因为常规的自动化测试工具需要准备测试数据、编写脚本，因此覆盖率不高，因此无法满足需求重构后的回归验证要求。
doom平台的出现解决了这一难题，它通过复制线上真实流量去做自动化回归，通过它发现了很多重构带来的bug，同时加快交易重构项目的上线进程。同时通过录制流量作为用例来实现日常自动化回归取代传统编写脚本的自动化回归大大提升了回归效率和覆盖率。

平台介绍

什么是doom平台

  doom自动回归平台是一个将一部分线上真实流量复制并用于自动回归测试的平台。 通过创新的自动mock机制不仅支持读接口的回归验证，同时支持了写接口（例如用户下单接口、付款接口）的验证。原理图如下：

  它与tcpcopy或者diffy的区别：tcpcopy、diffy是在应用外的网络层实现流量录制和回放的，它们只能实现一些只读页面的验证。doom是在应用内部通过aop切面编程方式实现的流量录制和回放功能，因此可以做到应用内部接口级别的回归验证，当然也支持服务级别或者http级别的回归验证。通过独创的中间件级mock以及内部自定义的mock，可实现写流量的回归验证以及跨环境的回归验证（线上引流到测试环境）。

 我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。

应用场景

• 系统重构时，复制真实线上环境流量到被测试环境进行回归，相当于在不影响业务的情况下提前上线检测系统潜在的问题。
• 可以将录制的流量作为用例管理起来进行日常自动化归回。

优势

• 低成本：无需编写测试用例，通过流量录制形成丰富的测试用例。
• 高覆盖：一方面线上大量真实流量确保覆盖率，另一方面支持中间过程的验证，例如发送消息的内容、中间计算过程等等的全对象的对比验证，传统手工编写验证点很难实现。
• 支持写流量验证：（注：写流量是指可能导致有数据变更的流量）不用担心写流量回放污染应用数据，支持线上引流到测试环境以及写流量的自动化mock。
• 低应用侵入：通过隔离容器技术、字节码级别的AOP技术、中间件级MOCK避免接入类冲突以及降低接入成本。

原理

• 如何实现回归验证？
    对于web应用来说，请求最终都通过发起http请求方式来完成。我们假定生产环境应用会正常的响应用户的请求，通过aop的方式将请求入参及返回结果以及执行过程中的一些快照数据例如访问数据库的入参和返回结果、访问远程服务器的入参及结果保存下来。然后将快照数据发送给测试机器（代码发生变化的机器）完成一次回放过程。通将落库数据、调用后台请求的数据以及返回结果和线上真实请求发生时的数据进行全量对比，发现其中的差异，从而识别被测试系统的问题。针对后台应用来说也是如此，只是后台应用一般都是通过rpc请求实现，这时只要记录rpc入参、rpc返回值以及中间快照数据用于回放即可。

• 如何保证数据库不被污染？
    mock是单元测试常用手段，用来解决接口未完成或者调不通的情况。将这个特性进行延展，在线上执行真实请求时就把写数据库的请求以及对外服务的访问保存下来，在回放时当执行数据库或者调用后台的服务进行mock，这样回放时不会真正的访问数据库，也不会真正的发起对后台服务的调用，因此会影响业务数据，甚至可以在线下环境进行回放，因为mock数据来源于真实请求，也省去了造数据的麻烦。

原文链接