CN103324566A - 一种网页产品多版本测试方法及装置 - Google Patents

Abstract

本申请公开了一种网页产品多版本测试方法及装置，用以准确预估多版本测试需要的时间，提高多版本测试的测试效率以及测试结果的准确性。其中，网页产品多版本测试方法，包括：针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；根据所述期望值，分别确定各测试版本需要的测试时间；在所述测试时间内，接收各访问用户提交的访问请求；并按照预设的用户分流规则，将各访问用户分配至对应的版本测试桶中；以及针对任一测试版本，分别记录各访问用户的操作信息，进行统计分析得到测试结果。

Description

一种网页产品多版本测试方法及装置

技术领域

本申请涉及页面测试技术领域，尤其涉及一种网页产品多版本测试方法及装置。

背景技术

在网页开发的过程中，对开发成果进行检验是必不可少的环节。本次产品升级是否能够满足最终用户的需求，往往对于产品负责人存在较大的考验，只能凭借自己的经验来预估用户的期望。采用传统方式来迭代开发产品存在一定的风险同时未必一定能达到预期。

随着互联网技术的发展，出现了多版本测试技术，数理统计中的假设检验为多版本测试提供了理论依据。多版本测试是将用户随机分配给不同版本(包括基准版本和测试版本)的网页产品，由于这种随机性不受用户行为及其它***因素的干扰，从而使得测试结果更加客观，能够针对地域或者用户群体进行实际测试，并通过收集并分析测试结果，来评估哪个版本能满足特定的要求，最终，将选择通过测试确定出的满足要求的网页产品进行全量发布。采用这种迭代式的发布，能够最大程度的迎合用户需求，减小对用户体验的伤害，从而也为后期产品提供持续升级的依据。

目前，多版本测试已经在很多行业中应用，例如医学、农业等，由于互联网产品更新频率快。周期短和成本低的特性，使得这种方式得到了大力推广。知名的互联网公司大都可提供多版本测试的实现方案。目前，较为典型的实现方案如下：

步骤1、提供测试的多个版本的网页产品；

其中，各测试版本可以为整个页面的URL，也可以是页面的某一块区域。

步骤2、将步骤1提供的测试地址或区域名称作为参数，创建一个测试实例；

步骤3、测试实例创建完成后，在基准版本对应的页面上嵌入生成的分流及统计脚本，在测试版本对应的页面及着陆页(landing page)对应的页面上嵌入统计脚本；

步骤4、当有用户访问基准版本时，能够按等比例，将用户分流至各测试版本，并统计各测试版本对应的页面的相关指标。

现有的多版本测试方案中，由业务负责人根据经验来估算需要的测试时间，使得测试结果依赖于业务负责人的经验，影响了测试效率，同时，刚开始没有经验值能够参考时，是无法准确预估测试多长时间才能覆盖所有测试变量，从而无法准确预估测试需要的时间，使得各测试变量得不到充分测试，影响了测试结果的准确性。

发明内容

本申请实施例提供一种网页产品多版本测试方法及装置，用以准确预估多版本测试需要的时间，提高多版本测试的测试效率以及测试结果的准确性。

本申请实施例提供一种网页产品多版本测试方法，包括：

针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

根据所述期望值，分别确定各测试版本需要的测试时间；

在所述测试时间内，接收各访问用户提交的访问请求；并

根据预先配置的选择器参数，确定所述选择器参数对应的用户分流规则；

根据所述用户分流规则，将各访问用户分配至对应的版本测试桶中；以及

分别记录各访问用户的操作，得到测试结果。

本申请实施例提供一种网页产品多版本测试装置，包括：

获取单元，用于针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

第一确定单元，用于根据所述期望值，分别确定各测试版本需要的测试时间；

接收单元，用于在在所述第一确定单元确定出的测试时间内，接收各访问用户提交的访问请求；

第二确定单元，用于根据预先配置的选择器参数，确定所述选择器参数对应的用户分流规则；

分配单元，用于根据所述第二确定单元确定出的用户分流规则，将各访问用户分配至对应的版本测试桶中；

记录单元，用于分别记录各访问用户的操作，得到测试结果。

本申请实施例提供的网页产品多版本测试方法及装置，首先获取预期某一参考指标达到的期望值，进而根据该参考指标的期望值来计算需要的测试时间，这样，在实施测试时，可以在计算出的测试时间内，按照预设的分流规则，将用户提交的访问请求分配至不同的版本测试桶中进行测试，由于测试时间的计算无需依赖人的经验，从而能够有效避免人为因素及经验不足而导致的测试不充分，提高了测试效率以及测试结果的准确性。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

