分布式系统测试的难点与分析

1、分布式系统测试的难点与分析分布式系统测试的难点与分析分布式系统具有软硬件平台分布性、高稳定性、高可用性、 高可扩展性、高可管理性、高并发性及数据一致性等多种特 性。正是由于这些重要的特性，使得分布式系统的测试过程 变得相对复杂和困难。本文主要从分布式系统测试的四个重 要方面出发，探讨分布式系统测试过程中存在的一些难点问 题并进行适当的分析。分布式系统测试环境 一般来说，分布式系统是由一组服务器或者网络设备组成 （如图 1）。我们在部署测试环境的时候， 所涉及的系统架构 也会是比较复杂的，有以下几个方面：网络架构。在图 1 中，我们应该如何在本地测试实验室环境 中模拟分别位于北京和纽约的两个数据

2、中心呢？由于地理 原因，北京和纽约之间网络的 RTT （ Round Trip Time ）至少 不会低于某个值。所以，在正式进行测试之前，我们需要构 建出测试所需要的网络环境，模拟出这样的固定网络延时。 硬件要求。例如，我们曾经测试过一个分布式的文件系统， 数据服务器要求运行在裸盘设备上（数据的存储格式、寻址 方式自定义以提高查找速度） ，所以，在安装操作系统时需要特别考虑这样的需求。同时，在测试前，我们需要按照系 统设计的要求采购硬件设备。例如，硬盘的规格（ SATA 硬 盘还是 SAS 硬盘）、内存的规格等。 配置复杂。分布式系统涉及的软硬件平台较多，整个系统中 需要设置的参数项非常多，

3、系统配置过程会相应地变得复 杂、困难和易错。例如，在图 1 中，我们需要配置的系统配 置文件至少有十多个。图 1 一个典型的分布式系统 如果条件允许的话，分布式系统的测试环境应该由测试工程 师自己来搭建。系统管理员、网络管理员等都没有办法完全 代替测试工程师来进行这些工作，因为他们并不清楚在实际 的测试过程中，测试工程师对软硬件环境的具体需求是什 么，尤其是不同的测试用例对于环境的要求可能是不一样 的。分布式系统功能测试 在测试执行过程中，对测试结果的分析是一个需要进行深入 思考的重点问题。分布式系统测试的重点在于对后端服务器 集群的测试， 而判定系统中是否存在 Bug 则是我们需要解决 的重

4、要问题。那么应该如何确定是否存在 Bug 呢？ 对于测试结果的分析，我们通常观察下面几种情况。观察前端应用的返回结果。这里需要分两种情况来考虑：第 一，按照前端应用业务功能点及流程进行操作，观察返回结 果是否符合业务方的需求预期； 第二，操作后端的服务器 （通 常是重启、宕机、断网等操作） ，观察前端应用的返回结果 是否符合系统的设计需求。分析服务器日志。在功能测试过程中，当我们在启动服务器 的时候，需要将日志级别定义为 Debug 级别（最低级别） 。 这样做的主要目的是为了能便于测试工程师来分析日志和 定位问题。为了能更好地定位问题，常常需要在服务器程序 代码中进行日志打桩，把程序中的一些

5、重要数据通过日志的 方式展现出来。通常情况下，我们需要对日志的格式进行约 定，在日志行中增加一些关键字来进行分类，这将便于测试 工程师进行日志分析，也有利于开展分布式系统的自动化测 试。另外，值得注意的是，我们尽可能地将打桩代码放在 Debug 代码中，避免影响系统代码，引入新问题。 分析操作系统的一些重要信息。我们测试的分布式系统绝大 多数是基于 Linux 操作系统开发的，在测试的过程中，除了 详细分析程序日志以外，还需要对操作系统的一些重要数据 信息进行分析，从而来诊断服务器程序是否存在异常。以 Linux 操作系统为例， 我们常常会使用 top 命令、 netstat 命令 及 sar

