背景

根据典型的测试金字塔结构，一个产品的测试可分为三个层级。第一层是单元测试，主要对程序函数进行测试。第二层是集成测试，在百度内部是大家常理解的模块测试。第三层是系统级测试，对产品整体进行的测试。这种测试分层原理同样遵循二八定律，越往下的层级，往往用较小的测试成本，就能换取较多的功能覆盖；而越往上的层级，往往会耗用很多的时间，却发现很少量的问题，但是一旦有bug出现，问题影响面、定位成本，修复成本也是很高的。因此很多新的产品线，在系统级测试上的技术投入，是望而却步的，往往仅在最终上线前，才在接近线上的真实环境上做人工验收测试。

然而像搜索、广告这种系统架构非常复杂，质量要求又特别高的产品，就比较依赖系统级测试的手段来保证线上的稳定性，往往一个系统性能缺陷或异常分支问题，就有可能影响到上百万的流量或收入损失。因此在很多产品线系统级测试是上线不可缺失的一环。

产品创立初期系统比较简单，系统级测试往往并不会成为测试效率的瓶颈。但随着系统架构越来越复杂，对于系统级测试技术和自动化水平的要求也是与日俱增的。百度商业产品的系统级测试技术，有着超过6年的技术积累，期间也是经历了几次技术的演进。这篇文章就给大家回顾一下，这几次技术架构演进，团队是怎么样根据产品需求和公司导向不断变化而一直努力和坚持，把系统级测试技术从0分做到60分，又从60分做到90分的过程的。

演进历史

▌手工测试时代

还记得2009年之前系统只有几个模块的时候，当时的环境还是比较简单的，有两台机器就能把整个系统给部署起来，当然那时候的环境部署也是靠人手工从线上同步的。QA通过apache自带的ab工具或通过loadrunner模拟http请求，对系统进行发压，压力结束之后通过手工执行一系列stat脚本统计出模块的各种性能数据，最后编辑到word文档里，作为当时的主要一份测试报告内容。

这个时代，没有太多可讲的内容，当时百度还是普遍以传统瀑布开发流程和手工测试为主，在团队规模相对较小以及迭代效率相对很低的情况下，这种测试手段也没有遇到明显的瓶颈。

▌自动化脚本时代

2009年开始百度QA内部开始大力发展自动化。当时很容易想到了，系统级测试改进的第一站就是如何将重复的，手工执行的工作用脚本给自动化起来。因此有了后面的一键自动部署环境，一键自动发压，以及自动生成报告等功能。相比手工测试，效率上的确有了一个质的飞跃。

但同时也发现像环境搭建、压力、性能、diff等测试各种工具推出来之后，工程师学习使用和配置这些工具的成本变得很大。工具之间也有很多重复性的逻辑，比如所有工具都需要考虑模块启停控制，日志分析等功能。另外，当有项目并行时，机器协调及沟通成本就变得越来越大。

▌自动化平台时代

为解决自动化脚本泛滥之后带来的技术冗余以及测试过程管理等问题，团队从2011年开始考虑建设业务线自有的系统级测试平台。

平台设计成测试平台、环境、任务三层管理模式。测试平台是一批资源的集合，该资源可以用于部署不同场景的测试环境，每个环境上可以串行的运行多个测试任务。平台通过合理的调度，使得多人使用的时候，资源可以互斥。另外，通过可视化的配置管理，使得底层工具对用户透明，用户仅需要关注环境需求和测试场景需求本身。

为解决工具泛滥的难题，首先从工具层面定义了统一的接口规范，以及所有工具放到统一的框架中进行开发。通过将环境工具以及各种系统测试工具底层抽取了公共的lib以及环境操作lib，使得各个工具之间重复的功能得到了有效控制。另外各个工具对平台暴露统一的接口，使得平台在调度不同的工具的时候，都能用统一的逻辑。

为解决系统架构日益膨胀之后带来的资源成本的难题，平台引入环境解耦技术，将产品拆解成多个子系统，通过驱动和桩模拟系统上下游服务，使得每个子系统都能独立的进行测试，通过流量录制和回放技术，怎么样在百度上推广自己的产品使得测试效果接近真实系统。从这个方案中大家也能看到，系统拆分不是很灵活，且不同的拆分方案下，需要定制不同的下游桩来做定制回放，整套方案的管理成本也是不小的，这个也为后面可定制子系统的发展打下了很好的基础。

产品的系统级测试由此进入到工业时代。整个团队的测试模式和工具研发模式也因此平台的诞生而变得更加规范、统一。

▌测试云时代

产品线从2011年开始推行持续集成研发模式转型。在持续集成能力建设初期，也感受到了此前积累的测试自动化在此过程中发挥了更大的价值。但同时也发现，持续集成使得系统级测试的需求变得更加频繁，为了保证主干的稳定性，甚至想尝试把系统级测试前置到开发阶段来执行，这样对于系统级测试资源和执行效率的要求也变得越来越高。

