实验(ABtest)特性的回归/自动化测试

Question

我们正在使用自动化测试工具Cypress来执行回归测试。我们在一周内发布了2个版本，因此自动回归测试对我们来说至关重要。

在生产中有一些特性是实验性的，即这些特性只适用于一定比例的用户。最终，这些功能可能会扩展到100%的用户，或者完全放弃。这些特征在实验中停留了1-4周。

尽管这些都是实验性的特性，但我们必须在以后的每个版本中对这些特性进行回归测试。我们还没有自动化这些功能，因为有30%的可能性，这些可能会完全放弃。因此，我们对这些特性进行了手工测试，这是一项耗时的工作。

对于这类特性的回归测试方法有何建议？

Answer 1

虽然我没有一个完整的答案这个问题是特殊的，但区别于常见的“我如何测试”的问题是高频率的变化。彻底测试一切都是一种方法，但正如@vicky99 99所解释的那样，对于一个非常短暂的特性来说，投资是不值得的。

在我看来，有两条路要走。有一种方法可能会有所帮助，但很大程度上取决于您的产品，那就是有一个良好的测试基础结构--环境、测试运行程序、测试API、测试框架、文档等等，然后尝试将测试转移到开发人员的左侧和开发阶段的早期。

拥有坚实的测试基础设施意味着开发人员可以相对快速、无痛苦地添加测试，这些测试可能是最基本的，但这比完全没有测试要好。团队的测试自动化专家将通过维护测试基础结构并在开发新特性的同时添加新特性来支持这项工作。

到目前为止，这听起来像一个团队应该工作的正常方式，但是您必须调整它以适应速度和效率，例如开发人员之间更好的沟通，将测试开发放在更高的优先级，或者首先接受更简单的测试，然后再对它们进行改进。

另一种可能无法独立存在的方法是进行出色的监测和数据分析。既然你已经做了AB测试，你可能会有遥测被发回和分析。您可以使用这些数据在生产中进行测试并查找错误，您可能应该有一个自动系统来分析数据引发警报，并且您应该使这个系统不仅能够智能地查找错误报告，而且还可以查找异常的使用模式。由于您已经使用上述方法完成了基本测试，所以您可以非常确信您的特性是稳定的，并且bug不会太常见。

Answer 2

在手工测试的成本/工作/速度与自动化特性之间的权衡似乎是一个问题。

我假设您有很好的提交阶段验证测试。这意味着你的特性定义的一部分是用单元测试和集成测试覆盖这个特性，不管它是留在应用程序中，还是在A/B测试之后被删除。如果不是这样的话--考虑让测试工作更接近开发阶段，向左移动，就像前面提到的那样。

在这种情况下，您可以通过降低引入可能无法验证的业务逻辑的风险来减少手动测试的数量。手动测试只应在高级别上执行，这取决于您有哪些风险并试图减轻风险。

如果这个特性还在继续的话--用E2E测试来覆盖它，并消除其余的手工工作。

另一种方法是在作出go/no决定之前引入记录和播放自动化。例如使用柏树记录器

面对技术，低级别的测试应该还在，但是在这种情况下，您可以通过临时验证这些测试的功能来消除手工的工作。由于维护成本和脆弱性，对于长期运行的测试自动化来说，录制和回放是一个可怕的选择，但对于短期特性(记录、测试和丢弃这些测试)来说，这些功能可能运行良好。稍后，您可以通过使用Cypress进行可靠的测试来覆盖该特性。

Answer 3

从自动化测试服务的角度来看，很难从自动化测试服务的角度来确定这类特性的通用自动化策略。一种更好的办法是逐案处理。例如，它将更好地自动化一个功能，将停留4周，而不是那些预期将在1周后停止。

另一个需要考虑的因素可能是通过手动测试使其自动化所节省的时间的总体成本。你得考虑维修费用。最后，这个特性被期望保留的可能性有多大，那么它是值得自动化的，因为您最终将不得不这样做。