图1为本申请实施例中，网页产品多版本测试方法的实施流程示意图；

图2a为本申请实施例中，基准版本投放的广告样式；

图2b为本申请实施例中，测试版本投放的广告样式；

图3为本申请实施例中，为用户分配版本测试桶的逻辑结构示意图；

图4a为本申请实施例中，一个测试变量的多版本测试的测试框架示意图；

图4b为本申请实施例中，多个测试变量的多版本测试的测试框架示意图；

图5为本申请实施例中，配置页面的效果示意图；

图6为本申请实施例中，采用本申请实施例提供的网页产品多版本测试方法进行测试的流程示意图；

图7为本申请实施例中，网页产品多版本测试装置的结构示意图。

具体实施方式

为了准确预估多版本测试的测试时间，使得各测试变量能够得到充分测试，以达到提高测试效率以及测试结果准确性的目的，本申请实施例提供了一种网页产品多版本测试方法及装置。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施一

实施例一为本申请实施例中，网页产品多版本测试方法的实施流程，如图1所示，包括以下步骤：

S101、针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

具体实施时，不同的网页产品有不同的衡量指标，因此，不同的网页产品关注的参考指标也不同，例如，对于电子商务网站来说，关注的参考指标主要有转化率、订单转换率以及蹦失率等，其中转化率是指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率；订单转换率是指在一个统计周期内，所有访问者当中，有多少比例的人数进行了某项对网站有利动作行为，例如对于电子商务网站来说即为成功下订单，支付的行为；蹦失率是指在一个统计周期内，用户浏览第一个页面就离开的访问次数占该入口总访问次数的比例。在进行测试时，需要首先获取期望本次测试，某一参考指标的指标值相对于基准版本变化的期望值，即期望测试版本与基准版本提升或者降低的幅度值，以参考指标为转化率为例，假设基准版本中的转化率为2％，期望测试版本比基准版本的转化率提高为40％，即期望测试版本比基准版本能够提升的期望值为2％*40％＝0.008。

S102、根据该期望值，分别确定各测试版本需要的测试时间；

具体的，本申请实施例中，采用概率统计中样本取值估算法，根据基准版本的平均用户访问量、期望值以及本次测试中、测试版本与基准版本差异性变量的个数来计算所需要的测试时间，具体的公式如下：其中：n表示该测试版本需要的测试时间；δ为标准偏差，样本分布中对变化性的一种衡量因子，cov表示基准版本中，某一参考指标对应的指标值，需要说明的是，不同的网页产品关注的参考指标可以不同；r为变量因子，表示基准版本与测试版本之间的差异性变量的数目；Δ表示预期该测试版本与基准版本相比变化的期望值，即期望测试版本与基准版本相比，提升或者降低的幅度值；s为用户量，表示基准版本的平均用户访问量；tra为用户分配率，表示欲分配给测试版本的用户比例。

上述公式中，测试时间是有两部分计算得到的，即测试变量所需要的用户量及访问测试版本的用户量，其中：

测试变量所需要的用户量cou可以表示为：

表示引起的标准误差；访问测试版本的用户量d_cou可以表示为：d_cou＝s*tra。因此，在预估本次测试需要的测试时间时，需要预先确定以下数据：基准版本的平均用户访问量s(可以设置为基准版本的日访问量)，欲分配给测试版本的用户比例tra，基准版本与测试版本对照存在的差异性变量(即基准版本与测试版本之间的区别)的数目r，基准版本中、某一参考指标的指标值cov，预期测试版本与基准版本相比，该参考指标的指标值提升或者降低的幅度值Δ。

为了更好理解本申请实施例，以下通过电子商务网站中，在同一个广告位根据不同策略投放不同类型广告的方式来说明多版本测试需要的测试时间的确定方法。

