CN101894068A - 一种嵌入式软件可靠性加速测试方法 - Google Patents

Abstract

本发明公开了一种嵌入式软件可靠性加速测试方法，通过建立软件任务剖面，来随机抽取产生软件任务序列，作为实际可靠性测试中施加的完整而有效的测试输入；测试过程中统计收集任务特征和任务状态，测试过程达到稳定过程后进入控制过程，施加测试策略，最后对软件可靠性进行工程评估。本发明控制过程中的测试策略的提出达到了合理高效地加速可靠性测试过程的目的，也拓展了对嵌入式软件进行可靠性测试的思路。基于软件任务剖面生成的软件任务序列，可以满足对复杂的输入条件的描述和覆盖，保证了可靠性测试数据的可信性；评估方法不依赖于失效数据的假设数学分布，适用于对精度没有过高要求的嵌入式软件的可靠性评估。

Description

一种嵌入式软件可靠性加速测试方法

技术领域

本发明涉及软件可靠性测试领域，具体地说，是指一种基于软件任务剖面的嵌入式软件可靠性加速测试方法。

背景技术

目前嵌入式软件被广泛应用于航空航天、金融、医疗、电信等各个领域。伴随着应用的发展，嵌入式软件的可靠性问题已成为人们所关注的焦点。软件可靠性测试是实现软件可靠性增长和对软件可靠性进行评估的有效途径。

但是，从测试的角度来看，由于嵌入式软件自身的实时特性和反应特性决定了嵌入式软件的输入受到取值大小、时序和时间响应等诸多条件的限制，输入条件十分复杂，几乎无法覆盖到软件所有可能的输入情况；另一方面，对比嵌入式软件的一般测试，可靠性测试的测试量更加庞大，测试效率问题也成为制约嵌入式软件可靠性测试广泛开展的瓶颈。

传统的软件可靠性测试方法中，作为可靠性测试输入的可靠性测试用例的生成都是基于穆莎(John Musa)所提出的操作剖面，这种方法简单实用，对运行之间没有相互影响、运行相互独立的软件来说非常有效。但是这种静态的操作剖面不能完全描述嵌入式软件的实际运行情况，目前，对嵌入式软件操作剖面的研究主要集中在对操作剖面的改进所形成的使用剖面，使用剖面多数是采取UML的活动图和顺序图对“使用”进行建模得到的，但是仍不能完全解决运行间存在的复杂的条件约束关系。另外，在施加用例运行测试的过程中除了有时根据条件使用一些测试自动化工具以外并没有针对性的采取软件可靠性测试策略来提高软件可靠性的测试效率。

发明内容

本发明为了解决嵌入式软件可靠性测试中所面临的困境，从嵌入式软件自身的特点入手，结合使用信息，构建一种嵌入式软件可靠性加速测试方法，使得可靠性测试用例最大可能地满足复杂的输入条件限制，测试过程的设计在不影响评估置信度的情况下，可以减少测试量。本发明提供的嵌入式软件可靠性加速测试方法，针对嵌入式软件建立软件任务剖面，用于嵌入式软件可靠性测试用例的生成，在测试过程中，根据稳定过程和控制过程中收集测试数据进行软件可靠性测试，实现提高软件可靠性测试效率的目的。

本发明提供的基于软件任务剖面的嵌入式软件可靠性测试方法，在测试用例生成上综合考虑软件自身特点和使用情况满足复杂的输入条件，在测试过程中提供控制策略提高测试效率，从而实现对嵌入式软件进行更全面、更具有针对性的可靠性测试。

本发明所提供的可靠性加速测试方法主要包括以下步骤：

第一步，建立软件任务剖面；

第二步，生成软件任务序列即软件可靠性测试用例；

在软件任务剖面完整和正确建立的基础上，随机抽取和生成软件任务序列，软件任务序列是在实际可靠性测试中施加的完整而有效的测试输入。

第三步，人工编写测试脚本，建立测试环境，开始测试；

第四步，测试过程中统计收集测试数据(包括任务特征和任务状态)，根据稳定判据判

定测试过程是否达到稳定过程；

第五步，进入控制过程，也同时收集测试数据(包括任务特征和任务状态)，施加控制

过程测试策略；

第六步，对软件可靠性进行工程评估，结束测试。

利用稳定过程和控制过程两个过程中收集到的测试数据(包括任务状态和任务特征)给出一种近似的软件任务可靠度评估方法。另外，可以选择和使用已有的软件可靠性评估模型，利用测试过程中收集到的失效数据对被测软件进行可靠性评估。

所述的稳定过程是指当任务状态覆盖率C达到某个级别C_T时，继续增加测试用例，软件的可靠性水平始终稳定在一个水平R，此时的软件可靠性增长十分缓慢，即认为达到“停滞期”。其数学描述为：

{|R_j-R_i|＜ε，ε→o⁺|(|Nt_j-Nt_i|→b)∧(C＞C_T)，j＞i＞0，b＞0，C_T＞0}

