Page 57 - 《软件学报》2025年第7期
P. 57

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


                 分布式系统的超时逻辑, Chronos      [21] 认为深层路径的超时交互逻辑很少在常规测试中被触发, 可能隐藏许多缺陷.
                 Chronos 设计了深度优先的模糊测试算法, 实时计算每个故障序列触发的超时逻辑深度, 优先变异可达深层超时
                 逻辑路径的输入, 成功在主流分布式系统中发现了                27  个新的鲁棒性缺陷.

                 2.6   针对扩展性缺陷的测试工具
                    可扩展性缺陷是指分布式系统在增加资源                (如增加节点或存储容量) 时, 无法保持或提升其性能和稳定性的
                 缺陷. 这类缺陷会影响系统在扩展过程中的表现, 限制上层分布式应用的业务扩张发展. 由于真实分布式应用通常
                 需要成百上千个分布式节点来运行, 而在测试过程中通常难以获取如此多的计算资源来模拟和测试系统的可扩展
                 性. 因此, 针对可扩展性缺陷的测试工具的主要难点在于, 如何在有限资源下, 探索有效进行大规模节点的模拟和
                 测试的方法.
                    为了解决分布式系统扩展性测试中的资源限制问题, Gupta                   等人  [53] 于  2011  年提出了  DieCast 测试工具.
                 DieCast 通过在少量物理机器上多路复用分布式节点的虚拟机                 (VM), 并精确调整    CPU、网络和磁盘资源, 使每个
                 VM  在计算资源和通信行为上都能模拟原始服务机器. 这种方法使                   DieCast 能够在较少物理资源的情况下, 有效模
                 拟原始服务的行为. 针对大规模分布式存储系统的扩展性测试挑战, 2014                      年  Wang  等人  [56] 开发了  Exalt 测试库.
                 Exalt 引入了一种创新的数据表示方式, 使得在底层存储层面上也能实现数据的有效识别和压缩, 即便这些层次不
                 理解更高层次的语义和格式. 这一技术极大地促进了分布式节点在物理资源上的高度共存, 使得在有限机器上进
                 行数以万计节点的大规模实验成为可能. 工具              ScaleCheck [62] 是一种针对大规模数据处理系统可扩展性缺陷的测试
                 工具, 它能够在单台物理机上部署并测试整个分布式系统. ScaleCheck                 利用全局事件驱动架构        (GEDA) 在单进程
                 集群中模拟分布式节点间的通信, 并通过处理幻觉                 (PIL) 技术进行非侵入式修改, 以有效管理和协调机器上数百
                 个  CPU  密集型节点的资源使用. 这使       ScaleCheck  在使用较少计算资源的情况下, 成功检测如           HDFS  和  Cassandra
                 等真实系统中的扩展性缺陷, 累计发现            10  余个严重缺陷. 类似的工具       Minha [84]  是一个专为  Java 语言实现的分布
                 式系统测试而设计的工具, 它通过在单个             JVM  中虚拟出多个     JVM  实例来模拟分布式环境. 这种设置允许每个虚
                 拟节点仿佛运行在独立的机器上, 拥有自己的网络和                 CPU  资源. 框架支持并发和分布式        JVM  字节码程序的运行,
                 可扩展至数千个虚拟节点, 并支持对整个系统的实时全局观察.

                 2.7   测试环境设置与测试器协作策略
                    在对分布式系统进行测试时, 除了关注检测目标缺陷类型外, 一些测试工具通常会关注待测分布式系统的测
                 试环境设置问题, 并使用测试器同时对接不同分布式节点, 以更精准及时地获取系统的关键状态, 提高测试效率.
                 然而, 多测试器的设计会引入分布式测试器之间的高效协作难题.
                    早在  1999  年, Ulrich  等人  [51] 提出了分布式系统动态测试架构 TMT, 该框架包含多个分布式测试组件, 用于与
                 待测系统交互并生成测试输入; 一个全局测试者则负责观察系统内部的交互, 并通过同步事件协调并行测试器. 随
                 后, Hsaini 等人  [68] 提出基于时序信息同步的分布式测试协调策略, 开发了一种生成本地定时测试序列的新算法来
                 描述每个端口的行为. 此算法有效减少了测试器间的消息交换量, 提高了测试效率. 然而, 该策略仅限于时序逻辑
                 缺陷检测, 无法支持新的缺陷检测类型. 为应对去中心化分布式系统测试中的协作难题, LOKI                           [75] 和  Tyr [76] 是点对
                 点协调通信模式的策略, 使测试节点伪装成正常服务节点, 利用现有通信机制进行测试器间协调. 此方法旨在减少
                 测试工具的适配成本并提高可扩展性, 但在通信效率上不及中心化协调模式, 尤其是在需要实时控制分布式系统
                 时. 因此, 针对精准故障注入测试, Phoenix      [78] 和 Chronos [21] 等工具采用了中心化协调者设计, 实时监控分布式节点
                 的运行状态, 并动态优化测试流程. 中心化设计能够更好地收集关键信息, 以便在整个测试过程中作出及时调整.
                 此外, 由于云原生环境下的弹性、动态资源分配和容器化等特性, 使得动态测试更加高效和灵活. 通过容器化技
                 术  (如  Docker 和  Kubernetes), 能够快速构建、协同和调整分布式测试器, 大大降低了传统静态测试环境的开销.
                 典型工具   Frisbee  [67] 、CND [85] 、ChaosBlade [86] 等是接近生产环境的测试方法  (preproduction deploys), 即在部署至生
                 产环境之前, 通过统一的容器管理接口协同不同分布式测试器, 将微服务或组件在一个仿真度非常高的测试环境
                 中运行, 模拟实际的工作负载和流量. 这种方法能够更好地捕捉分布式系统中的复杂错误, 尤其是难以在本地测试
   52   53   54   55   56   57   58   59   60   61   62