数据驱动测试脚本（测试驱动指引）

小君 2023-04-14 17:42:18 238

数据驱动测试脚本（测试驱动指引）开发阶段推荐实践即在编码层面，我们用TDD方法以测试驱动的方式编写代码。在需求层面，我们使用类似的BDD方法以测试驱动的方式构建系统。原则规范

概念

测试驱动开发（Test-Driven Development，TDD），用一句话讲，就是“写代码只为修复失败了的测试”。我们先写一个测试，然后再写代码让测试通过。当我们在当前结构中找出最佳设计时，由于有足够的测试做保障，我们可以放心地改动现有设计而不必担心破坏已完成的功能。使用这种开发方法，我们可以让设计更加优良，能编写出可测试的代码，同时还能避免在不切实际的假设基础上过度地设计系统。要得到这些好处，只需不断添加可执行测试，一步步地驱动设计，从而最终实现整个系统。这种短开发周期的开发方式与旧方式有很大不同。我们习惯于先设计，然后编码实现，最后做一些并不完备的测试。（我们都是优秀的程序员，很少犯错，所以稍加测试即可，不是吗？）TDD完全颠倒了整个过程。我们会先写测试描述出目标，然后写代码达到这个清晰的目标，最后再设计——在已有代码的基础上找出最简单的设计。随着TDD不断深入到开发领域，这种测试先行的思想也不断向上深入到需求阶段，衍生出来ATDD、BDD等相关方法。

目标

通过TDD提高应用程序内部质量，通过ATDD/BDD确保交付客户的软件符合用户需求。

即在编码层面，我们用TDD方法以测试驱动的方式编写代码。在需求层面，我们使用类似的BDD方法以测试驱动的方式构建系统。

原则

先写测试代码，然后编写符合测试的代码。至少做到完成部分代码后，完成对应的测试代码。
测试代码不需要覆盖所有的细节，但应该对所有主要的功能和可能出错的地方有相应的测试用例。
发现 bug ，首先编写对应的测试用例，然后进行调试。
不断总结出现 bug 的原因，对其他代码编写相应测试用例。
不断维护测试代码，保证代码变动后通过所有测试。
不断维护测试代码，提高测试代码的可读性与可维护性。
遵从测试金字塔，数量上来说 UT > BDD > 手工测试。

规范

综合

必须：测试代码也是代码，需要源代码管理。
必须：测试代码不需要再写测试代码，但需要代码评审。
必须：单元测试、BDD测试的代码和项目代码放在同一个代码工程里，用不同目录区分。
必须：用于回归的E2E测试代码可以放到与项目代码不同的工程中。
必须：单元测试、验收测试以及BDD可以自动化执行。
必须：不同技术栈可以采用不同的自动化测试框架，但是都需要能够接入DevOps平台。即可以由平台触发测试，并反馈测试状态和结果。
必须：每次push都会触发单元测试，并反馈测试结果。
建议：每次push都会触发BDD测试，并反馈测试结果。
建议：每日运行一次全量回归的E2E测试，并反馈结果。

单元测试

建议：工程名：[ProjectName].Unit.Tests。如：项目工程为 abc.service，那么单元测试工程为 abc.service.unit.tests。
建议：文件名：[ClassName]Tests。如：bookService.java 测试类为 bookServiceTests.java。
建议：方法名：由三部分构成，[name_of_method]_[scenario]_[expected_behavior]，如：Add_SingleNumber_ReturnsSameNumber。
必须：方法结构：遵从 Act-Arrange-Assert 结构。如
unit test method structure 展开源码

BDD

必须：不要尝试用BDD取代单元测试！开发人员应该先干好自己的单元测试。
建议：当项目中的BDD完整执行需要超过15分钟，改进测试代码。
必须：BDD测试使用Gherkin风格的描述语言，即Given-With-Then。
建议：feature都放置在项目的 src/tests/features/ 文件夹，可以按照不同功能集合，建立不同子目录。
建议：step定义放置在项目的 src/tests/features/steps/中，子目录结构与保持与features/子目录一致。
建议：每一组近似功能的测试，放到同一个.feature文件中。如：src/tests/features/useraccount/signup.feature，放入注册相关的测试。
建议：每一个feature包含的特性集，必须能够独立运行。不同的feature测试之间不互相影响。
建议：不要尝试通过文件名建立feature和用户故事的关联关系。如：features/sotry_38971_ log_ in. feature。

推荐实践

开发阶段