目录
一、主要内容
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）系统测试
-
基于规格说明书的测试技术
-
通过用于界面或系统接口来实现测试执行