星载软件可靠性测试实践

石 柱，郑 重

(中国航天科技集团公司软件评测中心，北京100048)

0 引言

为验证星载软件的可靠性，在软件验收之前，应进行软件可靠性测试，以评估星载软件的可靠性是否能满足任务书规定的可靠性要求。软件可靠性测试一般在软件产品验收阶段进行，在软件需求方参与的情况下实施，其目的是在给定的统计置信度下验证软件产品是否达到了规定的可靠性指标要求。在测试过程中，软件版本是冻结的，即不会试图通过定位错误后再排出错误来解决所发现的失效。通过软件可靠性测试，得到一个二选一的结论，即软件是否已经达到了规定的可靠性指标［1］。目前，特别在航天等对可靠性要求较高得领域，还缺乏开展可靠性测试和评估的实践和经验，亟待开展软件可靠性测试方法的研究和实践工作。本文在对软件可靠性测试一般方法和过程研究的基础上，针对某星载嵌入式软件的特点，根据用户需求，给出了开展软件可靠性测试的过程、途径和方法，并给出了对该软件的可靠性评估结果，从而验证了该过程和方法的可行性。

1 软件可靠性测试方案

1.1 测试对象

本次测试对象是某星载嵌入式软件，该软件产品在设计上存在一些亟待解决的可靠性问题，例如，软件不定期复位 (复位间隔几周或几个月)、计算精度下降等，这些问题严重影响了空间飞行器任务的顺利执行。在对该型号软件在轨失效情况进行可靠性评估后发现:该软件不能满足卫星总体对该软件提出的可靠性要求 (平均无故障时间MTBF大于6个月，置信度大于0.6)，而且随着该软件关键等级的提高，以及新的应用需求，对该产品的可靠性提出了更高的要求。

在经过一系列可靠性分析和测试后，研制单位对该软件进行了修改，即本次可靠性测试的软件版本即为修改后的软件版本。本次测试目的即是验证修改后的软件是否能满足规定的可靠性指标要求。

1.2 测试过程

软件可靠性测试是指为了保证和验证软件的可靠性要求而对软件进行的测试，与一般软件测试不同，软件可靠性测试的主要目的不是发现所有的软件错误和缺陷，而是通过获取软件失效数据进行分析，评估软件当前的可靠性水平，预测未来可能达到的水平，从而验证软件可靠性的定量要求是否得到满足［2］。

根据以上特点，参考以往经验，此次软件可靠性测试工作过程如图1所示，主要包括7个工作环节。

图1 软件可靠性测试过程

(1)确定验收准则

根据软件的特点，以及用户的要求制定出适合的验收准则，以便能获得可用来判别验收通过与否所需的数据;

(2)定义失效

软件失效的定义是面向用户的，即用户不期望发生的那些故障才可算作失效，因此，在进行测试之前，首先要明确定义测试中软件发生哪些故障可以算作失效，以及失效的严重程度，便于数据的收集。

(3)构造使用剖面

所谓使用剖面是指:软件各种使用情况及其发生概率的集合。在使用信息分析的基础上，按照被测软件的实际使用规律，构造软件的使用剖面。

(4)生成测试用例

基于上述构造的软件使用剖面，通过程序生成测试数据及自动测试驱动工程文件 (含多个脚本文件)，该工程文件相当于测试用例集，以驱动高动态仿真器对该软件进行测试。

(5)准备测试环境

软件可靠性测试对测试环境有苛刻的要求，要求测试环境与被测软件的真实运行环境尽可能一致，并在测试期间不对软件进行任何修改，以保证软件失效率在此期间看成时恒定的。本次测试的环境由测试方和委托方合作开发专用的可靠性测试环境，包括测试设备、相关软件及环境。

(6)执行测试并收集分析测试数据

在上述工作准备就绪的情况下，执行可靠性测试，并通过可靠性测试平台中的监测功能收集测试数据及发生的失效数据，测试人员分析发生的失效事件，并将有效的失效记录下来。

(7)可靠性评价

根据测试期间发生的失效次数和时间，利用可靠性模型，评估软件的可靠性指标是否达到预期的可靠性指标要求，得出拒绝或接受被测软件的结论。

1.3 验收准则的确定