这里，b是规定的较小的正数，Nt_i表示第i组测试中测试用例的个数，Nt_j表示第j组测试中测试用例的个数，R_i表示第i组测试完成后得到的软件可靠性估计，R_j表示第j组测试完成后得到的软件可靠性估计。若两组测试的用例个数的差值接近于正数b，而对应的可靠性估计的差值小于某个规定的正数ε，同时任务状态覆盖率C大于或等于某个事先规定的级别C_T时，即认为已到达稳定过程。

所述的控制过程是指在稳定过程的基础上的一种追加测试的过程，应用针对性的测试策略，选择软件任务序列，加快软件缺陷的发现，从而保证被测软件在短时间内可靠性能够进一步提高。当软件可靠性增长达到目标值，即可以终止控制过程。

本发明与现有技术相比，具有以下明显的优势和有益效果：

1、本发明给出了一种新的软件任务序列的生成方法，可以满足对复杂的输入条件的描述和覆盖。

2、稳定过程的提出符合嵌入式软件运行的实际情况，对测试数据的收集和统计丰富了测试过程所应收集的数据类型和种类，为进一步的可靠性评估提供基础和依据。

3、控制过程中的测试策略的提出达到了合理高效地加速可靠性测试过程的目的，也拓展了对嵌入式软件进行可靠性测试的思路。

4、本发明提出的方法已应用在了某个航电嵌入式软件系统的工程实例中，证明了基于软件任务剖面生成软件任务序列，稳定过程与控制过程相结合的可靠性加速测试方法的可行性和有效性，通过了工程实例的考核和验证，该可靠性加速测试方法在工程应用方面具有较大的价值。

5、给出了任务可靠度的工程近似计算方法，它的优点是该评估计算方法不依赖于失效数据的假设数学分布，同时基于软件任务剖面生成的软件任务序列保证了可靠性测试数据的可信性。适用于对精度没有过高要求的嵌入式软件的可靠性评估。

附图说明

图1为本发明提供的软件可靠性加速测试方法的流程图；

图2为本发明开发软件任务剖面的流程示意图；

图3为本发明软件任务序列随机产生的示意图；

图4为实施例中由子任务集组成的INS系统的任务剖面示意图；

图5为实施例中对INS导航子任务集进行描述的示意图；

图6为实施例中对INS维护子任务集进行描述的示意图；

图7为实施例中任务状态覆盖率和累积覆盖率图。

具体实施方式

为了便于本领域普通技术人员理解和实施本发明，下面通过具体实施方式对本发明作进一步的详细和深入描述。

图1为本发明软件可靠性加速测试方法的流程图，该方法首先建立嵌入式软件任务剖面，利用随机方法生成软件任务序列(即可靠性测试用例)，开始测试后，首先进入到测试的第一阶段——稳定过程，随着测试的进行，根据稳定判据判断测试过程是否达到稳定，如果否，则继续执行软件任务序列进行测试；如果是，则进入到测试第二阶段——控制过程，在控制过程中施加相应的测试策略，对稳定过程和控制过程中收集到的测试数据(包括任务状态和任务特征)进行统计，然后给出软件可靠性工程近似评估，从而实现整个软件可靠性测试过程。具体实现步骤如下：

第一步，建立软件任务剖面，实现流程如图2所示，具体为：

(1)根据软件需求规格说明书和任务相关的要求，得到任务集T；

(2)进一步将任务集T划分，得到任务集T中所包含的子任务集T_i。特殊情况下，子任务集T_i中只包含一个任务，i＝1，2，3......n；n表示任务集T中子任务集的个数。

(3)分别确定各子任务集T_i之间的时序转移关系和概率转移关系；

(4)按照需求和使用信息分析每个子任务集T_i中任务t_ij(i＝1，2，...，n；j＝1，2，...，n_i)，其中i表示任务集中的子任务集的序号，j表示子任务集T_i中的任务序号，n_i表示子任务集T_i中的任务个数。

根据子任务集之间的时序转移关系和概率转移关系，画出子任务集转移图，如图3中的子任务集T₁，T₂，T₃和T₄；

(5)确定任务间的时序转移关系和概率转移关系，画出任务转移图，按照任务描述方法对每个任务进行描述，如图3中子任务集T₃中从任务t₃₂到任务t₃₃的转移概率为P_32-33，子任务集T₄中从任务t₄₅到任务t₄₂的转移概率为P_45-42；

(6)将子任务集逐层分解，如果需要可以进一步分解为子子任务集，如图3中的T₂₁和T₂₂，T₃₁和T₃₂)，直到底层的子任务集或子子任务集可以直接由一个或几个任务组成，确定任务间的时序转移关系和概率转移关系，画出任务转移图，按照任务描述方法对每个任务进行描述，从而得到被测软件的软件任务剖面。

建立软件任务剖面的过程中有两个重要问题：一是确定任务之间的关系；二是任务的具体描述方法。