考虑到平台对于资源管理的方案，还是一个个独立的私有集群，由于集群之间用户、环境和任务分布不均与，带来很大的资源浪费以及任务排队等问题。随着业界Cloud技术的发展，也给系统级测试技术优化带来了新的思路。通过将资源整合和模块混布，使得相同资源的情况下，任务的吞吐量得到了一个很好的提升。另外多个用户共同竞争剩余资源，整体的任务排队时间也有了一个很好的控制。为减小资源灵活分配带来的环境数据迁移的成本，引入hdfs/nfs做中间数据缓存，通过增量存储技术，使得环境数据可以进行快速的快照和镜像恢复。

同时，为了进一步缩减测试成本，希望系统可以解耦到任意组合。在此前子系统解耦的方案的基础上，也进行了重构。

• 录制环境从线下搭建的环境迁移到了线上旁路，模块的更新更加及时，截取的数据更加真实实时，线下仿真效果更好。

• 通过nb（百度内部使用的通用截包工具）+redis做数据回放服务，免去了此前stub的数据管理和部署成本。

• 系统可以任意定制，缺失的下游通过回放服务来补充数据，数据覆盖和测试效果可以和全系统下的表现相当。

这套方案在很长一段时间内支撑着凤巢检索系统从数10个模块发展到上百个模块，几百人研发团队的持续集成工作开展，是帮助凤巢团队成为公司第一批CI标杆团队的重要武器。同时基于业务线多年精细化的打磨，也为后面平台化的重构提供了很好的技术保障。

▌平台化时代

2014年，在公司提出的接口化、平台化的战略口号下。平台也在考虑如何将系统级测试这种技术门槛很高的技术抽象成服务，从而在其他产品线得到更广泛的使用和推广。因此平台进行了一次整体的重构，旨在通过提供一套通用的建模工具和测试组件，使得产品线构建系统级测试能力可以像搭积木一样简单、灵活。

平台提供两个通用测试组件。一个是环境搭建组件，可以支持单机、多机部署方式，物理机/虚拟机/容器等多种资源形式，和公司内的主流PAAS平台打通。另一个是系统测试组件，通过一些合理的抽象分层设计和灵活的测试场景描述能力，产品线只需要通过简单的配置，就能够支持性能、diff和压测等不同的系统级测试场景。同时框架支持开发diy插件，满足产品线定制化的场景需求。当然产品线也可以自己开发工具，只需要实现平台所定义的接口，就可以接入到平台变成服务。

平台提供了一套拓扑建模工具，产品线可以根据被测系统的部署和测试需求，构建测试拓扑。平台通过三层结构来刻画测试需求，第一层是模块，产品线可以配置模块的CPU/MEM/DISK/PORT等需求，以便平台可以调度到合适的资源，同时需要模块设置一些静态参数（如log位置、启动命令、启动线程数等）和自定义参数，使得工具和平台可以更好的理解模块的属性。这里除了被测模块，测试程序也需要进行定义，如driver/stub。第二层是子系统，也可理解是被测模块的集合，方便用户理解测试范围。第三层是拓扑模板，产品线根据测试场景驱动，绘制出测试系统的拓扑，可支持模块分组、多实例，以及支持实例间直连/混连，同时选择和配置配套的环境工具和测试工具，就能构建出一个用户可见的测试服务。

用户使用的时候就比较简单了，只需要选择拓扑模板，搭建环境，启动测试任务，即可由平台调度，最终生成测试报告了。通过平台化重构，使得开发者更加专注工具的实现逻辑，而不用资源和任务调度。用户更加关注测试需求本身，而不用考虑工具和资源细节，最终形成一个良性发展的平台生态。目前平台已经支持公司内几十个产品，每周接近1W次规模的系统级测试任务执行。

总结和未来展望

通过历史上三次大的系统级测试技术的重构，从业务线专用做到公司通用，不断将技术和用户体验做到极致，这里有很关键的三点信念。

• 与时俱进：技术的发展需要适应产品业务的发展需要，追求过度设计或者设计不足都会导致项目失败。

• 匠人精神：任何技术的成功都不可能一蹴而就，需要一点点做起，并不断在产品线进行打磨，当技术遇到瓶颈的时候，要敢于寻求突破而不是逃避。

• 开放心态：通过内部开源，扩大技术生态。没有任何通用的技术可以解决所有产品线的问题，只有通过开源让可以让大家共同参与改进，才能让产品线不会因为10%的需求不满足而放弃使用技术。

平台离一百分的目标还很遥远，微服务、容器化技术的迅速发展，使得系统的环境部署和测试变得更加复杂，同时也对测试工具和平台有着更高的标准规范。线上测试也是系统级测试场景创新的下一站，到时候也会对工具和平台提出新的要求。只要抱着十年磨一剑的信念，紧跟着公司和业务发展的步伐不断前行，相信系统级测试的技术还会迎来更多的创新和挑战。