转自：http://www.taobaotesting.com/blogs/2138

分布式系统在越来越多的公司和产品系统中应用，作为分布式系统要求高扩展，高稳定，高可靠，高可用，并且部署复杂、软件角色多、硬件依赖强，对于测试来说，分布式系统的测试面临以下难点：

n  分布式事务：多机、多角色协作，测试场景多且复杂

n  多线程：多线程场景难模拟

n  多系统：关联的外围系统多，而且又都是分布式

n  一致性要求：强一致、弱一致、最终一致

n  稳定性要求：如何保证7*24小时系统稳定

n  可用性要求：各种系统异常场景，软件、硬件因素

n  兼容性要求：多客户端服务端版本，多服务方式（REST、JavaClient）

n  性能要求：吞吐量和响应时间，软硬件因素

如何来应对这个难题，可以从如下几个方面来应对：

（1）       多层次测试保障。将测试分为不同的层次，在每个层次注重不同的测试重点。

a)         单元测试：开发人员完成，覆盖基本逻辑

b)        白盒异常测试：有针对的对各个系统异常进行代码级模拟，验证系统是否有能力处理并保持可用

c)         接口测试：保证服务的各个对外接口符合预期，基本功能验证

d)        集成测试：高压力、高并发、多种系统协作的基本功能和异常场景测试（软件、硬件异常）

e)         稳定性测试：高压力模拟常见应用和故障的混合场景，多种方式并行进行。

f)         仿真测试：建立客户应用回归环境，仿真客户使用场景

（2）       低成本测试。所谓低成本测试就是在测试过程中采取一系列的策略，降低测试成本，包括在前期参与设计方案评审和Code Review。明确不可靠模块的应用风险，核心模块的持续投入，自动化回归和多环境并行测试，并且参与线上应用情况的分析和线上故障的排查，做好bug的应对方案。

（3）       高效定位问题。从测试用例出发，确定出现bug的特定场景，根据完善的日志和监控体系来进一步分析出现问题的条件，从而能逐级缩小测试用例，从黑盒的测试用例转入白盒测试用例，另外可以利用自动化测试分析工具来进行分析。最核心的还是要对产品本身有深入的了解，产品的需求和产品的实现都要理解。

（4）       DST，分布式系统测试工具。

DST拥有以下的强大功能：

ü  支持编写测试用例实现多机并行测试

ü  可集成多种已有的测试工具及用例

ü  可配置的监控数据自动收集与展示

ü  日志自动分析与查看

ü  可扩展的任务执行控制功能

ü  性能、功能结果对比

ü  测试报告自动生成

DST的整体框架：

其中WebServer 主要提供了测试管理的功能，包括用例场景，实验室，集群管理和监控日志查看，和测试报告生成的功能。

测试集群完成了测试用例的分发和执行，并且通过TestCaseRunner来集成多种测试工具。

数据分析平台则主要完成监控数据和日志数据的存储和分析，并将分析结果推送给WebServer以供用户查看。

DST的页面图

除了以上几点，神秀还分享了一些在分布式系统测试中积累的一些经验：

（1）       分布式事务最难搞。需要注意的点有三个：

a)         单系统、单机出现异常不能影响事务正确性

b)        不可过分信任依赖系统

c)         系统设计时的检查更为重要，多系统异常难模拟，难考虑完整。在系统设计时的reivew更能提前发现问题，避免后续测试出现问题再排查浪费时间。

（2）       性能的小问题不容忽视。主要体现在以下几个方面：

a)         关键性能指标看不到是系统稳定性的地雷

b)        通过关注测试系统的性能表现可以快速发现线上系统隐患

c)         测试人员比开发人员对线上性能更有发言权

d)        及时的给出测试数据和改进意见是测试价值的体现

e)         关注线上性能表现可以完善测试用例，更贴近实际

（3）       GC是性能的重要因素。可以参考的点：

a)         减少GC暂停时间是优化的目标

b)        避免内存碎片对应用的影响

c)         观察线上系统GC状况避免故障（内存泄露、FullGc）

d)        Gc 日志和gc 监控帮助我们发现最合理的配置

（4）       线上最容易发现隐患，测试人员要多参与线上应用情况和线上问题的分析。

（5）       有bug也不能影响系统稳定，系统不可能没有bug，往往出了bug如何处理比bug本身更重要，这对系统的健壮性和系统的自我调节和报警能力提出了更高的要求。