其他分享
首页 > 其他分享> > 如何测试复杂的逻辑

如何测试复杂的逻辑

作者:互联网

业务的规则和验证占据了客户提供的需求的很大一部分。当我们观察这些需求是如何通过业务分析师或客户来表达和传达给整个项目团队的时候,我们就会知道大多数这样的业务规则和逻辑是以一个逻辑程序流程图来表达的。

复杂需求的逻辑程序流程图由许多分支、节点和决策框组成。希望测试人员能够覆盖所有这些分支,触及这样一个复杂逻辑树的每一个角落。面对过如此复杂的业务流程,并尝试过许多测试用例/测试场景准备技术,以简化流程。

最后,发现决策表测试技术在这方面非常有用。以下是决策表技术如何使复杂业务逻辑的测试场景准备更加容易。

使用决策表技术为登录屏幕编写测试用例:

举个例子, 让我们来看一个决策表的例子,登录屏幕的业务需求。

要做的第一步是命名所有的分支,然后用下面的数字或字母表离开。

123是leaf a b & c 是branch

注意策略

使用决策表技术的优点


但是也有局限性

某些测试用例准备技术,如边界值分析,等价类划分不能直接适用于此模板。但是,可以在组合列中记下它,并在编写测试用例时使用它们

在解释为什么其他测试用例编写技术不能像决策表那样保证准确性之前,我想快速地提醒其他黑盒和白盒测试用例编写技术。

其他测试用例设计技术


对于为业务逻辑编写测试用例,最好遵循以下步骤准备测试用例,以确保最大的测试覆盖率:


涉及大量的if和else逻辑测试

比如处理一个问卷调查类的测试, SPSS 和交叉分析,有各种逻辑判断。这里举一个处理客户订单的订单处理系统

单元测试来测试这样的服务基本上就是一场噩梦。必须模拟所有依赖项,其中 mocking 依赖于通过该方法的流以及在特定情况下应用的不同业务规则。在一定数量的模拟和代码路径,你的头脑将爆炸的。

寻找的是一种重新组织方法的方法,它允许更容易地测试方法,而不必考虑所有的依赖关系,同时仍然保持代码的可维护性,并且不会将其分散到一千个不同的地方,在那里再也不能遵循逻辑。我认为这可能需要一些权衡。

目前想到的解决方法就是,设计一个小的组件,以便多个组件可以协作。每个组件都将是小的、有凝聚力的和重点突出的

建议使用过滤器链。过滤器链是按顺序执行的处理器链表,链中的每个环节可以选择保留执行,或者可以调整通过过滤器链传递的消息

拦截过滤器模式(Intercepting Filter Pattern)用于对应用程序的请求或响应做一些预处理/后处理。定义过滤器,并在把请求传给实际目标应用程序之前应用在请求上过滤器可以做认证/授权/记录日志,或者跟踪请求,然后把请求传给相应的处理程序。以下是这种设计模式的实体。

每个组件只有一对依赖项,可以在组合根上创建链。

这种设计允许使用一个或两个模拟对管道的每个部分进行单元测试。你有一个可伸缩和灵活的设计,以满足你不断增长的需求,增加更多的逻辑,以订单布局。处理链中的每一步都很小而且紧密。组件的命名指示了责任,并且容易为其他人导航。


readmore

https://www.tutorialspoint.com/design_pattern/intercepting_filter_pattern.htm
https://blog.csdn.net/LU_ZHAO/article/details/105237117
https://en.wikipedia.org/wiki/Intercepting_filter_pattern
https://softwareengineering.stackexchange.com/questions/355423/how-to-make-complex-business-logic-with-lots-of-dependencies-better-testable

https://www.softwaretestinghelp.com/decision-table-test-case-design-technique/

github博客
微信公众号:chasays, 欢迎关注一起吹牛逼,也可以加微信号「xxd_0225」互吹。

标签:逻辑,决策表,复杂,技术,测试用例,测试,过滤器
来源: https://www.cnblogs.com/ievjai/p/14381885.html