测试工具和测试自动化

人类的进化史和发展史，就是一个不断创造和使用工具的历史。工具是人类想象力的物理呈现，也是社会进步的巨大助力。对于测试而言，工具同样不可或缺，甚至于如果想判断某个厂商的测试水平是处于"蛮荒时代"还是已经进化到了"现代社会"，观察其使用的测试工具就能知道个大概。事实上，很多测试项目，尤其是性能和稳定性测试项目，必须借助测试工具才能完成；验证业务的大规模部署能力，没有工具的支撑更是不可想象。举个简单例子，对一个可以同时接入4000个PPPoE的设备进行测试，如果没有测试工具，就只能搭建一个4000个客户端的环境，这在实践中几乎不可实施，更何况类似测试项目会很多，而且每个版本都需要重复测试。

一、测试工具

伴随着网络技术的爆发式发展，种类繁多的测试工具也被开发出来，根据其主要功能，大致可以分为下面几类*（*注：现在的测试工具都比较复杂，不一定能完全严格分类，比如Chariot和Avalanche都能提供强大的流量产生功能，又是很好的业务模拟工具）。

流量发生工具：主要用于生成大规模网络流量，测试设备的转发平面功能。这类工具有的是直接安装在主机上的软件，如Chariot；也有的是专用硬件，比如Spirent和IXIA等专业厂商提供的测试仪器；

协议仿真工具：主要对信令协议进行仿真，测试设备的控制平面功能。比如路由协议仿真，MPLS相关协议仿真，认证接入协议仿真等测试工具；

业务模拟工具：主要是对应用层协议和客户业务进行模拟，测试设备的应用和业务承载能力。一般的L4-L7的测试仪器和工具都提供了强大的业务模拟能力，比如Avalanche，BPS等测试仪器和Chariot软件；

攻击类工具：包括黑客工具、Fuzzing和Vulnerability类测试工具，测试设备的安全性和攻击防范能力。典型的有Mu Dynamics、Codenomicon、BIFFIT、SAINT、NESSUS、nMAP以及SYN flood等DDOS工具；

平台类工具：一般提供的是一个二次开发平台，有完善的集成开发环境，支持多种适合用于测试的高级计算机语言（如Perl、TCL、Python等），可进行复杂的二次开发，集成了为适应测试而封装和抽象的Lib库，甚至提供一些已经经过实践检验的自动化测试套件，并且可以通过外部接口调用其它测试仪器和工具。类似微软的Visual Studio开发环境，只不过它是为开发服务，前者是为测试服务。平台类工具投入巨大，主要为了满足厂商建设自己独特的测试能力体系的需要，一般由厂商自行开发与维护。H3C构建了这类平台，称为通用测试平台（VTP，Versatile Test Platform）。

一般来说，对于成熟的协议或应用测试，都有优秀的商业测试仪器和测试工具，可以满足80%以上的测试需求。但对于最新的协议和应用，或者特定客户的非标准定制需求，就要求厂商具备一定的测试工具自主开发能力。以H3C为例，在802.1x协议刚开始在国内应用时，在大量用户同时接入设备的条件下，设备会较大概率出现软件崩溃。于是，测试团队自行开发出一个模拟大量802.1x用户接入的工具，最终很快就发现并解决了问题，而具备类似功能的商业802.1x测试工具，大约时隔两年后才在市场上出现。

H3C对于测试仪器和测试工具在优化测试效率、提高测试水平、提升产品质量方面的重要性深有体会。在这方面的投入很大。一方面，大量采购了业界先进的商业测试仪器和工具，如Spirent、IXIA、BPS和Veriwave等公司的测试仪器和测试软件。另一方面，通过专门的测试平台团队也独立开发了众多的测试工具和软件，为商业测试软件覆盖不到的测试需求提供支持，确保H3C能以最快的速度推出最新特性。该团队开发的测试工具目前已经形成系列并成为测试工程师的重要助力，如多客户端模拟系列工具，路由协议系列测试工具，一致性系列测试工具，综合业务模拟系列工具等。该团队开发的通用测试平台则构建了一个公司级的自动化测试框架，提供了完善的GUI，CLI自动化测试解决方案，为H3C的全系列产品测试提供服务。