本次可靠性测试采用无失效考核方案，即根据该软件的可靠性定量指标——平均无失效运行前时间 (MTBF)，确定一个预定的可靠性测试连续无失效的累积时间 (设为T')，然后进行可靠性测试，若实际的累积连续无失效测试时间 (设为T)超过T'，即T＜T'，在给定的置信水平γ下认为达到了可靠性要求;如未达到要求，即T＜T'，则软件需要修改，那么在修改后仍需重新按无失效考核方案进行测试。

在开展测试之前，应用两种可靠性模型拟合 (指数分布模型、正态分布模型)对该软件在轨失效数据进行拟合，通过拟合结果发现，其失效间隔并不是一个稳定、均匀的分布，所以造成方差过大，因此，正态分布模型拟合该软件失效率是不适合的，尽管指数模型存在误差，但是相比正态分布模型的结果，指数模型的误差是可以接受的，因此，该软件的失效率服从指数分布，在这种情况下，无失效考核时间与MTBF的时间比计算公式为

由置信度γ=0.6可以计算得到:无失效考核时间为MTBF的0.91629倍，由MTBF=0.5年得到，如果投入一台被测件进行测试，其无失效执行测试时间为:0.5年×0.91629=0.458145年 (即168天)，即本次可靠性测试最少执行的时间是168天，在168天内如果没有发生一次失效，则可认为该软件达到了要求的可靠性水平［3］。

2 软件可靠性测试方法

参照GJB899《可靠性鉴定与验收试验》和用户需求，本次软件可靠性测试的关键步骤拟采取以下方法和途径:

2.1 定义失效

进行软件可靠性测试，首先需要明确定义软件失效，经与研制方的沟通，此次测试的失效定义为［4］:

(1)软件复位:发生主动复位或被动复位;

(2)无定位数据:连续半小时不能提供有效导航定位数据，软件也未复位。

2.2 构建测试环境

在测试过程中，投入一台星载嵌入式设备作为被测件，该设备接收高动态仿真器信号 (以下称动态机)，运行时间为168天;同时，又投入两台设备作为比对分析，其中包括一台动态机，该设备与被测件运行相同的测试用例，另一台接收静态天线信号 (以下称静态机)，两台设备运行时间均为168天。测试中引入比对设备的目的是，当被测设备发生故障时，能正确定位故障原因是否是设备本身问题还是仿真器信号问题，且CPU时间与日历时间一致。

为确保尽可能在真实环境进行可靠性测试，全面考核该软件的所有对外接口及使用剖面，应保持被测软件在整机环境中运行，即应保持该软件与其他软硬兼得正常数据交换和信号交换。通过高动态信号仿真器模拟接近真实运行状态的信号，并可通过改变电文源码、伪码类型、传播误差等因素考核该软件在各种信号输入条件下的故障发生率。

星载嵌入式软件可靠性试验平台包括运行平台和监测平台两个部分，其中运行平台设备主要包括受试设备 (包括监测数据采集模块);监测平台设备主要包括高动态仿真器、工控机、监测设备及监测软件等。该试验平台的设备连接图如图2所示。该环境在运行正确和稳定的前提下，提供如下功能:

(1)记录并输出测试过程中该软件发生复位的次数、时间和相关场景;

(2)记录并输出测试过程中发生连续半小时不能提供定位数据的次数、时间和相关场景。

图2 可靠性测试平台设备连接

2.3 构造使用剖面

软件可靠性测试的过程必须以某种方式近似地反映软件的真实运行情况，测试的基本过程要求首先确定一个以概率方式定量描述软件系统使用过程的统计模型，然后由模型产生测试用例，以求能合理地反映软件使用的统计规律。本次测试通过构造软件的使用环境和使用剖面来刻画软件的使用情况，其中，使用剖面不仅包括对软件操作和使用概率的描述，还包括可能的操作约束和序列信息。下面给出使用环境和使用剖面的构造过程［5-8］。

(1)使用环境的构造

使用环境的构建包括:导航星星座模型、大气模型、载体模型、天线模型，其中:

1)导航星星座模型主要是对导航星星历和历书的变化的模拟;

2)地球周围的大气层会影响信号的传输，引起测量误差，因此应该对这些误差进行修正。对于该卫星软件而言，因其工作在对流层之外，所以电离层效应是其中最重要的定位误差之一;

3)根据卫星的实际运行情况并通过以下设置来建立载体模型，包括:载体特性及动力学极限，载体轨道、载体指向;

4)根据卫星的实际运行情况并通过以下设置建立接收天线模型，包括:天线信号类型及通道分配、天线偏移量、接收天线模式;

(2)使用剖面的构造

在对软件使用信息分析的基础上，按照软件的实际使用规律，构造该软件的使用剖面，本次测试构造以下几个该软件的使用剖面，包括电文、信号功率、伪距随机噪声和载体动作，其中以电文剖面为例:

由于电文参数在实际运行中绝大多数情况下都较为稳定，但在某些情况下会出现异常，因此，电文剖面可根据电文参数正常和异常对电文进行划分。

1)根据与开发方沟通，电文正常的概率为0.99，异常的概率为0.01，按照导航电文不健康类型、电文精度和其他极端情况，又可将电文的异常类型分为9类;

2)每次发生电文异常的星数是随机的，即可能是一颗星，也可能是多颗星，对于单一导航星和所有导航星来说，电文的某一或全部的参数错误时随机和均等的。

电文参数异常可以根据以上导航星数和异常类型的不同组合和概率来构造剖面，最终共生成289个剖面。

在测试用例设计中，电文正常范围值由高动态仿真器来保证，对于异常值需要构造测试用例。根据导航星电文异常发生的概率和运行时间计算，需从288个异常剖面中随机抽取20个电文异常操作，最后将20组异常数据随机分配到168天的时间轴上。由于该软件的一个轨道周期大约是2个小时，因此，设定每个异常持续2个小时，一台仿真器需要构造10个不同的用例，即从288个电文异常剖面中抽取10个用例。

