基于时间模拟率的测试方法研究

刘洋+徐超+王凯+赵鹏

【摘 要】通信产品迭代速度快、测试周期短、软件稳定性测试时间不足，造成了隐含缺陷的产品流入市场的情况。针对以上问题，提出一种时间模拟率的稳定性测试方法，测试一天可模拟产品实际运行N天，并通过TETRA平台框架层面的通信接口进行了测试实验，实验表明该测试方法可以有效地縮短测试周期，在有限的研发周期内更大程度地提高产品稳定性。

【关键词】稳定性测试 时间模拟率 TETRA D-Bus

Study on the Testing Method Based on the Time Simulation Rate

[Abstract] Communication products have characteristics of quick renewed products， the short testing period and the insufficient testing time of the software stability， leading to impliedly defective products entering the market. In view of this situation， a stability testing method based on the time simulation rate was proposed in this paper， which can simulate the practical operation of N days in one day. In addition， it was tested by means of the communication interface on the architecture of the TETRA platform. Experiments show that the testing method can effectively reduce the testing period and highly enhance the stability of products in the limited R&D cycle.

[Key words]stability test time simulation rate TETRA D-Bus

1 引言

随着当今通信技术的日益迅猛发展，专业通信产品的市场越来越庞大，但同时竞争也越发激烈，在产品更新迭代加快推动通信产业不断发展的同时，也暴露了由于研发周期短，产品稳定性测试验证时间不足，导致流入消费者手中的产品在使用过程中出现各式各样的问题的情况发生，严重影响了客户体验。因此，在有限时间内，如何更有效地加强产品稳定性性能测试已经成为通信行业急需攻克的难题。目前已提出的测试理论多偏重测试流程和开发流程；而实际上，在产品的实际使用和测试中，其质量问题会更多的体现在产品业务和技术方面，传统的测试理论对此却缺乏关注。特别是对于需较长时间测试才能暴露的问题，实验室有限时间的测试难以百分百地发现，这就要求有一套理论来评估产品的质量，并基于此进一步加强测试。针对以上问题，本文提出一种时间模拟率的测试概念，即实验室测试1天可以模拟产品实际运行N天，通过压缩测试时间，力争在尽可能短的时间内发现更多的产品隐患。对基于时间模拟率开发的TETRA的平台框架层面的接口测试方案进行测试验证，并将测试结果与产品实际运行结果进行对比，表明该方法具有可行性高、可扩展性强的特点。作为评估产品质量的一个度量衡，对于其他非通信类型产品的测试，希望能提供比较好的借鉴和启发意义。

2 测试时间模拟率及应用策略

测试时间模拟率是一种测试时间相对产品实际运行时间进行压缩的比值，在测试时间和测试设备数量均受限的情况下，通过在实验室测试环境以一定的时间比例模拟产品实际运行，从而发现更多的产品稳定性问题。该模拟率可以用数学比例1：N来代替，“1”指实验室环境下的测试时间，N则是对应的可以模拟的实际系统的运行时间。

测试时间模拟率区别于常规的压力测试，后者旨在发现系统能支持的最大负载，常规地为了检查系统的反应、运行速度等性能指标，发现产品的性能瓶颈；测试时间模拟需要结合压力测试、性能测试和自动化测试等手段对测试时间进行压缩。

在应用策略方面，一般而言，测试时间模拟率的具体应用需要结合产品的业务和技术特点，给出多角度多维度的评判。一般来说，基于产品面临的外部挑战，应用策略可以分为以下两种。

业务角度的应用策略：针对产品的业务模型，分析在一定测试时间内所能触发的业务量、业务复杂度与现场时间的比值，则可推演出要达到同等业务量，实验室测试所需时间与实际系统运行所需时间的比值。如测试系统与实际系统单位时间内的在线用户数比值、用户业务请求量比值等。因产品业务的差异，应用策略千差万别。

技术角度的应用策略：从产品自身的技术特性可以分析其技术角度的模拟率比值。如单位时间内产品涉及到的配置组合（产品所采用的服务器类型、参数类型等）、所经历的外部环境情况（工作温度范围、GPS信号变化情况等）等。

结合产品自身的设计，可以从产品组成模块/网元的角度，进一步分析模拟比，模块可以分为：

业务模块：直接处理产品业务的模块；

平台模块：不直接处理产品业务，但支撑业务模块，比如操作系统，可以通过分析其内存使用，发现线程挂死等异常发生几率的比值。

下文以通讯系统中的D-Bus平台为例，深入展示测试时间模拟率的应用。

3 模拟率测试案例及验证

3.1 D-Bus通信简介

