“生产引流测试”的方法，这种方法的本质就是 把生产系统发生的一切复制到测试系统上来。这种测试方法适合有大量用户的系统，如电商网站、电信计费系统、大型控制系统（如机场调度系统）等。这么做有两个好处：

创新互联公司2013年至今，先为秦安等服务建站，秦安等地企业，进行企业商务咨询服务。为秦安企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

1.能够让系统在真正上线以前就能够真正经受实践检验。多年来的测试实践告诉我们，测试永远是抽样活动，即使经过很大强度的 充分测试，很多大型系统上线后仍然马上会产生这样那样的问题，有时候这些问题往往是致命的。

2.不会象灰度发布那样拿部分用户当小白鼠，引发部分客户不满；其实要实现灰度发布在一定程度上会增加系统架构复杂性，不是哪个公司都能玩得转。

当然生产引流测试必须满足一个前提： 那就是已经有了生产系统，在特性升级或者技术重构的时候使用这招。 ^_^|||

生产引流测试的用法一般有如下几种：

1.非功能测试（主要是性能测试），看看将生产系统的压力引到测试系统后，测试系统会不会产生性能问题。这种测试往往非常有效，因为，我们做性能测试也是非常有局限性的：场景选取不可能跟真实用户带来的压力完全一致；网络、硬件环境也可能不一样；某些超大型网站根本没办法模拟那么大的压力，只能依靠缩量模型做测试并估算真实的性能。

非功能测试不太关注业务逻辑的正确性，因此我们可以从网络层进行生产引流，这样效率更高，模型更加简单。目前有一个非常不错的工具tcpcopy，非常适合web类产品。它的工作原理可见下图：

部署一个agent在onlineserver上。从tcp层截取数据包，然后生成向Testserver的请求数据包（通过换网络传输的数据包的包头）， 这样压力就传导到了Testserver上。Testserver的响应数据包被 Assistant server截获，截获后拆包，删除包中内容（减小部署在Online Server端agent的压力），封包，回复给Online Server上的agent（TCP协议要求必须有来有回）。Tcpcopy在网易，淘宝，去哪儿等很多公司都得到了非常好的应用，目前国外也有很多用户开始使用这个工具了，如果大家有兴趣可以查看作者在Github上的页面 https://github.com/wangbin579/tcpcopy 或者作者的博客： http://my.csdn.net/wangbin579 很赞作者王斌！

2.功能测试

对于功能测试，单纯的使用tcpcopy就有些不足了。 因为功能测试关注业务逻辑，我们一般要对结果内容进行比对，而不是简单的抛弃。而在网络层进行内容比对代价是非常大的，有时候是不可完成的任务，如非web类产品；另外，不同的技术架构造成了某些内容是无法简单在网络层复制的，如某些加密信道传输的内容、包含了认证信息的内容、对目标机器信息有依赖的内容。这样， 我们就需要在应用层想办法，而不是在网络层。一般我们会在应用层加一个代理将请求和响应进行复制，这个代理根据被测系统的技术架构不同而不同，比如web服务器，可以搞一个反向代理来做这件事儿；银行、电信用的多的Message Queue 可以采取pubsub的模式；可以在交易中间件、企业总线上做一些改造，只要系统设计的不是太难搞，办法总是有的。

下面给出一个最简单的模型：它描述了 技术重构的系统（功能上无变化）进行生产引流测试的思路。

实时对比：

与实时比对相比，延时比对模型的变化如下：

代理的作用变成了纪录生产日志，有时候能够直接利用系统的日志模块数据，不用分流，性能压力减少了很多。

多了一个存储模块存储日志（有可能复用系统现有日志模块）

多了一个对比引擎，它的作用是：从存储取出成对的请求-响应的数据，将请求数据发送到测试系统，接收测试系统的响应，与存储中的响应结果比对，然后生成报表。

引擎可能要做比较复杂的日志分析工作：请求-响应配对，清洗无效数据，做数据筛选等。

由于做了隔离，基本上杜绝了测试系统污染生产系统的风险。

延时比对也有很多缺点：有很多技术架构，实时复制比记log再还原要付出的成本小很多；发现缺陷的时间点出现延迟。

 

对于 业务升级类型的 系统，业务流程或者计算逻辑发生了变化， 使用生产系统数据进行比对的难度就大大增强了，但还是可以做，模型如下：

这张图跟上张基本一样，唯一的不同就是比对引擎变成了“加强型”比对引擎。

加强的地方表现在：对业务不同点进行处理，使得比对工作能够顺利进行。

有一些技术架构下，对不同点进行处理非常困难。例如，web应用，一个表单多了一项。你有可能要重写http请求的内容。

 

小结：是否要利用生产引流测试说到底还是一个工程型问题。 一定要看它的投入产出比。