基于故障注入的应用软件可靠性测试

姜 文，刘立康

(西安电子科技大学 通信工程学院，陕西 西安 710071)

0 引 言

随着计算机技术的发展，云计算技术在各行各业的应用普及，基于云计算的应用软件的种类也越来越多。软件产品在使用过程中出现软件失效，将导致一系列严重的事故与后果。软件测试阶段不仅需要进行软件的功能、性能测试，还需要对软件进行可靠性测试，以确保新开发的软件上线后能够正常运行。

在可靠性测试技术中，故障注入技术应用十分广泛。与传统可靠性评测技术相比，它具有无需建立和求解复杂的系统模型、实验时间短、结果精度高等优点，已引起众多学者和研究人员的重视。目前对故障注入技术应用非常成功的领域之一是容错系统的可靠性验证。

文中介绍了可靠性测试的基本概念；叙述了可靠性测试过程以及各个角色在测试过程中的职责和任务；结合工作实践叙述了一个云化通讯软件实例采用故障注入技术在云环境开展可靠性测试工作的全过程；最后给出了测试结果分析。

1 软件可靠性基本概念

软件可靠性是指软件在所规定的环境条件下和规定的时间内正确地完成任务的能力。

1.1 软件可靠性的定义

1983年美国IEEE计算机学会对软件可靠性[1]给出如下的定义：

(1)在规定的条件下，在规定的时间内，软件不引起系统失效的概率。该概率是系统输入和系统使用的函数，也是软件中存在的缺陷的函数。

(2)在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。

经美国标准化研究所批准，该定义成为美国的国家标准。1989年中国国标GB/T-11457 采用了这个定义。

1.2 软件可靠性测试

软件可靠性测试包括：测试数据、测试环境的准备、测试运行、可靠性数据收集、可靠性数据分析和失效纠正。目的是为了发现软件运行中出现的错误，实现软件可靠性增长；验证软件的可靠性要求，定量评估软件的可靠度。

1.2.1 可靠性测试方法

可靠性测试方法主要有两种类型：

(1)基于操作剖面开展测试。

按照软件操作剖面[2]对软件进行随机测试的测试方法。根据软件在客户实际使用过程的各种操作的使用概率选择操作剖面，对软件系统进行可靠性测试。

(2)基于故障注入开展测试。

故障注入是按照选定的故障模型，采用人工的方法将故障注入到特定的目标系统中，同时采集系统对所注入故障的反应信息，通过这些信息对系统进行可靠性分析。

1.2.2 软件故障注入技术

与其他可靠性评价技术相比，故障注入方法能方便灵活、便捷有效地处理各种可靠性问题，得到了越来越多的关注。故障注入技术[3-6]有模拟实现的故障注入、硬件实现的故障注入和软件实现的故障注入三种。

软件故障注入是通过修改硬件或软件的状态变量或相关数据来模拟故障的产生，加速系统的失效，分为静态注入和动态注入两种类型[7-11]。

静态故障注入主要通过程序变异的方法，通过改变原程序，使被测系统文件静态的存在错误，从而使其运行时出现故障。静态注入占用很少的系统资源，能够较好地保持系统原来的时序，这种注入法有很好的优化性。

动态注入是在被测系统正常运行过程中，实现故障注入。该种方式是根据被测系统的运行状态或条件注入故障的，具有灵活性。

2 可靠性测试

2.1 可靠性测试过程

软件产品在需求分析阶段时，就需要启动针对软件的可靠性分析。可靠性测试过程[12]主要包括：仔细研读软件需求说明书、分析测试需求、提交测试策略、设计测试用例、搭建测试环境、执行可靠性测试、分析测试结果，如图1所示。

图1 可靠性测试过程

(1)制定测试计划：明确可靠性测试的对象、目的、内容、方法、进度要求。

(2)分析可靠性测试需求：根据需求说明书，确定可靠性测试方案，编写测试策略。

(3)设计测试用例：设计测试用例设计，编写自动化测试用例脚本。

(4)搭建测试环境：搭建测试所需的各种软硬件环境，如数据、网络、测试工具的安装和设置等。

(5)执行可靠性测试：采用手动或者自动化模式执行可靠性测试，记录测试数据。

(6)分析测试结果：根据可靠性测试数据，分析测试结果，提交测试报告。

