最近我多次被问及自动化测试中
验证
和
验证
之间的区别，以及关于应用和记录每种测试的一些建议。首先让我花点时间来定义这些术语。
验证与验证
验证是测试您的产品是否符合您编写的规格/要求。 “我有没有按照我说的去做？”
验证测试您如何很好地解决导致您编写这些需求的业务需求。有时也称为验收或业务测试。 “我建造了我需要的东西吗？”
V&V 共同确保您的软件以无错误（理想情况下）的方式实现其目的。
在您的工作流程中使用 V&V
在更传统的瀑布流程中，在开始时定义了规范和要求，通常在测试周期结束时执行验证。您花费大量时间定义和构建产品，确保您的软件没有错误，然后进行用户验收测试，或将其提交给客户/用户，甚至可能是 Beta 版本。
在 敏捷开发过程 中，理想情况下验证和确认活动尽可能同时发生。这是因为你总是在更新和完善你的用户故事，需要不断的小 V&V 循环来实现这种持续的反馈。
产品负责人的部分职责是在冲刺之前定义功能应该是什么样子，在开发过程中征求任何需要的客户反馈，并在必要时代表用户发言。因此，验证部分落在 PO 上，但也融入到您的敏捷过程本身中。因为理想情况下，您使用的是短期开发迭代以及来自用户/客户的持续反馈，所以实际上您几乎是在练习持续验证。
将敏捷验证和验证应用于某些行业可能有点令人生畏。我什至听过人们错误地说“由于 X 法规，我的行业无法以敏捷方式进行测试”之类的话。例如，在医疗设备中，您需要确保遵守 FDA 法规/指南，例如 21 CFR 第 11 部分和 ISO 13485，这些法规/指南更加注重验证要求，并且更加注重风险和文档。验证活动相当简单，通常通过自动化完成。验证可能更棘手。
我知道几个医疗设备或其他受监管团队所做的一件事是 探索性或会话测试 ；这可能是一个很棒的工具，尤其是对于混合软件/硬件设备。结构和文档是 FDA 看待测试的固有方式，但结构并不意味着它必须预先编写。
以类似于以下的格式在一张纸上给您的测试员分配任务：
“与 ______ 一起探索 ________ 以发现 ________”
一个例子可能是：“如果输入信息是直观的，
探索
药品库存控制
与
各种产品
来发现
。”
或者更好的是让他们自己想出一堆这样的东西来找点乐子。这可以作为一种发现未成文需求中的缺陷的方法以及作为一种测试用户体验的方法。如果您使用上述结构，本质上是一个测试章程，记录您的步骤和结果，并且您还生成了文档化的验证测试！
本文最初出现在 Jeffrey Martin 的 SmartBear 博客 上。
