比较测试的设定和分析

标签: 资料报告 比较测试 | 发表时间:2011-09-13 21:19 | 作者:P迪 小宇
出处:http://www.alibuybuy.com

基于前一篇文章——T检验和卡方检验中提出的数据比较方法,其实我们在生物或者化学的实验中经常也会涉及比较,这篇文章就来具体介绍如何在现实的网站分析环境中使用这些方法,使用的前提和环境是怎样的。

其实我们在做数据分析的时候经常进行比较分析,但往往以观察分析法为主,“T检验和卡方检验”为我们的比较分析提供了很好的科学的定量分析方法,让比较的结果更有置信度和说服力。但在使用定量分析的比较方法前,还有很多因素需要考虑,当我们需要精确地分析比较的效果,我们一般都会做比较测试,而其中涉及测试环境的设定,数据的选择和获取等,以排除一些非相关因素的干扰,让比较的结果更加真实可信,所以下面就介绍下如何合理地进行比较测试。

比较测试的类型

比较测试或实验的类型有很多,但都跳不出抽样、重复、分组、比较这几个流程,所以从实验设计的角度,我们可以简单地把比较测试分为两类:基于时间序列的组内比较基于对照实验的组间比较

时间序列的组内比较

基于时间序列的组内比较一般在时间序列上的某个时间点引入实验变量或者施加实验刺激,并在实验刺激的前后进行重复测试,分别叫做“前测”和“后测”,对前测和后测分别进行抽样比较,从比较的结果反映实验刺激是否对结果有显著的影响。详细的流程见下图:

Time-Serial-Comparison

举个有趣的例子,如果公司的员工前4个月在正常的薪资待遇的水平上工作,体现出正常的工作效益和工作满意度;然后从第5月开始给员工进行加薪(施加实验刺激),再观察之后4个月员工的工作效益和工作满意度,将之前4个月的结果(前测)与后4个月的结果(后测)进行比较,分析员工的工作效益和工作满意度是否存在显著性差异,进而证明加薪这个实验刺激是否对提升员工的工作效益和满意度有显著性影响。这就是简单的时间序列比较测试的基本流程。

但基于时间序列的比较测试会受很多因素的干扰,比如上面的例子在实验过程中CPI的增长、公司业绩的下滑或者运营环境的恶化都可能导致实验结果的失效,或者验证的结果不可信,所以下面会具体说明需要排除的干扰因素。

对照实验的组间比较

基于时间序列的组内比较只是基于一组样本,只是样本在时间序列的某个点上受到了实验变量的刺激;而对照实验需要设定两组样本,也就是“实验组”和“控制组”,并对实验组施加实验刺激,控制组维持原状态不变,从而比较实验组和控制组是否存在显著差异来反映实验的刺激是否影响了结果。因为对照实验涉及两组样本,所以这里需要额外注意抽样的规范性,我们需要保证两组样本的特征具有相似性,可以进行比较。具体的实验设计见下图:

Controlled-Trial-Comparison

还是使用上面的例子,但在对照实验中设置对照组和实验组是必需的,比较不再是基于前测和后测。比如我们让部分员工维持当前的薪资待遇继续工作,而另外一部分的员工提升他们的薪资待遇,从而比较为提升待遇的员工和提升待遇的员工的工作效益和工作满意度的差异,如果差异显著就可以证明提升薪资待遇这个实验刺激对结果是有显著影响的。

对照实验因为参与比较的两组样本都是基于相同的时间序列轴,所以随着时间变化的影响因素对实验的比较结果的影响不再重要,因为两组样本同时受到了同样的影响,但因为是组间比较,所以两组样本如果存在差异性,那么对结果就会造成较大影响,比如上例中A组选择的是基层员工,B组选择中高层员工的话,比较的结果显然是缺乏科学性的。下面就具体介绍下比较测试中可能存在的影响因素有哪些?

前提与影响因素

首先看一下从用户体验的角度,如果我们进行可用性实验,需要考虑的影响因素有哪些:

  • 外部噪声和干扰:外部干扰信息、临时的电话和呼唤等;
  • 经验和熟练:因为可用性实验一般需要重复过程,所以随着实验的进程,用户渐渐熟悉对网站和工具的使用;
  • 消耗:随着实验进程,用户可能失去耐心,或者精力无法集中;
  • 主观预测:当进行重复实验时,用户容易用先前的测试结果来推测之后的测试,同样会影响实验结果的可信度。

以上是可用性实验中需要考虑的影响因素,有些只存在于实验环境中,如果衍生到WEB分析中,同样需要注意一些影响因素,而对于上面介绍的时间序列组内比较和对照实验组间比较,各自的影响因素又各不相同:

时间序列的组内比较

基于时间序列的组内比较可能存在的干扰因素相对较多,因为外部环境和内部环境都会随着时间发生变化,所以为了让基于时间序列的前测和后测两组数据具有可比性,我们必须规避以下几类因素的影响:

  • 数据本身存在的自然增长或下降趋势;
  • 规避节假日或者外部事件的影响;
  • 规避特殊的营销推广其带来的影响;
  • 规避内部其他可能影响测试结果的因素(实验刺激必须唯一)。

对照实验的组间比较

对照实验因为两组样本处在相同的环境和时间序列上,所以需要规避的影响因素比上面要少很多,但相较组内比较,组间比较需要额外考虑两组样本是否具有可比性:

  • 两组样本特征相似,可比较(抽样规范性);
  • 实验组跟对照组之间只存在唯一的实验刺激导致的差异。

无论是基于时间序列的组内比较还是基于对照实验的组间比较,都要规避外部环境的重大变动,或者特殊的外部事件对网站造成的重大影响,或者服务器故障或数据统计异常造成的数据不完整或不准确,因为这些因素造成的影响已经可能导致用于比较的数据本身就存在巨大误差,或者不可信,都是无法规避和弥补的。

网站应用实例

网站环境下最常见的比较测试显然就是A/B Testing,AB测试为网站的改版和优化提供了对照实验的比较测试环境,具体的流程如下:

A-B-Testing

访问网站的用户被AB测试的系统自动分成了两组,一般情况下是按比例对半划分,当然很多情况下也会根据需要按其他合适的比例,如1:3,1:5等。这里的A方案和B方案一个是未做改动的原方案,另一个是改版后的新方案,如果一次需要测试多个改进方案的效果,那么就需要设定多个实验组,而控制组只要一个就行。

A/B Testing属于对照实验的组间比较的测试方法,所以同样需要符合对照实验的前提,规避对照实验可能存在的其他影响因素。因为A/B Testing遵循了简单随机抽样的方法,所以我们可以认为实验组和对照组之间的样本无明显的差异,具有可比性。同时,对照实验基于相同的内外部环境和相同的时间序列,所以诸如节假日、数据自然增长或下降、特殊推广期等的影响可以不用考虑,但某些特别重大的外部事件或者网站服务器故障导致的数据问题还是需要在比较测试之前进行排除。另外对照实验中必须控制每个实验组的实验刺激只能是1个,不然无法区分到底是哪个实验刺激对实验结果造成的影响。

在规避上述影响因素后,基于A/B Testing的数据比较可以使用我在上篇文章中介绍的“T检验和卡方检验”的方法直接进行显著性的检验,进而验证实验刺激对结果是否存在显著性影响,这里不再重复举例了。

A/B Testing有自己的优势,它比基于时间序列的比较的限制因素要少很多,但A/B Testing毕竟需要预先构建相应的自动分流系统,可能在某些特定的环境下或者对某些特殊的网站而言没有相应的环境可以进行AB测试,这个时候我们就不得不选择时间序列的比较测试。

基于时间序列的组内比较需要规避推广、节假日和外部营销事件的影响,这个可以通过选择合理的测试起止时间,选择合适的前测和后测样本进行规避,但如果网站本身数据存在明显的上涨或下降趋势,那么我们必须对数据进行必要的处理:

改版前 改版后
用户数 订单数 用户数 订单数
12395 576 13920 704
13237 641 14391 715
13450 732 15692 781
13872 693 16533 839
14673 770 15916 813

上表是某电子商务网站基于时间序列改版前后的比较测试,前测和后测各选取5天的数据进行比较,以“订单数”作为比较指标,为了说明改版能不能显著地提升每天订单的数据。如果我们不考虑数据本身的自然增长,直接比较改版前后日均订单数的差异:

改版前日均订单数682.4 < 改版后日均订单数770.4

显然改版后日均订单有显著提升,说明改版有效?那么我们将数据的自然增长考虑进去,我们可以将日均用户数的增长率作为整个网站数据的自然增长率:

(改版后日均用户数 – 改版前日均用户数) / 改版前日均用户数 = 13.05%

改版前日均订单数682.4 * 1.13 = 771.1 > 改版后日均订单数770.4

比较的结果发生了改变,改版前的日均订单数在乘上自然增长率后要比改版后的日均订单数高,但相差不多,从结果看应该是改版对订单数的提升无显著影响。显然后面考虑网站自然增长率后的比较结果更加科学,更加可信和具有说服力。这就是我们在基于时间序列的比较测试中需要考虑的一些问题。当然上面是基于简单的观察分析比较,如果需要更具统计学意义的定量比较,同样可以对数据进行自然增长处理后使用T检验或者卡方检验。