2.2 可靠性测试过程中的角色

软件可靠性测试涉及到以下角色：系统工程师、测试架构师、软件开发工程师、软件测试工程师和质量工程师。各角色各司其职，分工协作共同完成软件可靠性测试。

各角色的职责和任务：

(1)系统工程师(SE)：跟客户确认对软件产品的需求，编写软件特性设计规格文档，并在特性设计规格文档中给出针对软件可靠性的相关技术方案和要求。

(2)测试架构师(TSE)：根据软件特性设计规格文档，编写可靠性测试策略与测试用例。

(3)软件开发工程师：根据软件特性设计规格文档进行编码、处理软件可靠性的各类故障问题。

(4)软件测试工程师：搭建可靠性测试环境，编写自动化测试用例脚本，执行软件可靠性测试。

(5)质量工程师(RQA)：负责对软件开发与软件测试过程中各项流程的监管与审核。

3 基于云网络环境的软件实例

该实例是一个云化通讯软件产品开发项目，总的代码量大约三百万行。基于云环境进行可靠性测试，在云网络环境中注入故障，测试软件产品对于环境的容错能力。

3.1 云环境的层级结构

软件产品实例的云环境的层级结构[13-15]如表1所示。

表1 软件产品运行的云环境层级结构

3.2 云网络环境的部署和软件产品的安装

3.2.1 配置硬件设备

S3900磁阵(存储设备)与11块E9000单板上架与连线；E9000单板与交换机系统连接，交换机系统可以连接局域网和广域网；通过网络登录E9000单板的设备管理页面，将所有的E9000单板下电之后的状态设置为PXE(preboot execute environment，预启动执行环境)启动状态。

3.2.2 部署单位私有云

安装FusionSphere软件(华为云操作系统，FusionSphere云操作系统从5.0之后的版本全部基于OpenStack)，其中一块E9000单板作为虚拟机软件的控制节点，将剩余的E9000单板通过PXE的方式加载到FusionSphere的硬件管理页面上；通过FusionSphere软件配置网络平面、对接存储设备、划分管理节点与服务节点等。

3.2.3 创建虚拟机

在管理节点下创建FusionSphere Openstack虚拟机；创建管理节点与服务节点；创建管理节点与服务节点的用户。

(1)登入管理节点用户，创建管理节点所需要的网络。

(2)登入计算节点用户，创建计算节点所需要的网络。

古代封建专制政权家天下，皇家也是基因论的忠实拥趸。皇帝号称真龙天子，代替上天行事。皇子阿哥之流自然顺理成章地“善游”。甭管他们是否天天只知拈弓弹雀、提笼架鸟、不务正业，只要生在皇家，便是龙子龙种，将来是一定要子承父业做皇帝的。打着君权神授的幌子，蒙蔽百姓，妄想家天下，历朝历代的皇帝概莫能外。秦始皇是第一个从皇帝名号上动此脑筋的，所以他自称“始皇帝”，妄想子子孙孙二世三世乃至万世地传承下去，可惜只传到二世，秦王朝就寿终正寝了。

(3)在管理节点用户下创建搭建CGP所需要的第三方用户。

创建16个虚拟机，虚拟机的规格数据包括操作系统、CPU、内存、系统盘、数据盘以及网络配置等。在虚拟机上配置网卡，在网卡上配置私有云IP地址。这些虚拟机组成VLAN局域网。

3.2.4 安装CGP网络管理平台(安装OMU虚拟机)

上传CGP(carrier grade platform)的版本包以及镜像包，虚拟机上添加网卡与浮动IP地址之后，分别安装主、备OMU虚拟机。OMU安装完成后，组成基于Client/Server结构的网络系统。OMU的客户端工具为LMT(local maintenance terminal)。

LMT工具通过MML(man-machine language)命令，对网元进行操作和维护。通过网络系统的管理用户(用户名admin)负责网络系统管理。

3.2.5 部署安装软件产品

通过LMT客户端工具安装软件产品，上传产品软件的版本包以及镜像包之后，安装软件产品，给产品业务虚拟机配置网络环境。软件产品安装完成后，涉及到故障注入的虚拟机如表2所示。

表2 虚拟机功能描述

4 搭建测试环境