二、测试自动化

测试工具和测试自动化，两者是一对孪生兄弟。测试工具的目的就是为了代替部分繁琐的手工测试操作，或完成手工测试不可能完成的测试活动，实现一定程度的测试自动化。测试自动化的发展进化和测试工具的进步密不可分，随着测试工具的进步和完善，很大一部分测试工作已经可以做到无人值守，实现完全意义上的自动化。回顾自动化测试技术的发展历史，大致可以分为三代。

第一代，以工具为中心的自动化

时间：90年代中期之前

这一代自动化使用的测试工具，以捕捉/回放（Capture/Replay）工具最为典型，即捕获用户的鼠标和键盘操作，并记录下来，下次测试时可以回放这些操作，重复上次的测试。这些工具一般也提供简单的脚本功能，测试人员还可以根据需要对记录的脚本进行修改，比如增加循环操作以及一些简单的判断条件等，以强化测试。不过因为脚本语言简单，脚本功能往往只是其中的点缀。如QARun，WinRunner，就是这种工具的典型代表。这代测试自动化技术有很大的局限性：

自动化程度有限。每种工具都有自己独特的脚本语言，但又不是一个全功能的脚本语言，能自动化的操作有限，构不成一个完整的自动化解决方案，不同工具的脚本无法共享；

对SUT（System Under Test）的变化适应性较差。如果SUT的GUI有了变化，录制的脚本几乎不能再用，这在软件总是不断改进和变化的时代几乎是致命的缺陷。

第二代，以脚本为中心的自动化

时间：90年代末至21世纪初

这是自动化的个人英雄主义时代。一些测试团队在这个阶段已经认识到采用统一脚本语言的重要性，并找到了适合测试工作的、功能完备的脚本语言，在团队中大力推行。但因为经验有限，缺乏良好的顶层设计，测试自动化主要依靠测试工程师的主观能动性，八仙过海、各显神通，每个人都是脚本工程师，测试脚本大量产生。

这代自动化虽然有了统一的脚本语言，测试工程师之间也可以进行少量的脚本共享。但总体而言，是各自为战，风格不同，质量参差不齐。和个人测试环境密切关联的个人自动化成果难以充分转化为有效的团队平台积累。不过，这个阶段培养了大量的技术熟练的测试自动化工程师，为下个阶段打好了人员和技术基础。

第三代，以平台为中心的自动化

时间：21世纪初至今

在第二代自动化摸索几年后，有眼光的测试管理者和出色的测试工程师，都认识到这种野蛮生长产生的脚本在可维护性、可重用性、拓扑适应性方面都存在很大问题，不能真正形成持续有效的团队积累。于是，自动化测试的顶层设计被提上日程：构建一个出色的自动化测试平台；脚本基于逻辑拓扑进行开发，在执行时才映射到物理拓扑；把常用测试操作抽象为Action word并实现，作为通用类库供所有测试工程师使用；制定脚本的开发，验收，维护规范，保证脚本的一致性、通用性和可维护性。基于这个测试自动化平台开发的脚本，才真正可转化为有效的团队积累。

以H3C的测试自动化发展为例，在1999年之前，只是利用简单的捕捉和回放测试工具，基于这些工具编写简单的脚本，属于第一代自动化。1999-2002年期间，测试平台团队引入了适应通信设备测试的TCL语言，开发了通用测试平台，但统一的ATF（Auto Testing Framwork）尚未成熟，处于第二代自动化阶段。2003年，H3C测试团队发布了ATF，并启动Testbladev1/v2脚本体系的开发，这标志着H3C的测试自动化进入了第三代，并在实践中不断优化。基于VTP和ATF，H3C已经实现了80%以上的功能测试的自动化，并提供了多个性能测试、压力测试及持久性测试的自动化测试套件。