美文网首页
为什么要理解业务流程背后的逻辑

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

作者: circle_hyy | 来源:发表于2023-10-06 14:32 被阅读0次

虽然已经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个测试案例都可以测试通过并且发现不了缺陷,但是如果你知道这个逻辑,你就可以轻松找到让系统出错的参数,而不必做无用功。
所以对测试而言,设计文档和需求文档是同等重要的,测试非常有必要参与设计评审。在设计测试用例阶段,也要多和开发沟通设计实现细节,才能设计出针对性强的测试用例,避免遗漏测试点,并且能在这个阶段通过设计方案提前发现开发的漏洞,发现系统风险是最好的了。同理,测试用例评审时,所有相关的开发也需要参与,除了补充测试用例中遗漏的重要测试场景,还可以给开发完善设计的思路。
你说,那这样不是毙掉了不懂代码的测试吗。不是的,设计不等于代码,你知道系统调用链路并不等于你需要知道代码中的每个类。
你说,测试资源受限制,没有这么多精力去理解,给测试的时间只刚好够写测试用例和执行测试,哪里有时间去搞懂实现方式。首先这并不会花费你什么额外时间,而且越是时间不够,精准测试就越重要不是吗。

相关文章

  • 2017-07-18

    理解产品背后的逻辑,基于理解然后创新

  • 《愚昧者的愚昧》

    《愚昧者的愚昧》 本书探讨的是自欺与欺骗背后的逻辑。一个人欺骗别人的动机比较好理解,但是我们为什么要欺骗自己呢?骗...

  • 理解商业背后的逻辑

    这是我每天写一篇原创文章的第1641天 无论是一个人,还是一个公司,都要有自己的“飞轮”,这样才能不断成长。 打工...

  • 《愚昧者的愚昧》

    本书探讨的是自欺与欺骗背后的逻辑。一个人欺骗别人的动机比较好理解,但是我们为什么要欺骗自己呢?骗自己有什么意义?骗...

  • 如何跟业务打交道(客户方-领导层)

    一、保持对没一个事件的逻辑思维及规则,大胆说出来 二、针对需求思考背后的逻辑,多问几个为什么?一定要先理解 三、针...

  • 当悲伤逆流成河--悼念我失去的爱

    今夜,我要悼念我死去的苟且。 是的。 和风霜雨雪相比更严苛的是语言。 语言产生不同理解。 而理解背后深层的逻辑是你...

  • 重新理解 MVP | 产品

    如何理解 MVP ?为什么投入大量资源,但我的产品项目还是会失败?你真的清楚 MVP 背后的底层逻辑么? 对于一家...

  • 2018-01-08

    -须知1.Controller层要负责业务流程的控制: 2.Service要负责业务模块的业务逻辑应用设计: 3....

  • 【原创】学习的核心

    学习的核心不是掌握技术,而是技术背后的逻辑。只有掌握了技术背后的逻辑,才不会被技术所困,才能跳出技术去理解技术、丰...

  • 产品经理应该具备哪些能力

    逻辑能力 产品经理需要把用户所有的操作情况都考虑到,业务流程要闭环,需要严谨的逻辑能力。 沟通能力 因为产品经理需...

网友评论

      本文标题:为什么要理解业务流程背后的逻辑

      本文链接:https://www.haomeiwen.com/subject/wmipbdtx.html