假设在某电子商务网上有一个250*250的广告位，现有两种类型的广告样式，分别如图2a和图2b所示，假设，图2a为基准版本，是正在投放的广告，图2b为测试版本，测试版本相对于基准版本来说，对页面布局进行了调整。包含两个测试变量，分别为：第一测试变量——页面布局的调整，第二测试变量——权重因子的调整，假设本次测试关注的参考指标为着陆页(landing page)转化率，且基准版本的相关数据如下：基准版本的平均用户访问量为30000，基准版本的landing page转化率为2％，针对第一测试变量，预期测试版本与基本版本相比，landing page转化率提高40％，针对第一测试变量，预期测试版本与基本版本相比，landing page转化率提高20％，并确定在本次测试中，将各分配20％的用户至各测试版本，即针对第一测试变量对应的测试版本分配30000*20％＝6000的用户，针对第二测试变量对应的测试版本分配30000*20％＝6000的用户，以下针对每一测试变量，确定其对应的测试版本需要的时间。

一、页面布局的调整

通过比较基准版本与测试版本，可以看出主要有4个差异性变量。由上述公式计算测试时间为： $n=16*{\left(\frac{\sqrt{0.02*0.98}}{0.02*0.4}\right)}^2*4/30000*0.2=3.27,$ 为了确保能够该测试变量能够得到充分测试，可以按照4天的测试时间进行测试。

二、权重因子的调整

由于匹配策略中共有两个权重因子进行了调整，因此，测试版本与基准版本相比，存在两个差异性变量，这样，由上述公式计算需要的测试时间为：

$n=16*{\left(\frac{\sqrt{0.02*0.98}}{0.02*0.2}\right)}^2*2/30000*0.2=0.41,$ 同样，为了保证各测试变量能够得到充分测试，可以按照0.5天的测试时间实施测试。

后续只需根据确定出的测试时间对测试版本进行测试即可，因此，网页产品多版本测试方法，还可以包括以下步骤：

S103、在确定出的测试时间内，接收各访问用户提交的访问请求；

S104、根据预设的用户分流规则，将各访问用户分配至对应的版本测试桶中；

S105、针对任一测试版本，分别记录各访问用户的操作信息，并进行统计分析得到测试结果。

具体实现多版本测试时，可以有不同的实现方式，考虑到Web环境的特殊性以及用户体验等，不能每次都采用新的分流规则使所有用户重新分配，因此，本申请实施例中，采用数理统计中随机抽样简阳的理论采用分桶方式来实现多版本测试。任一访问用户在首次访问时，按照预设的分流规则将该访问用户分配至某一版本测试桶中，并向用户返回为其分配的版本测试桶的桶标识，当用户后续再次访问时，需要首先判断该用户是否携带有桶标识，若无，则重新进行分配，否则直接将该访问用户定位分配至对应的版本测试桶内。由于在访问用户首次进行访问时，按照预设的分流规则将用户分配至某一版本测试桶内，当用户基数足够大时，根据概率论中的0-1分布是可以满足预期用户构成的。如图3所示，为用户分配版本测试桶的逻辑结构示意图。

对于不同网页产品，可以选择不同的分流规则将访问用户进行分流。分流规则实际上是一种分配算法，如随机分配、轮询分配，按照Cookie分配或者按照IP_hash分配等等。

基于上述的原理，本申请实施例提出了一种分桶方式的通用多版本测试框架，其结构分别如图4a和图4b所示，其中：

图4a为只涉及一个测试变量的多版本测试的测试框架，图4b为涉及多个测试变量的多版本测试的测试框架，例如，某次测试中，需要对页面布局进行了调整后对应的测试版本，以及对排序算法进行了调整对应的测试版本同时进行测试，此时，便涉及两个测试变量：页面布局和排序算法。对于只涉及一个测试变量的多版本测试，只包括一个测试组，该测试组中可以包括测试桶1、测试桶2......；对于涉及多个测试变量的多版本测试，包括多个测试组，每个测试组可以包括测试桶1、测试桶2......，当用户请求访问时，将首先将该用户分配到一个测试组，然后再根据分流规则将用户分配至某一测试桶中，每个测试桶中有需要动态替换的变量，如涉及页面布局的调整时，该动态替换的变量可以为前端页面区块，而涉及排序算法调整时，该动态替换的变量可以为后端排序算法调用的地址。

