本文主要是介绍TCon 2012之分布式系统测试实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
转自：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本身更重要，这对系统的健壮性和系统的自我调节和报警能力提出了更高的要求。
这篇关于TCon 2012之分布式系统测试实践的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
