生产引流测试

  

"生产引流测试”的方法,这种方法的本质就是   。这种测试方法适合有大量用户的系统,如电商网站,电信计费系统,大型控制系统(如机场调度系统)等。这么做有两个好处:

  

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

  

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

  

当然生产引流测试必须满足一个前提:   。^ _ ^ | | |

  

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

  

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

  

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

  

  生产引流测试

  

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

  

  

  

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

  

下面给出一个最简单的模型:它描述了   进行生产引流测试的思路。

  

  

  

  生产引流测试

  在上图中:   红色箭头为生产请求数据。   蓝色箭头为生产响应数据。   绿色箭头为测试响应数据。   代理有2个作用:复制用户到生产系统的请求,引流到测试系统;复制生产系统的响应发送给对比器。   对比器的作用:比对同一请求生产系统和测试系统的结果是否一致,将结果生成报表。                     ,      。   ,               生产引流测试”>
  与实时比对相比,延时比对模型的变化如下:
  代理的作用变成了纪录生产日志,有时候能够直接利用系统的日志模块数据,不用分流、性能压力减少了很多。
  多了一个存储模块存储日志(有可能复用系统现有日志模块)
  多了一个对比引擎,它的作用是:从存储取出成对的请求——响应的数据,将请求数据发送到测试系统,接收测试系统的响应,与存储中的响应结果比对,然后生成报表。
  引擎可能要做比较复杂的日志分析工作:请求——响应配对,清洗无效数据,做数据筛选等。
  由于做了隔离,基本上杜绝了测试系统污染生产系统的风险。
  延时比对也有很多缺点:有很多技术架构,实时复制比记日志再还原要付出的成本小很多,发现缺陷的时间点出现延迟。
  ,
  
  
  
  ,但还是可以做模,型如下:
  
  
  这张图跟上张基本一样,唯一的不同就是比对引擎变成了“加强型”比对引擎。
  加强的地方表现在:对业务不同点进行处理,使得比对工作能够顺利进行。
  有一些技术架构下,对不同点进行处理非常困难,例如,网络应用,一个表单多了一项。你有可能要重写http请求的内容。
  ,
  小结:是否要利用生产引流测试说到底还是一个工程型问题。
  。<h2 class=生产引流测试