业务需求与系统功能，你分清楚了吗？

本文首发于【林子的空间】

场景 01

“Story 上的 AC（验收标准）可以直接作为 Test Case（测试用例），就不用再详细写 Story 相关的 Case 了。”

“AC 不能写成 Test Case 那样的，AC 肯定不能作为 Case。”

“为啥啊？AC 写得详细点，不就可以作为 Case 了吗？”

“AC 跟 Case 是两码事，AC 是从业务视角出发的验收标准，而 Case 是用来验证系统功能的。”

听到这里，是不是觉得有点意思？你赞同哪个观点呢？别急，咱们接着往下看。

场景 02

“你们的测试用例全部都是系统的操作步骤哈，那怎么知道相关的业务需求实现了呢？”看到那一条条格式整齐的测试用例，清一色描述的是系统的操作步骤，不禁产生这样的疑惑。

“我们这些测试用例就是根据业务需求文档来写的，需求文档上也是这样描写的系统操作步骤。” 测试人员如是说。

好吧，我理解需求、开发和测试都已经习惯了这样的方式，那么，真的没有问题吗？我们来听听 PM 怎么说：“大家对业务上下文理解不清晰，都只知道系统如何操作、提供了哪些功能，包括测试人员，测完了系统功能正常，但是他们可能都不知道自己测试的功能关联到什么业务，也不知道业务需求是不是满足了。”

不知道你平常的测试用例是怎么写的呢？有没有同样的问题？

场景 03

“新来的那位资深 QA 同学技术很不错，感觉对业务理解还是不够，想要他讲一下 XX Feature（特性）的业务，结果他一上来就打开系统，给我们演示具体的操作流程……”

“嗯，我也发现了，还是好多人只会关心系统功能，不能很好的理解业务的，这样的话很难判断业务优先级，让测试帮助优化业务价值了。”

是啊！系统操作看得见摸得着，理解起来简单多了，要真正理解业务及其价值，可不是件容易的事情。我之前有撰文写过这方面的内容，欢迎参考：

《业务价值驱动的测试》

《敏捷测试如何帮助优化业务价值》

业务需求与系统功能是一回事吗？

*场景 03*里的那位同学其实并没有很好的区分出业务需求和系统功能，所以才会把系统功能当业务来介绍。那么，业务需求和系统功能的区别和联系分别是什么呢？

系统功能不是业务需求

我们先来看一个例子，下面这个是业务需求吗？

“在截止日期前 5 天系统自动发送 Email 提醒用户填写问卷”

可能有同学会说，是的啊，这就是业务需求，是业务人员这么说的。可是，事实上，这不是业务需求，真实的业务需求应该是：

“需要在截止日期到来前提醒用户填写问卷，以免错过填写，没法进入下一个环节。”

而实现这个业务需求，也就是提醒用户，可以有多种方式，可以是：跑过去告诉客户、打电话通知、发送纸质信件、发送电子邮件、发送微信等及时消息、发送系统通知……

因此，系统功能，包括系统操作步骤、页面跳转这些，只是描述系统工作的方式，是业务需求在系统中的一种实现方式（HOW），并不是真正的业务需求（WHAT）。

什么是业务需求

从前面的例子可以看出，业务需求不是系统必须做的事情，而是业务需要做的事情。业务需求是业务流程和功能的组合，可能是：

• 一个必须要执行的流程

• 执行该流程需要的数据

• 控制该流程和数据的业务规则

保险业务是比较典型的能够体现上述元素的业务，我们以保险业务为例说明。下图所示为寿险业务流程，投保的相关信息都属于流程需要的数据，包括不同的险种以及投保人身份信息等等，而相应的保险规则就是业务规则。

图片来自：https://wenku.baidu.com/view/82d269fcaef8941ea76e05dc?pcf=2&bfetype=new

常见的业务例子有：公司管理、策略、财务、市场、采购、设计、研发、IT、客户服务、HR、生产、质量管理、运营等。

业务需求相对来说发生变化的频率比较低，而系统功能可能会在不断的优化过程中发生比较大的变化。

测试只需要验证系统功能吗？