D-Bus是一种高级的进程通信机制，具有低延迟、低开销、高可用性等特性，是desktop-bus的简称。该通信协议由freedesktop.org开源项目组提供，并基于GPL进行许可发行。其主要概念为总线，注册之后的进程可通过总线发送和接收报文信息，或者等待内核相应事件响应，例如系统某种服务状态变更或是主机发出某种内核操作指令。由于基于D-Bus协议的消息传递相对比较高效且稳定，目前已被广泛地应用到多个版本的Linux操作系统当中，而且软件开发人员能利用D-Bus协议去实现复杂多样的通信软件开发。

作为D-Bus的进程间通信机制，总线通常会在一个操作系统中存在很多条，并由D-Bus总线守护程序进行相应管理。以系统总线（System Bus）为例，其在Linux操作系统内核引导时，就会被载入到系统的内存当中，此时只有内核级别的程序、Linux桌面程序以及高权限级别的软件程序才能进行总线的消息写入，以确保操作系统的安全，并且能有效预防恶意或未授权的程序进行的相应写入尝试。会话总线（Session Buses）能同时存在很多条，一般由普通进程创建，并且被某个进程私有独占，其被用于进程间消息的传递。其中，程序进程首先必须进行注册，之后才能进行总线消息的接收。

D-Bus提供了一种匹配器（Matchers）机制，以使程序能有选择性地进行消息接收。同时运行中的进程程序均会注册一个回调函数，便于在收到指定消息时进行相应的业务处理。这种机制能有效防止不相关消息的接收，从而避免导致程序运行时的性能较弱。

在D-Bus机制中，对象、服务、消息等概念相对比较重要。其中对象是一个封装后的匹配器与回调函数实体，它以端到端（peer-to-peer）方式使每个消息都具有唯一的源地址以及目的地址，以便确定通信路径。当一个进程在总线注册时，需要创建相应的消息对象。在进程注册到某个地址后，相应的总线服务会被自动获取。D-Bus提供了服务查询接口，进程可通过该服务查询接口判断服务是否存在。注册的进程能通过发送信号的方式将消息放到总线上，此时，其他进程则通过总线接收并解析消息。回调函数会在注册进程收到相关信息后，自动做出反应并且返回相应的方法。

3.2 案例验证背景

一般而言，在系统测试中，一些系统随机性问题（尤其较严重问题）随着时间的推移会不断被暴露出来，继而被研发人员改进和修复；在版本的不断演进中，问题被暴露的概率越来越低，甚至难以被日常的测试所发现。对此，需要明确缺陷问题有无根本修复；问题在实验室有限的环境和有限的测试时间下是否能够充分暴露；如何确保此类问题不会在项目现场发生。要对此类问题进行一个时间比的探讨，才能使其在某一数量级的硬件条件和一定的运营时间内不会暴露出来。

下文将分析一个平台的接口级压力测试，实验室的人员和设备极其有限（尤其是系统设备数远远小于现场设备数）。以某一中型项目现场为例，TETRA系统基站数高达70个，基于有限的设备和人员，如何尽可能地模拟现场设备运行的多种交互，这对系统的模拟覆盖测试提出了更高的要求。

目前TETRA系统业务层面的压力测试由于比较常见而容易被关注，且一般TETRA系统厂家会进行比较广泛的测试。而平台框架层面的接口测试往往会被一般的厂家所忽略，在现场大业务量运行时，除了业务模块软件承载巨大压力，底层接口同样也承载巨大的压力。因此，为了提高测试模拟率，自动化测试开发团队基于通用平台的通信流程，开发设计了相应的通信程序，并且基于测试环境测试，最终根据测试结果进行了模拟率的验证。

3.3 自动化测试工具设计

底层平台接口层面的通信分为客户端及服务端两部分，通信基于D-Bus协议。该D-Bus平台主要实现通信包的转发，其中，服务端程序功能主要为设计实现接口，并发布接口对象，从而生成对象路径及总线名；客户端程序功能主要为通过总线访问对应服务端程序中的接口，客户端连接到服务端需要设定服务端的IP地址、端口号以及总线名。

为了测试这个通用平台的稳定性，分别用C++和Python语言对同一平台接口开发了自动化测试工具，不仅涉及到软件的线程间通信、主机内进程间通信，还涉及到跨主机的进程间通信。其中，测试程序设计中不涉及系统中各类实际存在的通信程序的交互，如基站守护进程、网元程序等，即模拟测试程序和实际基站系统运行程序均基于D-Bus通用平台，但模拟程序不会影响实际程序的运行，仅加大接口模拟的力度，使实际程序调用接口时更易发生、暴露缺陷问题。整体测试通信模型如图2所示：

为了尽可能地模拟现场业务，在测试软件设计中加入了线程间通信、主机内進程间通信、跨主机间进程间通信，这样底层平台的多种业务能够得到有效模拟。

