使用测试用例作为成本和风险控制工具

我们都经历过或者看到过由于各种原因(如范围变更、成本过高或调度问题)而没有按计划执行的软件开发项目。看到软件项目是如何实际执行的，特别是当前面提到的场景正在发挥作用时，突出了预先构建项目的重要性。

不幸的是，当项目处于成本或进度压力下时，测试是第一个被削减或削减的领域之一，但这并不罕见。这种策略不仅没有达到预期的效果，而且几乎总是适得其反。在过程中减少或推迟测试并不会改变解决方案的质量。它所做的只是延迟问题检测。

在开发过程的早期发现相同的问题，而不是在最后发现，即在单元测试和生产操作中发现相同的问题，成本是指数级的，并且几乎总是需要更少的时间来修复。为了强调这一点，考虑在经过验证的生产环境中发现bug的场景:

• 问题必须被识别、报告，并可能解决。
• 必须对问题进行重现、分类和分配优先级。
• 这个问题可能会被开发人员再次复制并修复。
• 修复需要在测试环境中进行部署和测试。
• 需要在验证环境中部署和测试修复。
• 需要将修复部署到生产环境中。

上面列出的步骤不包括批准、代码审查、状态报告、变更管理等。然而，这仍然说明需要更多的时间和资源来发现和修复使其进入生产环境的错误，而不是在初始开发期间的单元测试中这样做。虽然这是最坏的情况，但它仍然说明了总体要点:在过程的后期识别错误是昂贵的。这还没有考虑到潜在影响产品、客户或公司品牌的相关成本。

在离开发越远的地方发现一个bug，修复它的成本就越高。由于这个原因，测试应该在项目计划期间被视为成本和风险控制工具。调整项目计划以创建测试用例作为功能和技术设计的一部分，或者与之并行，这是非常有效的，因为:

1. 它确保预先完成适当的测试用例创建。在这样做的过程中，如果/当项目处于压力之下，它会阻止善意的决策者在项目后期减少或切断测试用例的创建。我们构建这个项目是为了保护我们自己。
2. 创建测试用例的过程通常强调最终解决方案对最终用户的外观。通过创建测试用例并在开发之前与涉众和最终用户一起审查它们的过程，提供了在编码开始之前识别错误沟通和差距的机会，从而减少了重新工作的风险。
3. 测试用例为开发人员提供了额外的上下文，以增强和澄清设计。这有助于确保开发人员清楚地了解解决方案应该是什么样子，从而减少了首先引入错误的可能性。完全避免bug可以节省大量的时间和成本。特别是与创建测试用例的最小时间投资相比;测试用例很可能在项目后期创建。
4. 开发人员现在有了一个健壮的测试脚本，可以在执行单元测试时遵循，它应该与最终的验证测试脚本紧密匹配。查找和修复bug最便宜的地方是在单元测试期间，因此为开发人员提供额外的工具来提高预先检测率是非常有价值的。

虽然在开发之前要求创建测试用例的这种小转变在表面上看起来微不足道，但在实践中，它可以对项目产生深远的积极影响。

您还发现了哪些与测试相关的技巧和技巧来帮助在项目早期检测bug并降低总体成本?

这篇文章的作者是Jason Sampers。Jason是Maverick Technologies的应用程序架构师，Maverick Technologies是领先的自动化解决方案提供商，为流程工业提供工业自动化、战略制造和企业集成服务。Maverick在广泛的领域提供专业知识和咨询，包括工业自动化控制、分布式控制系统、制造执行系统、运营战略、业务流程优化等。

Maverick Technologies是一家相2016年6月28日的会员。

您是否具有本内容中提到的主题的经验和专业知识?您应该考虑为我们的CFE媒体编辑团队做出贡献，并获得您和您的公司应得的认可。点击在这里开始这个过程。