传统测试方式和 ABTest 的区别究竟在哪里？如果一个产品功能有两个解决方案，两个方案孰优孰劣我们不清楚，那该怎么办呢？来自新浪新闻客户端的测试专家韩明豹通过传统测试方式与 ABTest 的对比分析为你进行解答！

1、AB Test Framework 产生的背景

新浪新闻客户端视频联播页面现存两种界面，第一种是依次往下联播，另一种则是以列表的形式展示未来播放的视频。

以上两种联播界面哪个是最好的，我们不知道。首先没有数据帮助我们进行分析，其次没有实践以及用户来论证，所以需要向用户拿数据。我们应该怎样获取用户数据呢？在不伤害用户的前提下，在小范围影响下，利用一个渠道将部分功能投向用户，然后获取统计数据，进行相关调研，再决定哪个方案更优。
普通的实现方法：第一个是分渠道包，第二个是做出服务器可配置的功能，将一部分用户灰度打开。经过客户端来判断，把代码写在客户端里面，根据时间、机型等条件部分开启灰度功能。
但是这些方法都具有弊端，第一不够灵活，技术实现复杂度比较高，成本也比较高；我们一旦将这个功能抛向市场有些是不可控，发布之后出现问题是不可能立刻将它下线的，风险比较大；再一个实验的周期比较长，至少需要一个版本才能拿到有益的数据；
基于这些问题提出了解决方案：
第一个是缩短试错周期。每个功能如果都需要两个版本反复测试，效率会很低。
第二个是减少用户的伤害。因为一旦伤害了用户，会造成用户对应用的卸载。
第三个是降低制作成本。降低开发成本，减少不必要的人力投入。
需要数据反应速度快，然后保证 APP 正常功能的稳定性。

2、AB Test 系统架构

AB Test 系统架构主要分为以下几个方面：第一个策略的制定者即 AB Test 策略服务器，还有运行到我们客户端里面的 AB Test SDK，它是管理整个策略对上层业务升调机制的，再有我们的数据统计机制，我们采用的是现在比较成熟的 sima 日志系统。主要的流程就是我们的 AB Test SDK 通过携带一些机型、坐标及其他类参数上报给我们的 AB Test 测试服务器，然后由 AB Test 测试服务器经过运算对指定用户产生一个指定策略，然后下发给 AB Test SDK，SDK 经过处理加工之后会对上层业务提供策略，上层业务根据策略执行相关的逻辑代码之后，会产生一些行为日志，通过 sima 来上报，我们会通过 sima 后台导出数据。通过数据分析得出一些结论，如果需要其它的尝试，我们可以重新配置我们的服务器，进行下一轮的灰度测试。

3、AB Test 决策流程

AB Test 决策的一般流程，首先从一个功能提出，一般会预想两个方案，经过 AB Test 系统决策，对小规模的用户进行分统，确定出哪个方案应用到哪些用户上。AB Test 系统经过一系列的比对，综合这些后台配置信息，还有各种策略的维度，计算出对应策略，下发给 SDK，SDK 会通过会控制一些上层业务逻辑的执行逻辑代码统计数据，根据统计数据的收集系统初步得出结论。灰度可能在很短的时间就可以得出结论了，把这个结论直接反馈到 AB 系统里，然后通过后台的配置直接将全部用户切到我们已经论证过的方案上。如果对样本不太满意，可以通过动态改变后台的配置，重新分统并且重新进行第二轮的灰度实验。

4、AB Test 策略维度

AB Test 目前已可以对包括新闻信息、地理坐标、版本信息、发布渠道、城市、网络类型等进行判断，更多的维度正在持续扩充中。

5、AB Test 生效机制

AB Test 有一个生效机制，可以根据策略服务器下发的生效机制对某些策略进行生效。一般分为立即生效，在拿到服务器下发的策略后，会将策略立即生效，并通知相关策略的使用者，立即生效主要用于用户不会及时感知的行为。
还有热启生效以及冷启生效。热启生效就是退出界面，重新进入生效（可用于调整界面，但需使用者注意业务逻辑，防止出现异常），冷启生效就是杀死进程之后，重新进入生效（用于调整界面，风险低）。两个启动之间区别不是很大，热启会比冷启实时一些；冷启会比热启更加安全一些，可以防止一些代码初始化造成异常。

6、AB Test SDK 技术实现

AB Test SDK 的实现几乎不占用系统什么资源，主要包括 ABTestCore，主要功能是完成策略缓存、策略读取、会根据上层对接口的实现来判断策略的有效性，再执行上层已经注册过来的对应策略的代码块；再上层是一个 ABTestManager，主要用来拉取策略，上报各个维度信息，做一些策略缓存，根据不同时机进行立即、热启、冷启生效，在某些时机对策略进行生效。
再往上一层是 AB Test SDK 要用到的一些泛型 Bean，还有 APP 使用者要用到的接口（Interface），这些接口是 ABTestCore 来使用的，主要作用是根据上层判断逻辑来判断对应策略的有效性。

7、AB Test 后台

AB Test 后台服务器根据后台配置以及维度匹配生成对应的策略。后台配置是后台管理人员来干预的；维度匹配，当一个策略提出的时候，会明确出覆盖到哪些人，这些都会经过后台配置，包括它的范围、时间以及生效方式。当客户端带着我们的维度信息上报的时候，经过运算对相应的客户端产生相应的策略，然后策略下发到 AB Test SDK，AB Test SDK 进行处理再对上层的业务逻辑进行生效。
a-5855-4b71-987f-9d33d5b84e95.jpg! large)

8、数据统计（sima）

日志上报并不复杂，AB Test SDK 在获取策略时会上报灰度信息到日志服务器，AB Test 在执行灰度功能的时候也会进行上报，这两者的上报会汇总到 sima，通过 sima 数据的比对分析可以大致判断每个功能的使用情况。

9、案例分析

在新浪新闻客户端现有两个刷新功能，一个是正在上线的下拉刷新功能，还有一个是正在灰度中的刷新功能，还没有完全放开，影响范围比较小。
另一个是明日头条功能，这功能陆陆续续已经做了有 100 个左右，包括那些已经确定和正在线上进行灰度实验的功能。
AB Test 与传统方式相比，测试、定型周期只需一个版本，比传统测试方式相比至少需要少一个版本测试；AB Test 对用户的影响比较小，可以随时下线，而传统的测试方式一旦上线，将会持续一个版本； AB Test 实现起来相对简化，而传统方式需要专人跟踪，实现起来比较复杂；传统方式的统计数据需要经过一个版本才会有意义，AB Test 可以进行实时更改；
传统方式不支持个性化定制，一个 APP 对应一个用户展现不同的组合，在传统方式里无法实现的， AB 测试支持个性化定制。

10、AB Test 未来规划

1、加入智能的数据的算法，以及多维度的分析；
2、加入多策略分析，进行大数据的挖掘，分析各个策略之间的相互影响。
3、加入推送生效机制，通过 AB Test SDK 进行策略获取，实效比较低，加入推送策略机制，会推送给相关用户，实现立即生效。
4、完善 AB Test 平台机制，将 sima 日志进行上报，策略配置进行整合。