大规模分布式系统的测试实践.doc

大规模分布式系统的测试实践文/许呙兢,陈舟锋,郑刚飞天测试的挑战飞天开放平台基于一个核心系统,即飞天大规模分布式计算系统(简称飞天)。飞天期望把几千台PC构成一台“超级计算机”,为上层多种不同的开放服务和云应用提供通用的分布式存储、计算和任务调度等多重功能。由此可以看出,飞天具有平台化、通用性和大规模的特性,于是,飞天测试的挑战也由此而来。挑战一:平台软件的复杂性和互联网发布节奏之间的矛盾。飞天包含多个复杂的分布式模块。模块本身的复杂性乘以各模块之间的协议依赖,按照传统软件开发流程计算,发布一个质量可靠的稳定版本通常需要1~2年。这样的发布节奏远远满足不了上层开放服务和云应用快速发展的需要。挑战二:通用平台支持多种不同应用带来测试用例数的爆炸。对于飞天,不同的应用场景、不同的数据量、不同的请求压力、不同的机器规模,有可能在代码里面走的路径完全不一样,对系统的压力点也各不相同。无论是试图覆盖所有应用对飞天的所有用法,还是从设计出发遍历模块接口的各种组合,对测试用例设计而言都是不收敛的。那么,当测试用例剪枝无门,是否还有其他捷径?挑战三:对于大规模生产集群上的问题如何用小规模测试集群暴露。在阿里各地的数据中心,飞天的生产集群是上千台物理机组成的。考虑到成本,测试集群规模通常不超过生产集群的十分之一。统计数据显示,100台和1000台的分布式环境的软硬件故障率、压力瓶颈点、数据量级、网络性能都会有很大差异。常规测试方法很难在小集群上发现大规模的问题。下面,我们来谈一下飞天测试实践当前是如何应对这三种挑战的。分层测试和持续集成目前,飞天底层模块的发布节奏是半年一次,上层模块的发布则更为频繁,最短可以达到三周发布一次。这样的发布节奏主要依靠分层测试和持续集成的机制。按测试层次来分,飞天测试可以分为单元测试、功能测试、系统测试、集成测试、E2E测试(端到端测试)。为了加速飞天新版本的质量收敛,飞天团队几乎每个成员都会参与到上述测试类型中——无论是开发同学,还是测试同学。一般来说,产品只会对外部接口进行功能测试和系统测试,但由于飞天模块本身就是分布式的,每个模块都具有一个传统软件产品的复杂度,所以模块团队除了负责单元测试,也会进行功能测试和系统测试。模块团队内,开发同学除负责单元测试之外,还会承担功能测试和局部特性的系统测试,测试同学通常更专注在测试设计和模块级别的系统测试。飞天有独立于模块的集成测试团队,集成测试主要负责两块。一方面,通过持续集成的回归测试集来保证系统中的各个模块改动集成在一起能够很好地工作,一旦发现无法短期修复的质量回退的话,模块改动会被立刻关闭或回滚。为保证持续集成效果,不同层次的回归测试集都被尽可能自动化,并且定义合适的回归频率,模块改动在设计时也会考虑方便关闭或回滚。另一方面,集成测试也进行平台级别的系统测试,极尽所能地对飞天进行各种严刑拷打,考察底层模块的功能、性能和系统容量,以及在极端或典型应用场景下系统的稳定性和服务可用性。飞天新版本上线前,开放服务团队一般都会用集成测试通过的版本跑E2E测试。E2E测试的责任人需负责向应用方了解具体需求,这个需求不仅是一个对接口功能的需求,还包含了数据量的需求、机器规模的需求、吞吐率的需求、延迟时间的需求以及业务量在一天或者一周内的曲线等信息。E2E测试通常要构造近乎完整的应用场景,尽可能模拟/重