我们都知道，测试从测试类型上分成白盒测试、灰盒测试、黑盒测试，分别对应于开发V模型中的单元测试、集成测试和系统测试。测试从执行手段上分成两类：手工测试和自动化测试。

业界通用的系统测试方法主要是黑盒测试，也就是搭建模拟环境，分析设计和开发出对应的用例及自动化测试脚本进行测试，包括配置、功能、性能、压力、组合、一致性、异常功能测试等。黑盒测试在保障系统基本功能方面发挥了重要的作用，但是随着测试的进一步深入，我们逐渐面临了一些新的问题，具体表现在以下几个方面：

 部分模块外在表现很少（比如路由算法模块等），通过纯黑盒测试可测试的内容不多，测试覆盖不全；

 部分测试项目内容虽然变化不大、修改不多（比如性能优化项目、底层模块内部整改项目等），但是从功能测试的角度上讲涉及的范围很广，黑盒测试投入大；

 测试结果观察手段有限，一般从用户接口（通过业务流量、表项错误、断言、DA）观察，但有时候内部模块间调用出错不一定能够马上表现出错误来，而要到后面的操作才能发现问题，从而导致定位和复现时间较长；

 异常测试的条件、特定的时序事件触发条件不方便构造。

这些问题将会导致部分模块及项目的测试效率不高，以及测试覆盖不全面。针对这些问题，H3C创新性的提出TCL嵌入式测试技术，并将其应用在Comware V7（以下简称：V7）系统的测试中。TCL嵌入式测试技术打破了黑盒测试只能从外部观察的局限性，它从系统内部直接对模块和消息进行测试，并取得了较好的实际测试效果，解决了上述的四个方面问题。

TCL (Tool Command Language)是一种解释执行的脚本语言(Scripting Language)，是业界主流自动化测试语言，修改后不需重新编译，TCL解释器直接执行。在传统的黑盒测试中，TCL也有大量应用，测试模型如图1所示.

图1 传统黑盒测试自动化模型

原有自动化测试模型，是在PC上运行自动化测试脚本，通过TCL解析器，向设备发送命令行配置、控制仪器打入流量验证等测试手段完成自动化测试。

TCL嵌入式测试是将TCL语言解释器植入Comware V7系统中，并且通过TCL扩展命令调用cOmware V7系统模块内部接口，以构成测试条件达到测试的目的。从测试类型看，它属于灰盒测试。从测试阶段看，它类似集成测试，介于单元测试和系统测试之间。从测试手段看，利用TCL语言编写测试脚本进行更为细致的模块接口功能、子模块功能测试。测试脚本开发出来后，可以用于自动化测试。

V7系统的测试在继承原有软件系统的自动化测试技术基础上，通过TCL嵌入式测试技术，把TCL解析器植入到V7系统中，并根据测试需求封装了一系列的模块接口扩展函数。开发的TCL嵌入式测试脚本可以调用命令行配置命令和扩展函数进行更为细致的功能测试，并自动获取运行结果，自动解析功能是否正常，从而实现了很多模块功能点的自动化测试，提升了V7系统的自动化测试比例。

TCL嵌入式测试技术作为一种灰盒测试技术，在V7测试实践过程中，有如下的几个典型的测试模型及应用。

模型一：模块接口测试

系统由各大组件组合而成，组件特性一般包括路由组件、MPLS组件、组播组件等（如图2 所示），其中组件又是由各大模块组成（比如路由组件一般包括OSPF模块、BGP模块等），每个模块又是由一系列的函数组合实现其功能。

通用的业务模块的测试，比如OSPF模块、BGP模块等，都有提供给用户的命令行接口，黑盒测试通过这些命令行能够去测试这些模块的功能。系统中也有些模块，比如路由管理模块（RM模块），这些模块完全是厂商自己实现的内部的模块，其对用户来说，基本上是不可见的，但是他们又是连接OSPF模块和其它模块的桥梁。这些模块之间通过模块对外提供的接口函数进行交互。也就是说，如果通过黑盒测试，将无法直接测试到RM模块，只能通过BGP模块这些有用户接口的模块间接的去测试RM模块。这样会导致有些功能无法覆盖到，或者说覆盖到这些功能的条件很难构造。

图2 系统架构图

而TCL嵌入式测试技术，把RM模块对外的接口函数通过TCL语言全部封装出来，使得测试人员可以通过TCL语言测试脚本调用这些接口函数，并利用内部集成的TCL解析器运行TCL测试脚本去完成这些模块的功能测试。通过TCL嵌入式测试脚本，我们就很容易遍历模块对外接口的各种参数情况（包括边界值），特别是一些参数的异常值情况，这是黑盒测试的盲点。