软件任务剖面描述了子任务集、子子任务集以及任务间的时序转移关系和概率转移关系，任务与时间密切相关，任务之间在时间上具有的关系称之为时序转移关系。主要包括顺序关系、并发关系和偏序关系三种，所述的顺序关系是指一个任务发生并完成后，另一任务在其后发生；所述的并发关系是指多个任务同时发生、同时进行的关系；所述的偏序关系是指每个任务都有明确的发生时刻，如一个任务在某一时刻发生，另一任务要求在另一时刻发生。偏序关系既可用绝对时间来表示也可用任务间的相对时间来表示。特殊地，顺序关系是偏序关系在时间轴上的一种连续分布。子任务集之间的时序转移关系类比任务之间的时序转移关系，同样具有顺序、并发和偏序三种关系。

软件任务剖面是动态的：任务之间不是相互独立的，除了存在上述的时序转移关系以外，有的任务之间还存在条件约束关系，即任务的发生是以一定条件的达到作为前提的，即这些条件是任务发生的必要、非充分条件。这些条件可能是用户的一个按键，也可能是系统要满足的一个状态等。在划分子任务集时保证了子任务集之间是相互独立的，因此子任务集之间不存在上述的条件约束关系。

概率转移关系包括两种：第一种是指上一个子任务集完成后转移到下一子任务集的发生概率；第二种是指同一子任务集中不同任务之间发生转移的概率。概率信息的获取主要来自两方面：一是参考历史信息，概率的确定基于对以往使用信息的统计；二是对于无历史信息记录的软件，则根据软件用户的需求并参照经验给定。

任务描述方法的基本步骤为：

(1)确定实现任务的所有事件{E_i|i＝1，2，...，n}；

(2)确定事件之间的时序转移关系和条件约束关系；

(3)确定表示事件的变量的属性，即给出表示事件的变量，确定变量类型、取值或取值范围。表示事件的变量类型包括以下三种：

(a)离散型变量：主要有枚举型、布尔型和字符型。对于每一种类型的离散型变量，需要在描述中给出各种取值的概率，但是要注意每个离散型变量V_i(i＝1，2，...，m，m是变量V的个数)的各个取值的概率(

)_j之和必须满足(j表示变量V_i的第j种取值情况，n_i表示变量V_i取值的个数)。

(b)连续型变量：主要有整型和浮点型，对于这种类型的连续型变量，其取值范围由取值区间的集合表示，即取值范围可以划分为多个取值区间，并给出在这些取值区间上分别取值的概率，保证概率之和为1。例如，连续型变量X有m个取值区间，则变量X在所有m个取值区间的取值概率之和应为1，即

(j表示变量X的第j种取值情况，m表示变量X取值区间的个数)，取值区间的分布情况与任务的实际执行情况密切相关，所以分配取值的概率时也要考虑到实际情况。

(c)与时间相关的变量：前两种变量是通过取值来描述输入行为的变量，对于嵌入式软件，其输入行为不仅与取值相关而且与时间有关，因此表示事件的输入变量还应该有这样一类具有时间特性的与时间相关的变量。例如，对于某种输入行为随时间呈现一定的变化规律，则可以用服从相应的数学分布的与时间相关的变量来表示。

第二步，在软件任务剖面的基础上，通过随机抽取产生用于进行可靠性测试的软件任务序列。

首先定义软件任务序列是带有时间标签的一组可能存在关系的任务t_ij(i＝1，2，...，n；j＝1，2，...，n_i)组成的一次软件运行，每个任务可能来自于不同的任务集、子任务集或子子任务集。软件任务序列集合TSP的数学表达式为：{TSP|TSP＝<tsq_k，P_k>，k＝1，2，...，N}，tsq_k表示第k个软件任务序列，P_k表示第k个软件任务序列发生的概率，N表示软件任务序列的个数。因此，软件任务剖面也可以看作是由一系列软件任务序列及这些软件任务序列发生的概率组成的软件任务序列集合。一个软件任务序列对应软件可靠性测试的一次运行，也就是一个完整的能用来进行软件可靠性测试的测试用例。软件任务序列按照软件任务剖面随机抽取生成，同时刻画软件任务剖面的要求。

图3给出了在子任务集、子子任务集、任务基础上产生软件任务序列的示意图，也表示了子任务集、子子任务集、任务和软件任务序列四者之间的关系，图中椭圆表示子任务集或子子任务集或任务，箭头表示时序转移关系，线上标注转移概率，图3中有四个子任务集T₁，T₂，T₃和T₄，子任务集T₁中有4个任务t₁₁、t₁₂、t₁₃和t₁₄；子任务集T₂包含两个子子任务集T₂₁和T₂₂，其中，任务t₂₁、t₂₅属于子子任务集T₂₁，任务t₂₂、t₂₃和t₂₄属于子子任务集T₂₂；子任务集T₃中也包含两个子子任务集T₃₁和T₃₂，其中，任务t₃₁、t₃₅和t₃₆属于子子任务集T₃₁，任务t₃₂、t₃₃和t₃₄属于子子任务集T₃₂；子任务集T₄中有6个任务t₄₁、t₄₂、t₄₃、t₄₄、t₄₅和t₄₆。图3中有多个软件任务序列，例如，由t₁₂，t₂₁，t₂₄，t₄₅，t₄₂和t₄₆构成了一个软件任务序列t₁₂→t₂₁→t₂₄→t₄₅→t₄₂→t₄₆。

