通信网管系统OMC的性能测试研究

燕鹏飞，张厚保

（中国交通通信信息中心，北京 100011）

1 引言

本文从实践角度，阐述通信网管软件OMC性能测试的理论和方法，希望能引领读者从抽象的软件性能测试理论，映射到实际项目中，对OMC系统的性能测试有所了解。

2 性能测试概述

2.1 性能测试在软件开发生命周期中的位置

图1 性能测试在软件开发生命周期中的位置

软件生命周期分为：需求、设计、编码、单元测试、集成测试、系统测试。以V模型为例，呈现如上图。而性能测试属于软件系统级测试，其基础是一个已经完成功能测试的相对稳定的软件版本。

2.2 软件性能测试的概念

软件性能可以看作是一种指标，是产品需求中明确约定软件系统所要求达到的一种和时间相关或者与处理能力相关的指标。

软件性能的定义通常为：软件系统对于及时性要求的符合程度。对于时间方面规定的软件性能通常用响应时间来定义。处理能力是另一个重要指标，包括上行、下行以及系统内部的消息处理等。可靠性同样是软件性能的一个重要的指标，可靠性关乎到系统能否稳定可靠，关乎到客户对该系统的认可程度。通信网管作为通信网络的一部分，必须做到高可靠性。

软件的性能测试，就是通过测试工具，测试软件在各种使用环境下，是否能满足既定的软件性能指标。

3 OMC的性能测试

3.1 OMC的性能测试过程

软件的性能测试不是一劳永逸的，性能测试伴随着软件的生命周期持续开展。在通信网管软件OMC的测试过程中，随着OMC的一系列版本发布，其性能测试过程可以描述为一个螺旋模型，如图2所示：

图2 OMC的性能测试过程

3.2 OMC的性能测试方法

性能测试的方法有多种，根据不同阶段的需求，可以分别采用不同测试方法的组合。

3.3 性能测试

此处提到的性能测试，是狭义的性能测试，是软件性能测试的基本方法。性能测试方法是通过模拟实际运行场景的业务压力量进行测试，验证系统的性能是否满足预期的性能指标。这种方法针的测试结果，可以具体考量系统的响应时间、处理能力等性能指标。OMC系统，根据电信运营商的测试规范，有诸多性能指标，如界面响应时间、设备上报消息延时、告警呈现延时、性能文件上报等。OMC性能测试中，通过模拟规模数据的网元，构造批量变化的配置数据、告警数据、性能上报数据等场景，测试系统的各个性能指标。这个测试方法贯穿于OMC性能测试的始终。

3.3.1 配置测试

配置测试是指通过被测系统的软/硬件环境调整，了解不同环境对系统性能影响的程度。具体地说，就是服务器类型和操作系统类型的不同，对于OMC系统的性能指标影响不同。软件系统的性能都是在一定的环境下表现出来的综合性能。环境因素包括很多：硬件环境（CPU主频，个数，单个CPU的核数，单核CPU的并发线程数；物理内存大小，虚拟内存大小；磁盘的I/O处理能力）；所依赖的软件环境（操作系统的相关配置，数据库的相关配置）；自身的软件环境（如：并发线程的设置；虚拟机内存设置等）。

进行同一个典型业务在不同的配置环境下的测试，并进行结果对比分析可以有效的发现系统的性能瓶颈，可以找到对系统进行优化的依据；也可以根据对比结果选择最适合系统的硬件环境，以及评估如何调整才能实现系统的拓展性。

在OMC的设备选型测试中，此处采用了多轮配置测试方法，对系统进行评估、优化，以及优化后进行设备选型。

3.3.2 负载测试

负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其他加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等。用这种测试方法，可以找到系统的处理极限。在网管软件OMC的选型测试中，使用了负载测试方法，对于不同的软硬件配置环境，对比系统运行的性能容量，为OMC的软硬件选型提供依据。

3.3.3 压力测试

压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。在OMC的稳定性测试环节，采用了压力测试的方法。

3.3.4 并发测试

并发测试验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。

OMC系统是通信网管软件，其重点应用场景不是多用户的并发场景，而是大量业务并发场景。因此，在实际测试中，并发测试针对的是OMC系统内部实现的并发，多线程并发、数据库死锁、数据库事务处理等方面。

3.3.5 可靠性测试

可靠性测试方法通过给系统加载一定的业务压力，例如资源在70%～90%的情况下，系统持续运行一段时间后，测试系统是否稳定。OMC系统的稳定性测试使用了该测试方法，通过在持续的业务压力下运行，查看OMC系统的处理能力、响应时间、内存和CPU使用状况，以及查看是否有错误处理等情况。

3.3.6 失败恢复测试

