生产引流测试

发表于:2014-06-04来源:博客园作者:skytraveler点击数: 标签:软件测试
在上篇文章《让用户帮你做测试》中我提到了“生产引流测试”的方法,这种方法的本质就是把生产系统发生的一切复制到测试系统上来。这种测试方法适合有大量用户的系统,如电商

  在上篇文章《让用户帮你做测试》中我提到了“生产引流测试”的方法,这种方法的本质就是把生产系统发生的一切复制到测试系统上来。这种测试方法适合有大量用户的系统,如电商网站、电信计费系统、大型控制系统(如机场调度系统)等。这么做有两个好处:

  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的模式;可以在交易中间件、企业总线上做一些改造,只要系统设计的不是太难搞,办法总是有的。

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

  实时对比:

  在上图中:

  红色箭头为生产请求数据。

  蓝色箭头为生产响应数据。

  绿色箭头为测试响应数据。

  代理有2个作用:复制用户到生产系统的请求,引流到测试系统;复制生产系统的响应发送给对比器。

  对比器的作用:比对同一请求生产系统和测试系统的结果是否一致,将结果生成报表。

  比对是实时的。

  请求和响应必须附加流水号:这样做比对的时候才会不那么费劲(应对异步的情况),否则

  生产系统同测试系统的初始状态必须一致,不然做比对也会很困难:举例来说,电商网站中某种书的库存数。

  实时比对的好处是:能够在出现bug的第一秒就发现它。但它也存在问题和局限性:生产系统与测试系统直接相连可能给生产系统带来风险,实际上在很多生产安全要求较高的公司,这么做是不被允许的。

  延时对比:

  与实时比对相比,延时比对模型的变化如下:

原文转自:http://www.cnblogs.com/skytraveler/p/3542046.html