第三步，人工编写测试脚本，建立测试环境，开始测试，执行软件任务序列。

对第二步根据软件任务剖面随机生成的软件任务序列，人工编写测试脚本，建立好测试环境，然后开始测试，执行软件任务序列。

第四步，收集测试数据，对任务状态的覆盖情况进行记录和统计。所述的测试数据是指任务特征和任务状态数据。

所述的任务特征是任务实现过程中相对独立的有特性的行为。软件任务是由一个或多个任务特征来共同实现，它是这一任务的执行区别于其它任务的执行的标志。任务特征集合TC(Test Characteristics)信息可以根据软件任务剖面提取，一个软件任务序列中必包含一个或多个任务特征，任务特征组成的集合为：

TC＝{tc_i|i＝1，2，...，N}

N为任务特征的个数，tc_i表示第i个任务特征。

满足任务特征之间相互独立，即tc₁∩tc₂∩...∩tc_i＝Φ。

所述的任务状态是任务特征的动态属性，用任务状态ts_ij来刻画和表示任务特征，同时描述任务特征的具体实现，即某一任务特征由若干个任务状态实现，对于任务特征集合TC中的第i个任务特征tc_i，存在tc_i＝{ts_ij|j＝1，2，...，M_i}，其中，j表示第i个任务特征tc_i的任务状态序号，M_i表示第i个任务特征tc_i所包含的任务状态ts_ij的个数。

嵌入式软件在运行过程中所经历的所有任务状态组成的集合定义为任务状态空间，用S表示。对嵌入式软件来说，可以通过软件任务序列的运行实现对任务状态空间S的覆盖。

$S=\left\{\underset{i=1}{\overset{N}{\&cup;}}\underset{j=1}{\overset{M_i}{\&cup;}}{\mathrm{ts}}_{\mathrm{ij}}\right\}$

用S表示嵌入式软件的任务状态空间，tc_i表示软件的一个任务特征，则根据上述分析存在关系同理，某一个任务特征

其中，tc_i表示由任务状态ts_i1，tc_i2，..，ts_iMi构成的一个任务特征，假设对每个任务状态ts_ij(i＝1，2，...，N；j＝1，2，...，M_i)有Y_ij个取值，则由任务状态ts_ij(i＝1，2，...，N；j＝1，2，...，M_i)构成的任务状态空间共有

个任务状态，种取值，由任务状态及其取值产生的组合情况更加复杂。由此看来，任务状态空间是非常庞大的，但是通过运行由软件任务剖面生成的软件任务序列可以有规律地实现一定的任务状态覆盖。

任务状态覆盖率C是指实际测试中软件经历的不同的状态个数与状态空间中所有状态个数的比值。

以任务状态覆盖率作为确定测试过程是否达到稳定的判据，前面所述用来描述稳定过程的公式中：

{|R_j-R_i|＜ε，ε→o⁺|(|Nt_j-Nt_i|→b)∧(C＞C_T)，j＞i＞0，b＞0，C_T＞0}

C_T即为这里所指的稳定判据。C_T表示当任务状态覆盖率C达到一定程度(软件不同，C_T不同，通常可认为是0.85-0.9之间)会产生饱和效应，可靠性增长会进入到一定的“停滞期”即增长变得十分缓慢，此时认为软件可靠性测试达到了稳定。但大多数情况下，此时软件可靠性增长仍然未达到预期的软件可靠性目标值。因此就要进入第二阶段控制过程。

第五步，进入控制过程，施加控制过程的测试策略，同时也收集测试数据。控制过程是指在稳定过程的基础上的一种追加测试的过程，所应用的测试策略(特别是在软件任务序列的选择方面)加快了软件缺陷的暴露，随着对暴露的软件缺陷的修改和移除从而进一步实现软件可靠性的增长以达到预期的软件可靠性目标值。

为了提高控制过程的效率，控制过程的测试策略如下：

(1)对测试过的完全相同的软件任务序列不再测试，同时对测试过的相似软件任务序列也不再测试。

所述的相似软件任务序列是指软件任务序列中的任务的集合相同、时序相同，而对于其中的某一任务，其任务特征和任务状态可以不同。

(2)加入对可靠性影响大的软件任务序列。

在测试中，任务状态通常用一个状态变量表示，该状态变量被称为任务状态变量，对任务状态变量为浮点型的，则将该任务状态变量的取值划分为k个区段，落在这k个区段中每一段的取值的贡献按1/k折合，以此类推，枚举型变量有q个取值，则每个取值的贡献按1/q折合。

