为什么要理解业务流程背后的逻辑

虽然已经2023年了,但还是有技术人员认为,测试是不需要理解需求背景和设计方案,也不用参加需求评审、设计评审,只需要按照需求文档,就可以编写详细全面的测试用例,甚至很多测试也是这么认为的。也有很多纯黑盒功能测试对自己熟练掌握“业务流程”而沾沾自喜。不理解业务流程背后的逻辑,仅依靠需求文档和对业务的表面理解,真的可以做好测试工作吗。
因为测试工作是针对一系列输入,将输出结果和预期进行比较的过程。我们可以将代码当成一个函数y=f(x)。因为不知道内部实现逻辑,我们不知道这是什么函数,只能设计一系列输入,x1、x2、x3,看输出的y1、y2、y3是否和需求文档中说明的预期相同。而且由于不可能穷举所有输入,通常按照等价类边界值等方式选取有代表性的值(或组合)作为输入。
假设需求是x和y的乘积是10,我们可能会选x=1、2、1.5、2.5,测试结果确实无误。但是,代码中的设计是y=10/x,当x为0时,程序就异常了。不理解函数,你能知道x是不能为0的吗,你会刚好覆盖到这个场景吗。
你可能会说,x为0是特殊值,肯定会测试的,那假设函数为y=10/(x-1)呢,你保证一定会覆盖到这个值吗。
你可能会说,特殊情况应该在文档标明,否则就是文档疏漏。如果需求要求xy=10,只是程序设计成了y=10/x呢。
你可能又会说,那这就是需求和设计不符,开发没有按照需求实现,噢,亲爱的,你的工作就是要找出这些不一致吖,让开发100%按照需求实现,你琢磨琢磨这个可能性有多大。
于是你退一步说,那开发应该在设计文档里标明实现逻辑,或者在测试案例评审的时候跟测试提出需要增加这个情况的测试,有没有可能开发写的时候觉得这里肯定不会出问题。
你也可能会说,然后我不懂背后逻辑,但是我测试经验丰富,根据以往错误经验,经常能发现重要缺陷,看到上传图片我就能想到图片类型、图片大小限制,看到金额计算我就知道不能用float类型处理,你能确保每次都刚好选中特殊入参吗。
开发说优化了代码,让你回归一下,比如原本函数是y=√x^2,改成了y=x,这两个函数看起来相等,但是x的作用域其实不同,这并不真正是同一个函数,所以你真的不用知道开发的改动点,只是拿几个场景测一下主流程就觉得可以0 bug上线了吗。
再举一个常见的例子。借款申请提交成功页会提示该客户在我行未开卡,请联系客户经理办卡。测试同学认为,测试数据默认没有开卡,这样提示是正常的,当要执行有卡的情况的案例时,找开发同学拿测试数据,一提交果然提示已开卡,测试通过。
你有没有思考过,校验客户是否开卡的逻辑是什么,是某个服务提供了专门的查询接口,检验的要素是什么,或者是去某某库中查询的,这个库的数据是怎么来的,是业务系统自己的数据还是从基础数据导过来的,导数的逻辑是什么,会不会出现注销了的卡也当成已开卡,导数是T+0还是T+1,如果是T+1会不会有问题。当你看到页面上这个您已开卡/未开卡时,有思考过这些问题吗,还是看到页面有按照需求的不同结果展示,就认为测试充分了。
功能测试不只是根据原型图在页面上点点点,能跳转到相应的页面,返回相应的数据,出现相应的提示就是100%覆盖了。你可以不看代码,但是对你负责的系统,你需要知道业务流程、数据走向、表结构、数据类型。否则即使你测完了,发现了多少缺陷,也顺利通过了验收,测试质量也是堪忧的,只是什么时候生产问题会暴露出来而已。
这里说的业务流程,不仅是操作流程,还包括系统交互、数据流,即使你熟练掌握该系统使用流程,用户填写××提交后,系统返回××,后台生成代办事项……是个使用过的人都可以说出来,你作为系统的测试和使用者的区别是什么,核心竞争力是什么。你应该知道,用户填写的信息,提交是用的什么接口,是什么服务调用什么服务,数据是落到什么表,哪些任务是通过调度触发的。
现在我们经常听到测试质量和测试效率,测试质量不是单纯靠时间堆砌能弥补的。就拿前面的y=10/(x-1)来说,你设计了1000个xn,如果你没有刚好用x=1,显然这1000个测试案例都可以测试通过并且发现不了缺陷,但是如果你知道这个逻辑,你就可以轻松找到让系统出错的参数,而不必做无用功。
所以对测试而言,设计文档和需求文档是同等重要的,测试非常有必要参与设计评审。在设计测试用例阶段,也要多和开发沟通设计实现细节,才能设计出针对性强的测试用例,避免遗漏测试点,并且能在这个阶段通过设计方案提前发现开发的漏洞,发现系统风险是最好的了。同理,测试用例评审时,所有相关的开发也需要参与,除了补充测试用例中遗漏的重要测试场景,还可以给开发完善设计的思路。
你说,那这样不是毙掉了不懂代码的测试吗。不是的,设计不等于代码,你知道系统调用链路并不等于你需要知道代码中的每个类。
你说,测试资源受限制,没有这么多精力去理解,给测试的时间只刚好够写测试用例和执行测试,哪里有时间去搞懂实现方式。首先这并不会花费你什么额外时间,而且越是时间不够,精准测试就越重要不是吗。

你可能感兴趣的:(为什么要理解业务流程背后的逻辑)