嘉宾介绍
高嘉峻，天猫无线技术专家，苹果核博主。曾参与过口碑网，蘑菇街，SegmentFault多款App的架构和开发工作。
在一篇文章《天猫App的动态化配置中心实践》（文末阅读原文查看）中我们聊了关于Native App动态化的问题。无疑Native的动态化能力较Web要弱很多，很多操作是依赖版本节奏的。这就导致在Native App上许多决策无法快速验证，对存在不足的逻辑没办法快速修正。受到这些条件的限制，那个唯快不破的铁律在Native App上遭遇到了尴尬。每一个产品决策会变得异常谨慎，因为一个错误的决策要持续整个版本周期可能被修复。慢慢的我们就会发现，不出错会成为做出决策的重要因素，而有意义却退居二线。
所以具备快速验证和及时修正这两个能力就显得非常重要，打造这样的能力需要一个完整的解决方案。我们认为，这个方案是一个以A/B测试为核心，结合周边多个系统能力，共同组成的一个试错平台。在这个平台上，我们的团队，不管是业务方还是工程师，都可以快速应变，不畏惧出错，变得灵动起来。
A/B测试
说到A/B测试，这到底是个什么东西？我个人的理解是：狭隘的说，A/B测试是以分桶为核心，以依据分桶结果执行不同逻辑为基本原理，以获取最优解为目的一种测试方案。
一般认为，A/B测试的主要场景有两种：对比实验和灰度发布。
对比实验
所谓对比实验，就是同一时间执行两套甚至多套方案，通过对比反馈数据，对这些方案作出评价。
灰度发布
灰度发布则是，某个新功能或版本正式发布前，先圈一部分人作为小白鼠，试用这个功能或版本。我们从稳定性，业务效果等多方面观察这部分试用者的反应，对这个新功能或版本作出评价。
不管是对比实验还是灰度发布，最终目的都是期望只是发布带来的效果最大化。
体系
一个单一的A/B测试框架并不能帮助我们达成目的，还需要诸多周边能力辅助。要实现丰富的分桶条件，需要设备和用户的信息收集机制；要实现线上逻辑实时调整，要Native逻辑动态化方案；要实现动态调整分桶逻辑，需要分桶条件下发系统；实现观察对比实验结果，需要数据收集和分析平台，等等。
在天猫，我们整合各方能力搭建了一个称为AirTrack的试错平台。在AirTrack平台上动态实验条件，实时运算SDK和数据收集和反馈平台三部分是重中之重。
动态实验条件
在传统的Web A/B测试中，实验条件的计算和分桶逻辑执行都在后端完成，具有非常好的动态性，可以随时发布随时生效。在Mobile场景下，很多时候我们惯性的延续这种思路，把这些逻辑放在后端，通过API吐出不同的数据来控制App端的不同形态。这种方式固然有很好的动态性，但一个致命问题在于，这样的设计依赖数据API，只能用于数据层面的实验。
我们认为数据API在Mobile场景中仅仅占一小部分，而我们要建设的是一个代码级别的A/B测试框架，必然不能依赖数据API，而是要具备在端上完成此前后端承担的全部工作。具体的说，就是我们需要在App端实时运算实验条件和执行分桶逻辑。所有的逻辑都在App端，那么动态化的问题怎么解决？幸好我们具有成熟的基础设施建设，可以通过配置中心实现实验条件动态化。
我们把实验条件的数据结构设计为一棵树。根节点是运算起点，非叶子节点是一个逻辑表达式，叶子节点都是实验条件运算的结果。
通过一段JSON描述这棵实验条件树，再利用配置中心的动态能力把数据动态下发到端，从而实现了实验条件动态化。
实时运算SDK
App端的业务代码调用AirTrack SDK，初始化一个AirTrack实例，指定该实例需要进行的实验名称，把需要加入实验的若干逻辑注册到这个实例中。AirTrack实例在执行阶段，根据实验名称，通过配置中心获取实验条件，从条件树的根节点开始计算，最终找到一个叶子节点，通过叶子节点中携带的信息定位到需要执行的实验逻辑，并执行该逻辑。从而完成整个实验过程。
在条件树的Demo中我们可以看到非叶子节点有两种类型
带属性的运算
哈希运算
带属性的运算，利用了天猫状态中心的数据能力，通过条件节点中指定的状态名称获取状态中心中的当前属性值，与给定值进行运算符指定的运算，当运算结果为真，则落入左子树，假，落入右子树。
哈希运算，则是使用设备ID，条件名称和当前节点深度三个因素组合成一个因子，并对该因子进行0-10,000的哈希，通过哈希结果可知当前设备落入那一段区间内。根据给定的子节点和比例关系决定落入哪一棵子树。
数据收集和反馈平台
在天猫App中有一套成熟的数据采集SDK，数据以界面为线索被收集并同步到后端。我们对这个收集SDK进行一些改造，在AirTrack SDK中自动调用数据采集接口，把执行结果的分桶信息写入埋点。
根据数据采集收集的日志，我们有一套完整的以页面为线索的数据分析平台。在这个平台上我们可以看到页面维度的全部信息，除了PV，UV，点击率等常规数据，该页面的入口和出口流量，转化率等等。
而我们对A/B测试数据的要求也正是这些，所以我们对数据分析平台改造支持分桶统计，可以平行看到各个分桶的数据。
实践
配置灰度发布
之前我们说A/B测试的两个主要场景之一是灰度发布，配置中心是一个典型场景。修改一份配置后，需要对这次变更进行灰度发布，以求安全稳定。
我们预先定义若干灰度方案，每一个灰度方案就是一份A/B测试的实验条件。例如，我们有一份实验条件是：
第一个20分钟生效10%
第二个20分钟生效50%
第三个20分钟生效80%
通过1个小时的灰度逐步上线。在灰度过程中，我们可以在数据监控平台上实时发现问题，随时终止灰度进程。如果一切正常，那么这个变更就会自动全量发布。
首页模块对比测试
在天猫App的首页上有很多坑位，我们会在坑位变更中，使用了对比测试方案。
在某次变更中，首先切20%的流量作为样本，把样本五五开，10%执行旧逻辑，10%执行新逻辑，在线上试运行两天。根据反馈的数据显示，我们对比两个坑位的转化率和展示效果，发现新坑位效果并没有达到预期。所以撤回新方案，并实施改造，再次上线对比实验，直至达到预期效果。
在整个决策过程中，花费了1周时间。然而这样的决策在没有试错平台的情况下，需要跨越一个甚至更多个版本。
个性化弹窗
在实施A/B测试的过程中，发现这个平台除了处理以上的两个场景，还可以有更多功能。甚至可以在常规业务中发挥效果。
大家经历过天猫App首页的红包雨，擦雾霾等功能。这是一个独立的弹窗系统支持的，然而这个系统并没有很好的解决在什么条件下出现弹窗这件事。最初的方案只是分时间段弹窗，也就是说，弹窗有一个生效队列，到了某个时间点某个界面一定会弹出某个框。
我们希望弹窗逻辑可以更加聪明，能根据设备和用户信息个性化的出现。这个需求刚好与AirTrack所提供的能力契合，A/B测试并不一定要决定好坏，做出决策，当然也可以支持个性逻辑区分。我们使用AirTrack SDK的配置，把不同的弹窗条件单做桶来看待。通过动态配置AirTrack的分桶逻辑，并指定弹窗桶号来实现了这个个性化弹窗的需求。
以上就是我们在天猫App上最主要的三个实践场景。天猫在A/B测试领域的探索刚刚开始，我们相信随着探索的深入，A/B测试一定可以在App开发和维护中衍生出更加强大的能力，起到越来越重要的作用。
QA环节
Q：逻辑代码是动态加载吗？A：这个方案是我们设计的一个行级布局。只有布局和展示是动态的。其他逻辑还不是，但我们已经在研究如何用JS来解决native逻辑动态了。
Q：如果想简单实现，后台下发一个json配置，里面包含空间名，属性值，动态修改，和这个方案的id，后台记录这个方案id，然后对比效果，这样会有啥问题。
A：这个方案的点在于，控制比例和实时调整。所以，其实后台下发JSON这件事，如果是做在某一个业务后台上，那么这个能力就无法复制到其他业务中。
Q：您说的个性化弹窗是个独立的系统，是类似组件的形式吗？
A：不是组件。是一个独立于界面系统之外的弹窗，可以在任意界面之上弹。
Q：您说的桶是什么东西？A：所谓的桶，就是用户属于哪一部分。在这张图里，也就是说这个用户会落在哪一个叶子节点。
Q：百分比是怎么控制到用户的？A：控制百分比，我们用设备ID+实验名称做哈希。
Q：天猫灰度测试都是通过动态配置测一些UI吗？会不会有一些不能被动态配置覆盖到的功能或一些新实现的功能无法使用这种灰度方式进行测试？A：会有这样的问题。硬编码逻辑无法动态更新，但硬编码逻辑可以AB测试。比如，搜索框颜色，我们没有做动态化，但在native代码里使用Airtrack SDK注册了多个色值，用配置的方式调整条件。实现不同色值的对比实验。
Q：如何选取用户设备，分享提到是随机的，但是如何确定没有其他因素受影响呢，如果多个因素都在测试，一般咋处理呢，简单说，上线以后看测试效果的时候，如何避免干扰因素，避免结果遇到。
A：我们要求业务方来评估这个实验使用随机样本是不是OK，如果不OK，需要更精准的切分流量，我们可以使用属性来实现。就像上一张图片里的，我们可以根据各种属性，决定是否落入某个桶。
业务逻辑的代码需要预埋，无法动态。也就是说我们的AirTrack SDK提供的是代码级的测试方案，即使是刚才说的动态化，那也是那个界面动态框架调用AirTrack SDK，把动态逻辑埋进去。所以这个动态能力，是动态框架提供的，而不是AirTrack。
Q：移动端用户如何分桶呢？
A：会把上图那样的一棵树用JSON描述出来，下发到端，端上SDK会从根节点开始向叶子节点爬。
Q：能解释下上面这张图吗？蓝色和红色点，以及default。
A：红色的点，条件判断，需要进行运算的，要得出左or右蓝色的店，叶子节点，持有业务信息和桶号。
关于Default：因为我们做AB测试是对新逻辑的实验，有新逻辑必然有旧逻辑。我们认为落入Default节点的就是旧逻辑。
所以在上图你看到有3个Default点，但只有一个打了对号。也就是说，只有那个对号的会被拿来做数据比对。因为他的量和另外A和B的量基本一致。
Q：请问上图是用户的维度还是业务的维度？还是都是。
A：都是这些个性属性我们都是通过状态中心实现的，这些状态包括各种维度设备维度：系统版本，屏幕分辨率业务维度：用户活跃度用户维度：性别，年龄。
Q：请问天猫有新版本发布的灰度测试吗？先选择一部分用户安装新版本测试效果。如果有，这部分用户是选择厂外的还是内部的员工？
A：我们有版本灰度，iOS版本灰度目前方案是场外越狱。下周马上启动场内员工。现在我们通过状态中心可以区分一个用户是否为场内用户。
Q：请问你们是如何激励场内员工参与灰度的？有没有遇到没什么人参与的情况？
A：咳咳，这个问题我们也在纠结，说实话今天下午我们还在讨论这个问题。此前，我们设立过试用达人的奖项，这个可能也是接下来要采取的方案之一。
Q：这个sdk中具体包装点什么呢？
A：这个SDK最主要的逻辑就是，爬那个树形结构的算法，得到一个结果（桶号）；接受业务注册上来的逻辑代码，并根据计算得到的结果选择执行一段逻辑代码。
Q：转化率一般在几个点算是合格？误差率是怎么计算的？A：我们看的是与旧逻辑的提升，不是绝对值。因为样本大小是一样的，所以误差都被忽略了。
转载请注明来自『移动开发前线』公众号
公益传播测试知识、技能与正能量！感谢作者！分享测试生活，思考测试人生！
文章图片来自网络，如有侵权请见谅，请联系我们妥善处理。
twftesting@163.com
欢迎加入我们：
官网：www.huicewang.com
中国软件测试群： 172923163
测试编程技术交流群: 231767115
性能测试技术交流群: 385202672
咨询QQ：2657535456
公众号：慧测
