第22章 事件驱动架构软件测试

目录

一、主要内容

1、事件驱动架构概述

2、质量特性

3、测试策略

二、事件驱动架构概述

1、概念

（1）事件

（2）事件通知

（3）事件驱动架构

2、事件驱动架构优点

3、事件驱动架构的缺点

4、事件驱动架构一般范式

5、事件驱动架构支持的功能

三、事件驱动架构的质量特性

1、功能性

2、可靠性

3、性能效率

4、易用性

5、信息安全

6、兼容性

7、维护性

8、可移植性

四、事件驱动架构测试策略

1、通常采用分层测试策略进行测试

（1）单元测试

（2）集成测试

（3）系统测试

2、对事件驱动架构实现的业务逻辑测试策略

（1）单元测试

（2）集成测试

（3）系统测试

---

一、主要内容

1、事件驱动架构概述

2、质量特性

3、测试策略

二、事件驱动架构概述

1、概念

（1）事件

• 指 状态的显著变化； 例如有一个超链接，将鼠标放到超链接上是一个状态，点击超链接后又是另一个状态；
• 从来源来分，事件可以分为系统内部事件和外部事件；
• 从类型来分，可以分为业务事件和系统事件。

（2）事件通知

• 是将事件通知到架构其他部分的一种特殊的消息；
• 比如说点击按钮之后，要将点击的动作传到其他部分去响应，传递点击这个动作的特殊的消息叫做事件通知。

（3）事件驱动架构

• 是指通过事件进行通信的一种软件架构，是最常用的架构范式的一种；该架构关注的是事件的产生、识别、处理和响应的情况。

2、事件驱动架构优点

• 天然为事件的发生和处理建立了模型
• 事件与事件处理逻辑、事件处理逻辑之间都得到了充分的解释
• 交互式的响应性能较好

3、事件驱动架构的缺点

• 要考虑异步通信中的常见问题
• 开发相对复杂，与事件处理相关的点也非常常见
• 同时在实践中，此类缺陷导致的失效往往比较难以复现和定位

4、事件驱动架构一般范式

• 通知：由于内外部事件引发或触发的特殊的消息被送到事件队列中
• 事件队列（event queue）：接收事件的入口，同时存储事件
• 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元。包含流式处理方式或注册发布处理方式（订阅、推送）两种实现方式。
• 事件通道（event channel）：分发器与处理器之间的联系渠道
• 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
• 对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

5、事件驱动架构支持的功能

• 事件通知的编码解码（可选）
• 事件通知的发送与接收
• 事件队列的管理与维护
• 时间的注册/注销
• 事件的优先级（可选）
• 事件与注册记录的匹配和过滤
• 时间的广播/转发
• 事件通道的创建、管理与维护（可选）
• 事件处理机制的调用方法
• 事件处理后的返回和/或后续处理（可选）

三、事件驱动架构的质量特性

1、功能性

与特定的业务领域密切相关，与架构实现关系比较小；但是如果将功能和架构完全分开，可能会导致一部分缺陷的产生，例如功能的逻辑上下文有问题，意外事件处理有问题，实时性能方面可能也存在问题

• 功能完备性
  • 基本与架构无关
  • 事件驱动架构能简化复杂交互响应的实现
• 功能正确性
  • 基本与架构无关
  • 由具体的业务逻辑实现决定
• 功能适合性
  • 与架构无关

2、可靠性

• 事件通知的编码解码
  • 测试关注点：编码解码库出现问题、编码解码缓存出现溢出；
  • 测试方法：决策表，语法分析；
• 事件通知的发送与接收
  • 测试关注点：消息的丢失、消息的重复；
  • 测试方法：场景法；
• 事件队列的管理与维护
  • 测试关注点：队列的溢出；
  • 测试方法：边界值分析法；
• 事件的注册与注销
  • 测试关注点：事件重复注册；
  • 测试方法：代码评审；
• 事件的优先级（可选）
  • 测试关注点：优先级倒挂；程序在处理时一般都是先处理高优先级的事件，但是一些高优先级的业务会依赖一些低优先级的业务，就会出现一直处理高优先级业务，但是又不能按照预期状态处理的情况；
  • 测试方法：场景法、静态分析法；
• 事件与注册记录的匹配和过滤
  • 测试关注点：对核发事件的识别有问题、转发逻辑有问题；
  • 测试方法：单元测试中加入适当的代码覆盖技术，对通知的参数可考虑等价类、决策表等相关的方法；