这篇文章可能写得有点长,本来想分两篇发布,但因为内容不太好分段,也怕影响内容的连贯性,所以最终都整合到了一篇,希望大家有耐心能够看完。当然期间的一些看法如果有问题,或者大家有自己的其他见解,都可以在下面评论留言,非常欢迎大家提出其他的看法。一边在看羽毛球世锦赛男单决赛一边更新了这篇博客,希望文中不要存在过多地错误或者错别字 ;)

» 本文采用 BY-NC-SA 协议,转载请注明来源:网站数据分析 » 《比较测试的设定和分析》

 


© 推荐 for 互联网的那点事, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

你可能也喜欢:

三种可用性测试方法介绍

可用性测试(软件/Web)

11款不同版本浏览器性能测试:IE7表现最差

性能测试开源小工具——http_load

第一次可用性测试
无觅

Feed enhanced by Better Feed from Ozh

相关 [测试 设定 分析] 推荐:

比较测试的设定和分析

- 小宇 - 互联网的那点事...
基于前一篇文章——T检验和卡方检验中提出的数据比较方法,其实我们在生物或者化学的实验中经常也会涉及比较,这篇文章就来具体介绍如何在现实的网站分析环境中使用这些方法,使用的前提和环境是怎样的. 其实我们在做数据分析的时候经常进行比较分析,但往往以观察分析法为主,“T检验和卡方检验”为我们的比较分析提供了很好的科学的定量分析方法,让比较的结果更有置信度和说服力.

[转]Jmeter测试结果分析

- - 小鸥的博客
Jmeter测试结果分析这一篇,我打算分成上下两部分. 上篇,主要讲述如何使用jmeter中Assertion对结果进行简单的分类;下篇,主要讲述的是当我们拿到测试结果后,我们应该如何去看待这些测试结果. 用过LoadRunner的人都知道,LoadRunner本身提供了很多函数可以对收集回来的结果进行一些初步的分析.

LoadRunner做性能测试 从设计到分析执行

- - CSDN博客推荐文章
  测试中报错的信息解决:. Failed to connect to server "域名:80": [10065] No Route to Host.   这种错误信息有两种情况,一是交换机堵塞,一是服务器网络堵塞或者CPU无法响应(网卡中断处理不过来了).   从服务器端检查下iptables 是否开启,看看 /proc/sys/net/ipv4/ip_conntrack_max 是多少.

Android 平台 HTTP网速测试 案例 API 分析

- - CSDN博客推荐文章
作者 : 万境绝尘  . 工信部规定的网速测试标准 : 除普通网页测速采用单线程外,用户宽带接入速率测试应使用多线程(多TCP连接)HTTP下载进行测速,测试中使用的线程数量为N(N≥4). -- 建立连接 : 用户终端设备发起测试请求后,与测速平台建立 N 条 TCP 连接,并在每一条 TCP 连接上发送HTTP[GET]请求发起一次测试过程.

性能几何 小米手机硬件分析及跑分测试

- Jack - cnBeta.COM
小米手机之所以成为近期智能机产品中的明星,就在它超高的硬件配置. 其机身尺寸为125x63x11.9毫米,整机重149克. 该机采用的是夏普推 出的4英寸触控屏,分辨率为854x480像素,搭载主频 1.5GHz高通Snapdrogan System 3系列的MSM8260双核处理器,内置1GB RAM内存和4G ROM容量空间,配有800万像素后置摄像头,使用1900mAh电池.

测试

- 香姜 - 韩寒
测试......>>点击查看新浪博客原文.

Android单元测试与模拟测试

- - 神刀安全网
考虑可读性,对于方法名使用表达能力强的方法名,对于测试范式可以考虑使用一种规范, 如 RSpec-style. 不要使用逻辑流关键字(If/ese、for、do/while、switch/case),在一个测试方法中,如果需要有这些,拆分到单独的每个测试方法里. 测试真正需要测试的内容,需要覆盖的情况,一般情况只考虑验证输出(如某操作后,显示什么,值是什么).

免费测试VPN

- 勇 - iGFW
lusovps目前提供免费15天的PPTP VPN试用服务,. 申请地址:https://cart.lusovps.com/cart.php?a=add&pid=13. WHMCS注册系统,可以参考 http://igfw.tk/archives/3727. 注册后无需审核,立刻激活,帐号信息会发至邮箱.

HTTP负载测试

- - 博客 - 伯乐在线
英文原文: ON HTTP LOAD TESTING 来源: oschina. 有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择. 这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑. 在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.