A/B测试与灰度发布

1、A/B测试与灰度发布相关的一些术语

测试起源

1.1 桶测试(Bucket Testing):这个没有什么地方给出明确的定义,但是通常来说是国外用于测试游泳池是否存在漏水行为的一种比较测试。即将一桶水放到泳池中,分别标明内外水位,放置一段时间后,如果外部水位明显下降(超过XXX英寸),则证明水池漏水。这个和软件测试没有什么直接关系,但是他是一种两个方案之间的对比性测试,用于识别缺陷。

1.2 多变量测试(Multivariate Testing):这个使用市场营销的一个术语,通常用于在多个变量的复杂环境下,对营销方案效果的比较技术。

进化

1.3 A/B测试(A/B Testing):Wikipedia的定义,“是Web设计(通常指用户体验)中用于区分两种网页设计对收益最大化目标(如点击率)效果支撑程度的一种试验手段”。主要用于比较两种设计的优劣程度。桶测试(Bucket Test)、多变量测试(Multivariate Testing)是A/B测试的变体,因为可能涉及到多种场景的比较。A/B测试还用于市场营销渠道的比较,这和定义是一致的,因为网页就是一种营销渠道。

1.4 灰度交付:“灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。”

2、A/B测试和灰度发布和传统的测试的不同点

2.1 可以有多个现成的产品来,实实在在的去测试(桶测试)

2.2 A/B测试是支持多变量测试的一种方式

2.3 A/B测试时一套系统,是灰度发布的一种实现方式

到此为止,测试与运维已经集成到一个过程当中了

3、A/测试与灰度发布的理论支持

产品是多维度的,设计体验、交互体验、系统质量、运营支持等等,

测试的目的是为了系统最终的交付,一套各方面都足够好的系统,而不是文档上定义的系统,系统是需要不断进化的。

测试的质疑贯穿产品的设计到编码到最终的运营过程,并最终促使产品的改善,周而复始。

符合互联网思维敏捷的本质。

4、A/B测试与灰度发布的运用

3.1 推荐系统之间不同算法的比较,不同变量的比较

3.2 设计方案中不同方案的比较

3.3 设计调整,方案调整

3.4 故障控制

如果你系统需要优化一些你自己无法预测和控制的领域的时候。

试试A/B测试吧,有利于控制未来的风险

数据是优化系统的重要依据 ,想要在哪方面做优化,就在哪方面积累数据。

时间: 2024-10-19 17:21:47

A/B测试与灰度发布的相关文章

【微服务从入门到精通】:(一)微服务的蓝绿发布及灰度发布

蓝绿部署 基本上,蓝绿部署是一种以可预测的方式发布应用的技术,目的是减少发布过程中服务停止的时间. 简单来说,你需要准备两个相同的环境(基础架构),在蓝色环境运行当前生产环境中的应用,也就是旧版本应用,如图中 App1 version1 . App2 version1 . App3 version3 . 当你想要升级 App2 到 version2 ,在蓝色环境中进行操作,即部署新版本应用,并进行测试.如果测试没问题,就可以把负载均衡器/反向代理/路由指向蓝色环境了. 随后你需要监测新版本应用,

使用nginx实现的灰度发布思路研究(待实践)

灰度发布也叫 A/B 测试,原理是一套系统在实现了负载均衡,全国节点都部署了系统之后,可以在新功能上线后,让一小部分用户先使用,从中收集使用信息来做对比和发现bug,及时调整,最终分发到全国的节点. 实现灰度发布的几个思路: 1.以nginx为例的分流,IP是最终的关键,从而以IP围绕中心,可以衍生出很多定义,比如用户标识.用户分组.设备ID及分组等,但是最终还是离不开IP去分流. 2.nginx支持模块开发,如果在一套成熟的系统中,可以开发自己的模块,从而脱离IP为分流导向,指定自己的精确分流

Android、iOS、和Web如何做灰度发布?

