你好，这里是工行架构，我是任长清。

这节课是我们《工行业务架构实践》系列课程的最后一课，我们来到了业务研发中的最后一个流程环节：需求验收，也就是测试。完成了需求验收，也就完成了业务研发流程的闭环，可以将我们的产品投向市场。

谈到需求验收的设计，你很可能也有这样的困扰：怎样才能更合理、更准确地划定验收的范围？我们都知道，做需求验收会面临一个很大的挑战，那就是测试是无法穷尽的。资源的限制导致我们不可能做到把所有的功能点全部覆盖一遍，因此划定范围就特别重要。范围划得过小，可能会造成业务功能或业务场景的遗漏，无法保障需求投产的质量；范围划得过大，又会浪费了业务研发资源。

在传统的需求验收方法中，范围划定和测试设计主要都是依赖测试人员自身的经验，经验的局限性和个人的思维惯性容易导致投产风险，并且在不同的人员间会出现较大的差异，难以执行统一的标准。

一个更理想的状态是，我们希望需求验收设计在使用个人经验的同时，可以尽可能地将组织级的资产用起来，将组织级的智慧给到个人，帮助他又快又好地完成这项工作。所以今天，我来给你介绍一套基于业务架构的需求验收设计方法，既能帮助你找准测试范围，又能帮助你高质高效的设计案例。

基于业务架构的需求验收设计方法是指依据在需求设计环节引用的业务资产、业务资产关联的IT资产等内容，完善需求验收范围并设计测试案例的方法。我会和你一起分析需求验收的结构，告诉你可以怎样一步步利用资产做好验收设计，并通过我们工行的实践案例共同来看看这套方法的应用效果。相信这套方法能够解决你的困扰，帮你轻松画好测试的“小圈圈”。

需求验收设计的结构

首先我们来看看下面这张图，需求验收设计应当包含什么呢？

前面讲到，需求验收的一个很大的挑战就是测试是无法穷尽的，为了提高设计效率同时保证验收质量，我们需要通过分析和设计为测试执行做好准备工作。我们需要从无法穷尽的庞杂功能中，围绕需求变化点找出两类功能：必须要测的与紧密相关的。

每期版本需求验收需要执行的测试案例集合，通常由两部分构成：一部分是在需求中明确提及的当期版本改造内容，包括功能性需求和非功能性需求。功能性需求也就是本期需求的变化点，非功能性需求是为了实现变化点必须做的技术支撑等。这些都属于必须要测、不测不行的内容，应当紧贴需求来设计测试案例进行验证。

另一部分是基于当期版本改造内容扩大识别的测试范围，通常包括业务需求变动可能影响到的存量数据、相关业务和接口调用等情况。相关的非功能性的测试需求也会包含在内，例如安全、性能、兼容性方面的测试等。以上这些都属于与需求变化点紧密相关，很可能会受到影响的部分，应当纳入测试范围，做有针对性的验证。

我们本节课介绍的基于业务架构的需求验收设计方法为这两部分都提供了解决方案。

对于必须要测的内容，自动推送测试案例的方法能够将需求变化点直接继承到测试案例中，充分发挥业务架构从需求设计到需求验收的贯通作用。对于紧密相关的内容，提出测试关注要点并提示相关测试范围的方法能够活用业务资产与IT资产，提升业务研发效能。

需求验收设计的方法

在需求验收这一业务研发的收官环节中，组织积累的资产和前面的各个环节形成的资产都可以供我们使用。

业务研发中使用到的资产包括业务资产和IT资产两大类。其中，业务资产包括流程模型、产品模型、实体模型等业务架构资产，以及在业务与技术之间起纽带作用的业务需求书等项目研发过程资产。IT资产主要是业务架构指导下形成IT设计成果。

第一个方法，自动推送测试案例。这个方法是以标准化编写的用例为基础开展测试分析，完整覆盖所有用例，并通过分析用例的各个要素将用例内容分析映射为最小集合的测试案例，进一步补充完善后，你会得到必须在需求验收中进行验证的测试案例。具体的操作方法分为三步。

第一步，引用用例以明确测试案例的范围。用例体现的都是当期版本改造内容，可以全部应用到测试分析中，直接为我们提供需求分析必须覆盖的范围。其中，用例的业务场景以及相关的产品、客户、渠道、合作方等信息都可以直接转化为测试案例中的业务场景，用例中提及的风险关注点可以直接作为测试案例的验收风险点。

第二步，继承用例关键要素形成测试案例中的流程和规则。用例中的业务流程是从客户或内部用户的角度描述的业务发起至结束的完整的业务处理流程，也就是验收中应当覆盖的基本操作路径和流程分支。我们可以将业务流程拆分为测试案例的操作步骤，保证操作步骤的完整性。

业务规则、前置条件、错误流、页面要素图都是用例中的关键要素。其中，前置条件指的是系统在开始执行用例之前必须要满足的先决条件；错误流也就是异常处理，主要指的是潜在的阻止用例成功执行的条件。这些要素共同描述了本期的详细改造点，我们可以将它们全部转化为测试案例中的规则，明确需求验收必须验证的具体内容。

