CN104348679B - 一种分桶测试的方法、装置和系统 - Google Patents

Abstract

本申请提供了一种分桶测试的方法、装置和系统。该方法包括步骤：根据接收到的每个用户的搜索请求分析每个用户的应用维度；基于预先设置的分桶逻辑，并根据每个用户的应用维度，为每个用户的搜索请求分配一个或多个测试号，其中，每一个测试号与预设测试层中的多个功能测试中的一个功能测试相匹配，每个功能测试用于测试由搜索请求得到的搜索结果页中的一个功能；基于一个或多个测试号所匹配的一个或多个功能测试，对搜索结果页中相应的一个或多个功能并行地执行测试。根据本申请，可以通过多个测试层并行测试逻辑正交的功能，并在每个测试层中进行更细粒度的功能测试，提高了测试数据的针对性和准确性。

Description

一种分桶测试的方法、装置和系统

技术领域

本申请涉及测试领域，尤其涉及一种分桶测试的方法、装置和系统。

背景技术

互联网搜索产品可以根据用户需求的变化而不断的改进和优化，如，搜索结果页（Search Result Page，简称Srp），其中某个按钮是放在页面左边还是右边，都面临着多个设计方案的选择。设计方案的优劣可以借助分桶测试（Bucket Testing，简称bts）的方法来收集用户的真实使用数据加以衡量，进而择优选择设计方案。

所述分桶测试是指，根据分桶逻辑对用户进行的功能测试。所述分桶逻辑是一种访问量分配的方法，分桶就是划分访问量、即按某种方式来分配访问量。其中，A/B测试（A/BTesting）是分桶测试的最简单形式，即设定一个或多个基准桶，基准桶用于测试现有的功能，其作为比较改进后的功能的测试效果的基准，再设定一个或多个测试桶，测试桶用于测试改进后的功能，通过考察基准桶与测试桶之间在测试获得的各项指标上的差异，最终确定测试桶的效果，如是否优于基准桶等等。其中，每一个桶（基准桶、测试桶）具有一个分组号（bucket id）。

结合图1所示的现有技术的分桶测试系统架构示意图来说明分桶测试。

用户的搜索请求首先被发送到web应用服务器。web应用服务器接收到用户的搜索请求后，根据该搜索请求为用户随机分配一个分组号，用户可以根据获得的分组号访问web应用服务器。进一步地，将具有同一个分组号的多个用户的网站访问量称之为一个桶，web应用服务器可以向在同一个桶内的用户提供具有某一功能的服务。也即是说，一个桶可以用于测试web应用服务器提供的一个功能。基于用户的搜索请求和分组号，分别请求相关的引擎服务器，如，导航引擎服务器，搜索引擎服务器等，以得到相关的页面资源数据。Web应用服务器将各相关引擎服务器返回的页面资源返回给用户，从而可以得到包含需要测试的功能的搜索结果页（Search Result Page，简称Srp）。用户在搜索结果页里可以进行进一步地操作，例如：点击导航细化搜索条件。用户的操作（用户行为）可以以日志的方式记录下来。基于日志生成与分组号对应的测试数据（指标）。将同一功能在测试桶的测试数据和在基准桶的测试数据进行比较。其中，测试桶对应改进后的功能，基准桶对应现有的功能（即已经存在的原有功能、而非改进后的功能）。进而可以得到用户对现有功能和改进后的功能的使用感受，进而比较出现有产品功能和改进后产品功能的优劣，并以此确定是否全量上线测试桶对应的优化或改进的产品功能。

在现有技术中，桶的数量决定了可以测试的功能的数量，当需要测试的功能增多时，可以在一个桶中测试多个功能，即，为多个功能测试分配一个分组号，并将多个功能展示在一个srp页面中，但是，多个功能公用一个分组号进行测试，可能造成多个功能的测试数据融合在一起，相互干扰，不易区分用户行为数据归属于哪一个功能，不利于在相同的功能之间进行分析和比较，影响测试数据的准确性。

在现有的分桶逻辑是将用户随机分布在各个桶中，无法针对特定用户群体、特定地域用户的相关功能的进行测试，测试数据缺乏针对性，例如，无法针对男用户进行运动种类排序的功能测试。

现有技术对被测功能采用先确定测试时间、再上线测试的方法，并且需要进行上线操作，容易导致上线时刻不准确，例如，上线操作时间过长使上线时刻滞后，然而测试数据是参考预先确定的测试时间而生成，从而造成测试数据不准确的问题。

根据现有技术的分桶测试方法，若在功能测试过程中发现某个测试的功能出现错误，则只能回滚同一批上线的多个功能测试，或者重新对需要测试的功能进行开发、测试，这样影响其他功能测试的正常进行并且不容易评估在重新开发、测试的过程中该存在问题的功能对其他功能的影响，存在稳定性风险。并且，测试数据与分组号绑定，存在问题的功能再次上线时，需要重新分配分组号，若与之前的分组号不相同，则会造成测试数据分散，不利于数据分析和比较。

发明内容

本申请的主要目的在于提供一种分桶测试的方法、装置和系统，以克服现有技术存在的上述缺陷，解决多个功能并行测试，以支持更多功能测试，提高了分桶测试效率的问题，进一步，还可以解决有针对性更细粒度的测试的问题，进一步，还可以解决提高功测试数据准确性的问题进而提高评估的精确度，进一步，还可以解决安全便捷、低成本的线上功能测试的问题。