主要参考了: https://www.zhihu.com/question/21714205 https://www.zhihu.com/question/28296375 一.概述 所谓的灰度发布,在行业内叫做A/B Test,所以可以搜索一些这方面的关键词 下面是某公司的灰度发布流程,仅供参考. 一)经典总结1: 1)web页面灰度.按照ip或者用户id切流啊.具有随机性,可以控制比例    2)服务端灰度.考验主系分能力了,可以做逻辑切换开关,按照义务相关属性逐渐切流    3)app.一

基于Geoip城市的灰度发布

1.安装epel源 wget https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm rpm -ivh epel-release-6-8.noarch.rpm 2.首先安装 MaxMind 的 GeoIP 库,其官网是: http://www.maxmind.com,MaxMind 提供了免费的 IP 地域数据库(GeoIP.dat),不过这个数据库文件是二进制的 yum install GeoIP G

灰度发布

现状: 目前产品有新版本,release测试通过以后,直接放到更新服务器上,做全量用户推送.当发现新版本存在测试未覆盖到的问题时,造成的影响面较大,解决问题的代价也很大.因此可以考虑引入灰度发布. 灰度发布: 新版本准备好时,挑选全量用户中的一小部分用户,先推送新版本功能.过一段时间确认没有大的问题后,再进行全量用户的推送. 灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现.调整问题,以保证其影响度. 目前大多主流WEB应用都使用了灰度发布的方式. 扩展: 一种更高明的灰度发布方式是:

MaxCompute flighting —— Task灰度发布

转载自zifu 前言 按照百科词条的解释:灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式.灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现.调整问题,以保证其影响度.降低发布上线的风险. 灰度发布的关键是选择合适的灰度策略,把符合策略的流量引入到新版本上.灰度策略的选择需要考虑待发布对象在链路或系统中的位置角色(如客户端.移动APP.服务后台等).用户属性和发布需求目标等.本文将对MaxCompute的Task灰度发布系统进行介绍. MaxCompute Task灰度发布 Max

线上版本灰度发布策略

从接触运维开始,最苦逼的事情就是业务上线,为什么这么说? 就是因为有了很多的大坑队友.不是因为开发的童鞋漏提代码,就是因为测试童鞋线下测试的不到位导致代码扔到线上后出现各种问题,各种404.近期和各位童鞋研究了应对这种现象的解决方案,得到了如下结果: 上线分为如下几种等级:测试发布.预发布.灰度发布.正式发布,下面分来来针对这四种发布介绍下区别. 测试发布:写完程序在线下测试,测试的过程和结果成为测试发布. 预发布:程序经历过测试发布后要把代码在线上部署一套(和生产环境一模一样的环境),使用生产

我理解的灰度发布。

灰度发布,就是产品的新功能,让一部分人先看到,再让一部分人看到,再让....这样直到全部上线或者下线.. 常用的灰度发布,就是先加一批白名单,再加一批集团用户,再开发一台机器,再切全量. 每开放一步,就多一批用户测试和反馈,然后你在迭代产品的优化方案,继续上面步骤. 之前在邮箱的时候除了这种方式之外,还会有实验室的方式,邀请用户尝试新功能开启.其实这些都很常见,就像Google labs里的一些模块,让用户主动自行去玩,即用户申请加入白名单. 微博或者Qzone升级的时候也开放了邀请用户升级的过

互联网产品发布之灰度发布

1. 为什么要灰度发布 互联网服务变动频繁,发布周期短.速度与质量总是难以双全. 灰度发布能降低发布风险,减少影响范围. 降低对测试的依赖,减少线下自测的数据构造成本. 方便集中监控日志,全量发布由于各层负载均衡的作用,很难跟踪一条完整的调用链路. 可以灰度测试帐号,测试账户通过之后再灰度真实用户帐号,进一步降低发布的风险和影响. 方便回滚. 不能靠灰度发布解决的问题 需要强调的是:上文所说的“可以容忍的影响”必须是可恢复的,比如API无法调用一段时间,但是修复之后,就可以成功调用.而永久性地丢