在测试中，用任务特征对可靠性评估的贡献f(d_i)和任务特征的各种任务状态对可靠性评估的贡献g(s_ij)来衡量对可靠性的影响，所谓加入对可靠性影响大的软件任务序列等同于加入具有如下特征的软件任务序列：

(a)任务特征对可靠性评估的贡献f(d_i)：

F(D)＝{f(d_i)≤1|i＝1，2，...，n}

对F(D)中所有f(d_i)按照从大到小排序，包含相对较大的f(d_i)的软件任务序列认为是对可靠性影响较大的软件任务序列，一般取F(D)集合中排列前30％的为相对较大的f(d_i)。

(b)任务特征的各种任务状态对可靠性评估的贡献g(s_ij)：

$G\left(S_i\right)=\left\{g\left(s_{\mathrm{ij}}\right)\right|j=\mathrm{1,2},...,m,\underset{j=1}{\overset{m}{\mathrm{\&Sigma;}}}g\left(s_{\mathrm{ij}}\right)=1\}$

对G(S_i)中所有g(s_ij)按照从大到小排序，包含相对较大的g(s_ij)的软件任务序列认为是对可靠性影响较大的软件任务序列，一般取G(S_i)集合中排列前30％的为相对较大的g(s_ij)。

(c)任务状态

对任务状态验证进行统计：

只要任务状态s_ij的任务状态变量的取值的所有情况中有一种情况被覆盖到，认为该任务状态s_ij已验证，则v(s_ij)＝1。如果任何一种情况都没有被覆盖到，认为该任务状态s_ij没有验证，v(s_ij)＝0。将没有验证的任务状态s_ij作为对可靠性影响较大的软件任务序列。

(3)运行关键的软件任务序列：这里关键的软件任务序列是指遍历到关键或重要的任务特征的软件任务序列，即任务特征对可靠性评估的贡献f(di)大，且含有多个任务(通常任务个数要大于等于3)的软件任务序列。此外，将运行失败产生后果严重度高的软件任务序列也看作是关键的软件任务序列，需要在控制过程中优先施加。

第六步，对软件可靠性进行工程评估，计算软件的任务可靠度，结束测试。

软件的任务可靠度：通常定义为软件在软件任务剖面所规定的时间内和规定的条件下，完成规定任务的能力，为任务可靠性；任务可靠性概率度量为任务可靠度。任务可靠度分为单任务可靠度和多任务可靠度，对于复杂的嵌入式软件而言，任务可靠度的考量通常是基于复杂的多个任务的执行结果，因此本发明中的任务可靠度即指多任务可靠度。

本发明中利用测试数据即任务特征和任务状态数据的相关信息计算软件的任务可靠度，给出软件任务可靠度的近似计算式：

$R=\frac{\underset{i=1}{\overset{n}{\mathrm{\&Sigma;}}}f\left(d_i\right)*(\underset{j=1}{\overset{m_i}{\mathrm{\&Sigma;}}}g\left(s_{\mathrm{ij}}\right)*v\left(s_{\mathrm{ij}}\right))}{n}$

式中，n为任务特征的个数，m_i为任务特征tc_i所包含的任务状态的个数。

实施例

应用本发明提供的嵌入式软件可靠性加速测试方法对某惯性导航系统(以下简称INS)的实时控制软件进行软件可靠性加速测试，INS的主要功能包括导航计算、过程控制、故障处理等。INS软件通过1553B总线与DCMP、DTE、FCS、MC、CADC等11个航电子系统进行数据交换，通过各设备之间的控制命令数据实时传输保证过程控制和故障处理等，具体测试过程如下：

第一步，软件任务剖面的建立。

根据本发明中提出的软件任务剖面的生成方法，首先对软件的需求规格说明进行分析，明确软件的功能集，根据各功能的特点以及功能之间的联系，得到软件的任务集(即INS所有的任务的集合)和子任务集，进而分析得到每个子任务集中的任务，见表1，其中，导航子任务集中包含系统备份和导航数据人工修改两个子子任务集：

表1INS的子任务集及任务列表

由表1中可以得到INS的自检测、导航、姿态模式、维护、INS对准、状态监控、进场数据修改和飞行结束共8个主要子任务集以及各子任务集中所包含的主要任务总共22个，通过分析各子任务集之间的时序转移关系和概率转移关系以及每个子任务集中任务的时序转移关系和概率转移关系，就可以得到INS的8个主要子任务集的软件任务剖面，它是由子任务集组成的INS系统的任务剖面的进一步描述。由于篇幅所限，本实施例中只对导航和维护两个比较典型的子任务集举例描述，如图5和图6所示，图中的每个椭圆都表示一个任务，对于相对复杂的任务用任务描述图表示；对于类似于只有一个事件的简单任务则可以直接确定表示事件的变量及取值。

第二步，生成软件任务序列。

