几种常见测试

原文链接：https://blog.csdn.net/shanshangyouzhiyangM/article/details/81456991

灰度测试：

是指在黑与白之间，能够平滑过渡的一种发布，进行的一种测试。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。除了AB test灰度发布另一种思想是，只发布给一小部分用户，如：App在发布之前，可能会针对性的给一小批种子用户发送下载链接，或者到小的应用市场去发布。用小流量发布的方式来检验新版会不会有问题。

为什么要做灰度发布？
很多公司在定义一个产品，一个功能的时候，有的说白，有的说黑，但是互联网产品真正的定义者是谁？当然是用户，你说了不算，我说了也不算，用户口碑才是硬道理，因此需要一个灰度周期，让用户决定其生死，定义其黑白。

分桶测试(bucket testing BTS)

分桶测试(bucket testing)，简称BTS。让不同的用户在访问特定的互联网产品的时候，由系统来决定用户的分组号（我们称为bucket id），然后根据分组号，令用户看到的是不同的产品版本，用户在不同版本产品下的行为将被记录下来，这些行为数据通过数据分析形成一系列指标，而通过这些指标的比较，最后就形成了各版本之间孰优孰劣的结论。

A/B测试 (A/B Testing)

分桶测试的最简单形式，称为A/B testing。即设定一个基准桶，再设定一个或以上的测试桶。然后考察测试桶与基准桶之间在各项指标上的差异，最后确定测试桶的效果。这种方法论，很容易在现实生活中找到影子。其实，改革初期建立的深圳特区，就是一场伟大的A/B testing，基准桶就是中国内地，测试桶就是深圳，当时各自的用户量是9亿 vs 30万（以当时的人口计算）。对于A/B testing而言，测试桶的用户量、流量都不会太大，这是为了确保BTS万一失败，对于整体系统的影响尽量小。当然，测试桶的用户量、流量也不能太少，否则测试效果容易受到未知因素的干扰，而变得不稳定。对于A/B testing而言，判断测试组与基准组孰优孰劣非常简单，只要将二者的指标进行对比即可。但是，如果版本中包含多个因素，那么确定每个因素的贡献，就不好评估了。

多变量测试 (Multivariate Testing)

分桶测试的高级形式，是多变量测试。在多变量测试中，每个可以改变的地方称为因素，而每种因素的可能具有的状态称为水平。比如，你想同时改变某个搜索产品的按钮颜色、排序算法、索引数据这3个地方，那你需要一个3因素的多变量测试。如果，按钮的颜色为3种，那“按钮颜色”这个因素是3水平的。多变量测试允许你在同一时间测试多个要素处于不同水平时对于搜索产品的影响。通过多变量测试，你能十分清楚的看到不同的变化组合，对最终效果的影响。

举例而言，如果对某个搜索产品进行BTS测试的范围为：3种按钮颜色、2种排序算法和2种索引数据，那么该如何确定效果最佳的搭配呢？一般，我们会进行排列组合，产生不同的版本，使得每个版本对应一种水平的组合，这样我们就要构造322=12种版本参加BTS测试。接下来我们只要确定好每个版本的流量分配即可，即哪些桶对应哪个版本。
最后，也是最有难度的地方在于，如何通过各版本的指标分析，来确定哪个版本最好、每个因素贡献程度以及结论的可靠性。这将比A/B测试要复杂的多，建议各位看官在有兴趣尝试之前，回顾一下统计学的假设检验、实验设计方面的知识。限于篇幅，这里我们就不展开。