Page 69 - 《软件学报》2025年第7期

2990 软件学报 2025 年第 36 卷第 7 期

待测系统的异常行为判断条件. 在测试过程中, Jepsen 会实时检测这些判断准则, 并在识别出行为异常时及时输出
缺陷报告. 图 11 展示了一个 Jepsen 的缺陷判断模型样例, ExampleChecker 定义了一个简单的检测器, 对比测试执
行前后读取的返回结果, 用于检查分布式系统的读取操作是否一致.

图 11 Jepsen 缺陷检测模型示例

Deligiannis 等人 [102] 提出的动态测试工具通过使用 P# [103] 编程语言 (一种对 C#语言的扩展) 来检测分布式系统
的关键属性. P#语言支持用户对属性进行正确性判断建模, 模型需要指定两种属性规范: (1) 安全属性规范概括了
源代码断言的概念, 安全违规是导致错误状态的有限轨迹. P#支持使用断言来指定 P#机器本地的安全属性, 还提
供了一种使用安全监视器来指定全局断言的方法. (2) 活性属性规范表示非终止性, 一个典型的活性缺陷是死循环
执行路径. 通常, 活性属性通过时间逻辑公式来指定. 基于这两种属性规范, 该工具在测试过程中实时监控模型中
指定的属性, 任何违反这两种属性的系统执行情况将被识别为系统逻辑缺陷并记录下来. 另一个类似的动态测试
框架 Frisbee [67] , 提供了一种声明性语言和相关的运行时组件, 用于在 Kubernetes 上测试分布式应用程序. 首先,
Frisbee 需要用户提供一个自定义模型, 该模型描述被测系统的关键状态机和依赖环境及其启动流程. 接着, Frisbee
会自动与 Kubernetes 容器对接, 在容器中部署必要的软件, 启动待测系统, 并根据状态机模型执行测试. 通过持续
监控系统运行状态, Frisbee 自动检查与预期行为的偏差, 从而有效地发现和报告系统中的潜在缺陷.

3.3.5 基于系统特征总结的测试准则
用户自定义判断模型面临高人力成本、长学习与建模周期, 以及缺乏通用性等挑战, 限制了其广泛应用. 鉴于
相同类型的分布式系统通常共享一些基本特征和功能目标, 可以通过归纳总结这些共性特征来构建通用测试准
则. 该方法包含两个核心步骤: 首先, 分通过分析待测系统的历史缺陷记录, 人工总结出导致缺陷的共性特征和根
本原因; 其次, 从系统的设计和架构出发, 研究设计文档、架构图及相关技术规范, 提炼系统关键属性 (如一致性、
原子性、隔离性等), 从中制定通用测试准则.
针对分布式系统升级过程中的缺陷, Zhang 等人 [70] 分析了 8 个广泛使用的分布式系统中 123 个实际升级失败
的历史报告, 详细总结了升级失败的严重性、根本原因、暴露条件及修复策略. 基于此, 他们设计并实现了缺陷判
断器 DUPTester, 用于检测跨版本的系统不兼容问题. DUPTester 主要关注两类数据不兼容问题: 一是序列化库定
义的数据, 当新版本修改消息或文件格式时, 可能导致升级失败; 二是枚举类型数据, 当升级时枚举类中增加新变
量, 导致后续变量索引变化, 进而与原版本语义不兼容. 通过检测这些数据的兼容性, DUPTester 在主流分布式系
统中累计发现了 800 多个由于升级导致的不兼容逻辑缺陷, 有效提高了系统升级的稳定性.
针对分布式网络故障的特征分析, Alquraan 等人 [104] 提出了动态测试工具 NEAT. 该工具首先进行了全面的分
布式缺陷调研, 分析了广泛使用的分布式系统中的 136 个严重系统故障, 发现其中 25 个故障是由网络分区故障引
起的, 并且这些故障大多会导致灾难性的影响, 如数据丢失、已删除数据重新出现、锁失效和系统崩溃等. 基于这
些历史缺陷报告, NEAT 确定了故障触发的执行顺序、时序和网络故障特征, 包括特定的事件执行顺序、网络隔
离的持续时间、网络延迟和数据包丢失率等. 随后, NEAT 依据这些特征构建了自动化的网络分区缺陷判定器, 大
大简化了测试流程. NEAT 在 7 个主流分布式系统上进行了评估验证, 累计发现并报告了 32 个缺陷.
针对去中心化区块链系统共识过程中的缺陷, Chen 等人 [76] 通过分析主流区块链系统 (例如以太坊、Fabric、