根据表1INS的子任务集及任务列表，归纳得到INS每个子任务集中的任务所具有的任务特征，从而进一步得到每个任务特征相应的任务状态，用表2给出。

表2INS的任务特征和任务状态

对任务进行细化和分解，考虑软件的使用，分析软件的可测任务和相应的软件任务序列，获得软件任务序列，如表3所示为一个软件任务序列：

表3某个软件任务序列

时间(ms)	输入	具体变量	前提条件
				25	加电BIT	MAIN_MODE＝IBIT
9852	快对准	SUB_MODE＝FAST	初始化完成
				12506	罗经对准	SUB_MODE＝GC	初始化完成
13417	转导航	MAIN_MODE＝NAV	对准完成
				45610	修改59号机场的经度	LONGITUDE＝1236942563	初始化完成
45610	修改59号机场的纬度	LATTITUDE＝25634	初始化完成
				45610	修改59号机场的高度	ALTITUDE＝10521	初始化完成
103289	CADC备份	CADC BUSTATIC-PRES SURE-BUALTITUDE-DEGRADED	导航
				1224563	结束飞行	EOF	初始化完成
	关机	关闭电源

注：由于被测软件主要是通过1553B总线进行通讯的，有特定的数据传输格式，这里就不再具体列出符合格式要求的数据，仅用有逻辑含义的变量表示。

第三步，人工编写测试脚本，建立测试环境，开始测试。

第四步，测试过程中统计任务特征和任务状态，根据稳定判据判定测试过程是否达到稳定过程。

任务状态变量根据类型会生成更多的任务状态：

①离散型任务状态变量：例如，查看MFL清单的第一页、下一页、上一页、最后一页；②布尔型任务状态变量：例如，DTE数传设备的开关；③连续型任务状态变量：例如，经纬高的修改范围；④数组形式的任务状态变量：备份数据，其中包括操纵目标号、经度、纬度、高度等多种信息，故障清单列表也是一种数组形式的任务状态变量。

基于软件任务剖面生成软件任务序列，将每50个软件任务序列设为一组，将生成的1100个软件任务序列编为22组，对每组软件任务序列执行中的任务状态覆盖率和累积任务状态覆盖率进行统计见表4，同时在实验的过程中，记录软件出现失效的软件任务序列号。

表4INS加速实验过程

图7给出了该过程的任务状态覆盖率和累积覆盖率图，结合表4和图7可以看出：执行了16组800个软件任务序列后累积任务状态覆盖率就达到了83.1％，但是再继续测试3组(17组～19组)150个累积任务状态覆盖率只增加了0.5％，特别是再继续测试3组(20组～22组)150个用例覆盖率保持在83.6％没有发生变化，此时可以进入到第二个阶段控制过程阶段。

第五步，测试过程中收集测试数据，施加控制过程测试策略。

根据控制过程的测试策略，继续分四组(每组30个)共计追加测试用例120个。表4的控制过程阶段部分分别给出了追加的每组软件任务序列(30个)对覆盖率的影响情况。表5是对控制过程中测试用例追加情况的说明，可以看到，每组测试用例基本都是关键软件任务序列，对可靠性贡献大(大于0.5)的任务特征和任务状态都占到50％左右，另外，测试用例会针对那些没有验证过的任务状态，由此体现了控制过程追加测试用例的准则。

表5控制过程追加测试用例表

序号	追加软件任务序列数目	关键软件任务序列个数	f(di)＞0.5所占百分比	g(sij)＞05所占百分比
					1	30	28	62％	60％
2	30	28	58％	57％
					3	30	27	54％	49％
4	30	26	51％	48％

在第26组测试用例运行后，任务状态累积覆盖率达到了93.9％，此时控制过程结束。再挑选运行一组30个软件任务序列，在执行过程中没有发现失效(即无失效运行)。

第六步，进行软件可靠性工程近似评估。

通过对这30个软件任务序列中任务特征和任务状态的统计，利用任务可靠度的工程近似算法，得到此时软件的任务可靠度。

结果分析说明：

(1)根据任务可靠度的工程近似算法计算得到INS的任务可靠度。稳定过程中共测试22组1100个软件任务序列；控制过程中共测试4组120个软件任务序列，过程结束。此时，任务状态累积覆盖率达到了93.9％(最后两组该覆盖率是相同的)，且运行最后一组软件任务序列不再出现失效，因此经过稳定过程和控制过程后的软件可靠性测试已经在一定程度上使得被测软件的可靠性得到了比较充分的增长。计算任务可靠度时，挑选运行一组30个软件任务序列没有发现失效(即无失效运行)通过对这30个软件任务序列中任务特征和任务状态的统计得到软件的任务可靠度，此时得到的评估结果是比较可信的。

