业务需求与系统功能，你分清楚了吗？
读完需要
9分钟速读仅需 3 分钟
场景 01
小贾：“Story 上的 AC（验收标准）可以直接作为 Test Case（测试用例），就不用再详细写 Story 相关的 Case 了。”
小易：“AC 不能写成 Test Case 那样的，AC 肯定不能作为 Case。”
小贾：“为啥啊？AC 写得详细点，不就可以作为 Case 了吗？”
小易：“AC 跟 Case 是两码事，AC 是从业务视角出发的验收标准，而 Case 是用来验证系统功能的。”
听到这里，是不是觉得有点意思？你赞同哪个观点呢？别急，咱们接着往下看。
场景 02
“你们的测试用例全部都是系统的操作步骤哈，那怎么知道相关的业务需求实现了呢？”看到那一条条格式整齐的测试用例，清一色描述的是系统的操作步骤，不禁产生这样的疑惑。
“我们这些测试用例就是根据业务需求文档来写的，需求文档上也是这样描写的系统操作步骤。” 测试人员如是说。
好吧，我理解需求、开发和测试都已经习惯了这样的方式，那么，真的没有问题吗？我们来听听 PM 怎么说：“大家对业务上下文理解不清晰，都只知道系统如何操作、提供了哪些功能，包括测试人员，测完了系统功能正常，但是他们可能都不知道自己测试的功能关联到什么业务，也不知道业务需求是不是满足了。”
不知道你平常的测试用例是怎么写的呢？有没有同样的问题？
场景 03
小艾：“新来的那位资深 QA 同学技术很不错，感觉对业务理解还是不够，想要他讲一下 XX Feature（特性）的业务，结果他一上来就打开系统，给我们演示具体的操作流程……”
小贝：“嗯，我也发现了，还是好多人只会关心系统功能，不能很好的理解业务的，这样的话很难判断业务优先级，让测试帮助优化业务价值 了。”
是啊！系统操作看得见摸得着，理解起来简单多了，要真正理解业务及其价值，可不是件容易的事情。我之前有撰文写过这方面的内容，欢迎参考：
1
业务需求与系统功能是一回事吗？
场景 03里的那位同学其实并没有很好的区分出业务需求和系统功能，所以才会把系统功能当业务来介绍。那么，业务需求和系统功能的区别和联系分别是什么呢？
系统功能不是业务需求
我们先来看一个例子，下面这个是业务需求吗？
“在截止日期前 5 天系统自动发送 Email 提醒用户填写问卷”
可能有同学会说，是的啊，这就是业务需求，是业务人员这么说的。可是，事实上，这不是业务需求，真实的业务需求应该是：
“需要在截止日期到来前提醒用户填写问卷，以免错过填写，没法进入下一个环节。”
而实现这个业务需求，也就是提醒用户，可以有多种方式，可以是：跑过去告诉用户、打电话通知、发送纸质信件、发送电子邮件、发送微信等即时消息、发送系统通知……
因此，系统功能，包括系统操作步骤、页面跳转这些，只是描述系统工作的方式，是业务需求在系统中的一种实现方式（HOW），并不是真正的业务需求（WHAT）。
什么是业务需求
从前面的例子可以看出，业务需求不是系统必须做的事情，而是业务需要做的事情。业务需求是业务流程和功能的组合，可能是：
一个必须要执行的流程
执行该流程需要的数据
控制该流程和数据的业务规则
保险业务是比较典型的能够体现上述元素的业务，我们以保险业务为例说明。下图所示为寿险业务流程，投保的相关信息都属于流程需要的数据，包括不同的险种以及投保人身份信息等等，而相应的保险规则就是业务规则。
图片来自：https://wenku.baidu.com/view/82d269fcaef8941ea76e05dc?pcf=2&bfetype=new
常见的业务例子有：公司管理、策略、财务、市场、采购、设计、研发、IT、客户服务、HR、生产、质量管理、运营等。
业务需求相对来说发生变化的频率比较低，而系统功能可能会在不断的优化过程中发生比较大的变化。
2
测试只需要验证系统功能吗？
系统功能是业务在系统的实现方式，系统功能工作的正确性必然是需要验证的。这部分主要包括合法输入能够得到正确的输出、页面流转方式正确、各个 UI 组件工作正常、以及系统对于异常情况的处理等。
但是，仅仅验证系统功能就够了吗？
我们来回顾前面的场景 02，这是真实发生了的对话。
业务需求文档里描述的内容只有简单一两句话带过业务，其他的 99%都是描述的系统操作，包括页面布局、系统菜单、页面流转等非常具体的操作流程，开发和测试都是基于这样的需求文档，一般都会忽略那仅占 1%的业务描述，主要关注的都是操作部分。因此，才会有领导的担忧：测试人员测试完成，甚至不知道业务是不是正确的……而业务分析、开发和测试人员都已经习惯了这种方式，他们不会觉得有什么问题。
这样听起来还是挺可怕的，我们再利用保险那个比较典型的例子来看问题所在，下图是前面提到的保单承保的详细流程：
图片来自：https://wenku.baidu.com/view/82d269fcaef8941ea76e05dc?pcf=2&bfetype=new
从图中可以看到，“保单录入”到“保单打印”这部分可能是在系统完成的，也就是系统提供相应的功能。如果我们测试的时候只是关注系统能够完成这些操作，而不根据险种、投保人信息去判断相应的业务是否正确的话，肯定是有问题的，有可能会导致不符合条件的人还能投保成功！如果是理赔相关业务，可能最终赔付的金额都是错的，但是没人知道……
因此，测试除了保障系统工作的正确性，还需要基于真实的业务验证业务需求的满足情况。
3
测试用例需要体现业务吗？
回顾场景 01的争论：验收标准是否可以作为测试用例，引申出一个问题：测试用例需要体现业务吗？
业务需求需要验证，也正因为如此，我们会强调要理解业务、以业务价值驱动测试。因此，作为测试参考的测试用例，无疑也是需要体现业务的。
那么，测试用例该如何设计？如何做到体现业务呢？
刘冉老师的《测试用例编写和管理》一文对测试用例的编写和管理做了非常详细的介绍，其中提到了用领域特定语言（DSL）编写测试用例，我特别认可。
测试用例需要体现业务，测试用例应该是基于行为的、用业务语言表述的方式编写，不一定需要涉及具体的系统操作。
继续以保险业务为例，下面是一组关于新案件理赔时将案件录入系统的测试用例：
| 测试用例集 |
|---|
| 01. 新案件录入时，如果事故人不存在，检索无返回 |
| 02. 新案件录入时用事故者信息检索事故人 |
| 03. 新案件录入时用保单号检索事故人 |
| 04. 案件信息录入页面：责任为医疗费用和医疗津贴时，入院日期、出院日期、住院天数为必填项 |
| 05. 案件信息录入页面：责任为重大疾病时，首次确诊时间为必填项 |
可以看出这是一组非常具体的操作相关的用例，这些操作如果发生变化，相应的用例维护成本将是很高的，而且，很难从用例本身看出真实的业务。
如果我们把测试用例描述为：
当有新案件发生时，运营工作人员可以根据<保单信息>找得到相应的事故人，并且能够将<必须录入的案件信息>成功录入系统。
实例：
保单信息：事故人信息或保单号
必须录入的案件信息：责任为医疗费用和医疗津贴时，有入院日期、出院日期、住院天数；责任为重大疾病时，有首次确诊时间
这个用例里边并没有提到具体的页面，是相对抽象的业务逻辑描述。这是一种用领域特定语言（DSL）描述的方式，其中的实例部分可以理解为测试数据集，是可以跟用例中的业务逻辑部分分开的。
这种形式让人感觉更直观更清晰，总结起来有两个方面的好处：
业务逻辑跟数据分开，也不涉及具体的页面和操作步骤，增加了用例的可维护性；
用例体现了业务，能够通过用例更好的传递业务信息，测试人员采用这种用例设计方式，也能更好的理解真实的业务，做到将测试跟业务关联起来。
再回到场景 01，我们不难明白写的好的验收标准是完全可以作为测试用例的，而且比一般基于系统操作编写的测试用例更有优势，更值得提倡。
4
写在最后
系统功能不是业务需求，只是业务需求在系统中的一种实现方式，清晰理解业务需求至关重要。
测试不仅要验证系统功能的正确性，验证业务需求的满足情况更为关键，直接涉及到系统的实现是否有价值。
业务价值驱动测试做起来不容易，让我们从最基本的测试用例设计开始，改变以往的用例设计方式，通过用例传递业务价值。