6、 命令来查看操作系统的一些数据信息。例如，可以通 过 netstat 命令检查服务器程序是否正确地监听了指定的端口XT o借助其他分析工具。例如，如何判断服务器程序是否产生了 内存泄漏？通常需要借助于内存检测工具来进行分析。在 Linux 环境下，我们常用 Valgrind 来进行内存检测。这是一 款非常好用、功能强大的分析工具（官方网站： / ），可以帮助测试或者开发工程师快速 发现很多隐藏的程序 Bug，尤其是在内存检测方面（同时它 还具有很多其他优秀的功能，读者可以自己查看官网中的使 用手册）。分布式系统压力测试与性能测试 对于分布式系统而言，

7、压力测试和性能测试非常重要。在进 行压力测试和性能测试的时候，可能会碰到下面一些难点。数据准备。如何准备海量的测试数据并保证模拟数据的真实 性？以一个分布式的文件系统为例， 预先存入 100GB 的数据 还是存入 100TB 的数据、存入的文件是大小基本一致差别不 大还是各不相同甚至差异很大（例如，从几十字节至几十兆 字节不等），这些因素对于分布式系统的性能影响是有很大 差异的。另外，如果需要预先存入 100TB 的数据，若按每秒 写入1OOMB数据来计算，写入 1OOTB数据需要100 X 1024 X 1024/100=1048576秒=291.27小时=12天。我们是否能忍 受这么长时间

8、的数据准备工作？为了解决这样的问题，我们 需要对系统架构设计进行深入分析，设计好测试场景，并提 前进行测试用例的设计，以尽早开始准备测试数据。 性能或压力测试工具。通常来说，分布式系统的测试需要开 发一些测试工具来满足性能测试的需求。如果可以的话，建 议这样的测试工具最好由测试工程师自己来实现，因为测试 工程师更清楚自己的测试需求。当需要自己开发测试工具的 时候，有两个关键问题需要重点关注：第一，一些关键数据 的收集方式与计算将成为性能测试工具的关键，例如， TPS（每秒请求数）、Throughput （吞吐量）计算的准确性；第二， 要保证性能测试工具的性能，如果工具本身的性能不好，将 无法给

9、予分布式系统足够强大的压力来进行测试。另外，当 考虑到多并发（例如有 10 万客户端同时并发连接）时，如 果性能测试工具在一台测试机器上只能运行50 个或者更少的话，那么需要的测试机器数量也将会很庞大（例如 2000 台测试机），这个成本或许是许多公司不能承受的。因此， 性能测试工具本身的性能必须要足够好才能满足需求、降低 测试成本。分布式系统自动化测试 自动化测试是测试行业发展的必然趋势，对于分布式系统测 试而言也不例外。在实施分布式系统自动化测试的过程中， 我们可能会碰到下面两个难点问题。涉及平台多且硬件杂，测试流程控制困难。在实施自动化测 试的过程中，测试脚本需要控制的操作系统和应用程序

10、很 多，而且存在跨平台的特性，同时还有可能需要控制一些网 络设备。因此，选择一个优秀的自动化测试框架成为了非常 重要的工作之一。以我们的实践经验来看， STAF 是一个不 错的选择（官方网站： / ），它的平台 （ Windows 及 Linux 各版本）支持及开发语言的支持都很全 面。测试结果验证复杂。对于分布式系统的自动化测试来说，我 们需要通过测试脚本来收集各种测试结果数据以验证测试 结果的正确性。在实施自动化测试的过程中，我们可以将测 试结果数据收集部分模块化，通过各子模块来检测各项数据 是否正确。例如，我们会设计一个日志分析模块，主要负责 从服务器应用程序的日志中收集相应数据进行对比验证（本 文前面提到的在打桩日志中增加关键字部分就显得格外重 要）。随着互联网的发展，大型分布式系统也越来越多、越来越复杂、越来越重要。