可靠性测试是面向使用的测试，对于实时嵌入式软件基于任务的测试方法也是这一思想的一种体现，正是由于可靠性测试的这一特点决定了其测试的用例要多，测试的时间要长，通常认为由此而产生的重复测试是对某些功能的覆盖，而不同路径下功能的运行有可能产生不同的效应引发缺陷，这也是可靠性测试与覆盖测试不同之处，因此很多人认为的软件可靠性测试就该是长时间测试甚至是重复测试。但是通过这个实例可以发现，当测试用例(软件任务序列)的个数远小于统计最小测试量时，不仅是某些单一任务的覆盖重复，而且软件任务序列也产生了重复，也就是说会产生同一路径的重复执行，因此如果再继续进行可靠性测试，势必造成资源的浪费。

(2)同时，到有些理论上指导测试的停止准则在工程实践中会产生很大的差异，例如用统计理论估计最小测试量：

$N_{\min }={\left(\frac{{\mathrm{\&Phi;}}^{-1}\left(\frac{\mathrm{\&alpha;}+1}{2}\right)}{\mathrm{\&epsiv;}}\right)}^2\&times;(\frac{1}{\mathrm{Min}\left\{p_i\right\}}-1)$ (i＝1，2，...，m)

当取置信度α为0.7，ε＝0.2，Min{p_i}＝0.0108时，

计算得到最小测试量

$N_{\min }={\left(\frac{{\mathrm{\&Phi;}}^{-1}\left(\frac{0.7+1}{2}\right)}{0.2}\right)}^2\&times;(\frac{1}{0.0108}-1)={\left(\frac{1.04}{0.2}\right)}^2\&times;92=2488$

为此，在稳定过程执行的1100个测试用例的基础上，还是以50个任务序列为一组继续进行可靠性测试，测试结果记录见表6，当运行2488个软件任务序列后，状态覆盖率只达到83.9％；而稳定过程中在900个软件任务序列执行后，状态覆盖率就已经达到了83.5％，见表4。也就是说，当用例增加了1588个而状态覆盖率增加了0.4％，可以认为这部分测试的意义是很微乎其微的，另外83.9％的状态覆盖也并不充分，会同时使得测试结果的可信性受到一定的质疑。

表6一般可靠性测试过程

序号	本组软件任务序列个数	累积软件任务序列个数	本组任务状态覆盖率(％)	累积任务状态覆盖率(％)	失效个数
						23	50	1150	18.9	83.6	0
24	50	1200	20.2	83.6	0
						25	50	1250	18.8	83.6	0
26	50	1300	19.5	83.6	0
						27	50	1350	17.8	83.6	0

28	50	1400	19.6	83.6	0
						29	50	1450	20.1	83.6	0
30	50	1500	24.2	83.6	0
						31	50	1550	16.5	83.6	0
32	50	1600	18.5	83.6	0
						33	50	1650	19.4	83.7	0
34	50	1700	17.1	83.7	0
						35	50	1750	18.3	83.7	0
36	50	1800	18.7	83.7	0
						37	50	1850	19.2	83.7	0
38	50	1900	19.5	83.7	0
						39	50	1950	22.4	83.8	0
40	50	2000	20.7	83.8	0
						41	50	2050	20.1	83.8	0
42	50	2100	18.9	83.8	0
						43	50	2150	18.9	83.8	0
44	50	2200	23.1	83.8	0
						45	50	2250	17.8	83.8	0
46	50	2300	17.4	83.8	0
						47	50	2350	18.6	83.9	0
48	50	2400	20.3	83.9	0
						49	50	2450	19.1	83.9	0
50	38	2488	19.3	83.9	0

(3)实时嵌入式控制软件多为安全关键软件，所谓安全关键软件一方面是对可靠性的要求较高，而另一方面强调的是某些缺陷一旦发生会产生严重的后果。但是往往诱发这些有严重后果的关键缺陷的任务在使用中的概率很低，而使用频率高的任务在前期的功能测试或系统测试中已经经过了充分的测试，从而这些任务引发失效的概率会非常低，因此对安全关键软件的测试不但要考虑基于使用的统计规律，还要关注有可能引发关键缺陷的任务，包括这类任务的任务特征及任务状态，因此本发明中在控制过程引入的控制准则，而且实验结果表明：在控制过程中追加测试用例时，运行序号为24即第24组中的任务序号为1147的关键软件任务序列，在测试过程中确实发现了某重要缺陷(即：掉电时DTE数据传输过程中漏传数据)；在所做的对比实验中，还是以50个软件任务序列为一组作非加速方法的测试(即一般可靠性测试)，当抽样总数N＝4000时，能够测试到该缺陷的软件任务序列才出现一次，运行序号为76即第76组软件任务序列中任务序号n＝3787的软件任务序列在执行的过程中该缺陷才被发现。

Claims (7)

1.一种嵌入式软件可靠性加速测试方法，其特征在于：

第一步，建立软件任务剖面；

第二步，根据软件任务剖面，通过随机抽取产生软件任务序列，作为实际可靠性测试中施加的完整而有效的测试输入；

第三步，人工编写测试脚本，建立测试环境，开始测试；

