随着在电信行业工作的逐渐深入，人们对网管技术的理解已经由以前的只对网络管理协议的专注发展为对包括理论、实现技术和工程在内的成套网络管理相关技术的研究。提高网络管理建设的质量不再是简单地在网管协议之上发生争论，而是要解决如何在网络管理建设中应用成套的网络管理技术的问题。在这一系列网管技术中，网络管理接口测试即是其中的一个重要环节。
在电信网本身的建设教程中，为了保证网络本身的互联互通，我们有一套比较好的方法论，即电信设备的生产需要标准，电信设备的入网需要依据标准进行测试，全网设备版本需要统一管理。但是，在以往的网管建设过程中，人们却忽略了这一点，这主要体现在网管系统的引进过程中没有经过严格的测试，网管系统运行的质量无法保证，对全网网管系统的现状没有统一的概念，为网管系统的后续建设带来了困难。为了保证网管系统和设备之间的正常交互，就有必要对通过接口交互的双方进行某种以接口标准为依据的检验以判断双方对接口的符合程度，只有经过检验并通过认证的网络管理系统和被管设备，才能入网使用。在网络管理领域，这种检验被称作网管接口的测试。
一、网络管理接口测试的基本方法
1.网管接口测试是一致性测试
所谓一致性测试，就是执行一系列操作，驱动被测实现，并观察被测实现对确定行为的响应，根据某一被测实现与其实现规范的符合程度，得出一致性结论。
概括而言，一致性测试的目标就是要检测被测实现是否满足一致性声明中所阐述的静态和动态一致性要求。其中，对静态一致性要求的测试通过静态一致性分析（Static Conformance Review）实现，对动态一致性要求的测试通过测试行为（Test Campaign）来进行。上述两方面的测试过程是一致性测试过程的核心。在测试行为中，应在被测系统之上运行测试集，收集测试结果并生成测试记录。
2.网管接口测试是黑盒测试
在软件工程学中，一致性测试被分为结构性测试和功能性测试。结构性测试主要是在了解软件代码的基础上，有目的地设计测试用例，用于测试软件在各种输入测试数据的环境下是否运行正常，通常也被称为“白盒测试”。功能性测试通常称为“黑盒测试”，它不关心被测实现对某项操作的具体实现方法，只关心被测系统从软件接口上是否满足了该操作的功能要求。
网管接口一致性测试的方法基本上属于黑盒测试。从测试条件来说，网络管理接口的测试不属于软件产品内部的测试，而是第三方对产品进行的验证，因此不可能了解软件的具体实现。从测试目标来说，网络管理接口测试通过测试验证被测网管系统的接口，实现同网管接口规范之间的一致性，无需限制具体的实现。从测试手段分析，在一定的模拟或者实际网络环境下，对被测的网管系统输入必要的测试激励，通过比较被测系统的响应与接口规范所预期的测试结果的异同，判定被测系统在多大程度上与系统实现者所作的实现一致性声明相一致。这种测试只是根据网管接口规范描述，测试出用户陈述的一致性行为和被测系统的实际行为的差异，不能具体指出成熟出自源程序的哪一部分，也无法对错误进行修正。
3.网管接口测试基本参考模型
在被测系统一侧的网管接口是被测系统本身已经实现的实际接口，而在测试系统一侧的接口是测试系统自备的网管接口。
测试接口是由测试系统定义，由被测系统提供支持的接口。测试接口是一种基于某种互联方式（TCP/IP、X.25、V.24、Netbios等）、经过双方协调并共同认可的接口，接口语义的格式可以是基于消息的数据流的方式，也可以采用MML作为自定义接口的语义格式。接口语义的内容是根据TMN管理信息模型一致性声明导出的，能够被测试系统执行的SCRIPT语句，或者经过解释测试用例产生的测试原语。
4.基本测试方法
在进行网管接口测试时，测试方法的选择十分重要，它决定了网管接口测试的质量。在选择测试方法时，需要考虑以下几方面的问题：
*要能够满足测试覆盖度的要求，应当尽可能测试接口一致性声明描述中的所有可测试特性；
*要满足自动测试系统实现的可能性；
*要保证测试方法的可实现性，减少其实现的复杂度。
抽象测试方法是根据对被测实现（IUT）输入的控制和输出的观察来描述的。在一致性测试中，测试者可以从本地或远端的不同参考点（PCO）来观察和控制抽象测试原语（ASP:Abstract Service Primitive）的交互。但是，从系统模型角度而言，网管接口的被测实现本身不能像协议实体那样提供上测试界面，无法在被测系统的高层位置设置PCO，其上测试器功能只能由sut（System Under Test）或人工操作实现。因此，在实现时我们选择了较为简单的远程测试法作为网管接口的基本测试方法。
远程测试主要的特点就是在测试用例中没有子系统（Test System）和被测实现（Implementation Under Test）之间的协调过程，测试协调与测试调度由测试人员手工完成，测试者在进行测试时，从被测系统外部对被测实现的实时状态进行观察和控制，
根据被测系统执行测试命令的返回结果，决定测试用例的执行顺序。
5 基本测试环境
网管接口测试实际操作时运行的基本环境包括两个基本组成部分，即委托测试方所在的测试系统部分和被测厂家所在的被测系统部分。
委托测试所在的测试系统部分的测试环境主要有测试系统和网管接口通信协议栈组成，测试系统在网管接口测试起着极为重要的作用，它在网管接口测试过程中起着主导者的地位，所有的测试均将由测试系统发起和控制。一个测试系统的好坏决定着网管接口测试的质量高低。经过多年的努力，网管测试系统研制过程中的理论问题已经解决。随着新技术的不断出现和应用，相应的测试系统也在不断丰富和完善。但是测试系统的专用性较强，很难形成市场规模，其投入较高。目前市场上存在的测试系统不能满足测试评估的全过程，只能解决其中的一个阶段的问题，而且其有效性一般都没有得到实际的验证，尤其是针对不同类型的网管接口（如CORBA、Q3、SNMP等）必须要有专门的测试系统，因此，开发网管接口的测试系统具有其现实的必要性。
被测厂家所在的被测系统部分由厂家的网管接口实现系统和所管理的（仿真或物理）设备组成，根据不同的测试阶段的需求，被测厂家可以使用仿真设备和物理设备来构建测试环境，但厂家搭建的测试环境必须保证可以满足测试的需求，即可以保证测试规范中定义的所有测试项在测试环境中可以运行。
二、网络管理接口测试的基本流程
网管接口的一致性测试包括三个方面的内容，即协议一致性测试、信息模型一致性测试和管理功能一致性测试。在网管系统实现中，管理功能被映射为对一组管理对象的操作，而管理对象在完成具体操作时需要底层网管协议和通信协议原语的支持。协议的一致性是所有一致性基础，只有底层协议保持一致性，才能实现系统间“互联”；在通信协议保持一致性的前提下，才能进行信息模型的一致性测试；管理信息模型的实现与管理信息模型规模保持一致性，才能实现“互通”；并且，在信息模型保持一致性的前提下，方可进行管理功能的一致性测试；只有当管理功能满足一致性，网管系统间的“互操作”才会实现。
1.协议一致性测试
协议的一致性测试是保证网管系统和被管设备互通的基础，它包括对底层通信协议和高层网管协议的测试。目前国内外对协议的测试技术的研究起步较早，相关技术已经较为成熟，如果要进行通信协议的测试，只需购买相应的仪表就可以实现对通信实体间协议软件的一致性测试，例如对基于SNMP的网管接口进行测试，协议测试中的主要关注内容SNMP和UDP均可以通过协议测试进行。同时后续的网管接口信息模型一致性测试和管理功能一致性测试中，如果测试系统和被测设备之间能够正确交互管理信息，这同时也就证明了通信协议和网管协议保持了一致性。所以对于网管接口测试来说，并不把协议的一致性测试作为重点内容，而是在协议保持一致性的前提下，研究管理信息模型的一致性和管理功能的一致性测试。
2.信息模型的一致性测试
网管接口信息模型一致性测试用于验证被测用户所提供的网管接口，确定是否能以接口规范规定的正确形式提供管理信息。信息模型一致性测试的测试对象是接口规范的信息模型中定义的管理对象。管理对象是具体的被管资源的抽象，管理对象之间关联性反映了被管设备或资源之间的相互关春主理对象之间关系的动态一致性测试。
网络管理接口静态一致性测试是对单个管理对象的数据结构和可执行操作进行验证，包括是否支持对象实例的生成、删除及对象实例相关的各种操作，以验证被测系统声明能力的存在性。网络管理接口动态一致性测试是否对管理对象定义中描述的管理对象之间的动态关系以及复杂行为所进行的测试。
3.管理功能一致性测试
管理功能一致性测试用于验证网管接口所传递的信息能否真正指配网络的运行以及正确表达网络资源的具体运行情况。
管理功能测试的测试过程与信息模型一致性测试类似，但在测试过程中，测试系统必须与具体的物理设备相连。测试系统通过被测系统的管理接口对设备进行激励（发送网管协议原语），使被测系统的管理对象产生相应的反应，然后观察相应管理对象操作完成后产生的事件报告、对象的状态以及设备的实际运行状况，来检测被测系统管理接口上管理对象的状态变化是否正确反映了网络资源的实际运行状况，是否与管理功能测试规范中所描述的预期结果相符合。测试系统和设备同时作为测试观察点进行测试结果的分析。
三、测试中心在网络管理接口测试中的重要作用
网管接口测试是一项极其复杂、技术含量很高的工作，从事网管系统测试的人员本身不仅是计算机领域分布式处理技术的专家，同时又必须是相应电信业务网管领域的专家，并要有丰富的测试经验和严谨的工作态度。一个完整的测试流程包含多个复杂的测试阶段，需要多方的共同努力，仅靠个人的能力是不可能的，必须通过集体的力量，团结协作，并充分发挥每一个人的特长，才能保证测试的质量。为此，有必要设立专门的机构从事测试工作，一方面，可以在较长时期内保证测试人员的相对稳定和测试的质量，另一方面，在市场上现有的测试系统产品不能符合特定测试的要求时，测试中心可以提供相关开发力量，针对特定情况进行测试系统的二次开发，以满足测试需求。
摘自《通信世界》2002.2.18