为了解决上述技术问题，本发明的目的是通过以下技术方案实现的：

本申请提供了一种分桶测试的方法，包括以下步骤：根据接收到的每个用户的搜索请求分析所述每个用户的应用维度；基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为所述每个用户的搜索请求分配一个或多个测试号，其中，每一个测试号与预设测试层中的多个功能测试中的一个功能测试相匹配，每个功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能；基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试。

优选地，在根据本申请所述的方法中，所述分桶逻辑包括应用维度访问量分配逻辑。

优选地，在根据本申请所述的方法中，所述基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为所述每个用户的搜索请求分配一个或多个测试号的步骤，包括：将所述用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配，其中，所述应用维度至少包括以下内容：用户属性维度，搜索词维度，访问量来源维度；基于与所述用户的应用维度相匹配的功能测试的应用维度，为所述用户的搜索请求分配与所述功能测试对应的测试号。

优选地，根据本申请所述的方法，可以包括：预设一个或多个所述测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶，其中，所述一个或多个桶对应一个或多个功能测试；限制一个所述搜索请求在一个所述测试层中分配一个功能测试，其中，为一个搜索请求分配的功能测试数量小于或等于所述测试层的数量。

优选地，在根据本申请所述的方法中，所述为所述每个用户的搜索请求分配一个或多个测试号的步骤，包括：预先调度每一个所述测试层中的一个或多个功能测试的测试时间；为所述每个用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

本申请还提供了一种分桶测试的装置，包括：分析模块，用于根据接收到的每个用户的搜索请求分析所述每个用户的应用维度；分配模块，用于基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为每个用户的搜索请求分配一个或多个测试号，其中，每一个测试号与预设测试层中的多个功能测试中的一个功能测试相匹配，每个功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能；测试模块，用于基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试。

优选地，在根据本申请所述的装置中，所述分桶逻辑包括应用维度访问量分配逻辑。

优选地，在根据本申请所述的装置中，所述分配模块还包括：匹配单元：用于将所述用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配，其中所述应用维度至少包括以下内容：用户属性维度，搜索词维度，访问量来源维度；分配单元：用于基于与所述用户的应用维度相匹配的功能测试的应用维度，为所述用户的搜索请求分配与所述功能测试对应的测试号。

优选地，在根据本申请所述的装置中，还可以包括：预设模块：用于预设一个或多个所述测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶，其中，所述一个或多个桶对应一个或多个功能测试；限制模块：用于限制一个所述搜索请求在一个所述测试层中分配一个功能测试，其中，为一个搜索请求分配的功能测试数量小于或等于所述测试层的数量。

优选地，在根据本申请所述的装置中，所述分配模块还包括：调度单元：用于预先调度每一个所述测试层中的一个或多个功能测试的测试时间；进一步地，所述分配单元还被配置成：为所述每个用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

本申请还提供了一种分桶测试的系统，包括：bts管理服务器、web应用服务器、bts访问量分配装置，其中：所述bts管理服务器用于预先配置测试层、桶，设置分桶逻辑，设置并调度一个或多个功能测试；所述web应用服务器连接所述bts访问量分配装置，以接收来自用户的搜索请求，并对搜索请求进行分析，获得所述用户的应用维度；所述bts访问量分配装置，根据由所述web应用服务器分析得到的所述用户的应用维度，基于bts管理服务器设置的所述分桶逻辑，为所述搜索请求分配一个或多个测试号；所述web应用服务器基于与所述一个或多个测试号相匹配的一个或多个功能测试，收集每个功能测试对应的用户行为数据，以并行地执行功能测试。

优选地，在根据本申请所述的系统中，所述bts访问量分配装置分配的一个或多个测试号中的每一个测试号与在所述bts管理服务器中预设的一测试层中的多个功能测试的其中一个功能测试相匹配，其中，每个所述功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能。

优选地，在根据本申请所述的系统中，所述bts管理服务器单独控制一个或多个功能测试中每一个功能测试的上线与下线。

与现有技术相比，根据本申请的技术方案存在以下有益效果：

本申请可以预设多个测试层，并在该多个测试层中测试逻辑正交的多个功能，进而可以实现对一个用户并行地测试多个测试层中的多个功能测试；进一步地，每一个测试层还可以划分为多个桶，其中，在一个桶中可以进行多个功能测试，也可以在多个桶中进行一个功能测试，从而，可以在每个测试层中进行更细粒度的功能测试，提高了测试的准确性和测试的效率。

本申请可以采用多维度分桶的分桶逻辑，使功能测试在特定条件下进行，提高了测试数据的针对性和准确性。

本申请统一管理并单独控制各个功能测试，并且采用功能测试先上线再测试的方法，由系统自动启动功能测试，提高了测试数据的准确性，并且降低了人工成本。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是现有技术的分桶测试系统架构示意图；

图2是根据本申请实施例的分桶测试的系统架构示意图；

图3是根据本申请实施例的分桶测试的方法的总体流程图；

图4是根据本申请实施例的分桶测试的系统预设步骤的流程图；

图5是根据本申请实施例的分桶测试的测试层和桶的配置示意图；

图6是根据本申请实施例的分桶测试的方法的详细流程图；以及

图7是根据本申请实施例的分桶测试的装置的结构图。

具体实施方式