4.1 故障注入方法

在本软件实例中，通过五种方法注入故障。

CFE(common fault-injection entry)工具是公司自研的Linux操作系统下的故障注入工具，可以针对软件产品进行CPU消耗故障、内存消耗故障以及多种网络故障的注入。

4.1.2 TC工具注入

TC(traffic control)流量控制器[16]，是Linux系统下的开源软件，可以为各类数据提供不同的带宽，从而控制它们的传输速度。在测试云化软件的可靠性时，可以使用TC工具注入网络丢包、错包以及时延等故障。

4.1.3 通过MML命令注入

通过LMT客户端登录OMU，通过执行MML命令实现软件模块重启、虚拟机复位，模块主备倒换故障注入。

4.1.4 通过ifconfig命令注入

ifconfig命令是Linux操作系统的环境配置命令，通过执行ifconfig命令，改变虚拟机网络配置，用于注入虚拟机网络平面端口故障。

4.1.5 通过openstack nova命令注入

在云环境中通过openstack虚拟化软件管理所有的虚拟机，执行可靠性测试时，可以通过openstack nova命令注入故障，故障类型为虚拟机重启与虚拟机迁移。

4.2 性能测试工具NTE

NTE(network traffic emulator)工具是公司自研的性能测试工具，可以对通讯软件产品在实际使用环境中的客户呼叫进行计算机仿真。在进行软件产品的可靠性测试时，需要在用户呼叫仿真的背景下，注入各种故障，来获取测试数据。根据测试数据分析软件产品的可靠性。

4.3 搭建测试环境

(1)部署软件实例的私有云网络环境；

(2)通过LMT客户端登上OMU后，执行MML命令部署软件实例的业务虚拟机与进程；

(3)通过LMT客户端登上OMU后，使用LMT上的“文件传输服务”将CFE工具和TC工具上传到OMU虚拟机之后，再通过scp命令将这两个工具安装到执行故障注入的虚拟机上；

(4)将性能测试工具NTE与自动化脚本工具GTR安装到指定执行机上。

5 基于云环境的可靠性测试

结合软件实例，介绍基于云环境的可靠性测试工作。

5.1 测试用例设计

测试架构师分析软件的产品的功能与性能测试特性之后，选定可靠性测试模型和注入故障类型，对虚拟机或者软件模块注入故障，开展可靠性测试，共设计40个可靠性测试用例，如表3所示。

表3 可靠性测试用例分类

5.2 可靠性测试流程

云化通讯软件实例的可靠性测试流程如图2所示。在测试环境中在启动业务软件和性能测试工具后，通过注入故障，开展测试工作。

图2 基于故障注入的云化软件可靠性测试流程

图2中专业术语注解：

CAPS(call attempt per second，每秒呼叫次数)：这里所指的呼叫次数包括成功呼叫(即呼叫接续成功，双方进行通话)次数和不成功呼叫(呼损)次数。

T1(业务故障时间)：故障注入时间到故障发生时间之间的时差，目前采用的故障注入时间到故障告警出现时间的差值。

T2(业务中断时间)：不成功呼叫(呼损)占用的时间；每隔固定的时间间隔查询读取呼叫器上业务呼损数sn；t=sn/CAPS，计算t的数值并且写入fail_caps数组中；最后选择数组中的最大值作为T2。

T3(业务自动恢复时长)：开始出现呼损的时间到不再出现呼损的时间之间的时差；在呼叫器上查询呼损数，一直到呼叫器上不再出现新的呼损(也就是呼损数sn不再增加)，然后取两个时间差值作为业务自动恢复时长。

5.3 自动化测试

该软件实例的可靠性测试采用自动化测试，脚本语言选择TCL，通过调用spider库中NTE的自动化的函数编写脚本和测试套，通过GTR工具编辑、调试、运行TCL脚本和测试套。

5.3.1 编写测试套

测试用例评审之后，测试工程师需要根据测试用例特点编写测试套完成测试环境的初始化，提供通用的测试模型参数，测试结束之后测试套进行测试环境清理。目前使用的呼叫模型参数有2种：

(1)透传模型：G711-G711，每秒20个呼叫(caps=20)，呼叫在线时长10 000 ms;

(2)转码模型：G711-G729，每秒5个呼叫(caps=5)，呼叫在线时长10 000 ms。