由于对于电子商务网站来说，其具有其独特的信息发布、索引、排序及处理流程，网站访问用户根据关键词查找自己感兴趣的信息，网站内部的信息搜索、筛选、排序和展现对用户是完全透明的。为了能够让用户在尽可能短的时间内查找到满足其需求的信息，网站需要经常性地对网页产品在索引、排序等算法及页面结构等方面进行升级。在网页产品升级的过程中，可能会涉及多个方面的调整，按照现有的多版本测试实现方案，由于测试变量过多，差异过大，即使采用多版本测试也无法获知各个测试变量对测试结果的影响，而且当前的大部分网页产品采用模型-视图-控制器(MVC，Model-View-Controller)分层模式来设计，现有技术中，基于这种分层结构的多版本测试，上层的分流结果影响到下层的用户基数，使得下层的用户基数值不断变小而导致的测试结果不准确。本申请实施例中，基于分桶式的多版本测试框架，每个测试组可以对应到各层涉及的测试变量，例如，页面元素、结构的调整，排序算法的调整以及中间业务逻辑层的变化等。这样，将分层式设计的网页产品进行了扁平化处理，对于网页产品升级过程中，各层涉及的测试变量在水平结构上进行隔离，使其相互之间不会影响，可以较为客观的评估各层的测试变量的调整对测试结果的影响，从而有效解决了现有技术中存在的上述问题。

实施例二

实施例二在实施例一的基础上，增加了选择器参数配置步骤，通过对选择器参数进行配置，可以根据实际需要来确定不同的分流规则，以更好地满足实际测试需求，使得测试结果更加准确。

具体的，选择器参数可以包括但不限于为访问用户的IP(互联网协议)地址、Cookie，也可以为网络侧设置的白名单以及自定义参数等。

其中，当选择器参数为访问用户的IP时，其对应的分流规则可以为：根据访问用户的IP地址，确定所述IP地址对应的哈希值；并确定指定区间范围内的哈希值对应同一版本测试桶。在接收到用户的访问请求之后，根据访问请求中携带的IP地址，利用哈希函数确定该IP地址对应的哈希值，具体实施时，可以指定某一区间范围内的哈希值对应相同的版本测试桶，并据此完成对用户的分流；当选择器参数为访问用户的Cookie时，其对应的分流规则可以为：确定指定区间范围内的Cookie对应同一版本测试桶，并据此完成对访问用户的分流。

具体实施时，也可以采用自定义的方式确定选择器参数，例如，可以提取Cookie、Session(会话)或者Request(请求)中包含的一些用户特征信息作为选择器参数，相应地，根据提取的用户特征信息确定分流规则。以Request中携带的关键词信息为例，其对应的分流规则可以为：将查询同一关键词信息的用户分配至同一版本测试桶中。

较佳地，为了达到对选择器参数的可视化配置，选择器的重用以及选择器参数修改后的实时生效，无需每次修改选择器参数重新进行发布，本申请实施例中，通过管理端工具来完成选择器参数的配置，具体的处理流程如下：

步骤1、创建一个新的测试时，可以动态的配置测试生效时间、选择器参数、测试组以及每个测试组中包含的不同测试版本，如图5所示，为配置页面的效果示意图；

步骤2、对外提供网页产品测试配置变更的服务，同时提供根据网页产品名称获取对应的配置参数信息的服务；

步骤3、当有新的测试创建或者修改时，会将配置参数的变更信息存储在本地，在开始测试之前，会首先查询配置参数是否有更新，若有，则会请求配置参数的数据信息；若无，则不访问配置参数的数据信息，这样，能够有效避免每次都获取配置参数的数据信息造成的资源浪费。

实施例三

为了更好地理解本申请实施例，以下结合本申请实施例的应用场景对本申请实施例的实施方式进行说明。

对于网页产品的升级，不论是页面布局或页面元素的变化，后台算法逻辑的调整、还是流程的增减，必定都有对外展现的应用层，从而，测试方案的制定也是基于该层进行设计的。如图6所示，采用本申请实施例提供的网页产品多版本测试方法进行测试的流程如下：

S601、接收用户的访问请求；

其中，用户提交的访问请求中可以携带相关用户信息，例如，用户的IP地址、Cookie等。

S602、提取访问请求中携带的用户信息，并存储在本次访问的本地线程中；

S603、获取网页产品的名称对应的选择器参数；

具体的，根据需要升级的网页产品的名称，从管理工具端获取配置的选择器参数。

S604、根据获取的选择器参数确定对应的分流规则；

S605、根据确定出的分流规则，将请求访问的用户分配至对应的版本测试桶中；

以选择器参数为IP地址为例，首先需要计算该IP地址对应的哈希值，以及确定该哈希值所属的区间范围，将该用户分配至该区间范围内的哈希值对应的版本测试桶中，并从版本测试桶中获取到需要的动态变量，利用这些动态变量对基准版本中相对应的内容进行替换，完成本次测试。