本申请将访问量（用户的搜索请求等对网站产生的访问流量）划分为一个或多个分层，每一个分层作为一个测试层，并且多个测试层之间可以测试逻辑正交的不同的功能，用以并行地进行功能测试，进一步地，每一个测试层还可以划分多个桶，用以进行更细粒度的多个功能测试，并且桶与功能测试之间不存在严格的一对一关系，即，根据本申请提供的分桶逻辑，一个桶可以做一个功能测试，也可以做多个功能测试，一个功能测试也可以通过多个桶来进行。

本申请所述分桶测试是根据分桶逻辑，针对每一个用户访问并行地进行的一个或多个功能测试。一个功能测试可以测试一个功能，并且每一个功能测试具有一个测试号。基于单维度分桶逻辑和多维度分桶逻辑，可以为一个来自用户的搜索请求分配一个或多个测试号，也即是说，根据搜索请求所具备的条件可以在多个测试层中的每一个测试层中选择并进行一个功能测试。这样，在用户浏览过程中，可以同时执行多个功能测试，并基于每一个功能测试的测试号生成对应的测试数据。

从而，本申请通过以上方法提高了分桶测试的测试效率，并且提高了测试数据的针对性和准确性。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步地详细说明。

本申请提供了一种分桶测试的系统，如图2所示是根据本申请实施例的分桶测试的系统架构示意图。

在该系统中，可以包含bts管理服务器、web应用服务器、相关引擎服务器等，以及与web应用服务器相连接的bts访问量分配装置。

Bts管理服务器可以收集功能测试需求，包括但不限于，需要测试的功能、该功能针对的用户范围等。例如，需要对搜索结果的排序功能进行功能测试，并且该功能针对特定类型（如某地域、某性别）的用户进行测试。可以根据收集的功能测试需求或根据页面中涉及的功能预先配置测试层、桶，设置分桶逻辑，设置并调度功能测试。

可以预先对访问量层级数量进行设置，得到一个或多个测试层，并且每一个测试层具有相同的访问量阈值。其中，一个或多个测试层，是指以分层方式来将逻辑正交的多个功能进行区分，用于分别测试逻辑正交的多个功能，从而可以进行多个功能的并行测试。

具体而言，系统还可以具有一个可调的访问量阈值，即，当系统访问量增加时，该访问量阈值可以适当增加。

bts管理服务器还可以对测试层进行进一步地划分，如，划分为多个桶。其中，该多个桶中可以包括一个或多个基准桶和一个或多个测试桶。优选地，每个桶能分配的访问量最大值基本相同。

进一步地，可以为每一个需要测试的功能分配/设置一个测试号，该测试号用于对应一个功能测试，并可以根据分桶逻辑确定该功能测试可以在某一个或多个桶中进行。

该bts管理服务器可以在访问量和功能测试设置完成后，上线该功能测试，并可以设置测试时间，在测试时间开始的时间点自动或人工启动功能测试。

另外，bts管理服务器还可以预先设置每一个测试层的分桶逻辑，该分桶逻辑可以是访问量的分配方式，如，将多个用户的多个页面访问平均分给多个桶，以进行功能测试。

用户可以通过客户端进行数据搜索，如，关键字搜索，在进行数据搜索时，需要向web应用服务器发送搜索请求。web应用服务器接收来自用户的搜索请求，其中，该搜索请求中可以包括与用户相关的cookie、用户身份信息、用户搜索信息（如，关键字）等等。Web应用服务器可以根据搜索请求分析出该用户的应用维度，如，该用户的性别、IP地址、所属的地域等信息。

进一步地，由于用户的访问量较大，可以由独立的数据分析服务器分析用户的应用维度，以减轻web应用服务器的运算量，或者可以将分析用户的应用维度这一任务分配给bts访问量分配装置或是其他独立的分析装置来完成，以明确web应用服务器各个装置之间的任务分工。

Web应用服务器中可以连接一bts访问量分配装置，如，可以将bts访问量分配装置内置于web应用服务器中。该bts访问量分配装置可以根据用户的搜索请求和分析出的用户的应用维度，基于bts管理服务器设置的分桶逻辑，为该搜索请求分配一个或多个测试号，也即是说，发出该搜索请求的用户可以基于不同测试号进行不同的功能测试，进一步地，所述bts访问量分配装置分配的一个或多个测试号中的每一个测试号与在所述bts管理服务器中预设的一测试层中的多个功能测试的其中一个功能测试相匹配，其中，每个所述功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能。

Web应用服务器基于该搜索请求和该搜索请求的测试号在相关引擎服务器（如，导航引擎服务器、搜索引擎服务器等）中请求与该搜索请求相关的页面资源，并将获得的页面资源返回客户端进行展示。

当bts访问量分配装置内置于web应用服务器时，web应用服务器可以连接bts管理服务器，可以根据所述设置的功能测试（测试号）收集所述功能测试的用户行为数据，以并行地执行功能测试。在用户浏览该页面时，所产生的用户行为数据，例如：鼠标事件、页面停留时间等，可以由web应用服务器负责记录在日志中，在该日志中可以包含该搜索请求对应的测试号。可以在预定时刻或在功能测试结束的时刻将记录的日志发送给一特定服务器（图中未示出），如，日志处理服务器，该特定服务器收集web服务器发送的日志，并基于日志中包含的测试号生成与测试号对应的测试数据，这样可以保证每一个测试数据对应一个功能测试，通过分析基准桶的测试数据（对应原有功能）与测试桶的测试数据（对应改进后的功能）孰优孰劣，并可以形成报告。

