流程，测试和日常任务的自动化始终具有一定的优势。 它简化，消除了返工，并赋予了从事创新和创造活动的工作自由。
在软件开发项目中，团队通常会寻求替代方案来优化工作流程，自动化测试，构建，部署和其他任务。 必须优化的这些任务之一是流程的缺陷重新测试。
最近，我有机会参加了一个可以使用该策略的项目。 测试与开发修补程序并行进行，并且在进行调整时，测试团队致力于自动化不同于预期的读取缺陷的流程。 也就是说，自动执行重新测试。
使用这种方法为我们带来了一些优势，其中包括：
- 验证补丁过程中的敏捷性
- 确保正在监视缺陷。 如果再次发生这种情况，则会自动通知团队。
- 学习使用Java，Cucumber，Selenium和代码版本控制测试自动化的技术
- 业务规则涵盖范围的开始
但是塞缪尔和断言？
断言是自动测试检查点。 那就是他是否通过的意思。 在这种情况下，它们是缺陷，如果流程没有完全完成，我怎么说测试是否通过？
他没有断言 。 在即将到来的项目中，重新添加甚至错误的检查点来重新考虑此策略可能会很有趣。 但是，修复后，有必要维护测试和所有错误的断言。 在我们的案例中，目标是在项目上启动Automation，并尽可能多地利用我们的时间来做。 我们没有添加断言，但是我们将整个流程自动化到发生缺陷的地步。 就是说，缺陷得到纠正后，几分钟后，我们将获得自动化流程并进行正确的验证。
“樱桃”蛋糕-与业务场景链接
在完成了最高优先级缺陷重新测试的自动化之后，我们已经进行了大量的自动化测试。 因此，我们决定演示该项目，并与一些更有经验的同事交谈，以告诉我们它的发展情况并收集反馈。 其中一些要点是：
- 在自动缺陷中，它们正在验证哪些规则或业务流程？ 哪些测试场景可以验证？
查赞 。 我们没有想到这一点。 对话之后，我们要做的第一件事是映射已经被100％覆盖的场景数量，以及哪些场景需要额外的内容，以便现在成为基于业务的自动化场景，而不仅仅是缺陷。
纠正缺陷后，我们开始使用缺少的验证来补充自动重播，并链接到映射到项目业务规则的测试方案。 因此，我们扩大了自动化项目测试的范围。 更具体地说，该项目从0％开始，最后是22.73％。 **
我相信，从这种经验中学到的主要不是工具，而是着眼于持续改进。 这是我们在上下文中使用的一种方法，用于学习，优化，简化和享受我们现有的时间。 我希望它能帮助那些希望从项目的自动化和方法，思维方式入手的人。
**覆盖率基于映射到项目的总测试方案。
