关于AB测试腾讯优测有话说
关于AB测试-腾讯优测有话说
很多软件测试的业内朋友在问，AB测试需要开发吗？甚至有很多人对AB测试不是很了解，腾讯优测的测试技术人员针对网友们的疑问，整理了一篇关于AB测试的内容，让大家一同来了解下AB测试。
AB测试概念
每每出现一个新的词汇或者技术，我们都要先来懂得它是什么意思，同样，我们先来讲一讲什么是AB测试。AB测试这个概念来源于生物学的双盲测试，互联网公司的AB测试采用的就是类似的概念：将Web或APP界面或流程的两个或多个版本，在同一时间维度，分别让两个或多个属性或组成成分相同（相似）的方可群组访问，收集各群组的用户体验数据和业务数据，后分析评估出版本，正式采用。这就是理论上AB测试的概念。
AB测试步骤
在软件测试领域，无论是兼容性测试，还是自动化测试，都有每个测试项目的基本测试步骤。由于AB测试是一个繁复迭代优化的过程，所以AB测试的基本步骤分为6步，
1. 设定测试目标；
2. 设计优化的迭代开发方案，完成新模块的开发；
3. 确定实施版本及每个线上的测试版本的分流比例；
4. 按照分流比例开发线上流量，进行测试；
5. 收集实验数据进行有效性和效果判断
6. 根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验
AB测试中分流的设计直接决定了测试结果是否有效
AB测试是对线上生产环境的测试，而之所以进行AB测试通常是对测试中的改进版本所产生效果的好坏不能十分确定，所以测试版本的流量通常不宜过大。尤其对于那些影响范围较大的改版（如主流程页面的重大调整），影响用户决策的新产品上线和其他具有风险性的功能上线通常采用先从小流量测试开始，然后逐步放大测试流量的方法。但是，测试版本的流量如果太小又可能造成随机结果的引入，试验结果失去统计意义。
为了规避这种因为样本量不足造成的试验结果不可用，在AB测试设计时可以采用如下措施：
1. 试验设计时预估进入试验的样本量，做分流规划时避免分配给测试集的样本量过少。
2. 除了进行AB测试外增加关于数据有效性考量的AA测试，将原始版本的流量中分出两个和测试版本相同的流量也进入测试。
例如：为测试一个新的功能，我们原本准备划分90%流量给老版本，10%流量给新版本；这时我们可以分配70%流量给老版本A，同时生成两个10%流量的老版本C和D进行AA测试，然后把剩余的10%流量给新版本B；在试验过程中通过考察分配给老版本C和D的两股流量是否存在显著性差异，从而认定试验分流是否有效。
3. 如果参与测试新版本已经分配了很大的流量比例，但是仍然存在样本量不足的情况，这时就只能通过拉长试验时间的方式来累积足够的样本量进行比较了。
AB测试的设计过程中另一个重要的点就是AB测试延续的时长了，通常AB测试延续的时间不宜太长，因为AB测试是对线上的多个版本的测试，这也就意味着线上系统需要同时维护多个可用的版本，长时间的AB测试无疑加大了系统的复杂性。但是，另一方面如果试验进行的时间太短可能会造成试验样本量不足的问题。同时，如果进行的是UI改版一类影响用户体验的测试，新版本上线后用户通常需要有一个适应的过程，这时我们通常会在试验开始时给用户一个适应期让用户适应新的UI版本，然后再考察试验的结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。适应期过后的试验时间长短除了需要考察样本量的情况外，还需要参考用户的行为周期，譬如说电商用户的购买行为有较强的周次规律，周末流量和购买量与工作日会有显著差异，这时测试的周期应该能够覆盖一个完整的周期，也就是应该大于1周。
在试验版本的设计过程中还需要考虑线上进行多个试验相互间的影响，譬如在电商的购买流程中我们同时对搜索算法和商品详情页的UI进行优化，这两个变动贯穿在用户的购物流程中，相互之间可能是有影响的，我们需要区分试验中这两种改动带来的影响分别是怎样的。
在这种情况下当然我们可以将用户流量分成：
A.老的搜索算法和老的详情页UI
B.新的搜索算法和老的详情页UI
C.老的搜索算法和新的详情页UI
D.新的搜索算法和新的详情页UI
这样四个版本，然后进行测试。但是这样分流的问题是对于流程中元素的改动，测试的版本是呈现指数上升的，在多个改动同时进行时就容易造成版本流量不足的情况。在这种情况下就需要引入试验分层的概念，将实验空间横向和纵向进行划分，纵向上流量可以进入独占实验区域或者是并行实验区域。在独占实验区域，只有一层，实验可以独享流量且不受其他实验的干扰。在分层区域，不同的应用属于不同layer，每个应用内部，又可以划分为多层，层与层之间相互不影响。流量可以横向经过多层，每一层可有多个实验。流量在每一层都会被重新打散。
这样多层次正交的实验方式使多个并发实验都可以保证具备一定流量的并行进行。
后，在对用户体验有明显影响的实验中通常采用对用户稳定的分流实现。即分到不同版本的用户在多次登录应用落入相同的实验版本，这样可以保证用户体验的一致性，保证用户能够在适应新版本的情况下有稳定的表现。通常会采用不同实验选用不同的hash种子，对用户的guid和上述分层实验的实验层次id的组合进行hash，然后根据hash值取余的方式进行分流。
AB测试效果分析
关于AB测试实验效果的分析通常分为两个步骤：实验有效性的判断、实验结果的比较。实验有效性的判断即判断实验的分流是否已经到达所需要的小样本量，从而能够以较大的概率拒绝两类统计错误的发生。小样本量的判断可以采用假设实验目标指标符合正态分布下，两类错误发生概率的分位数的方式进行估算。或者更一般的可以采用AA测试，对两个老版本的实验结果计算P值，从而判断其是否存在显著差异。如果AA实验的结果不存在显著差异，那么可以认为实验结果是有效的，进而可以对新老版本的实验结果进行进一步的判断。
在确认实验有效后就可以对实验的结果进行判断了，通常通过比较新实验版本和老版本是否存在显著差异（前述的P值判断），以及计算实验结果指标的置信区间（通常选用指标的95%置信区间），从而判断新版本是否相对老版本存在显著提升或下降。
AB测试的误区
误区1: AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况。
灰度发布是应用发布通常采用的方式，即对一个pool的部分服务器发布新版本的代码，而其余的服务器采用老版本代码，在确认应用正常的情况下逐步将新版本发布到pool的全部服务器。这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上。同时，灰度发布的分流单位通常是以服务器的流量为小单位的，不能做到对测试流量的分配。
误区2: 用参加实验的部分用户的体验质疑AB实验结果的正确性。
经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果。AB测试是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性。
误区3: AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化。
AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代。对于那些明显的bug修复，或者对于那些能够用户体验的功能，应该采用尽快上线并监控关键数据指标的方式。此外，AB测试也不是silver bullet, 通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比。
腾讯优测：https://utest.21ku***/home
以上就是腾讯优测总结整理的关于AB测试的一些资料，文章内容来源公共网络！
很多软件测试的业内朋友在问，AB测试需要开发吗？甚至有很多人对AB测试不是很了解，腾讯优测的测试技术人员针对网友们的疑问，整理了一篇关于AB测试的内容，让大家一同来了解下AB测试。
AB测试概念
每每出现一个新的词汇或者技术，我们都要先来懂得它是什么意思，同样，我们先来讲一讲什么是AB测试。AB测试这个概念来源于生物学的双盲测试，互联网公司的AB测试采用的就是类似的概念：将Web或APP界面或流程的两个或多个版本，在同一时间维度，分别让两个或多个属性或组成成分相同（相似）的方可群组访问，收集各群组的用户体验数据和业务数据，后分析评估出版本，正式采用。这就是理论上AB测试的概念。
AB测试步骤
在软件测试领域，无论是兼容性测试，还是自动化测试，都有每个测试项目的基本测试步骤。由于AB测试是一个繁复迭代优化的过程，所以AB测试的基本步骤分为6步，
1. 设定测试目标；
2. 设计优化的迭代开发方案，完成新模块的开发；
3. 确定实施版本及每个线上的测试版本的分流比例；
4. 按照分流比例开发线上流量，进行测试；
5. 收集实验数据进行有效性和效果判断
6. 根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验
AB测试中分流的设计直接决定了测试结果是否有效
AB测试是对线上生产环境的测试，而之所以进行AB测试通常是对测试中的改进版本所产生效果的好坏不能十分确定，所以测试版本的流量通常不宜过大。尤其对于那些影响范围较大的改版（如主流程页面的重大调整），影响用户决策的新产品上线和其他具有风险性的功能上线通常采用先从小流量测试开始，然后逐步放大测试流量的方法。但是，测试版本的流量如果太小又可能造成随机结果的引入，试验结果失去统计意义。
为了规避这种因为样本量不足造成的试验结果不可用，在AB测试设计时可以采用如下措施：
1. 试验设计时预估进入试验的样本量，做分流规划时避免分配给测试集的样本量过少。
2. 除了进行AB测试外增加关于数据有效性考量的AA测试，将原始版本的流量中分出两个和测试版本相同的流量也进入测试。
例如：为测试一个新的功能，我们原本准备划分90%流量给老版本，10%流量给新版本；这时我们可以分配70%流量给老版本A，同时生成两个10%流量的老版本C和D进行AA测试，然后把剩余的10%流量给新版本B；在试验过程中通过考察分配给老版本C和D的两股流量是否存在显著性差异，从而认定试验分流是否有效。
3. 如果参与测试新版本已经分配了很大的流量比例，但是仍然存在样本量不足的情况，这时就只能通过拉长试验时间的方式来累积足够的样本量进行比较了。
AB测试的设计过程中另一个重要的点就是AB测试延续的时长了，通常AB测试延续的时间不宜太长，因为AB测试是对线上的多个版本的测试，这也就意味着线上系统需要同时维护多个可用的版本，长时间的AB测试无疑加大了系统的复杂性。但是，另一方面如果试验进行的时间太短可能会造成试验样本量不足的问题。同时，如果进行的是UI改版一类影响用户体验的测试，新版本上线后用户通常需要有一个适应的过程，这时我们通常会在试验开始时给用户一个适应期让用户适应新的UI版本，然后再考察试验的结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。适应期过后的试验时间长短除了需要考察样本量的情况外，还需要参考用户的行为周期，譬如说电商用户的购买行为有较强的周次规律，周末流量和购买量与工作日会有显著差异，这时测试的周期应该能够覆盖一个完整的周期，也就是应该大于1周。
在试验版本的设计过程中还需要考虑线上进行多个试验相互间的影响，譬如在电商的购买流程中我们同时对搜索算法和商品详情页的UI进行优化，这两个变动贯穿在用户的购物流程中，相互之间可能是有影响的，我们需要区分试验中这两种改动带来的影响分别是怎样的。
在这种情况下当然我们可以将用户流量分成：
A.老的搜索算法和老的详情页UI
B.新的搜索算法和老的详情页UI
C.老的搜索算法和新的详情页UI
D.新的搜索算法和新的详情页UI
这样四个版本，然后进行测试。但是这样分流的问题是对于流程中元素的改动，测试的版本是呈现指数上升的，在多个改动同时进行时就容易造成版本流量不足的情况。在这种情况下就需要引入试验分层的概念，将实验空间横向和纵向进行划分，纵向上流量可以进入独占实验区域或者是并行实验区域。在独占实验区域，只有一层，实验可以独享流量且不受其他实验的干扰。在分层区域，不同的应用属于不同layer，每个应用内部，又可以划分为多层，层与层之间相互不影响。流量可以横向经过多层，每一层可有多个实验。流量在每一层都会被重新打散。
这样多层次正交的实验方式使多个并发实验都可以保证具备一定流量的并行进行。
后，在对用户体验有明显影响的实验中通常采用对用户稳定的分流实现。即分到不同版本的用户在多次登录应用落入相同的实验版本，这样可以保证用户体验的一致性，保证用户能够在适应新版本的情况下有稳定的表现。通常会采用不同实验选用不同的hash种子，对用户的guid和上述分层实验的实验层次id的组合进行hash，然后根据hash值取余的方式进行分流。
AB测试效果分析
关于AB测试实验效果的分析通常分为两个步骤：实验有效性的判断、实验结果的比较。实验有效性的判断即判断实验的分流是否已经到达所需要的小样本量，从而能够以较大的概率拒绝两类统计错误的发生。小样本量的判断可以采用假设实验目标指标符合正态分布下，两类错误发生概率的分位数的方式进行估算。或者更一般的可以采用AA测试，对两个老版本的实验结果计算P值，从而判断其是否存在显著差异。如果AA实验的结果不存在显著差异，那么可以认为实验结果是有效的，进而可以对新老版本的实验结果进行进一步的判断。
在确认实验有效后就可以对实验的结果进行判断了，通常通过比较新实验版本和老版本是否存在显著差异（前述的P值判断），以及计算实验结果指标的置信区间（通常选用指标的95%置信区间），从而判断新版本是否相对老版本存在显著提升或下降。
AB测试的误区
误区1: AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况。
灰度发布是应用发布通常采用的方式，即对一个pool的部分服务器发布新版本的代码，而其余的服务器采用老版本代码，在确认应用正常的情况下逐步将新版本发布到pool的全部服务器。这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上。同时，灰度发布的分流单位通常是以服务器的流量为小单位的，不能做到对测试流量的分配。
误区2: 用参加实验的部分用户的体验质疑AB实验结果的正确性。
经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果。AB测试是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性。
误区3: AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化。
AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代。对于那些明显的bug修复，或者对于那些能够用户体验的功能，应该采用尽快上线并监控关键数据指标的方式。此外，AB测试也不是silver bullet, 通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比。
腾讯优测：https://utest.21ku***/home
以上就是腾讯优测总结整理的关于AB测试的一些资料，文章内容来源公共网络！