本申请可以智能管理一个或多个上线的功能测试，并可以单独控制一个或多个功能测试中每一个功能测试的上线与下线，例如，在测试过程中发现某个功能测试的功能出现问题，可以单独关闭该功能测试，对其他功能测试不产生影响。例如在bts管理服务器中展示一个可以控制各个功能测试的界面，当发现其中一个功能测试出现问题时，则直接关闭该功能测试。

需要说明的是，bts访问量分配装置可以作为一个独立的服务器，也可以作为一个内置或外置的功能模块（装置）与其他服务器配合使用。随着功能测试内容的增加，应用维度的内容也会随之增加，进而分析应用维度所使用的信息也会越来越多，出于对web应用服务器的工作效率的考量，将bts访问量分配装置作为一个独立服务器可以增加整个系统的工作效率。并且，根据系统的数据处理能力的需要，可以在系统中设置一个或多个web应用服务器，以增加系统的数据处理能里。

基于本申请的数据搜索分桶测试的系统架构，本申请提供了一种分桶测试的方法。

如图3所示为根据本申请实施例的分桶测试的方法的总体流程图，对本申请所述的分桶测试的方法进行详细说明。

在步骤S301处，收集功能测试需求。

可以通过分析海量用户的用户行为数据和/或分析特定范围内多个用户的用户行为数据，获得用户对页面功能提出的新的需求，进而可以对页面中的功能实施改进，如，增加新功能、优化原有功能等，以增强用户的使用效果。数据搜索的功能可以包括与用户界面（User Interface，UI）、导航、搜索结果排序等相关的功能，所述一个或多个改进功能可以采用功能测试的方式进行测试，然后决定是否全量上线以供用户使用，也即是说，可以划分出部分访问量给改进的功能，由部分用户试用改进的功能，以获得真实的用户使用效果，根据使用效果优胜劣汰改进的功能。

在步骤S302处，基于收集的功能测试需求，对系统进行预先设置。

本申请可以进行更细粒度的功能测试，具体而言，可以区分用户的应用维度，在用户属性、搜索词、访问量来源地域等更为深入的范围内进行功能测试。例如，针对男性用户的功能可以使用来源于男性用户的访问数据进行功能测试；针对特定地域的用户的功能可以使用来源于特定地域的用户访问数据进行功能测试。从而提高了测试数据针对性。对功能的改进更具指导意义。

本申请针对一次搜索请求可以同时进行多个功能测试，即，同时测试多个功能。具体而言，本申请可以划分多个测试层，不同测试层可以进行不同的功能测试，用户的一个搜索请求可以在每个测试层中做功能测试，即一个搜索请求可以分配在不同测试层中用于不同的功能测试。例如，预设3个测试层，第一测试层用于测试UI的功能，第二测试层用于测试导航的功能，第三测试层用于测试搜索结果排序的功能，即可以同时进行3个功能测试（并行的功能测试），即，UI功能、导航功能、和搜索结果排序功能等功能的功能测试。

可以基于收集的功能测试需求，对系统进行设置，以实现更细粒度、更多功能的功能测试。如图4所示，图4所示为根据本申请实施例的分桶测试的系统预设步骤的流程图。

在步骤S401处，预先配置测试层数量以及配置每一个测试层的分桶数量。

可以直接预设一个或多个测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶。其中，所述一个或多个桶对应一个或多个功能测试，比如：一个桶可以对应一个或多个功能测试，一个功能测试也可以对应到一个或多个桶中。

具体而言，可以配置一个或多个测试层，用于测试逻辑正交的多个功能。其中逻辑正交可以理解为多个被测功能之间互不干扰，没有交集。例如，在搜索结果页中可以包括多个功能模块，可以完成不同的任务，该多个功能模块之间即为逻辑正交，如，与搜索结果排序相关的功能和导航相关的功能，该两个功能涉及不同方面，功能之间相互没有影响。

在一个实施例中，本申请可以根据页面中现有的正交的功能进行测试层的设置，例如，页面中涉及UI功能、搜索结果排序功能、导航功能这三个正交的功能，则可以设置三个测试层。设置多个测试层可以实现并行地测试多个功能，例如在一个页面中同时进行多个功能的测试。

为了考察每一个功能的功能测试效果，可以基于A/B测试的方法，在每一个测试层中设置多个桶。在本申请中桶是一种划分访问量的方式。在进行用户访问的分桶时，最好保证每一个桶中有足够的访问量进行功能测试。每一个桶与待测试的功能本身可以不存在一一对应关系，所以，在本申请中，一个桶可以进行一个或多个功能测试，一个功能测试也可以在一个或多个桶中进行。在该多个桶中可以设置一个或多个基准桶和一个或多个测试桶，其中，基准桶进行原有功能的功能测试，测试桶进行改进功能的功能测试，进而可以将基准桶的功能测试效果与测试桶的功能测试效果进行比较，从而得知改进的功能是否优于原有功能。

例如，预先设置A方案和B方案，A方案和B方案分别提供不同的页面功能。不同用户在一次浏览过程中，系统为部分用户提供A方案的功能，为另外一部分用户提供B方案的功能。即可以将用户的访问流量分为基准桶和测试桶。在基准桶中向用户提供A方案的功能，在测试桶中向用户提供B方案的功能。记录不同用户在A方案或B方案中发生的用户行为，进而可以通过分析用户行为获得测试数据，如，点击率（Click Through Rate，简称CTR），从而可以通过比较用户在A方案中的点击率和用户在B方案中的点击率，得到用户更偏爱A方案或B方案中的哪一个，如用户在A方案中的点击率高于B方案，则用户更偏爱使用A方案。

