青岛设计网站的公司专业的餐饮加盟网站建设

一、主要内容

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）系统测试

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

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