最近有朋友入职阿里做测试，每天和她打电话，一直在说表扬阿里的doom多么的好，说得我都心痒痒的，所以去查了一下，确实非常棒！
分享出来给各位看看，看看能否给各位测试的大佬做参考，提升工作效能！
原文：https://help.aliyun.com/document_detail/62635.html?spm=a2c4g.11186623.6.667.4169338eme9isd
什么是双引擎平台
双引擎自动回归平台（简称双引擎或者doom）是一个将线上真实流量复制并用于自动回归测试的平台。 通过创新的自动mock机制不仅支持读接口的回归验证，同时支持了写接口（例如用户下单接口、付款接口）的回归验证。 基于容器隔离机制以及完善的异常处理和监控机制，确保对应用本身的侵入非常小。 通过它，不仅能够实现低成本的日常自动化回归，同时通过它提供扩展能力可以支持系统重构升级的自动回归。 天猫、淘宝核心交易链路系统通过它实现低成本高覆盖率的日常自动化测试回归，同时内部的一些重大重构项目通过它保证系统的无故障升级。 它是复杂的难以通过传统方式做测试回归的业务系统以及金融类对故障十分敏感的系统的稳定性利器。
它与tcpcopy或者diffy的区别：tcpcopy、diffy是在应用外的网络层实现流量录制和回放的，它们只能实现一些只读页面的验证，而且无法实现跨环境的流量回放。双引擎是在应用内部通过aop切面编程方式实现的流量录制和回放功能，因此可以做到应用内部接口级别的回归验证，当然也支持服务级别或者http级别的回归验证。而通过独创的中间件级mock以及内部自定义的mock，可实现写流量的回归验证以及跨环境的回归验证（线上引流到测试环境）。
双引擎是一个封闭的系统吗？答案是否定的，我们希望把它打造成一个开放的平台，系统聚焦录制、回放、比对的核心能力。而数据的存储、数据的传输、中间件的扩展以及回放流程的都可以自定义扩展，使用者可以基于这些基础能力搭建适合自己业务的自动化回归平台。
目前双引擎在阿里巴巴集团内部被广泛使用，成为交易核心重构升级必不可少的利器。同时基于它扩展的‘天启’平台成为交易日常自动化回归的主要工具。
应用场景
系统重构时，复制真实线上环境流量到被测试环境进行回归，相当于在不影响业务的情况下提前上线检测系统潜在的问题。
可以将录制的流量作为用例管理起来进行自动化归回。
低成本：无需编写测试用例，通过流量录制形成丰富的测试用例。
高覆盖：一方面线上大量真实流量确保覆盖率，另一方面支持中间过程的验证，例如发送消息的内容、中间计算过程等等的全对象的对比验证，传统手工编写验证点很难实现。
支持写流量验证：（注：写流量是指可能导致有数据变更的流量）不用担心写流量回放污染应用数据，支持线上引流到测试环境以及写流量的自动化mock。
低应用侵入：通过隔离容器技术、字节码级别的AOP技术、中间件级MOCK避免接入类冲突以及降低接入成本。
主调用：待验证的流量入口，可以是http请求、也可以是一个java调用（公测版目前暂时只支持java调用）。子调用：主调用执行流程中的一些方法调用，这些方法调用入参返回值会被记录下来用于回放时再次调用到该方法是时进行mock。
读接入模式：主调用是读接口，所有对外请求可以不进行mock，也就是不存在子调用的概念，这样的好处是可以验证到整个请求链路。
写接入模式：如果对外有写请求，那么需要通过配置中间件隔离将对外请求作为子调用进行mock。
要实现引入线上流量来做回归验证牵涉到几个问题：流量如何复制？如何保证录制不影响业务？如何回放？如何解决写流量回放对业务的影响？如判断别被测系统bug？
java方法调用可以通过方法aop实现主调用以及子调用的入参和返回值的录制；http流量可以通过设置httpfilter或者对特定的servlet容器进行aop实现对http请求参数录制。当请求结束会启用异步线程池将录制数据序列化后发送给回放机器。
针对用于生产环境的录制机器，任何流量录制异常不影响业务流程正常执行。同时在系统负载高时具备主动停止流量录制的能力。 针对用于生产环境的回放机器（beta机器），客户端可以支持指定rpc中间件不会真正对外提供服务，支持指定的消息中间件不去发送和订阅消息，同时支持指定的数据库框架不去真正执行写数据到数据库。如果是web服务器需要接入方摘除回放机器的vip。
当回放后，可能会执行一些写逻辑，比如写分布式缓存、写db等等。而通过子调用mock的机制可以确保写不会真正发生，因此不会影响业务数据。
对于读接口，我们主要关注在相同请求下正常系统和待测系统的返回结果的差异，读接口也提倡对所有对外请求进行mock，这样回放时能保持当时的一个现场环境，保证验证的准确性。
对于写接口, 只验证接口返回结果是不够的，需要验证它具体写入的数据是否正确。例如创建订单会调用tp的写订单接口，那么我们需要验证回放时调用tp的参数和录制时调用tp的参数是否一致。
对比默认是全对象字段逐一对比，如果存在必然不一致字段，例如时间，系统ip等等可以配置忽略该字段的对比。默认开启子调用对比后所有子调都会对比，也可以配置排除一些不关心的自调用的对比。
答案是可以的，可能大家会疑问，线下库和线上都不一样，怎么跑的通？实际上如果所有对外请求都做了mock，那么线下回访并不会真正发起对外调用，都用线上数据mock，所以可以跑通。利用这点我们可以在项目测试环境回放线上执行的过程，帮助问题复现排查。
平台有中间件隔离配置，例如配置了hsf隔离，那么所有hsf对外调用都会作为子调用。类似的还包括tair、notify等等。另外也支持自定义一个类方法作为子调用。当然我们也提供白名单配置指定某些调用不进行mock，这样可以验证到下游的读逻辑或者解决无法mock的问题。
将部署了稳定代码的服务器作为流量采集源，对于待正式发布的代码，可以用录制的流量来进行回放和差异比对，以便于发现待测系统的问题。那么录制环境和回放环境所处环境不同，有一些必然不一致的信息，例如服务器ip、时间、以及一些随机数等等。怎么去处理这些差异呢？
排除法：平台支持指定字段排除对比，将不需要的字段排除即可。
指定对比法：将关心的业务数据进对比。
平台目前仅支持基于spring框架的java应用，非spring框架java应用需要做额外定制扩展。
目前支持java调用的录制回放、http流量的在集团内部版本支持，云版本后续会支持。
支持的隔离中间件以配置平台为准，如不支持请联系相关技术支持同学。
数据录制有一定的系统资源消耗，具体视应用而定，一般都在可接受范围以内。
运行客户端大概有100~300M的额外内存消耗，请规划好应用的内存。
网友评论