如图5所示为根据本申请实施例的分桶测试的测试层和桶的配置示意图。

预设两个测试层（A层、B层），在A层中包括A1、A2、A3、A4这4个桶；在B层中包括B1、B2、B3这3个桶。通过在每一层中设置基准桶和测试桶，可以用于对比、分析基准桶和测试桶中用户行为数据的差别，进而获得在基准桶中提供的功能与在测试桶中提供的功能的优劣比较结果。

例如：在A层中包括的4个桶各占总访问量的1/4，可以根据收集的测试需求预设A1、A3、A4为基准桶，A2为测试桶。A1、A3、A4中用户对页面的点击率为60%，A2中用户对页面的点击率为90%，那么对于A层总的访问量而言，平均每一访问达成的效果提升率为7.5%（（90%-60%）×1/4=7.5%）。在B层中的3个桶各占总访问量的1/3，当该3个桶未作功能测试时，即每一个桶对应的点击率为67.5%（（60%×3+90%）×1/4=67.5%）。换言之，在A层和B层进行测试的用户的访问量相同，并且同一页面中的多个功能测试共同对页面使用效果产生作用，所以A2所提升的效果也使B层中每一个桶的效果得到了增加。

在B层每一个桶的点击率为67.5%的基础上，设置B1、B3为基准桶，设置B2为测试桶，在B2中对应新的待测试功能，若B2中用户对页面的点击率70%，则可以与基准桶B1相比，B2的效果提升了2.5%（70%-67.5%=2.5%）。

在访问量阈值足够大的情况下，可以不限制各测试层中桶的数量，但要确保桶的访问量足够大，用以减少访问量的波动带来的影响。例如，设置基准桶和测试桶的访问量都是10个，则会因为访问量太小，用户在页面中的操作的不稳定性会给测试数据带来较大的影响，如，基准桶的访问量为10个都进行操作C，测试桶的访问量也是10个都不进行操作C，则测试数据的参考性将会降低；若将基准桶和测试桶的访问量都调到1000，则用户操作的不确定性带来的影响将被减小或忽略。

在步骤S402处，预先设置每一个测试层的分桶逻辑。

具体而言，每一个测试层可以有各自独立的分桶逻辑，所述分桶逻辑是一种访问量的分配方式，可以包括单维度分桶逻辑和多维度分桶逻辑。其中，所述维度可以是应用维度，如，与用户或功能相关的条件等。进一步地，单维度分桶逻辑可以利用一个特定条件或随机的方式将访问量分配到某个桶中，如，按照特定算法将用户的cookie映射为某个随机数，将该随机数与桶的数量取模得到用户本次访问对应的桶号。多维度分桶方式，如，应用维度访问量分配逻辑，可以利用与具体应用（功能）相关的多个应用维度（条件）来进行访问量分配。

应用维度（condition）可以包括用户属性维度，搜索词维度，访问量来源维度等等。

以商品搜索为例：

用户属性维度可以包括：男用户、女用户、高消费能力用户、中消费能力用户、低消费能力用户等。

搜索词维度可以包括：类目词、商品词、品牌词等。

访问量来源维度可以包括：北方用户、南方用户等。

具体而言，可以根据用户需求确定需要进行的功能测试并分配给该功能测试一个唯一的测试号，进一步地，该功能测试还可以被描述为一个三元组的形式，包括：测试层、桶数量、功能测试应用维度，例如，一个功能测试可以描述为在A测试层的3个桶中对特定地域的用户进行测试。所以，可以通过搜索请求分析出一个用户拥有的应用维度，并通过该应用维度访问量分配逻辑将该用户的应用维度与需要测试的功能的功能测试应用维度进行匹配，并为该用户分配与该用户应用维度相匹配的功能测试应用维度对应的测试号。

利用应用维度分配访问量的方式有助于个性化搜索和垂直化搜索。具体而言，所述个性化搜索，例如搜索结果可以针对不同用户属性维度进行展示，例如，为男用户展示男士用品，为女用户展示女士用品等等；所述垂直化搜索，例如搜索结果可以根据领域的不同展示不同的内容，例如，与美术相关的搜索结果以图片的形式进行展示。按照应用维度将用户划分为不同的分类，根据用户所属的分类进行相应的功能测试更有针对性，产生的测试数据的参考价值更高，例如，针对南方用户的功能只由南方用户进行测试，避免与测试内容无关的用户（如，北方用户）对测试数据造成的干扰。

在收集功能测试需求时，也可以按照应用维度来收集，以明确功能测试的测试范围，如功能测试需求可以包括：需要测试的功能、需要测试的应用维度、需要的桶数（访问量的大小）等等。

在步骤S403处，基于已经确定的需要测试的一个或多个功能，为该一个或多个功能中的每一个功能分配对应的测试号。

具体而言，系统可以为用于测试一个功能的功能测试分配一个唯一的测试号。通过测试号控制/引导该功能的测试，运行该测试号对应的代码、配置文件等。

在步骤S404处，上线所述一个或多个功能的功能测试，并确定功能测试的测试时间。

预先调度每一个所述测试层中的一个或多个功能测试的测试时间。

具体而言，功能测试可以在系统中先进行上线，再在系统中申请测试时间，由系统调度/安排需要测试的一个或多个功能测试，最终确定并设置可以进行功能测试的测试时间，例如可以在bts管理服务器中申请并设置测试时间。