基于上述构造的该软件使用剖面，每个剖面的动作序列都以仿真软件可识别的工程脚本文件的形式加载到每个场景中，该工程文件可以驱动高动态仿真器对该软件进行测试。

2.4 执行测试

按照方案的要求，本次测试共设计测试用例11个，其中动态轨道10个用例，静态轨道1个用例。动态轨道用例在时间上是连续的，且顺次执行，共运行168天;每个轨道的输入域均按照前面构造的4个剖面中描述的输入空间及概率进行抽取。所有动态测试用例运行同一轨道，该轨道是以某卫星轨道为基础而设计的。

本次测试的终止条件是:在测试中，累积测试时间达到验证测试计划的时间，完成所有测试用例的执行，并且测试平台完整记录测试过程中的监测数据，表明被测软件通过验证测试，则终止可靠性验证测试，若验证测试过程中发生失效，并确认是被测软件导致的，表明被测软件未通过验证测试，则终止测试［9，10］。

2.5 数据采集

在测试运行过程中，软件未发生由于本身设计原因而导致的复位，即该软件未发生定义的失效。根据可靠性测试理论，由于两动态机是运行相同的测试用例，因此被测件的考核时间以其中最长的计算，而且以下运行或操作过程所耗费的时间也不能算作考核时间:

(1)星载设备换轨道过程中无高动态信号的时间，共计3小时;

(2)人为或外界意外因素导致被测件复位到重新接收高动态信号之间所耗费的时间，共计7小时;

通过以上分析和计算，最终被测件的无失效考核时间为168天。

3 测试结果分析

根据可靠性评估规程，以及无失效考核时间与MTBF的时间比计算公式

由置信度γ=0.6可以计算得到:MTBF=180(天)

因此，按照目前运行结果，MTBF为180天，达到了可靠性指标要求 (180天)。

以上过程、方法和结果适用于该软件在该使用剖面下的运行情况。

4 结束语

本文针对某星载嵌入式软件特点，结合一般软件可靠性测试的过程，给出了开展该软件可靠性测试的关键步骤的解决方法和途径，包括失效的定义、测试环境的搭建、使用剖面的构造和数据的采集，最后通过测试结果的分析，给出了该软件的可靠性评估结论。本次测试的实践过程证明了该方法的实用性和可行性，为该软件的评价和验收工作提供了决策依据，同时在测试中发现了一些一般软件测试无法发现的软件错误，有利于该软件可靠性的提高。

［1］Michael R Lyu.Software reliability engineering:A roadmap［C］//Proc of Future of Software Engineering，Minnesota，2007:153-170.

［2］IEEE Std 982.1-2005，IEEE standard dictionary of measures of the software aspects of dependability［S］.New York:IEEE Computer Society Press，2005.

［3］WU Yumei，RUAN Lian.Research on the acceleration principle of software reliability testing ［J］.Computer Applications，2006，26(6):1449-1451(in Chinese).［吴玉美，阮镰.软件可靠性测试的加速机理研究 ［J］.计算机应用，2006，26(6):1449-1451.］

［4］SHI Zhu，ZHENG Zhong.Case study on software reliability measurement［J］.Systems Engineering and Electronics，2011，33(1):239-242(in Chinese).［石柱，郑重.软件可靠性度量实例研究 ［J］.系统工程与电子技术，2011，33(1):239-242.］

［5］ZHANG Xu，SHI Zhu，WANG Kunsheng.A test case generation approach of software reliability based on usage profile［J］Computer Simulation，2009，26(12):82-85(in Chinese).［张旭，石柱，王崑声.基于使用剖面的软件可靠性测试用例生成方法 ［J］.计算机仿真，2009，26(12):82-85.］

［6］Vincent Almering，Michiel van Genuchten，Ger Cloudt，et al.U-sing software reliability growth models in practice［J］.IEEE Software，2007，24(6):82-88.

［7］FENG Erqiang，LIU Chang，ZHENG Jun.Analysis on principle of software reliability accelerated testing methods［J］.Computer Engineering and Design，2011，32(9):3087-3090(in Chinese).［封二强，刘畅，郑军.软件可靠性测试加速方法分析 ［J］.计算机工程与设计，2011，32(9):3087-3090.］

［8］CAI Jianping.New explore on test method for software reliability［J］.Computer Engineering and Design，2009，30(20):84-87(in Chinese).［蔡建平.软件可靠性测试方法新探 ［J］.计算机工程与设计，2009，30(20):84-87.］

［9］ZHANG Lei，ZHOU Jifeng，ZHANG Qiang.Study on a testing method of verifying software reliability［J］.Computer＆ Digital Engineering，2010，38(6):86-88(in Chinese).［张磊，周继峰，张强.系统软件可靠性验证测试方法研究 ［J］.计算机与数字工程，2010，38(6):86-88.］

［10］CHEN Chunxiu，MA Li.Research of software reliability test technology ［J］.Computer Engineering and Design，2010，31(21):96-99(in Chinese).［陈春秀，马力.软件可靠性测试技术研究 ［J］.计算机工程与设计，2010，31(21):96-99.］