S606、记录各访问用户的操作信息，进行统计分析得到测试结果。

实施例四

多版本测试的最终目的是选择一个更符合用户体验的版本进行全量发布。但是，对于任一版本的网页产品单纯的从参考指标的变化来评价该版本的优良，其结果是片面的，且是不准确的，为了比较测试版本与基准版本的差异，本申请实施例中采用数理统计中假设检验的卡方分布来综合评判测试版本是否比基准版本有明显的改进。当然，应当考虑噪音数据对统计结果的影响，本申请实施例中采用置信度α＝0.05的常态分布，即当卡方值的结果概率值大于95％时，说明测试结果是可信的，测试版本相比于基准版本是有明显改进，即测试版本优于基准版本。具体实施时，对于置信度的设置不做限定，可以根据实际需要确定置信度。

基于上述分析，步骤S105可以包括：

步骤1、分别统计该测试版本的实际用户访问量以及参考指标对应的实际指标值；

具体的，在接收到用户的访问请求之后，会根据一定的分流规则将该用户分配至某一版本测试桶中，每一版本测试桶对应一个版本信息，在向用户返回响应信息时，将该版本信息设置到响应头中，并回传至用户访问的页面，用以跟踪用户后期的操作并记录，以便后续根据用户的操作信息进行统计分析等。

步骤2、根据测试版本的实际用户访问量和参考指标对应的实际指标值，以及基准版本的平均用户访问量和基准版本中、参考指标对应的指标值，采用卡方公式确定本论测试基准版本与测试版本对应的卡方值；

具体的，采用的卡方公式如下： ${\mathrm{\χ}}^2=\mathrm{\Σ}\frac{{(f_0-f_e)}^2}{f_e}=\mathrm{\Σ}\frac{{(f_{\mathrm{xy}}-f_x{f}_y/N)}^2}{f_x{f}_y/N}=N|\underset{x=1}{\overset{R}{\mathrm{\Σ}}}\underset{y=1}{\overset{C}{\mathrm{\Σ}}}\frac{{f_{\mathrm{xy}}}^2}{f_x{f}_y}-1|,$ 其中：χ²表示该测试版本与基准版本计算的卡方值；f₀测试版本实际测试中得到数据值；f_e表示根据卡方式计算得到的实际值；N表示基准版本和测试版本的实际用户访问量之和；R表示测试版本的个数；C表示测试版本与基准版本需要比较的数据维度；f_xy表示针对每一个测试版本统计到的实际数据；f_x和f_y分别表示将各测试版本中，同一维度的数据之和。

自由度df的计算公式为：df＝(R-1)*(C-1)，其中：R表示测试版本的个数；C表示测试版本与基准版本需要比较的数据维度。

步骤3、当确定出的卡方值超过预设阈值时，确定测试版本优于基准版本。

为了更好地理解测试结果评估的过程，以下仍然以图2a和图2b所示的两种类型的广告样式为例进行说明，测试版本相对于基准版本来说，对页面布局进行了调整，同时，后端算法对于广告的匹配策略有了一定的调整，修改了两个权重因子，也需要在本次测试中进行测试。由上述描述可知，本申请实施例中，包含两个测试变量，分别为：第一测试变量——页面布局的调整，第二测试变量——权重因子的调整，假设本次测试关注的参考指标为着陆页(landingpage)转化率，且基准版本的相关数据如下：基准版本的平均用户访问量为30000，基准版本的landing page转化率为2％，以下针对每一测试变量，分别对该测试变量对应的测试版本进行评估。

一、页面布局的调整

假设实施测试之后，实际测试收集到的数据为：实际用户访问量为：7349，真正到landing page的用户为224，则可以得到实际转化率为224/7349*100％＝3.04％，相比于基准版本的转化率(2％)有一定程度的提升，但只能说明在一定范围内测试版本比基准版本要好，但是两个版本之间是否有明显差异，需要进一步根据测试版本的卡方值来确定。

由上述描述可知，本次评估涉及的数据维度为二维，即C＝2，包括测试版本和基准版本的数据，每个版本中由包含访问用户中成功转化的用户和未成功转化的用户数量，其中，基准版本中，成功转化的用户数量为：30000*2％＝600，未成功转化的用户数量为：30000-600＝29400；测试版本中，成功转化的用户数量为：7349*3.04％＝224，未成功转化的用户数量为：7349-224＝7125，具体可以用以下的矩阵表示： $\begin{array}{cc}29400& 600\\ 7125& 224\end{array},$ 为了便于描述，以f_xy表示矩阵中的每个元素，其中x表示行号，y表示列号，由于只包含基准版本和一个测试版本，因此，R＝2，则根据卡方公式计算卡方值为：

