敏捷测试交付_连续交付–第四部分– A / B测试

敏捷测试交付

上一章： 持续交付–第3部分–功能切换

摘自Wikipedia ：在Web开发和营销以及更传统的广告形式中，A / B测试或拆分测试是Web设计（尤其是用户体验设计）的实验方法，其目的是识别对网页的增加带来的变化或最大化感兴趣的结果（例如，横幅广告的点击率）。 顾名思义，将比较两个版本（A和B），除了一个版本可能会影响用户的行为外，其他两个版本相同。 版本A可能是当前使用的版本，而版本B在某些方面进行了修改。 例如，在电子商务网站上，购买渠道通常是A / B测试的良好候选者，因为即使下降率略有提高也可以

代表了显着的销售增长。 通过测试诸如复制文本，布局，图像和颜色之类的元素，可以看到明显的改进。

尽管这听起来类似于功能切换 ，但A / B测试和功能切换在概念上有所不同。 通过A / B测试，您可以衡量功能或流程是否完整的结果，希望该功能或流程没有错误。 A / B测试是一种将完成的功能展示给用户并测试用户对此功能的React的机制。 使用功能切换时，您想测试代码是否按预期正常运行且没有错误。 在许多情况下，功能切换用于后端，而用户并没有真正体验到流程的变化，而A / B测试则用于将新流程或UI展示给用户的前端。

一致的用户体验。

在A / B测试中要注意的重要一点是一致的用户体验。 例如，您不能一次显示一个新的菜单选项，或者当用户返回到您的站点时，或者如果用户刷新浏览器，则不能再次显示相同的选项。 因此，根据您要进行A / B测试的策略来确定用户是A组还是B组中的用户，该用户应该保持一致。 如果用户返回到您的应用程序，则他们应始终“属于”同一测试组。

在Web应用程序中实现一致的用户体验是棘手的。 大多数Web应用程序都有两种类型的用户：匿名用户–未登录您的Web应用程序的用户； 登录用户–具有有效会话并在您的网站上通过身份验证的用户。

对于经过身份验证的用户，实现一致性很容易。 您选择的将用户分配给特定测试组的算法应适用于用户ID。 一种简单的算法是用户ID上的模数。 这将确保无论用户使用计算机还是浏览器，无论何时用户返回该站点，从他登录时始终将获得相同的值。

对于匿名用户，这更为复杂。 由于您不知道用户是谁，因此不能保证行为一致。 我们可以通过在用户的浏览器中存储一个永久性cookie来减轻问题，该cookie具有分配给用户的A / B测试组的值。 这样可以确保用户下次返回该站点时，将获得相同的组分配（您只应将一个用户分配给测试组一次）。 但是，由于网络的工作方式，此方法存在缺陷。 如果用户从其他浏览器，另一台计算机上浏览该网站，或者清理了浏览器Cookie，则您可能不知道该用户过去曾被分配到特定的测试组，因此您可能会再次将该用户分配给一个测试组（但他可能被分配到其他组）。

A / B测试策略。

分配测试组的最常见策略是百分比。 您可以定义您的用户获得A的百分比，获得B的百分比。像功能切换一样，您可以有多种策略来确定用户的测试组。 我们在Wix上使用的这类策略是语言，GEO位置，用户类型，注册日期等。 当然，您也可以组合策略，例如：“英国50％的用户将获得B，其余所有用户将获得A”。

报告和分析。

由于A / B测试的重点是确定一项新功能是否可以改善您的目标，还是不应该跟踪分配给测试组的所有用户，一旦确定您有足够的测试参与者，就应分析数据并确定新功能是否良好。 如果测试成功，则可能会增加测试组，甚至停止测试，并将新功能公开给所有用户。 另一方面，如果测试不成功，则将停止测试并还原。
如果测试不成功，但是您想要尝试改进并重新启动测试，则可以暂停测试以保持一致的用户体验，不要分配更多的用户来获取新功能组，但无论分配给谁看新功能将继续显示。 进行必要的改进后，您应该恢复测试并恢复为测试组分配用户。

现在，您可能会问自己，A / B测试与连续部署有什么关系？ 好吧，因为持续部署的全部目的是要从用户那里获得快速反馈，所以A / B测试是获得这种反馈的一种很好的机制。

下一章： 启动和自检

参考： 持续交付–第4部分–我们的JCG合作伙伴 Aviran Mordo在Aviran's Place博客上进行的A / B测试 。

翻译自: https://www.javacodegeeks.com/2013/05/continuous-delivery-part-4-ab-testing.html

敏捷测试交付