系统功能是业务在系统的实现方式，系统功能工作的正确性必然是需要验证的。这部分主要包括合法输入能够得到正确的输出、页面流转方式正确、各个 UI 组件工作正常、以及系统对于异常情况的处理等。

但是，仅仅验证系统功能就够了吗？

我们来回顾前面的*场景 02*，这是真实发生了的对话。

业务需求文档里描述的内容只有简单一两句话带过业务，其他的 99%都是描述的系统操作，包括页面布局、系统菜单、页面流转等非常具体的操作流程，开发和测试都是基于这样的需求文档，一般都会忽略那仅占 1%的业务描述，主要关注的都是操作部分。因此，才会有领导的担忧：测试人员测试完成，甚至不知道业务是不是正确的……而业务分析、开发和测试人员都已经习惯了这种方式，他们不会觉得有什么问题。

这样听起来还是挺可怕的，我们再利用保险那个比较典型的例子来看问题所在，下图是前面提到的保单承保的详细流程：

图片来自：https://wenku.baidu.com/view/82d269fcaef8941ea76e05dc?pcf=2&bfetype=new

从图中可以看到，“保单录入”到“保单打印”这部分可能是在系统完成的，也就是系统提供相应的功能。如果我们测试的时候只是关注系统能够完成这些操作，而不根据险种、投保人信息去判断相应的业务是否正确的话，肯定是有问题的，有可能会导致不符合条件的人还能投保成功！如果是理赔相关业务，可能最终赔付的金额都是错的，但是没人知道……

因此，测试除了保障系统工作的正确性，还需要基于真实的业务验证业务需求的满足情况。

测试用例需要体现业务吗？

回顾*场景 01*的争论：验收标准是否可以作为测试用例，引申出一个问题：测试用例需要体现业务吗？

业务需求需要验证，也正因为如此，我们会强调要理解业务、以业务价值驱动测试。因此，作为测试参考的测试用例，无疑也是需要体现业务的。

那么，测试用例该如何设计？如何做到体验业务呢？

刘冉老师的《测试用例编写和管理》一文对测试用例的编写和管理做了非常详细的介绍，其中提到了用领域特定语言（DSL）编写测试用例，我特别认可。

测试用例需要体现业务，测试用例应该是基于行为的、用业务语言表述的方式编写，不一定需要涉及具体的系统操作。

继续以保险业务为例，下面是一组关于新案件理赔时将案件录入系统的测试用例：

可以看出这是一组非常具体的操作相关的用例，这些操作如果发生变化，相应的用例维护成本将是很高的，而且，很难从用例本身看出真实的业务。

如果我们把测试用例描述为：

当有新案件发生时，运营工作人员可以根据<保单信息>找到到相应的事故人，并且能够将<必须录入的案件信息>成功录入系统。

实例：

• 保单信息：事故人信息或保单号

• 必须录入的案件信息：责任为医疗费用和医疗津贴时，有入院日期、出院日期、住院天数；责任为重大疾病时，有首次确诊时间

这个用例里边并没有提到具体的页面，是相对抽象的业务逻辑描述。这是一种用领域特定语言（DSL）描述的方式，其中的实例部分可以理解为测试数据集，是可以跟用例中的业务逻辑部分分开的。

这种形式让人感觉更直观更清晰，总结起来有两个方面的好处：

1. 业务逻辑跟数据分开，也不涉及具体的页面和操作步骤，增加了用例的可维护性；

2. 用例体现了业务，能够通过用例更好的传递业务信息，测试人员采用这种用例设计方式，也能更好的理解真实的业务，做到将测试跟业务关联起来。

再回到场景 01，我们不难明白写的好的验收标准是完全可以作为测试用例的，而且比一般基于系统操作编写的测试用例更有优势，更值得提倡。

写在最后

系统功能不是业务需求，只是业务需求在系统中的一种实现方式，清晰理解业务需求至关重要。

测试不仅要验证系统功能的正确性，验证业务需求的满足情况更为关键，直接涉及到系统的实现是否有价值。

业务价值驱动测试做起来不容易，让我们从最基本的测试用例设计开始，改变以往的用例设计方式，通过用例传递业务价值。

更多作者文章，欢迎关注：

林子的空间：https://www.bylinzi.com

公众号：by-linzi