${\mathrm{\χ}}^2=N|\underset{x=1}{\overset{2}{\mathrm{\Σ}}}\underset{y=1}{\overset{2}{\mathrm{\Σ}}}\frac{{f_{\mathrm{xy}}}^2}{f_x{f}_y}-1|=N*|\frac{{f_{x_1{y}_1}}^2}{f_{x_1}*f_{y_1}}+\frac{{f_{x_1{y}_2}}^2}{f_{x_1}*f_{y_2}}+\frac{{f_{x_2{y}_1}}^2}{f_{x_2}*f_{y_1}}+\frac{f_{x_2{y}_2}}{f_{x_2}*f_{y_2}}-1|$

$=(30000+7349)*|\frac{{29400}^2}{(29400+600)*(29400+7125)}+\frac{{600}^2}{(29400+600)*(600+224)}$

$+\frac{{7125}^2}{(7125+224)*(29400+7125)}+\frac{{224}^2}{(7125+224)*(600+224)}-1|=30.051$

当自由度df＝(R-1)*(C-1)＝(2-1)*(2-1)＝1时，根据卡方表可知，

由此可知，置信度高于99％，说明测试版本与基准版本有明显差异。

二、权重因子调整

假设实施测试之后，实际测试收集到的数据为：实际用户访问量：2487，真正到landing page的用户为57，则可以得到实际转化率为57/2487*100％＝2.29％，相比于基准版本的转化率(2％)也有一定程度的提升，以下根据测试版本的卡方值确定，测试版本是否比基准版本有明显差异。

由上述描述可知，本次评估涉及的数据维度为二维，即C＝2，包括测试版本和基准版本的数据，每个版本中由包含访问用户中成功转化的用户和未成功转化的用户数量，其中，基准版本中，成功转化的用户数量为：30000*2％＝600，未成功转化的用户数量为：30000-600＝29400；测试版本中，成功转化的用户数量为：2487*2.29％＝57，未成功转化的用户数量为：2487-57＝2430，具体可以用以下的矩阵表示： $\begin{array}{cc}29400& 600\\ 2430& 57\end{array},$ 同样，为了便于描述，以f_xy表示矩阵中的每个元素，其中x表示行号，y表示列号，由于只包含基准版本和一个测试版本，因此，R＝2，则根据卡方公式计算卡方值为：

${\mathrm{\χ}}^2=N|\underset{x=1}{\overset{2}{\mathrm{\Σ}}}\underset{y=1}{\overset{2}{\mathrm{\Σ}}}\frac{{f_{\mathrm{xy}}}^2}{f_x{f}_y}-1|=N*|\frac{{f_{x_1{y}_1}}^2}{f_{x_1}*f_{y_1}}+\frac{{f_{x_1{y}_2}}^2}{f_{x_1}*f_{y_2}}+\frac{{f_{x_2{y}_1}}^2}{f_{x_2}*f_{y_1}}+\frac{f_{x_2{y}_2}}{f_{x_2}*f_{y_2}}-1|$

$=(30000+2487)*|\frac{29400^2}{(29400+600)*(29400+2430)}+\frac{{600}^2}{(29400+600)*(600+57)}$

$+\frac{{2430}^2}{(2430+57)*(29400+2430)}+\frac{{224}^2}{(2430+57)*(600+57)}-1|=0.9877$

当自由度df＝(R-1)*(C-1)＝(2-1)*(2-1)＝1时，根据卡方表可知，

由此可知，置信度小于80％，说明测试版本与基准版本无明显差异。

进一步地，根据测试版本的评估结果，可以对选择器参数进行调整，例如调整分配给测试版本的用户比例，继续进行测试，并继续对测试结果进行评估，从而，实现在测试时间内，不断地循环实施测试，能够逐渐对网页产品进行改进，并达到预期效果。

本申请实施例提供的网页产品多版本测试方法，可以采用Java语言完成，并可以应用于不同的业务场景中，测试时间以及测试版本相比于基准版本是否有明显差异的评估方法，可以采用任何语言实现，由于涉及的计算量不大，对软、硬件没有特殊要求。