一般来说BGP模块和路由管理模块都是不同的开发人员开发，他们之间有个契约，就是BGP模块调用RM外部接口时候，不会传入错误的参数。正常情况下，别的组件也的确不会传入一些异常参数，但是特殊情况下，上层模块也可能传入了错误的参数，这样情况RM模块需要做容错性处理，才能使整个系统更加的稳健。这种接口测试是黑盒测试的盲点，TCL嵌入式测试技术可以保障V7系统的各个模块提供的对外接口函数的健壮性和子模块功能的正确性。如图3所示。

图3 嵌入式测试函数接口

模型二：测试各模块之间的交互过程细节

V7系统的各大组件模块在同一个系统下工作，他们之间不可避免的要传递一些数据和消息，这些消息和数据里面会携带一些模块之间约定的参数，这些参数必须是按照事先约定的内容和数据，整个系统的功能才能正确。但是如果在开发过程中，部分开发人员的出错，某些消息和数据没有遵循事先设计约定的内容，这样肯定会导致功能性错误。

但是并不是所有这些bug都立即能够表现出功能性错误来，就好像人中了某些毒，并不一定马上能表现出症状来一样，这些症状可能要有某些条件才能触发。这也是黑盒测试的一个困境。而TCL嵌入式脚本能够截获模块之间交互的消息和数据详细信息，并能够打印和解析出来，就如同在模块交互间打开了一扇观察的窗户，测试人员能够很方便的观察其参数是否携带正确；并及时发现这种bug。如图4所示。

图4 嵌入式测试模块交互

模型三：方便构造难以切入的点

在黑盒测试中，异常情况（特别是一些时序问题）的构造很不方便，但是这些在接口级别则很容易构造。还有一些状态机的中间状态，黑盒测试方式很难把握时机，用TCL嵌入式测试技术就很容易实现。

比如临界资源的保护，OSPF模块和BGP模块都要更新核心路由表，如果他们同时访问，肯定会有冲突，因此代码开发过程中，都会对路由表进行加锁保护，也就是OSPF模块要通过RM的接口函数更新路由表时，先在路由表上加一把锁，告诉其他模块在这个时间不能再更新路由表，当OSPF模块访问完成后，再释放这个锁，BGP模块才能通过RM的接口函数去访问路由表。

这个加解锁的程序代码是否正确，如果通过黑盒测试，只能构造条件让BGP和OSPF模块同时去访问路由表的情况，但是在代码中，这种加锁和释放锁是毫秒级的时间，也就是说路由表加锁了然后BGP模块再去更新路由表这样的情况很难构造出来。然而通过TCL嵌入式测试脚本就可以很方便了实现：用一个脚本先调用RM的接口函数更新路由表，给路由表加锁，然后暂停运行这个脚本，使路由表一直处于加锁状态；再通过BGP更新路由，BGP就自动通过RM再去更新路由表。TCL嵌入式之所以能够实现这样特殊时间的测试，是因为我们可以随时控制脚本的运行进度，使其在某个特殊的时机停下来，从而实现一些时序问题的测试，如图5所示。

同时对于某些接口函数执行返回失败的错误情况，也是黑盒测试不方便构造的，而TCL嵌入式测试技术则可以方便的模拟出各种失败的异常情况。

图5 TCL嵌入式测试特殊的时序点

模型四：内部性能规格压力测试

性能规格测试的对象一般是用户能够看见的性能规格，实际系统内部也是有设计规格的，比如消息队列的最大长度，LIPC通信的最大能力，内部计数的最大值等。这些内部规格测试是黑盒测试的盲点，黑盒测试不能完全的构造出消息队列满的时机，或者说有些内部计数要到达最大值可能需要系统运行一年的时间等，而这些都是TCL嵌入式测试技术的强项，通过一个测试脚本可以轻松的让内部消息队列的消息达到最大值，可以调用接口函数直接把内部计数写到接近最大值。

如果把系统比作一个人，测试就是给这个人做一个健康评估。黑盒测试的评估好比是中医看病，只能通过望闻问切及这个人的身体症状下结论。TCL嵌入式测试则不但继承了中医的外在评估，更能够进行深入细致的内部检查，好比西医的各种检查仪器，能够把人内部的器官状态直接展示出来。TCL嵌入式测试脚本能够深入测试V7系统的各个模块的内部之间的交互流程。

结束语

目前，V7系统的测试自动化率已经超过了30%这个业界平均水平，达到了40%的领先水准。同时由于TCL解析器在V7系统内部，自动化脚本执行效率大大提高，整个TCL嵌入式脚本完整执行一遍只需要1个小时左右时间，相比于传统自动化测试方式，节省了90%的时间。这使得TCL嵌入式脚本得到了充分了利用，每个版本发布，每个模块代码改动超过10%时，都会应用相应的TCL嵌入式脚本测试，保障不引入新的问题，使得保证软件版本的质量更加可靠和稳定。