实例化需求的干货都在这里了

127 2024-01-05

需求实例团队用户测试用例

本文2784字，阅读约需3分钟。

什么是实例化需求

实例化需求（Specification by Example, SBE）是一种软件开发方法，它在软件开发团队内部促进共同理解和协作，也能帮助团队与客户之间更好的沟通，确保软件的需求被清晰、完整地描述和有效地实现。该方法通过让各方参与以场景为基础的讨论来获取需求，这些场景可以被转换为可执行的测试用例并自动化运行。这种方法强调使用可执行的实例来描述需求，以便能够及时发现任何需求变更和交付问题。

实例化需求是否可替代测试用例？

实例化需求的目标并不是替代测试用例的编写，而是促进规范化的测试设计和提高测试质量和效率。

实例化需求非常重视团队和利益相关者之间的沟通和协作，它鼓励代表业务和技术的人员通过实例来定义系统需求，并将这些实例作为测试用例的基础。这些实例可以用来验证系统是否按预期工作，并用作发布前的验收标准，但这并不意味着其他测试用例就不该编写了。

除了基于实例的验收测试用例，还可以编写其他形式的测试用例，例如：

边界测试：在输入和输出的边缘条件下测试系统的行为。
异常测试：模拟非正常情况下的操作，例如用户输入无效数据或系统出现故障。
性能测试：测试系统的吞吐量、响应时间和资源利用率等性能指标，以确保系统在预期的负载下能够正常运行。

这些测试用例有助于发现和纠正系统中的缺陷，提高系统的健壮性，并确保系统能够满足用户和利益相关者的需求和期望。

如果非要把验收标准写成测试用例，我也不拦着，然而这不是实例化需求的初衷。

实例化需求应该以什么形式记录？

实例化需求通常在实践中使用Cucumber中的"feature file"描述需求，它的作用和需求文档一样，只不过“feature file”使用Gherkin语言来描述实例的场景和步骤，Gherkin语言的好处是，它接近于咱们的自然语言，可以使用用户/业务的语言进行书写；同时，因为它是有一定规则的结构化语言，可以被Cucumber自动转换为可执行的测试代码，开发人员再据此进行测试驱动开发。看到了吧，这样一来，就出现了“需求（场景）->测试代码->功能代码”这样的强联动，也就是说，这三者的一致性是通过代码强关联的。场景扮演着活文档和自动化测试的角色。

然而，实例化需求并不一定要使用"feature file"的形式来书写，它可以采用其他的文档形式来表达业务规则和需求，如表格、普通文本形式。在实例化需求方法中，关键在于通过一些实例来共享对软件系统需求的理解，以帮助团队理解、验证和共享业务需求。因此，实例化需求的关注点更多地在于如何描述业务需求，而不是选择用何种形式来描述。

用户故事中如何使用实例化需求

Mike Cohn在其著作《用户故事与敏捷方法》中提出了用户故事的“3C's”原则，即Card、Conversation和Confirmation。这三个字母分别表示用户故事的三个核心元素。

首先是Card（卡片），用户故事通常是以一张卡片的形式呈现在敏捷开发团队中。卡片简要描述了用户故事的名称、角色、活动以及计划使用场景。
接下来是Conversation（对话），这是指开发团队和利益相关者之间的对话。在对话中，开发团队和利益相关者可以讨论用户故事的具体细节和预期结果。对话有助于确定用户故事的范围和验收标准，是用户故事执行的重要过程。

实例化需求在这个阶段就体现在，使用具体的使用场景和实际例子来描述和澄清需求，而不是对要实现的软件功能泛泛而谈，从而帮助团队和业务利益相关者对需求快速达成一致，没有歧义。

最后是Confirmation（确认），指确定用户故事是否得到满足。验收测试是一种常用的确认方式，确保用户故事得到了正确、可操作且易于维护的实现。验收测试的目的是验证开发团队实现的功能是否符合利益相关者的预期和要求。

实例化需求在这个阶段就体现在，我们可以使用场景化的方式书写验收标准，并且（如前文所述）它能够帮助构建“需求（场景）->测试代码->功能代码”这一强关联，让确认落到实处。即只要利益相关者能够确认“需求（场景）”的正确性，那么自然就能够快速验证代码的正确性。

实例化需求和BDD、ATDD

BDD（Behavior-Driven Development）和ATDD（Acceptance Test-Driven Development）都是基于实例化需求的软件开发方法，可以说实例化需求是BDD和ATDD的基础，而BDD和ATDD是实例化需求的具体实践方式。同时，它们都强调团队合作、持续改进和自动化测试，目的都是帮助团队更好地理解和传达需求，开发出符合需求的高质量软件。但它们具有不同的重点和目标。

BDD强调团队协作和共同创造并执行场景，寻求对系统行为的详细描述，以确保所需的行为得到正确和一致的理解。BDD场景常常使用自然语言书写，清晰简洁的场景可以作为交流的工具，帮助团队成员进一步理解功能需求并验证实现。

ATDD侧重于定义明确的验收标准，使客户能够理解他们所期望的业务行为并验证其实现。它侧重于编写完整的、可执行的验收测试，以保证开发生产的软件符合需求。在ATDD中，与客户沟通和协作是至关重要的，以确保开发的软件符合客户需求，并且同时保证所开发的代码总是与所需的业务需求保持一致。

举例

我们可以用“开发一个电子商务网站”的例子，来说明BDD和ATDD之间的区别。

例如，当使用BDD时，团队可能会讨论以下场景：

- 当购物车中有商品时，用户应该看到总计金额。
- 当用户点击结账时，应该提示用户是否使用已保存的地址。
- 当订单被确认时，应该向用户发送一封电子邮件。

团队可能会评估每个场景的实现方式和逻辑，以确保场景得到正确的理解和验证。

当使用ATDD时，团队可能先定义以下用户故事：

- 作为使用电商网站的客户，我希望能够在我的购物车中看到总金额，以便我能够向自己的订购做出决策。
- 作为使用电商网站的客户，我希望在结账页面上选择使用已保存的地址，以便我不必重新输入我们已经知道的信息。
- 作为使用电商网站的客户，我希望在订单成功确认后收到一封电子邮件，以便我能够确认我的订单已成功提交。

然后，团队可以编写验收测试用例，以确保这些故事的实现得到正确的验证。

因此，BDD和ATDD的本质区别在于它们的重点和目标不同。BDD着重于促进团队内部协作和沟通，重视场景的共同创造和验证；而ATDD则注重与客户和利益相关者的协作和沟通，重视约束开发的范围，以便确保开发的代码能够满足客户的需求和期望。这些方法都有助于创建更具价值并维护性更高的软件。

总结

总之，实例化需求的核心就是实例，用场景化的实例在需求、开发和测试阶段发挥着它提升效率、避免歧义、促进沟通、达成一致的作用，我们不应该把实例化需求这一概念仅仅局限于某个具体的阶段，也不应该局限于某个具体的产出物，更重要的是，它是一种贯穿软件研发始终的工作方式和思维方式。我们需要因地制宜地灵活应用，具体落地的措施也要根据团队自身情况，循序渐进，持续改进！