所述系统调度/安排需要测试的一个或多个功能测试，即调度一个或多个功能测试的测试顺序和测试位置，以防止相同或相似的功能测试之间产生冲突。

具体的调度过程，例如：假设与排序相关的功能在C层进行功能测试，C层被划分为3个桶，设置1号桶为基准桶，2号桶和3号桶为测试桶。1-3号桶的现有使用情况为：2号桶进行2个功能测试，其中一个功能测试针对男用户的功能，持续到2天后；另一个功能测试是针对女用户的功能，今天结束。3号桶进行3个功能测试，其中，对东北三省用户进行一个功能测试，持续到明天；对江浙沪用户进行一个功能测试，今天结束；对新疆，西藏，内蒙古，甘肃的用户进行一个功能测试，持续到10天之后。本次需要测试的两个功能，分别为第一功能（C层，1个桶，男用户）、第二功能（C层，1个桶，安徽&河南用户），系统判断第一功能可以在C层、2号桶、3天后开始进行，第二功能可以在C层3号桶明天开始进行。

系统在已经确定的测试时间的起始测试时刻开始功能测试，并在测试时间的终止测试时刻结束功能测试，确保能够收集完整的数据。

在步骤S405处，基于每一个功能测试的测试时间，生成bts访问量分配描述文件。

Bts访问量分配描述文件可以包括需要进行功能测试的测试层、桶的数量、功能测试应用维度（三元组），可以在进行功能测试之前产生该文件。

系统可以加载与应用维度访问量分配逻辑信息相关的信息，例如，加载一个地域划分表，在该表中划分出属于北方用户的IP地址，属于南方用户的IP等，进而可以基于bts访问量分配描述文件，在大量用户中匹配出符合功能测试要求的用户。

在步骤S303处，基于对系统的预先设置，对一个或多个功能进行功能测试。

具体而言，可以在功能测试上线后进行功能测试，即可以为该功能测试分配访问量，以获得测试数据，通过真实的用户访问量来评估被测试功能的效果。

如图6所示为根据本申请实施例的分桶测试的方法的详细流程图。

以下步骤通过对测试桶的功能测试来说明本申请所述的分桶测试的方法。

在步骤S601处，接收来自每个用户的搜索请求，例如由Web应用服务器接收该搜索请求。

其中，在每个搜索请求可以包括用户的cookie、用户的身份信息、用户搜索的关键字（搜索词）等等信息。

在步骤S602处，依据每个用户的搜索请求，分析每个用户的应用维度，其中该应用维度可以包括用户属性维度，搜索词维度，访问量来源维度等，例如：用户的IP地址、用户所属的地域、用户的职业、用户的浏览偏好等等。

具体而言，Web应用服务器可以根据该搜索请求中包含的内容分析出用户的性别、用户的IP地址、用户的历史行为等等；根据用户的IP地址，进而通过预设的IP位置对照表查询到用户所属的地域位置，如，用户属于广东用户；根据系统中记录的该用户的历史行为记录，可以获得该用户的浏览偏好，如，偏好浏览历史相关页面或偏好浏览购物网站等等。换言之，根据接收到的每个用户的搜索请求分析所述每个用户的应用维度。

在步骤S603处，基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为所述每个用户的搜索请求分配一个或多个测试号。

其中，所述一个或多个测试号中的每一个测试号与一预设测试层中多个功能测试的其中一个功能测试相匹配，每个所述功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能。换言之，每个用户的搜索请求可以在多个测试层中的每一个测试层中分配一个功能测试，也即是说，每个用户访问在一个测试层中测试一个功能测试，那么，受测试层数量的限制，每个用户的搜索请求可以分配的功能测试数量应当小于或等于测试层的数量。

Web应用服务器将每个用户的搜索请求和应用维度发送至bts访问量分配装置，基于步骤S602分析出的该搜索请求的应用维度，bts访问量分配装置，根据预先设置的应用维度访问量分配逻辑确定该搜索请求可以进行哪些功能测试，并根据预先为功能测试分配的测试号为该搜索请求分配对应该功能测试的测试号。换言之，将所述每个用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配；基于与所述用户的应用维度相匹配的功能测试的应用维度（bts访问量分配描述文件中记录的功能测试应用维度），为所述用户的搜索请求分配与所述功能测试对应的测试号。

此外，应保证为用户分配的测试号是处于上线状态的功能测试的测试号。即，为所述用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

为搜索请求分配测试号，代表将该用户的本次访问分配至某测试层的某个桶的某个功能测试下，以进行该功能测试。

具体而言，在为每个用户的搜索请求分配测试号时，可以根据每个用户的cookie和应用维度为每个用户的搜索请求分配一个或多个测试号。

可以根据用户的cookie，按照特定算法进行运算，得到一个随机数，根据该随机数，将该用户的本次访问分配至对应的桶中，例如：在某测试层中存在10个桶并进行编号1-10，特定算法为将cookie值与桶的数量取模，结果模值对应具有相同值的桶号，如，用户的cookie=12345678，将cookie值与桶的数量10取模，结果为8，则该用户被分配至编号为8的桶中进行功能测试。

可以预设一个非测试桶，如0号桶，将没有cookie数据的用户分配给该桶，以避免该用户的应用维度与功能测试不符，而产生的干扰。