第三步，引用用例其他要素补充完善测试案例。除上面用到的关键信息外，用例中的其他信息也可以应用到测试案例中，形成有益补充。用例中的输入信息与输出信息可以映射到测试要素。用例中的后置条件和会计分录可以映射到案例中的检查项，后置条件指的是用例执行完成之后的状态，在验收测试中表现为测试结束后的验证结果。

完成上面三步后，用例已经全部映射形成了测试案例，实现了必测内容无一遗漏；用例中的关键信息也继承到了测试案例中，实现了业务需求到测试案例的无损转化。

**第二个方法，提出测试关注要点和提示相关测试范围。这个方法综合运用了业务资产以及与业务资产对接的IT设计信息，**来补充测试覆盖的业务流程集，实现对经验的补充，起到增强验收测试效果的作用。具体的操作方法分为两步：

第一步，根据IT架构变动识别测试流程的覆盖集，也就是对能识别出的关联范围整体划个大圈。我们先要获取当期版本IT架构中涉及的全部服务和程序，这里，需要获取的服务和程序包括但不限于根据用例开展的业务架构与IT架构对接结果、当期版本IT架构登记了的全部变更服务和程序、当期版本实际交付的版本实体。

对于获取到的全部IT架构，通过它们与业务架构资产的对接关系获取到当期版本涉及的全部业务架构资产，并将这些业务架构资产关联的业务场景全部纳入到当期版本的测试建议。通过IT架构到业务架构再到业务场景的关联路径，我们获得了业务流程测试应当覆盖的业务场景集，完成测试范围的“画大圈”。

第二步，根据涉及的业务架构内容识别重点测试范围，也就是在大圈的基础上再着重画小圈。根据当期版本IT架构中涉及的全部服务和程序，以及业务架构与IT架构对接结果，重点对与本期IT变动直接对接的业务场景、与这些业务场景存在流程上前后项关系或是共用了部分流程等的紧密关联业务场景等开展测试范围的识别。

相较于我们大圈中划定的业务场景，小圈中的业务场景更加可能受到本期功能变化的影响，进而引起投产风险，更需要关注和覆盖到。

依托于业务资产与IT资产的综合运用，可以实现以组织级的智慧为个人经验提供有效补充，为验收设计注入了新的思考维度与方向，在实践中可以根据资源投入做适当的排序和调整，获得对你更优的验收设计方案。

工行的实践案例

在我们工商银行内部，基于业务架构的需求验收设计方法已经应用在业务研发中，对验收设计起到了较好的辅助和补充作用。下面我将通过实践案例带你看看这个方法在实际设计过程中应用效果。

第一个案例，我们来看看这套方法在“必须要测”的内容上的应用。

以我行申请债券回售业务的一个用例为例，我们根据这一用例自动生成了一个测试案例，用例中对业务流程的描述全部转化为了案例的操作步骤，业务规则中的取值规则等细节信息根据映射规则分别转化到了案例的规则、要素、数据等字段中。如下表所示：

利用本节介绍的自动生成测试案例的方法，我们通过用例自动完成了验收设计，将需求变化点继承到了测试案例中，使得验收设计能够原原本本的、清晰且有结构地体现出本次需求改造的内容，有效提升了需求验收环节的质效。

第二个案例，我们再来看看这套方法在识别“紧密相关”的内容时的作用。

我行在对某个人贷款产品的协议签订规则进行调整时，通过综合运用资产识别范围和关注要点发现，项目实际修改的IT服务有一个不属于本期需求对应的服务范围，且这一服务关联着本次需求的上游流程，因此同样会影响到个人贷款产品协议的签订。

经过业务人员与开发人员沟通确认，这一服务与本次需求对应的服务之间存在着联动修改关系，应当在验收测试中予以关注。如果按照传统的测试设计流程，测试范围仅包括需求直接涉及的协议签订场景，我行通过本节课的方法提升验收设计，识别并补充了测试范围，有效降低了投产风险。

课程小结

讲到这里，本节课也就告一段落了。我来总结下本节课的重点内容：

• 需求验收设计包含两个部分：“必须要测”的需求提出当期改造的内容，与“紧密相关”的扩大识别的测试范围；
• 对于必须要测的内容，可以通过将需求变化点直接继承到测试案例中，充分发挥业务架构从需求设计到需求验收的贯通作用；
• 对于紧密相关的内容，可以通过综合运用业务资产与IT资产提示测试关注要点与相关测试范围，形成补充案例，提升业务研发效能。

在完成本节课的学习后，我想让你知道，这套验收设计方法不仅仅是可一步步遵循操作的操作指引，更是能够帮你拓展方向的思维方法。即使暂时受限于资产的不充足、系统的不完备等无法完整运用起来，你也可以试着用它梳理下你要验收的业务需求、审视下对应的业务场景，相信会带来不一样的设计思路。

思考题

请选取一个你实际工作中遇到的需求改造想一想，可以从哪些思考维度和方向识别相关测试范围，又有哪些资产可供你使用呢？试着写一写吧。

如果有什么问题，欢迎在评论区留言。