接近更真实——关于网络测试环境的困惑与反思

接近更真实

    ——关于网络测试环境的困惑与反思

    ■ 吴疌

    作为运营商的一名测试人员，笔者参加过很多个测试项目。但似乎大多数的测试都不是令人心情愉快的过程，尤其是大型测试中常会出现令人头疼的问题，使得厂商的技术人员和测试工程师十分沮丧和疲惫。那么，为什么曾在研发实验室里测试多次的设备在第三方实验室的验证性测试时还会出现难以解决的问题呢？

    工程师的困惑

    面对测试过程中出现的种种问题，笔者一直在想：是不是我们的测试要求过高了？答案是否定的。因为，从现在看来，测试的要求是很普通的，如果有足够的时间和强大的测试工具，那么测试的要求肯定会比现在要高很多，而测试过程也会更加严格，当然这也意味着会有更多、更烦人的问题和更漫长的夜晚。

    那么，是现在的设备功能太复杂了？的确，现在的设备功能越来越强大，测试也随之变得复杂，但是复杂的测试就一定意味着会出现各种问题吗？

    在与厂商技术人员的交流中，笔者发现他们也有着同样的困惑：测试的项目越多，测出来的问题就越多，但测试周期却在相对缩短，增加测试人员却得不到效率的提升，一切看上去似乎都在向不好的方向发展，那究竟问题出在哪儿呢？

    寻觅最佳的测试方案

    在外部原因很难给出一个满意答案时，我们不妨试着研究一下现有的测试方法。结果发现: 目前的困境在很大程度上是由测试方法和测试环境之间的冲突所造成的，而这种冲突在短时间内则是难以消除的。

    那么，想像中的最佳测试方案是什么样的呢？如果以发现缺陷的效率来评价一个网络测试方案的话，它应该必须具备如下特性：

    重复性——客观的测试必定是可重复的。在完全相同的测试环境下，每次测试的结果都应该是一致的，或是在误差范围之内的。为了提高测试的重复性，测试人员更容易倾向于一个稳定的测试环境和基本不变的测试方法，对于引进新的测试手段或对测试环境进行大的改动都心存芥蒂，因为新东西常会带来新问题。但是，当产品在第三方实验室中测试时，测试的环境和方法可能会有很大的不同，如果厂商的测试人员忽略了这些差异，就极有可能在测试中被搞得焦头烂额。

    隔离性——指的是在进行某项测试时，测试环境中的各个设备和设备的配置应该只和该项测试有关，非被测设备的性能不会对测试结果造成影响，非被测设备之间的兼容性和互操作过程不会影响最后的测试结果。隔离性反映的是隔离故障点的效率，这和检查问题时常用的“逐个击破，层层深入”的原理很相似。例如，在进行RIP测试时，测试环境中不会存在其他的路由协议，否则会对问题的定位造成困难。因此，测试过程往往是一个项目做完后再做另一个项目，或者分组在不同系统中做不同的项目，同时在一个系统内测试的项目少之又少，而且出现问题时多数人的第一反应就是配置有问题，需要清空配置或是重新启动。

    控制性——指的是在测试时，测试环境中的所有设备都是可控制和监测的。如果测试环节中存在无法修改的参数或者是无法查看配置和运行情况的设备，那么寻找问题的过程显然会辛苦几倍。在第三方实验室中兼容性和互操作性是非常重要的测试项目，而厂商的测试环境中第三方设备一般不多。所以在进行如MPLS/VPN设备互通性测试时，一个测试环境中即使同时只存在两个厂商的设备，对双方的技术人员来说都是一个巨大的考验，因为他们面对的是一个完全陌生的设备。此外，在进行“全黑”测试时（即测试过程自始至终都不允许厂商技术人员对设备进行操作或监控），常会使厂商的技术人员紧张，因为日常的测试经验使得他们对控制性非常看重，一旦失去了对设备的控制心中便很容易没了底。反过来讲，大量的配置命令和众多需要监控的参数或报警信息对测试人员也是一种考验，在单元测试或单模块测试时不太会出现这种情况，而在整体测试时却会经常发生，可见过多的控制信息也会造成控制性的降低。

    总之，厂商实验室中的网络世界是一个相对理想的世界。实验室的设备不多，测试人员对整个测试环境十分了解，因此实验室中的测试有着高重复性、高隔离性、高控制性的特点。测试人员分工明确，针对不同的单元有着不同的测试方案，而将整个系统进行彻底黑盒测试的机会不多。而第三方实验室的环境更接近于真实的网络，测试环境复杂、手段多样，经常对设备进行系统的整体性测试，相对于厂商的测试环境其重复性、隔离性、控制性都降低了不少。而这些因素恰恰是导致那些在厂商实验室中表现完美的设备在第三方测试后从天鹅变成了丑小鸭的原因。这个看似不合理的结论反映了网络测试中一个日趋激烈的矛盾——现有的测试手段无法在一个日趋复杂的测试环境中提供高效的测试方案。

    网络测试的5件利器

    事实上，随着技术的发展，实验室与真实网络之间的距离正在不断加大。真实的网络是一个极其复杂而又充满随机性的世界，要使实验室中的网络环境更加真实就必须在测试中引入概率分布和统计平均的机制，例如IMIX; 就必须做到同时进行多个测试项目，考察多个指标，并对结果进行综合分析; 就必须在测试环境中添加多个其他设备来验证被测设备的兼容性；就必须在进行功能和性能测试时同时进行管理性和安全性测试等等。

    在这样的测试环境里，网络中的数据流是以统计重复来发送的；而众多的网元和网络中运行的众多协议使得隔离性降低，其后果就是隔离故障点所花费的时间直线上升；再加上有可能要对多个设备进行操作才能模拟一个测试环境，而测试中需要监控的参数也可能会有很多，如果这些全靠人工操作效率势必很低。

    反观我们目前的测试手段，连自动测试都很难做到，几乎是赤手空拳，怎么能应付更真实、也更“低效”的测试方案呢？根据多年测试中积累的经验，笔者总结出了在更接近真实的测试环境下提高网络测试的效率的5件利器（具体内容见下）。虽然它们现在看起来有点儿超前，但对于一个网络测试来说，这些的确是缺一不可的。 ■

    出色的测试管理系统

    为了提高对测试的重复性，必须要能很方便地管理测试环境中各种配置文件，并对每次测试的数据、日志、报告等进行系统的管理。这在单元测试中实现起来并不困难，而在复杂的环境下进行复杂的测试时若没有一个出色的测试管理系统则是难以想像的。

    高效的测试监控和

    信息过滤系统

    为了在一个复杂的测试环境下寻找问题点，必须对测试环境中各个设备的多项参数进行监控，而在大量数据分析时拥有一个好的过滤机制无疑是从另一个方面提高了测试的隔离性和控制性。

    灵活的测试软件

    再强大的测试软件也有无用武之地的时候，所以我们需要更加灵活的测试软件，不仅是灵活的参数配置，还要能按照我们要求进行测试，并能自动配置网络中的各种设备。为测试脚本提供更强大的API，在现有的测试软件上增加“宏”的功能，提供实时的测试结果分析，这些对于测试人员来说都是十分必要的。

    通用的测试描述语言

    如何描述整个测试环境？如何说明整个测试流程？不要认为答案会很简单。想像一下你在运行GVRP和LACP的三层交换机上进行基于VLAN组播测试的环境吧！这不是一个网络拓扑图和几个表格就能解决的事情。未来的测试会比这复杂许多，如果没有通用而准确的测试描述语言，沟通将变得十分困难。

    优秀的测试人员  

    传统的测试和接近真实网络的系统性整体测试有很大的不同，后者对测试团队提出了很高的要求。测试团队中的每一个人不仅要有扎实的基础知识和优秀的分析能力，还必须对整个测试体系有着清晰和一致的认识。因为，在非常复杂的测试环境中查找问题的难度是很大的，发生任何的人工失误都会极大地影响测试效率。