进一步地，还可以根据应用维度对功能测试进行更深入的测试，即根据应用维度将用户的访问分配到更具体的功能测试中，在系统中预设应用维度访问量分配逻辑信息，根据用户的应用维度可以确定该用户的具体可以参与那个功能测试。例如，根据该用户的IP地址可以分析出该用户的应用维度为东北三省地区，在第8号桶中包含一个针对东北三省的用户的功能测试bts1，和一个针对广东省的用户的功能测试bts2，则可以对该用户的访问进行bts1。

单维度分桶逻辑和多维度分桶逻辑可以单独使用，也可以同时使用。

在一个实施例中，同一用户的一次浏览行为可以在相同的一个或多个功能测试下进行，换言之，被测的一个或多个功能测试展示在一个方案中，并保持在一次浏览中方案的一致性，以确保用户在该页面中发生的用户行为都是针对同一方案进行，保证数据的完整性。所以，为了避免同一用户在一次浏览中所使用的方案不统一，例如，一srp包含bts1、bts2，但刷新srp后，该srp变为包含bts1、bts3，系统可以根据稳定的cookie决定为用户展示哪个方案，从而保持在一次浏览中为用户始终展示同一方案，从而避免了方案不统一带来的测试结果不准确的问题。

Bts访问量分配装置将为该搜索请求的测试号返回web应用服务器。

在步骤S604处，基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试。

Web应用服务器携带测试号、搜索请求向相关引擎服务器请求页面资源，例如，向导航引擎服务器、搜索引擎服务器等发送页面资源请求。在各相关服务器中可以预设配置文件，用于获取与该测试号对应的页面资源，确保该测试号对应的搜索请求（访问量）可以访问到被测功能。

将获得的页面资源返回给用户（客户端），并通过UI设计处理整个页面，用户可以在该页面中执行页面操作。

根据所述分配的一个或多个测试号，对所述用户并行地测试一个或多个功能。

在步骤S605处，记录所述每个用户针对每一个功能测试的用户行为数据，并生成每个功能测试对应的测试数据。

功能的改进效果需要数据进行支持，即用户认可的功能才可以被认作成功的功能改进，用户是否认可可以通过用户行为数据来体现，该用户行为数据可以是点击率（ClickThrough Rate，CTR），点击率是指网站页面上某一内容被点击的次数与被显示次数之比，例如，用户在srp页面中点击搜索结果的比率，该比率越高，说明该搜索结果越受用户关注，也就是用户的使用效果越好。

将用户行为数据记录在日志中，并将该日志与该功能测试的测试号进行关联，例如，将该测试号记录在日志中。

在预定时刻将记录的日志发送给日志处理服务器，该日志处理服务器可以根据日志生成测试数据，由于日志与测试号存在关联关系，所以该测试数据可以作为该测试号对应的功能测试所产生的测试数据。

在步骤S606处，将所述测试数据，与预设的基准桶获得的测试数据进行对比，以确定所述测试数据是否优于基准桶的测试数据。例如，在测试桶的功能的点击率为90%，而基准桶该功能的点击率仅为10%，则说明测试桶的功能优于基准桶的功能，可以将测试桶的功能全量上线，以供用户使用。

本申请还提供了一种分桶测试的装置，如图7所示为根据本申请实施例的分桶测试的装置的结构图。

在根据本申请所述的装置中，包括分析模块701、分配模块702、测试模块703。

其中，分析模块701可以用于根据接收到的每个用户的搜索请求分析所述每个用户的应用维度。

分配模块702可以用于基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为每个用户的搜索请求分配一个或多个测试号，其中，所述一个或多个测试号中的每一个测试号与一预设测试层中的多个功能测试中的一个功能测试相匹配，每个所述功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能。

其中，所述分桶逻辑包括应用维度访问量分配逻辑。

所述分配模块702还可以包括匹配单元7021、分配单元7022，调度单元7023。

所述匹配单元7021可以将所述用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配，其中所述应用维度至少包括以下内容：用户属性维度，搜索词维度，访问量来源维度。

所述分配单元7022可以基于与所述用户的应用维度相匹配的功能测试的应用维度，为所述用户的搜索请求分配与所述功能测试对应的测试号。

所述调度单元7023可以预先调度每一个所述测试层中的一个或多个功能测试的测试时间；进一步地，所述分配单元7022为所述每个用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

本发明所述的装置还可以包括预设模块704和限制模块705，所述预设模块704可以预设一个或多个所述测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶，其中，所述一个或多个桶对应一个或多个功能测试。

所述限制模块705可以限制一个所述搜索请求在一个所述测试层中分配一个功能测试，其中，为一个搜索请求分配的功能测试数量小于或等于所述测试层的数量。

测试模块703可以用于基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试。

在本申请所述的装置中，还可以包括一个用于记录用户行为数据的记录模块706，该记录模块706可以根据测试号的不同，记录下每一个测试号相关的用户行为数据，并以日志的形式进行存储。

另外，本申请所述的装置还可以包括一个发送模块707，该发送模块707可以设置一个特定时刻，在该特定时刻将记录模块707所存储的日志发送到已特定服务器，如日志处理服务器，有该服务器将所述日志生产测试数据，该测试数据对应测试号，以便明确该测试数据是归属于那一个功能的功能测试。

将同一功能的基准桶测试数据和测试桶的测试数据进行比较即可得知那一个功能更优越，更受用户的偏爱。