测试套的放置在指定路径下，供TCL自动化脚本调用。

5.3.2 编写自动化测试脚本

根据图2编写TCL脚本，主要对以下测试场景编写TCL脚本。

(1)调用测试套进行测试环境初始化，设置相关测试模型参数，启动性能呼叫；

(2)在MEID=0的CGP网元下，执行DSP TIME命令，并将查询到的时间存入变量time1，根据测试用例中的故障类型开始执行故障注入；

(3)在MEID=0的CGP网元下，执行LST ALM命令查询到告警产生的时间存入变量time2；

(4)将变量time2与time1的差值存入变量T1中，作为业务故障时间；

(5)执行故障注入之后，每隔固定的时间间隔，查询NTE上呼叫器的呼损数，呼损数除以caps，将结果写入数组fail_caps中。最后从数组fail_caps中取出最大的数值，存入变量T2中，作为业务中断时间；

(6)不断查询TTE工具上呼叫器的呼损数，一直到呼叫器上不再出现新的呼损(也就是呼损数不再增加)，将开始出现呼损到呼叫器上不再出现呼损之间的时长存入变量T3中，作为业务自动恢复时长；

(7)测试结束之后，统计到的数据T1、T2、T3以添加的方式写入指定路径下的csv文件中；

(8)清理测试环境，终止测试工作。

5.3.3 可靠性自动化脚本连跑

测试工程师完成自动化脚本编写之后，脚本经过测试架构师审查通过后，所有的脚本提交到配置库Git中，并将脚本同步提交到软件产品的自动化工厂。每一轮迭代开发结束之后，通过全部脚本自动化连跑，对软件产品进行可靠性测试，这样提高了测试效率。

5.4 测试结果分析

由测试工程师根据软件产品的可靠性规格基线与可靠性自动化测试的结果进行分析。表4给出了软件实例在云环境中，进程复位、倒换以及虚拟机复位这些场景对于T2(业务中断时间)的测试分析结果。

从测试的结果可知，复位与倒换故障注入时，待测进程与虚拟机上的业务中断时间在允许范围内，产品的可靠性较好。

其他测试数据由于篇幅所限，文中不再介绍。在可靠性测试过程中，没有达成软件可靠性基线指标的用例，测试工程师将测试的情况反馈给软件开发工程师，并和开发工程师一起定位解决。

表4 T2(业务中断时间)的可靠性测试分析结果

5.5 测试过程中遇到的典型问题

云化软件在可靠性测试过程中，遇到的一些典型问题，举例如下。

(1)测试过程中无法正常切换root用户导致脚本执行失败。

测试虚拟机迁移的场景时，需要切换为root用户，调用nova命令执行虚拟机迁移。测试过程中发现登录FusionSphere虚拟机化软件后台之后，脚本执行失败。经过定位发现，完成FusionSphere软件安装之后，需要修改/ettc/ssh/sshd_config文件，去掉对root用户加密限制；tcl自动化测试脚本才能正常切换到root用户，执行虚拟机迁移的nova命令。

(2)测试过程中未在脚本中加入环境恢复步骤。

测试虚拟机网络平面故障的场景时，执行ifconfig ethX down命令down掉虚拟机上的指定网口来实现故障注入；测试工作完成之后没有对down掉的网口进行恢复，直接进行下一个相关用例测试，导致测试脚本执行失败。定位脚本运行失败的原因时，发现了这个问题，在测试脚本中增加了恢复环境的场景，以后再没有出现这种情况。

在云环境中开展可靠性测试工作，有许多问题需要进一步进行深入探讨和研究。

6 结束语

随着云计算技术的高速发展，基于云化环境的软件在各个领域的应用不断普及和拓展。许多传统环境下的软件产品需要推出云化的软件版本，不仅需要关注软件的各种功能测试与性能测试，可靠性测试的重要性也逐步提升。基于云环境的可靠性测试是软件测试过程中的重要环节，尤其对于大型云化软件显得尤为重要。工作实践表明，做好基于云环境的软件可靠性测试工作，在软件开发过程中不断解决存在的各种问题，有助于提高软件产品的质量，提高上线后软件的安全性与稳定性，以更好地满足客户对软件产品的需求。