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