查看原文
其他

业务需求与系统功能,你分清楚了吗?

林冰玉 BY林子 2022-03-17

读完需要

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)描述的方式,其中的实例部分可以理解为测试数据集,是可以跟用例中的业务逻辑部分分开的。

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

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

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

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

4


   

写在最后

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

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

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


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存