第四步，测试过程中统计收集任务特征和任务状态，根据稳定判据判定测试过程是否达到稳定过程；

第五步，进入控制过程，施加测试策略，终止控制过程；

第六步，对软件可靠性进行工程评估，结束测试；

利用稳定过程和控制过程两个过程中收集到的测试数据计算被测软件的任务可靠度，软件任务可靠度的近似计算式如下：

$R=\frac{\underset{i=1}{\overset{n}{\mathrm{\&Sigma;}}}f\left(d_i\right)*(\underset{j=1}{\overset{m_i}{\mathrm{\&Sigma;}}}g\left(s_{\mathrm{ij}}\right)*v\left(s_{\mathrm{ij}}\right))}{n}$

式中，n为任务特征的个数，m_i为任务特征tc_i所包含的任务状态的个数。

2.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于：第一步中所述的建立软件任务剖面，实现流程如下：

(1)根据软件需求规格说明书和与任务相关的要求，得到任务集合T；

(2)进一步将任务集合T划分，得到任务集合T中所包含的子任务集T_i，i＝1，2，3……n；

(3)分别得到各子任务集T_i之间的时序转移关系和概率转移关系；

(4)确定每个子任务集T_i中任务t_ij的时序转移关系和概率转移关系，画出子任务集转移图；

(5)在每个子任务集中画出任务的转移图，同时按照任务描述方法对任务进行描述；

(6)将子任务集逐层分解，如果需要，进一步分解为子子任务集，直到底层的子任务集或子子任务集直接由一个或几个任务组成，得到被测软件的软件任务剖面。

3.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于：第四步中，当任务状态覆盖率C达到级别C_T时，继续增加测试用例，软件的可靠性水平始终稳定在一个水平R，其数学描述为：

{|R_j-R_i|＜ε，ε→o⁺|((Nt_j-Nt_i)→b)∧(C＞C_T)，j＞i＞0，b＞0，C_T＞0}

其中，b是规定的较小的正数，Nt_i表示第i组测试中测试用例的个数，Nt_j表示第j组测试中测试用例的个数，R_i表示第i组测试完成后得到的软件可靠性估计，R_j表示第j组测试完成后得到的软件可靠性估计，若两组测试的用例个数相差趋近于正数b，而对应的可靠性估计差值小于规定的正数ε，同时任务状态覆盖率C大于级别C_T时，即认为已到达稳定过程。

4.根据权利要求3所述的嵌入式软件可靠性加速测试方法，其特征在于：所述的级别C_T选取在0.85-0.9之间。

5.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于：第五步中所述的测试策略是指：

(1)对测试过的完全相同的软件任务序列不再测试，同时对测试过的相似软件任务序列也不再测试，所述的相似软件任务序列是指软件任务序列中的任务的集合相同、任务之间的时序转移关系相同，而对于其中的某一任务，其任务特征和任务状态不同；

(2)加入对可靠性影响大的软件任务序列；

(3)运行关键的软件任务序列。

6.根据权利要求5所述的嵌入式软件可靠性加速测试方法，其特征在于：所述加入对可靠性影响大的软件任务序列等同于加入具有如下特征的软件任务序列：

(a)任务特征对可靠性评估的贡献f(d_i)：

F(D)＝{f(d_i)≤1|i＝1，i＝1，2，...，n}

对F(D)中所有f(d_i)按照从大到小排序，包含相对较大的f(d_i)的软件任务序列认为是对可靠性影响较大的软件任务序列，取F(D)集合中排列前30％的为相对较大的f(d_i)；

(b)任务特征的各种任务状态对可靠性评估的贡献g(s_ij)：

$G\left(S_i\right)=\left\{g\left(s_{\mathrm{ij}}\right)\right|j=\mathrm{1,2},...,m,\underset{j=1}{\overset{m}{\mathrm{\&Sigma;}}}g\left(s_{\mathrm{ij}}\right)=1\}$

对G(S_i)中所有g(s_ij)按照从大到小排序，包含相对较大的g(s_ij)的软件任务序列认为是对可靠性影响较大的软件任务序列，取G(S_i)集合中排列前30％的为相对较大的g(s_ij)；

(c)任务状态：

对任务状态验证进行统计：

只要任务状态s_ij的任务状态变量的取值的所有情况中有一种情况被覆盖到，认为该任务状态s_ij已验证，则v(s_ij)＝1，如果任何一种情况都没有被覆盖到，认为该任务状态s_ij没有验证，v(s_ij)＝0，将没有验证的任务状态s_ij作为对可靠性影响较大的软件任务序列。

7.根据权利要求5所述的嵌入式软件可靠性加速测试方法，其特征在于：所述的关键软件任务序列是指遍历到关键或重要的任务特征的软件任务序列，即任务特征对可靠性评估的贡献f(di)大，且含有多个任务的软件任务序列；此外，将运行失败产生后果严重度高的软件任务序列也看作是关键的软件任务序列，需要在控制过程中优先施加。

Images