技术干货 | AB测试和灰度发布探索及实践

原文链接： https://segmentfault.com/a/1190000012377139

传统测试方式和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进行处理再对上层的业务逻辑进行生效。

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日志进行上报，策略配置进行整合。