• 事件的广播和转发
  • 测试关注点：事件广播和转发出现异常后，所有未出现异常的逻辑都会被锁定；
  • 测试方法：静态分析进行检查；
• 事件处理后的返回/后续处理（可选）
  • 测试关注点：未定义的处理逻辑、有错误的返回代码、对处理逻辑返回错误的代码、不合逻辑功能的要求、对多个事件处理逻辑之间的依赖关系出现时效的情况；
  • 对于多个问题可采用场景法，对于单个问题可考虑静态分析或代码评审来进行测试。

3、性能效率

• 事件通知的编码解码
  • 测试关注点：编码解码库出现问题；
  • 测试方法：等价类、边界值
• 事件通知的发送与接收
  • 测试关注点：消息延迟；
  • 测试方法：边界值；
• 事件队列的管理与维护
  • 测试关注点：事件长时间得不到处理；
  • 测试方法：场景法、等价类、边界值；
• 事件的注册与注销
  • 测试关注点：注册后未删除占用了一些资源；
  • 测试方法：场景法；
• 事件的优先级（可选）
  • 常出现问题：优先级的错误设置、代码逻辑出现错误而导致事件处理不及时甚至溢出；
  • 测试方法：场景法；
• 事件与注册记录的匹配和过滤
  • 测试关注点：时间达不到要求
• 事件的广播和转发
  • 测试关注点：占用资源比较多、超过系统的缓存容量
  • 测试方法：场景法；
• 事件通道的创建、管理与维护（可选）
  • 测试方法：场景法；
• 事件处理机制的调用方法
  • 测试关注点：不能满足事件特殊性的要求；
  • 测试方法：等价类法、边界值法；
• 事件处理后的返回和/或后续处理（可选）
  • 测试关注点：返回比较慢、处理出现陡缩；
  • 测试方法：静态分析；

4、易用性

• 事件通知的编码解码
  • 测试关注点：对用户触发的事件的合法性的检查，以及出现编码规范的错误时能否返回正确的错误代码；；
  • 测试方法：静态分析；
• 事件通知的发送与接收
  • 测试关注点：对异常的数据是否未做保护；
  • 测试方法：场景法；
• 事件的注册与注销
  • 测试关注点：重复注册、未注册却收到注销请求；
  • 测试方法：场景法；

5、信息安全

• 主要针对接口进行测试
• 事件通知的发送与接受
• 事件的注册与注销（跨越不同地域、网段的子系统）

6、兼容性

• 事件通知的编码解码
  • 测试关注点：编码或解码的逻辑不一致导致的误读、解码错误；
  • 测试方法：标准化的回归测试；
• 事件通知的发送与接收
  • 测试关注点：语义不一致；
  • 测试方法：标准的回归测试；
• 事件的注册与注销
  • 测试关注点：多个子系统之间对注册注销以及它的内容格式不一致；
  • 测试方法：标准的回归测试；
• 事件的优先级（可选）
  • 测试关注点：架构系统内部和外部的优先级定义出现不一样；
  • 测试方法：场景法；
• 事件的广播和转发
  • 测试关注点：事件进行广播和转发时系统之间出现兼容性问题，在不必要的范围内进行了事件的转发；
  • 测试方法：场景法；

7、维护性

在事件驱动架构下，一般很少出现维护性问题（因为基于这种架构的软件解耦已经很充分了）

• 可测试性
  • 事件收发机制
    • 侵入代码
  • 事件队列和分发器组件
    • 提取日志
  • 事件的注册/注销
    • 插入注册模块的功能
  • 事件处理机制的调用
    • 提供相关的钩子

8、可移植性

• 在事件驱动架构下，一般很少出现可移植性问题

四、事件驱动架构测试策略

1、通常采用分层测试策略进行测试

（1）单元测试

• 各个组件
• 事件收发模块/函数
• 编解码模块/函数
• 事件队列的管理模块/函数
• 通过功能和代码进行覆盖

（2）集成测试

• 围绕核心功能来设计

（3）系统测试

• 一般不安排

2、对事件驱动架构实现的业务逻辑测试策略

（1）单元测试

• 集中在事件处理逻辑中

（2）集成测试

• 优先级机制
• 集成测试可以跳过
• 业务逻辑依赖的事件驱动架构组件未经测试，必须完成集成测试

（3）系统测试

• 基于规格说明书的测试技术

• 通过用于界面或系统接口来实现测试执行