基于同一发明构思，本申请实施例中还提供了一种网页产品多版本测试装置，由于该装置解决问题的原理与网页产品多版本测试方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

如图7所示，为本申请实施例中，网页产品多版本测试装置的结构示意图，包括：

获取单元701，用于针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

第一确定单元702，用于根据获取单元获取的期望值，分别确定各测试版本需要的测试时间；

接收单元703，用于在第一确定单元702确定出的测试时间内，接收各访问用户提交的访问请求；

分配单元704，用于按照预设的用户分流规则，将各访问用户分配至对应的版本测试桶中；

统计分析单元705，用于针对任一测试版本，并进行统计分析分别记录各访问用户的操作，得到测试结果。

其中，第一确定单元702，可以用于按照以下公式确定任一测试版本需要的测试时间：

其中：n表示该测试版本需要的测试时间；cov表示基准版本中，任一参考指标对应的指标值；r表示基准版本与测试版本之间的差异性变量的数目；Δ表示预期该测试版本与基准版本相比变化的期望值；s表示基准版本的平均用户访问量；tra表示欲分配给测试版本的用户比例。

具体实施时，网页产品所版本测试方法，还可以包括：

第三确定单元，用于若需要同时对多个测试变量对应的测试版本进行测试时，在根据所述用户分流规则，将各访问用户分配至对应的版本测试桶中之前，确定各访问用户对应的测试组，测试组与测试变量一一对应，每个测试组包含多个版本测试桶。

具体实施时，网页产品所版本测试方法，还可以包括：

第二确定单元，用于根据预先配置的选择器参数，确定该选择器参数对应的用户分流规则。

具体实施时，选择器参数可以但不限于包括访问用户的IP地址和访问用户的Cookie，当选择器参数为访问用户的IP地址时，第二确定单元，具体用于根据访问用户的IP地址，确定该IP地址对应的哈希值；并确定指定区间范围内的哈希值对应同一版本测试桶；当选择器参数为访问用户的Cookie时，第二确定单元，具体用于确定指定区间范围内的Cookie对应同一版本测试桶。

具体实施时，统计分析单元705，可以包括：

记录子单元，用于针对任一测试版本，分别记录各用户的操作信息；

统计子单元，用于根据记录子单元记录的操作信息，分别统计该测试版本的实际用户访问量以及参考指标对应的实际指标值；

第一确定子单元，用于根据测试版本的实际用户访问量和参考指标对应的实际指标值，以及基准版本的平均用户访问量和基准版本中、参考指标对应的指标值，按照卡方公式确定该轮测试基准版本与测试版本对应的卡方值；

第二确定子单元，用于在所述卡方值超过预设阈值时，确定测试版本优于基准版本。

本申请实施例提供的网页产品多版本测试方法及装置，首先获取预期某一参考指标达到的期望值，进而根据该参考指标的期望值来计算需要的测试时间，这样，在实施测试时，可以在计算出的测试时间内，按照预设的分流规则，将用户提交的访问请求分配至不同的版本测试桶中进行测试，由于测试时间的计算无需依赖人的经验，从而能够有效避免人为因素及经验不足而导致的测试不充分，提高了测试效率以及测试结果的准确性。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

1.一种网页产品多版本测试方法，其特征在于，包括：

针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

根据所述期望值，分别确定各测试版本需要的测试时间；

在所述测试时间内，接收各访问用户提交的访问请求；并

按照预设的用户分流规则，将各访问用户分配至对应的版本测试桶中；以及

针对任一测试版本，分别记录各访问用户的操作信息，并进行统计分析得到测试结果。

2.如权利要求1所述的方法，其特征在于，根据所述期望值，分别确定各测试版本需要的测试时间，具体包括：

针对任一测试版本，按照以下公式确定该测试版本需要的测试时间：

$n=\frac{16*{\mathrm{\δ}}^2}{{\mathrm{\Δ}}^2}*r/s*\mathrm{tra},$ 其中：

n表示该测试版本需要的测试时间；

cov表示基准版本中，任一参考指标对应的指标值；

r表示基准版本与测试版本之间的差异性变量的数目；

Δ表示预期该测试版本与基准版本相比变化的期望值；

s表示基准版本的平均用户访问量；

tra表示欲分配给测试版本的用户比例。