失败恢复测试方法是针对有冗余备份和负载均衡系统设计的。这种方法可以用来检验系统在局部故障情况下，是否能正常运行。OMC系统采用集群策略部署，针对集群策略，进行主备切换测试、主机或备机宕机测试。测试过程中查看是否有业务丢失（如配置、告警消息丢失、性能文件处理丢失等），查看系统的处理能力是否正常等。

3.3.7 性能测试各阶段的方法应用

综上，OMC系统的性能测试各个阶段，对于测试方法的应用分布为：

图3 测试方法的应用分布

3.4 测试结果分析方法

3.4.1 操作系统计数器分析法

操作系统计数器分析方法，在OMC性能测试结果分析中，起到重要作用。操作系统计数器分析法重点关注内存、处理器（CPU）、磁盘I/O这些方面。

内存：使用操作系统命令，在OMC运行过程中，记录内存使用情况、内存交换区使用情况。统计记录的数据，查看内存占用走势以及内存泄漏情况。然后用代码走查分析方法，或使用内存查看工具，来对内存使用问题进行定位分析。

处理器（CPU）：用OMC相关进程的%CPU Usage衡量OMC系统对CPU的使用情况。一般上限不超过85%。

磁盘I/O：磁盘I/O也是影响系统性能的一个关键因素。在OMC系统测试过程中，发现OMC系统在存储过程中磁盘I/O是性能瓶颈，因此有针对性的进行了系统优化，同时在磁盘硬件选型方面采取了一定措施，解决这个瓶颈。

3.4.2 分层分析法

OMC系统包含多个逻辑层次。在实际测试中，采用分层分析法对测试结果进行分析。

图4 分层分析法

无论是上下行数据，都记录各个逻辑层次处理的时间段耗时。如下行操作：从客户端界面üü业务层调用üü平台支撑层处理üü和设备之间交互（或与数据库交互）。将操作在各个逻辑层次的耗时进行统计，分析得出系统瓶颈产生的层次。当分析出某个逻辑层耗时占比大后，还可以进一步分解该逻辑层次，继续深入采用此方法进行测试分析，逐步排查系统瓶颈产生的原因。

3.4.3 统计法

对于一个典型的业务进行相同的环境下（软件，硬件）进行多次测试，对多次测试结果进行统计分析是性能分析的常用办法。单次测试往往具有偶然性，对同一个操作进行多次测试，通过统计的方法进行结果分析。在进行统计分析的时候，要符合统计要求的样本数量，同时对异常点进行分离。如下示例：

表1 五次测试情况

图5 五次测试统计

上面图表是对同一个操作进行了五次测试，对测试结果进行统计后，可以作为最终的参考测试结果。

3.4.4 性能曲线趋势分析法

通过分析性能曲线的变化趋势对系统的性能进行分析。这个方法适用的场景很多，如：典型业务/操作随着并发数目增多的性能曲线下降的分析方法：性能主要通过时间来衡量。如图6所示，随着某一业务的增加，处理时间增加，系统的性能下降。

通常系统的性能曲线是一个平滑的曲线，随着并发的增加，时间平滑上升，性能平滑下降，找到性能跳变的位置，该位置为系统的性能拐点。在该拐点后，性能急剧下降，超出需求的范围。在性能评估中，改点可视为系统的处理能力的上限。OMC 系统的网元管理能力，就可以通过这个方法找到上限。图7是针对硬件环境变更进行性能分析，是OMC系统对于网元上行的消息风暴作受系统主频的变化的处理能力的变化：

图6 性能曲线趋势分析法

图7 针对硬件环境变更进行性能分析

从图7可以看出，在一定范围内提升硬件的CPU 主频是有助于性能提升的，但是提升到一定水平后系统的性能不再有明显的改善，说明此时系统的性能瓶颈已经不在处理器的主频了，需要分析其他因素了。

3.5 测试工具的引入

工欲善其事必先利其器，测试工具在性能测试中其中非常重要的作用。在OMC系统的性能测试过程中，模拟通信网元，构造通信场景的大量数据，使用发包工具模拟通信消息等。除了这些构造测试场景的工具外，还引入了如JProbe、JProfiler等工具协助定位和分析问题。

图8 使用JProbe工具查看客户端内存使用情况

如图8所示，使用JProbe工具查看客户端内存使用情况，一级一级追究java调用，直到定位出内存溢出调用的代码，最终使得客户端内存溢出问题得到定位和解决。

4 结束语

综上所述，OMC系统的性能测试，在OMC的系列版本开发过程中，做到了及时发现各种性能问题，帮助团队尽可能的对OMC进行了合理优化，顺利通过了性能要求。未来的性能测试方案，针对不同的系统架构，需要不断重新设计和优化，把理论结合实际，实施适合项目的流程和技术测量，这是工程师们应该完成的责任和使命。