本申请通过预设多个测试层，进而可以实现每个用户在多个的测试层中并行的测试多个功能测试；进一步地，每一个测试层还可以划分为多个桶，其中，在一个桶中可以进行多个功能测试，也可以在多个桶中进行一个功能测试，从而，可以在每个测试层中进行更细粒度的功能测试，提高了测试的准确性和测试的效率。

本申请可以采用多维度分桶的方式，使功能测试在特定条件下进行，提高了测试数据的针对性和准确性。

本申请统一管理各个功能测试，并单独控制各个功能测试，并且采用功能测试先上线再测试的方法，由系统自动开始功能测试，提高了测试数据的准确性，并且降低了人工成本。

本说明书中的各个实施例一般采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块或单元。一般地，程序模块或单元可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。一般来说，程序模块或单元可以由软件、硬件或两者的结合来实现。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块或单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

最后，还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其主要思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

Claims (13)

1.一种分桶测试的方法，其特征在于，包括：

根据接收到的每个用户的搜索请求分析所述每个用户的应用维度；

基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为所述每个用户的搜索请求分配一个或多个测试号，其中，每一个测试号与预设测试层中的多个功能测试中的一个功能测试相匹配，每个功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能；

基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试；

其中，所述应用维度至少包括与用户属性、搜索词和访问量来源相关的维度。

2.根据权利要求1所述的方法，其特征在于，所述分桶逻辑包括应用维度访问量分配逻辑。

3.根据权利要求2所述的方法，其特征在于，所述基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为所述每个用户的搜索请求分配一个或多个测试号的步骤，包括：

将所述用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配；

基于与所述用户的应用维度相匹配的功能测试的应用维度，为所述用户的搜索请求分配与所述功能测试对应的测试号。

4.根据权利要求1所述的方法，其特征在于，包括：

预设一个或多个所述测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶，其中，所述一个或多个桶对应一个或多个功能测试；

限制一个所述搜索请求在一个所述测试层中分配一个功能测试，其中，为一个搜索请求分配的功能测试数量小于或等于所述测试层的数量。

5.根据权利要求1所述的方法，其特征在于，所述为所述每个用户的搜索请求分配一个或多个测试号的步骤，包括：

预先调度每一个所述测试层中的一个或多个功能测试的测试时间；

为所述每个用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

6.一种分桶测试的装置，其特征在于，包括：

分析模块，用于根据接收到的每个用户的搜索请求分析所述每个用户的应用维度；

分配模块，用于基于预先设置的分桶逻辑，并根据所述每个用户的应用维度，为每个用户的搜索请求分配一个或多个测试号，其中，每一个测试号与预设测试层中的多个功能测试中的一个功能测试相匹配，每个功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能；

测试模块，用于基于所述一个或多个测试号所匹配的一个或多个功能测试，对所述搜索结果页中相应的一个或多个功能并行地执行测试；

其中，所述应用维度至少包括与用户属性、搜索词和访问量来源相关的维度。

7.根据权利要求6所述的装置，其特征在于：所述分桶逻辑包括应用维度访问量分配逻辑。

8.根据权利要求7所述的装置，其特征在于，所述分配模块还包括：

匹配单元：用于将所述用户的应用维度与预置的一个或多个功能测试的应用维度进行匹配；

分配单元：用于基于与所述用户的应用维度相匹配的功能测试的应用维度，为所述用户的搜索请求分配与所述功能测试对应的测试号。

9.根据权利要求6所述的装置，其特征在于，还包括：

预设模块：用于预设一个或多个所述测试层，并在所述一个或多个测试层中的每一个测试层中划分一个或多个桶，其中，所述一个或多个桶对应一个或多个功能测试；

限制模块：用于限制一个所述搜索请求在一个所述测试层中分配一个功能测试，其中，为一个搜索请求分配的功能测试数量小于或等于所述测试层的数量。

10.根据权利要求6所述的装置，其特征在于，所述分配模块还包括：

调度单元：用于预先调度每一个所述测试层中的一个或多个功能测试的测试时间；进一步地，

所述分配单元还被配置成：为所述每个用户的搜索请求分配处于测试时间内的一个或多个功能测试对应的一个或多个测试号。

11.一种分桶测试的系统，其特征在于，包括：bts管理服务器、web应用服务器、bts访问量分配装置，其中：

所述bts管理服务器用于预先配置测试层、桶，设置分桶逻辑，设置并调度一个或多个功能测试；

所述web应用服务器连接所述bts访问量分配装置，以接收来自用户的搜索请求，并对搜索请求进行分析，获得所述用户的应用维度；

所述bts访问量分配装置，根据由所述web应用服务器分析得到的所述用户的应用维度，基于bts管理服务器设置的所述分桶逻辑，为所述搜索请求分配一个或多个测试号；

所述web应用服务器基于与所述一个或多个测试号相匹配的一个或多个功能测试，收集每个功能测试对应的用户行为数据，以并行地执行功能测试；

其中，所述应用维度至少包括与用户属性、搜索词和访问量来源相关的维度。

12.根据权利要求11所述的系统，其特征在于，所述bts访问量分配装置分配的一个或多个测试号中的每一个测试号与在所述bts管理服务器中预设的一测试层中的多个功能测试的其中一个功能测试相匹配，其中，每个所述功能测试用于测试由所述搜索请求得到的搜索结果页中的一个功能。

13.根据权利要求11所述的系统，其特征在于，所述bts管理服务器单独控制一个或多个功能测试中每一个功能测试的上线与下线。