如何测试复杂的逻辑
作者:互联网
业务的规则和验证占据了客户提供的需求的很大一部分。当我们观察这些需求是如何通过业务分析师或客户来表达和传达给整个项目团队的时候,我们就会知道大多数这样的业务规则和逻辑
是以一个逻辑程序流程图来表达的。
复杂需求的逻辑程序流程图由许多分支、节点和决策框组成
。希望测试人员能够覆盖所有这些分支
,触及这样一个复杂逻辑树的每一个角落。面对过如此复杂的业务流程,并尝试过许多测试用例/测试场景准备技术,以简化流程。
最后,发现决策表测试技术
在这方面非常有用。以下是决策表技术如何使复杂业务逻辑的测试场景准备更加容易。
使用决策表技术为登录屏幕编写测试用例:
举个例子, 让我们来看一个决策表的例子,登录屏幕的业务需求。
要做的第一步是命名所有的分支,然后用下面的数字或字母表离开。
123是leaf a b & c 是branch
注意策略
- 决策框中指定的
所有验证
都应该由表中的列进行 - 流程图中提到的
所有结果
(叶子)都应该包含在决策表中 - 获得某一结果所需的
所有输入
组合都应在组合栏中提及,并且可以在编写测试用例时包括在内 - 在完成决策表之后,只需要验证逻辑树中的
所有分支和叶子
是否都被覆盖
使用决策表技术的优点
-
用
图表示的任何复杂
的业务流程都可以很容易地用这种技术覆盖 -
它提供了测试用例的信心。
不需要多次检查
自己的测试用例来获得信心 -
容易理解
。任何人都可以从这个 Decision 表模板生成测试用例 -
可以完全
避免
对测试用例和测试场景的返工
,因为它在第一次创建时提供了完整的覆盖率
但是也有局限性
某些测试用例准备技术,如
边界值分析,等价类划分不能
直接适用于此模板。但是,可以在组合列中记下它,并在编写测试用例时使用它们
在解释为什么其他测试用例编写技术不能像决策表那样保证准确性之前,我想快速地提醒其他黑盒和白盒测试用例编写技术。
其他测试用例设计技术
- 边界值分析是一种软件测试技术,测试用例的设计包括给定
范围内外
边界值的代表。 - 等价类划分也被称为等价类类划分是一种软件测试技术,它将给定的条件划分为多个分区,每个分区的一个输入数据可以被选择用于测试。
边界值分析和等价类分割是用于数值范围和长度的。这两种技术本身不能确保业务规则的100% 测试覆盖率。
- 状态转换测试是一种黑盒测试技术,它可以用来设计一个需要有限数量状态的系统的测试用例,并且在特定事件发生时可以从一个状态转换到另一个状态。
使用状态转换测试技术,我们可以确保覆盖逻辑树的所有部分,但不建议使用文档或工件,因为决策表技术可以确保覆盖决策表
- 错误猜测是一种技术,利用测试人员的经验来发现错误或应用程序中最有可能发现错误的部分。这是一种基于技能的技术,没有任何规则。
错误猜测更多的是关于经验,虽然经验是必需的,但它不能证明是一切
- 用例测试在这个技术中,用例/场景被用来编写测试用例。用例中描述了用户和系统之间的交互。
对于为业务逻辑编写测试用例,最好遵循以下步骤准备测试用例,以确保最大的测试覆盖率:
- 使用决策表测试用例设计技术来达到
100%
的逻辑覆盖率。 - 边界值分析和覆盖各种输入范围的等价类划分
- 字段级验证的组合和排列(尽管并非所有的排列都是必需的)。
- 错误猜测(除了上面三个步骤中可以识别出的错误之外) ,经验作为最后一步
涉及大量的if和else逻辑测试
比如处理一个问卷调查类的测试, SPSS 和交叉分析,有各种逻辑判断。这里举一个处理客户订单的订单处理系统
用单元测试来测试这样的服务基本上就是一场噩梦
。必须模拟所有依赖项,其中 mocking 依赖于通过该方法的流以及在特定情况下应用的不同业务规则。在一定数量的模拟和代码路径,你的头脑将爆炸的。
寻找的是一种重新组织方法的方法,它允许更容易地测试方法,而不必考虑所有的依赖关系
,同时仍然保持代码的可维护性,并且不会将其分散到一千个不同的地方,在那里再也不能遵循逻辑。我认为这可能需要一些权衡。
目前想到的解决方法就是,设计一个小的组件,以便多个组件可以协作。每个组件都将是小的、有凝聚力的和重点突出的
。
建议使用过滤器链
。过滤器链是按顺序执行的处理器链表,链中的每个环节可以选择保留执行,或者可以调整通过过滤器链传递的消息
。
拦截过滤器模式(Intercepting Filter Pattern)用于对应用程序的请求或响应做一些预处理/后处理。定义过滤器,
并在把请求传给实际目标应用程序之前应用在请求上
。过滤器可以做认证/授权/记录日志,或者跟踪请求
,然后把请求传给相应的处理程序。以下是这种设计模式的实体。
- 过滤器(Filter) - 过滤器在请求处理程序执行请求之前或之后,执行某些任务。
- 过滤器链(Filter Chain) - 过滤器链带有多个过滤器,并在 Target 上按照定义的顺序执行这些过滤器。
- Target - Target 对象是请求处理程序。
- 过滤管理器(Filter Manager) - 过滤管理器管理过滤器和过滤器链。
- 客户端(Client) - Client 是向 Target 对象发送请求的对象。
每个组件只有一对依赖项,可以在组合根上创建链。
这种设计允许使用一个或两个模拟对管道的每个部分进行单元测试。你有一个可伸缩和灵活的设计,以满足你不断增长的需求,增加更多的逻辑,以订单布局。处理链中的每一步都很小而且紧密。组件的命名指示了责任,并且容易为其他人导航。
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