此外，为了尽可能模拟实际现场，项目团队通过设计异常程序，以实现网络传输、网络接口异常及系统服务级的自动化异常干扰。客户现场真实环境会不定期地出现网络传输等问题，周期约为1～3天一次，采用该方法，设定一个小周期（5分钟到半小时），通过随机数产生器，在网络传输层面会随机产生丢包、乱序、乱码等状况，且网络接口会定时启用、禁用，系统服务也会在随机时间段内进行服务的禁用及启用。据此，能较充分且随机地模拟现场易出现的多种突发状况以进行测试，暴露问题缺陷，最终保证系统运行的健壮性及稳定性。图3为网络传输及接口异常模拟程序框架图：

3.4 测试环境

由于实验室设备资源有限且多数资源用于其它多种测试，最终分别在一台两载波基站、9台Linux虚拟机主机（模拟基站）环境上部署了开发的测试程序，并分别设定主机间和同一主机内的单一业务和多业务交叉通信场景，以达到时间模拟上的效果。其中，每主机新增40个通信测试进程并活跃运行，每进程调用25个线程，所以主机内运行1000个线程，10主机共运行1万线程来进行平台通信。

3.5 模拟率估算及测试结果分析

在实验室常规测试环境中，一台基站的活跃进程为5～10个左右，取平均值为7，每进程中活动线程为10个左右。在模拟测试程序设计运行后，一台真实基站（加上虚拟主机）一天的模拟量约等于“10000/（7×10×4）=35.7”台基站一天的模拟量，即模拟率约为1： 35.7。

经过测试分析发现，相应通信平台的接口缺陷问题只能被常规测试有限地发现，但有了自动化模拟程序后，能更多更快地发现相关缺陷，且自动化模拟程序发现的问题能覆盖到常规测试中发现的同样问题。

项目团队对缺陷问题出现的数量及所需时间进行过统计，

实际模拟的概率提升为“15/0.47”，约为32倍，即实际模拟率为1： 32，接近理论估算值1： 35.7。

根据上述结果对比，通过模拟程序测试效率和质量得到了大幅提升，测试覆盖到了业务层面的压力测试、平台框架层面的通信及异常干扰等尽可能多的场景。因此在实验室可快速模拟项目现场长时间的通信量，尽早暴露问题，以避免问题遗落在现场而导致隐形及难以估量的损失。

4 结束语

本文通过一个较典型的通信接口级压力测试案例来阐述模拟时间比这个概念，值得关注的是，真正做到系统级的时间模拟的估算和测试需要针对每一个随机问题进行技术分析，然后定量地分析，最后根据时间模拟率方法，采取相应的测试手段。

整体而言，本文提供了一个理论标准——问题模拟发现率，并提供了两个衡量标准：时间比例和覆盖比例，同时结合项目经历，就相关理论的验证进行了举例说明，使产品的质量有了一个量化的评估标准，有助于产品质量的提升。海能达公司的ACCESSNET-T IP DIB R5是最新专注研制的一款TETRA专网通信系统，由中国总部和德国子公司共同研制，就其架构而言，相比上一代产品，很多特性得到了改进和优化，并且模块化的程序更高、支持组网方式更灵活、业务流程更合理、功能相对更完善，并且由于测试方法的提升，相应的产品测试也更加充分，保证了产品的可靠性能。

参考文献：

[1] ETSI EN 300 392-5. Terrestrial Trunked Radio （TETRA）； Voice plus Data （V+D）； Part 1： General Network Design[S]. 2009.

[2] ETS 300 392-2. Trans-European Trunked Radio （TETRA）； Voice plus Data （V+D）； Part 2： Air Interface （AI）[S]. 1996： 76-84.

[3] FREEDESKTOP.ORG. dbus-specification； Part 4： Message Protocol， Revision 0.27[Z]. 2015.

[4] 中國电子学会通信学分会. TETRA在中国的应用和发展[J]. 移动通信， 2013，37（11）： 52-55.

[5] 徐超，冉斌龙，刘洋. TTCN在TETRA系统中的实践运用[J]. 移动通信， 2016，40（9）： 24-29.

[6] 周俊扬，杨丰瑞，杨程. 基于dbus的QT进程间通信机制的实现与优化[J]. 广东通信技术， 2014，34（1）： 23-26.

[7] 郑晓军. 无线通信TETRA系统简述[J]. 科技资讯， 2010（1）： 22， 24.

[8] Linuxdianc. 进程间使用D-Bus通信-Linux/UNIX典藏大系[EB/OL]. （2009-12-21）. http：//blog.csdn.net/linuxdianc/article/details/5046331.

[9] 徐超，贾迪非，刘洋. 基于TETRA系统的接口开放性研究