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

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

个测试工具: 针对配置输入生成的测试工具 CTests [22] 和 ECFuzz [80] ; 针对用户请求负载合成的工具 DUPTester [70]
和 Mocket [74] ; 针对节点间协作消息生成的工具 LOKI [75] 和 Tyr [76] ; 以及针对环境故障注入的测试工具 CrashFuzz [79]
和 Chronos [21] .
为了评估各个工具的通用性和测试效率, 我们选择了 3 个流行的开源分布式系统进行评测: 两个中心化分布
式系统 HDFS (版本 3.0.0) 和 ZooKeeper (版本 3.5.6), 以及一个去中心化分布式系统 IPFS (版本 1.0.7). 选择这些分
布式系统是因为它们在工业界被广泛使用并经过了大量测试, 同时也被大部分研究工作选为测评对象. 其中, 考虑
到测试工具 ECFuzz、CTests、CrashFuzz 和 DUPTester 在论文撰写时仅对 HDFS 和 ZooKeeper 的支持较为成熟,
因此我们在 IPFS 系统上根据工具的开源代码进行了手动适配. 考虑到 LOKI 和 Tyr 是针对去中心化分布式系统
中的拜占庭共识协议进行测试, 而 HDFS 和 ZooKeeper 不支持拜占庭容错, 我们在将 LOKI 和 Tyr 适配到 HDFS
和 ZooKeeper 上时, 去除了工具原本的拜占庭消息包生成, 仅生成符合待测系统消息规范的合法通信包.
我们在一台运行 64 位 Ubuntu 20.04 操作系统的机器上进行实验, 该机器配备了 128 个内核 (AMD EPYC
7742 处理器, 主频 2.25 GHz) 和 512 GiB 主内存. 所有测试的分布式系统都运行在 docker 容器中, 这些容器可以直
接从其官方网站下载. 为了进行定量比较, 我们为 HDFS、ZooKeeper 和 IPFS 的 docker 容器配置了 6 核 CPU、
16 GiB 内存和 480 GB 固态硬盘. 每个待测系统均启动了一个由 20 个节点组成的私有分布式网络进行测试, 节点
之间的带宽为 10 Gb/s. 所有实验的测试时间均设定为 24 h, 这是因为目前大多数动态测试工具的评估工作都采
用 24 h 作为通用的评估时间.
图 12 描述了实验的测试过程, 具体包括 4 个步骤: 测试环境准备、分布式系统构建、测试执行和结果分析.
第 1 步是环境准备, 需要准备测试工具及其依赖环境, 下载待测工具源码, 配置环境依赖, 并通过构建指令生成工
具的可执行二进制文件. 第 2 步是分布式系统构建, 用于构建分布式系统测试网络. 首先获取待测系统的最新版本
源码, 并根据构建脚本自动生成测试版本二进制及对应的覆盖率收集版本. 第 3 步是测试执行, 进行实际测试. 先
通过构建动态测试工具与待测系统的网络进行预测试. 如果预测试存在问题, 需返回前两步修改; 若预测试通过,
则执行 24 h 的持续测试. 第 4 步是结果分析, 用以统计分析各个测试工具在不同系统上的测试结果. 首先收集待
测系统的代码覆盖率数据, 这些数据帮助评估各类测试工具的有效性及代码探索程度. 除覆盖率数据外, 还重点统
计各工具挖掘出的缺陷数量. 利用工具自带的去重策略进行初步去重后, 进行人工分析, 进一步定位缺陷根本原因
并精细去重.

测试环境 启动系统 测试运行 结果分析
待测分布式 测试用例
测试工具包 系统源码 覆盖率收集
系统测试版
工具环境 本构建脚本 动态测试工具
依赖库 覆盖率插桩 输入 漏洞收集
指令脚本
待测分布式
构建脚本 系统网络 系统网络 漏洞去重
拓扑配置
构建 运行 收集
构建
待测系统网络 24 h 评估实验 代码覆盖率
动态测试工具 测试版 崩溃 系统漏洞 性能
逻辑
覆盖率收集版 ӻ࿃੐׳຋ड 漏洞 漏洞 漏洞
图 12 实验的测试过程

4.2 评估结果分析

4.2.1 工具测试表现
考虑到不同语言实现系统的代码覆盖率收集方法不一样: 对于 HDFS、ZooKeeper 等 Java 项目, 我们使用
JaCoCo [99] 工具收集覆盖率信息. 基于 JaCoCo 的代理模式, 通过 Java 的 ClassLoader 探针对 HDFS 和 ZooKeeper