3.如权利要求1所述的方法，其特征在于，若需要同时对多个测试变量对应的测试版本进行测试时，在根据所述用户分流规则，将各访问用户分配至对应的版本测试桶中之前，还包括：

确定各访问用户对应的测试组，所述测试组与测试变量一一对应，每个测试组包含多个版本测试桶。

4.如权利要求1所述的方法，其特征在于，按照以下方法确定用户分流规则：

根据预先配置的选择器参数，确定该选择器参数对应的用户分流规则。

5.如权利要求4所述的方法，其特征在于，所述选择器参数包括访问用户的互联网协议IP地址；以及

确定所述选择器参数对应的用户分流规则，具体包括：

根据访问用户的IP地址，确定所述IP地址对应的哈希值；并

确定指定区间范围内的哈希值对应同一版本测试桶。

6.如权利要求4所述的方法，其特征在于，所述选择器参数包括访问用户的Cookie；以及

确定所述选择器参数对应的用户分流规则，具体包括：

确定指定区间范围内的Cookie对应同一版本测试桶。

7.如权利要求1所述的方法，其特征在于，进行统计分析得到测试结果，具体包括：

分别统计该测试版本的实际用户访问量以及参考指标对应的实际指标值；

根据测试版本的实际用户访问量和参考指标对应的实际指标值，以及基准版本的平均用户访问量和基准版本中、参考指标对应的指标值，采用卡方公式确定本论测试基准版本与测试版本对应的卡方值；

在所述卡方值超过预设阈值时，确定所述测试版本优于所述基准版本。

8.一种网页产品多版本测试装置，其特征在于，包括：

获取单元，用于针对任一参考指标，获取预期各测试版本中、该参考指标的指标值与基准版本相比变化的期望值；

第一确定单元，用于根据所述期望值，分别确定各测试版本需要的测试时间；

接收单元，用于在在所述第一确定单元确定出的测试时间内，接收各访问用户提交的访问请求；

分配单元，用于按照预设的用户分流规则，将各访问用户分配至对应的版本测试桶中；

统计分析单元，用于针对任一测试版本，分别记录各访问用户的操作，并进行统计分析得到测试结果。

9.如权利要求8所述的装置，其特征在于，

所述第一确定单元，具体用于按照以下公式确定任一测试版本需要的测试时间： $n=\frac{16*{\mathrm{\δ}}^2}{{\mathrm{\Δ}}^2}*r/s*\mathrm{tra},$ 其中：

n表示该测试版本需要的测试时间；

cov表示基准版本中，任一参考指标对应的指标值；

r表示基准版本与测试版本之间的差异性变量的数目；

Δ表示预期该测试版本与基准版本相比变化的期望值；

s表示基准版本的平均用户访问量；

tra表示欲分配给测试版本的用户比例。

10.如权利要求8所述的装置，其特征在于，还包括：

第三确定单元，用于若需要同时对多个测试变量对应的测试版本进行测试时，在根据所述用户分流规则，将各访问用户分配至对应的版本测试桶中之前，确定各访问用户对应的测试组，所述测试组与测试变量一一对应，每个测试组包含多个版本测试桶。

11.如权利要求8所述的装置，其特征在于，还包括：

第二确定单元，用于根据预先配置的选择器参数，确定该选择器参数对应的用户分流规则。

12.如权利要求11所述的装置，其特征在于，所述选择器参数包括访问用户的互联网协议IP地址；以及

所述第二确定单元，具体用于根据访问用户的IP地址，确定所述IP地址对应的哈希值；并确定指定区间范围内的哈希值对应同一版本测试桶。

13.如权利要求11所述的装置，其特征在于，所述选择器参数包括访问用户的Cookie；以及

所述第二确定单元，具体用于确定指定区间范围内的Cookie对应同一版本测试桶。

14.如权利要求8所述的装置，其特征在于，所述统计分析单元，包括：

记录子单元，用于针对任一测试版本，分别记录各用户的操作信息；

统计子单元，用于根据记录子单元记录的操作信息，分别统计该测试版本的实际用户访问量以及参考指标对应的实际指标值；

第一确定子单元，用于根据测试版本的实际用户访问量和参考指标对应的实际指标值，以及基准版本的平均用户访问量和基准版本中、参考指标对应的指标值，按照卡方公式确定该轮测试基准版本与测试版本对应的卡方值；

第二确定子单元，用于在所述卡方值超过预设阈值时，确定所述测试版本优于所述基准版本。

Images