Cucumber测试实践

Thoughtworks思特沃克中国

于 2022-02-11 17:56:55 发布

阅读量943

点赞数

CC 4.0 BY-SA版权

分类专栏：敏捷实践文章标签：测试自动化测试敏捷测试

本文链接：https://blog.csdn.net/toafu/article/details/122885963

本文探讨了Cucumber在测试实践中的应用，强调了思路转变，如培养CICD意识，减少徒手测试，确保行为与断言闭环。通过Cucumber实践，作者指出它并非BDD，而是用于记录测试行为的脚本工具。文章还讨论了E2E测试的挑战，并提出了解决方案，提倡分离测试，以提高测试效率和质量。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

（来源：https://cucumber.io/docs/guides/overview/）

作为QA，可能我们在迭代中总会遇到这样一些问题：

开发进行重构影响范围大，每次都需要进行大量的回归测试耗时耗力
一些技术卡如果测试又不知道具体影响范围，不测试又总是觉得不安心
一些客户会要求提供一些类似测试用例或者是测试报告之类的测试成果物，但是在敏捷流程中这些可能不是必需品，如果单独准备会很麻烦

这些问题Cucumber测试实践都会提供一些解决思路，并且还远不仅限于此。

一、思路转变

1、培养CICD意识

CICD，持续集成持续部署/交付不是什么新概念，但是时至今日对于测试者来说很少有人对于测试有这个意识。敏捷流程中的测试者还是按部就班的根据Issue卡的内容构思测试范围、设计测试场景、执行测试用例，如果做的好一点可能会在之后补充一下简单的自动化测试。于是会出现的一种节奏上的偏差，敏捷流程中往往伴随着大量的、短时间内的变化，如果测试者依照上面的流程应对这些变化，这就意味着大量的重复工作。举一个最简单的例子，一个有鉴权的系统光登录就是每次测试必要执行的。于是，当大量的变化、大规模的重构在迭代中发生时，这就意味着测试者的工作量会是之前涉及到的Issue卡的总和，可能就需要为了妥协而采取减少一些测试场景等等措施。

试想一下如果把我们的测试工作也做成一个持续集成的产品呢？把我们所做的测试工作全部有计划、有规律的拓印下来。对于之前执行过的测试，之后只需要one click即能执行，对于拓展的业务需求，只需要在已有的语法上进行拓展。交付产品不断迭代，测试集也在不断迭代。这样不仅节省测试工作量同样也会让QA对于整个产品质量框架有一个整体的把控。