专利名称：一种嵌入式软件可靠性加速测试方法
技术领域：
本发明涉及软件可靠性测试领域，具体地说，是指一种基于软件任务剖面的嵌入 式软件可靠性加速测试方法。
背景技术：
目前嵌入式软件被广泛应用于航空航天、金融、医疗、电信等各个领域。伴随着应 用的发展，嵌入式软件的可靠性问题已成为人们所关注的焦点。软件可靠性测试是实现软 件可靠性增长和对软件可靠性进行评估的有效途径。但是，从测试的角度来看，由于嵌入式软件自身的实时特性和反应特性决定了嵌 入式软件的输入受到取值大小、时序和时间响应等诸多条件的限制，输入条件十分复杂，几 乎无法覆盖到软件所有可能的输入情况；另一方面，对比嵌入式软件的一般测试，可靠性测 试的测试量更加庞大，测试效率问题也成为制约嵌入式软件可靠性测试广泛开展的瓶颈。传统的软件可靠性测试方法中，作为可靠性测试输入的可靠性测试用例的生成都 是基于穆莎(John Musa)所提出的操作剖面，这种方法简单实用，对运行之间没有相互影 响、运行相互独立的软件来说非常有效。但是这种静态的操作剖面不能完全描述嵌入式软 件的实际运行情况，目前，对嵌入式软件操作剖面的研究主要集中在对操作剖面的改进所 形成的使用剖面，使用剖面多数是采取UML的活动图和顺序图对“使用”进行建模得到的， 但是仍不能完全解决运行间存在的复杂的条件约束关系。另外，在施加用例运行测试的过 程中除了有时根据条件使用一些测试自动化工具以外并没有针对性的采取软件可靠性测 试策略来提高软件可靠性的测试效率。
发明内容
本发明为了解决嵌入式软件可靠性测试中所面临的困境，从嵌入式软件自身的特 点入手，结合使用信息，构建一种嵌入式软件可靠性加速测试方法，使得可靠性测试用例最 大可能地满足复杂的输入条件限制，测试过程的设计在不影响评估置信度的情况下，可以 减少测试量。本发明提供的嵌入式软件可靠性加速测试方法，针对嵌入式软件建立软件任 务剖面，用于嵌入式软件可靠性测试用例的生成，在测试过程中，根据稳定过程和控制过程 中收集测试数据进行软件可靠性测试，实现提高软件可靠性测试效率的目的。本发明提供的基于软件任务剖面的嵌入式软件可靠性测试方法，在测试用例生成 上综合考虑软件自身特点和使用情况满足复杂的输入条件，在测试过程中提供控制策略提 高测试效率，从而实现对嵌入式软件进行更全面、更具有针对性的可靠性测试。本发明所提供的可靠性加速测试方法主要包括以下步骤第一步，建立软件任务剖面；第二步，生成软件任务序列即软件可靠性测试用例；在软件任务剖面完整和正确建立的基础上，随机抽取和生成软件任务序列，软件 任务序列是在实际可靠性测试中施加的完整而有效的测试输入。
第三步，人工编写测试脚本，建立测试环境，开始测试；第四步，测试过程中统计收集测试数据(包括任务特征和任务状态)，根据稳定判 据判定测试过程是否达到稳定过程；第五步，进入控制过程，也同时收集测试数据(包括任务特征和任务状态)，施加 控制过程测试策略；第六步，对软件可靠性进行工程评估，结束测试。利用稳定过程和控制过程两个过程中收集到的测试数据(包括任务状态和任务 特征)给出一种近似的软件任务可靠度评估方法。另外，可以选择和使用已有的软件可靠 性评估模型，利用测试过程中收集到的失效数据对被测软件进行可靠性评估。所述的稳定过程是指当任务状态覆盖率C达到某个级别Ct时，继续增加测试用 例，软件的可靠性水平始终稳定在一个水平R，此时的软件可靠性增长十分缓慢，即认为达 到“停滞期”。其数学描述为{I Rj-Ri < ε，ε — O+I (| NtrNti — b) Λ (C > CT)，j > i > 0，b > 0，CT > 0}这里，b是规定的较小的正数，Nti表示第i组测试中测试用例的个数，Ntj表示第 j组测试中测试用例的个数，Ri表示第i组测试完成后得到的软件可靠性估计，Rj表示第j 组测试完成后得到的软件可靠性估计。若两组测试的用例个数的差值接近于正数b，而对应 的可靠性估计的差值小于某个规定的正数ε，同时任务状态覆盖率C大于或等于某个事先 规定的级别Ct时，即认为已到达稳定过程。所述的控制过程是指在稳定过程的基础上的一种追加测试的过程，应用针对性的 测试策略，选择软件任务序列，加快软件缺陷的发现，从而保证被测软件在短时间内可靠性 能够进一步提高。当软件可靠性增长达到目标值，即可以终止控制过程。本发明与现有技术相比，具有以下明显的优势和有益效果1、本发明给出了一种新的软件任务序列的生成方法，可以满足对复杂的输入条件 的描述和覆盖。2、稳定过程的提出符合嵌入式软件运行的实际情况，对测试数据的收集和统计丰 富了测试过程所应收集的数据类型和种类，为进一步的可靠性评估提供基础和依据。3、控制过程中的测试策略的提出达到了合理高效地加速可靠性测试过程的目的， 也拓展了对嵌入式软件进行可靠性测试的思路。4、本发明提出的方法已应用在了某个航电嵌入式软件系统的工程实例中，证明了 基于软件任务剖面生成软件任务序列，稳定过程与控制过程相结合的可靠性加速测试方法 的可行性和有效性，通过了工程实例的考核和验证，该可靠性加速测试方法在工程应用方 面具有较大的价值。5、给出了任务可靠度的工程近似计算方法，它的优点是该评估计算方法不依赖于 失效数据的假设数学分布，同时基于软件任务剖面生成的软件任务序列保证了可靠性测试 数据的可信性。适用于对精度没有过高要求的嵌入式软件的可靠性评估。
图1为本发明提供的软件可靠性加速测试方法的流程图；图2为本发明开发软件任务剖面的流程示意图；图3为本发明软件任务序列随机产生的示意图；图4为实施例中由子任务集组成的INS系统的任务剖面示意图；图5为实施例中对INS导航子任务集进行描述的示意图；图6为实施例中对INS维护子任务集进行描述的示意图；图7为实施例中任务状态覆盖率和累积覆盖率图。
具体实施例方式为了便于本领域普通技术人员理解和实施本发明，下面通过具体实施方式
对本发 明作进一步的详细和深入描述。图1为本发明软件可靠性加速测试方法的流程图，该方法首先建立嵌入式软件 任务剖面，利用随机方法生成软件任务序列(即可靠性测试用例)，开始测试后，首先进入 到测试的第一阶段——稳定过程，随着测试的进行，根据稳定判据判断测试过程是否达到 稳定，如果否，则继续执行软件任务序列进行测试；如果是，则进入到测试第二阶段——控 制过程，在控制过程中施加相应的测试策略，对稳定过程和控制过程中收集到的测试数据 (包括任务状态和任务特征)进行统计，然后给出软件可靠性工程近似评估，从而实现整个 软件可靠性测试过程。具体实现步骤如下第一步，建立软件任务剖面，实现流程如图2所示，具体为(1)根据软件需求规格说明书和任务相关的要求，得到任务集T ；(2)进一步将任务集T划分，得到任务集T中所包含的子任务集1\。特殊情况下， 子任务集Ti中只包含一个任务，i = 1,2,3......η ;n表示任务集T中子任务集的个数。(3)分别确定各子任务集Ti之间的时序转移关系和概率转移关系；(4)按照需求和使用信息分析每个子任务集Ti中任务^(i = 1,2,.. .，η ； j = 1， 2，. . .，ni)，其中i表示任务集中的子任务集的序号，j表示子任务集Ti中的任务序号，Iii表 示子任务集Ti中的任务个数。根据子任务集之间的时序转移关系和概率转移关系，画出子任务集转移图，如图3 中的子任务集T1, T2，T3和T4;(5)确定任务间的时序转移关系和概率转移关系，画出任务转移图，按照任务描述 方法对每个任务进行描述，如图3中子任务集T3中从任务t32到任务t33的转移概率为P32_33， 子任务集T4中从任务t45到任务t42的转移概率为P45_42 ；(6)将子任务集逐层分解，如果需要可以进一步分解为子子任务集，如图3中的T21 和T22，T31和T32)，直到底层的子任务集或子子任务集可以直接由一个或几个任务组成，确定 任务间的时序转移关系和概率转移关系，画出任务转移图，按照任务描述方法对每个任务 进行描述，从而得到被测软件的软件任务剖面。建立软件任务剖面的过程中有两个重要问题一是确定任务之间的关系；二是任 务的具体描述方法。软件任务剖面描述了子任务集、子子任务集以及任务间的时序转移关系和概率转移关系，任务与时间密切相关，任务之间在时间上具有的关系称之为时序转移关系。主要包 括顺序关系、并发关系和偏序关系三种，所述的顺序关系是指一个任务发生并完成后，另一 任务在其后发生；所述的并发关系是指多个任务同时发生、同时进行的关系；所述的偏序 关系是指每个任务都有明确的发生时刻，如一个任务在某一时刻发生，另一任务要求在另 一时刻发生。偏序关系既可用绝对时间来表示也可用任务间的相对时间来表示。特殊地， 顺序关系是偏序关系在时间轴上的一种连续分布。子任务集之间的时序转移关系类比任务 之间的时序转移关系，同样具有顺序、并发和偏序三种关系。软件任务剖面是动态的任务之间不是相互独立的，除了存在上述的时序转移关 系以外，有的任务之间还存在条件约束关系，即任务的发生是以一定条件的达到作为前提 的，即这些条件是任务发生的必要、非充分条件。这些条件可能是用户的一个按键，也可能 是系统要满足的一个状态等。在划分子任务集时保证了子任务集之间是相互独立的，因此 子任务集之间不存在上述的条件约束关系。概率转移关系包括两种第一种是指上一个子任务集完成后转移到下一子任务集 的发生概率；第二种是指同一子任务集中不同任务之间发生转移的概率。概率信息的获取 主要来自两方面一是参考历史信息，概率的确定基于对以往使用信息的统计；二是对于 无历史信息记录的软件，则根据软件用户的需求并参照经验给定。任务描述方法的基本步骤为(1)确定实现任务的所有事件{E」i = 1，2，···，n}；(2)确定事件之间的时序转移关系和条件约束关系；(3)确定表示事件的变量的属性，即给出表示事件的变量，确定变量类型、取值或 取值范围。表示事件的变量类型包括以下三种(a)离散型变量主要有枚举型、布尔型和字符型。对于每一种类型的离散型变 量，需要在描述中给出各种取值的概率，但是要注意每个离散型变量Vi (i = 1,2, ...，m，m
是变量V的个数)的各个取值的概率(pvi)之和必须满足∑j=1(pvi)j =1 (J表示变量Vi的第
j种取值情况，Hi表示变量Vi取值的个数)。(b)连续型变量主要有整型和浮点型，对于这种类型的连续型变量，其取值范围 由取值区间的集合表示，即取值范围可以划分为多个取值区间，并给出在这些取值区间上 分别取值的概率，保证概率之和为1。例如，连续型变量X有m个取值区间，则变量X在所有
m个取值区间的取值概率之和应为1，即mΣj=1 =1 (j表示变量X的第j种取值情况，m表示
变量χ取值区间的个数)，取值区间的分布情况与任务的实际执行情况密切相关，所以分配 取值的概率时也要考虑到实际情况。(c)与时间相关的变量前两种变量是通过取值来描述输入行为的变量，对于嵌 入式软件，其输入行为不仅与取值相关而且与时间有关，因此表示事件的输入变量还应该 有这样一类具有时间特性的与时间相关的变量。例如，对于某种输入行为随时间呈现一定 的变化规律，则可以用服从相应的数学分布的与时间相关的变量来表示。第二步，在软件任务剖面的基础上，通过随机抽取产生用于进行可靠性测试的软 件任务序列。
首先定义软件任务序列是带有时间标签的一组可能存在关系的任务tu(i = 1， 2，. . .，n ;j = 1，2，. . .，ni)组成的一次软件运行，每个任务可能来自于不同的任务集、子任 务集或子子任务集。软件任务序列集合TSP的数学表达式为{TSP I TSP = <tsqk, Pk>, k = 1,2,... ,N}, tsqk表示第k个软件任务序列，Pk表示第k个软件任务序列发生的概率，N表 示软件任务序列的个数。因此，软件任务剖面也可以看作是由一系列软件任务序列及这些 软件任务序列发生的概率组成的软件任务序列集合。一个软件任务序列对应软件可靠性测 试的一次运行，也就是一个完整的能用来进行软件可靠性测试的测试用例。软件任务序列 按照软件任务剖面随机抽取生成，同时刻画软件任务剖面的要求。图3给出了在子任务集、子子任务集、任务基础上产生软件任务序列的示意图，也 表示了子任务集、子子任务集、任务和软件任务序列四者之间的关系，图中椭圆表示子任务 集或子子任务集或任务，箭头表示时序转移关系，线上标注转移概率，图3中有四个子任务 集T1, T2, T3和T4,子任务集T1中有4个任务tn、t12、t13和t14 ；子任务集T2包含两个子子 任务集T21和T22，其中，任务t21、t25属于子子任务集T21，任务t22、t23和t24属于子子任务集 T22 ；子任务集T3中也包含两个子子任务集T31和T32，其中，任务t31、t35和t36属于子子任务 集T31，任务
七32、^33 禾口 ^34 属于子子任务集T32 ；子任务集T4中有6个任务 t4i、t42、t43、t44、 和t46。图3中有多个软件任务序列，例如，由t12，t21，t24，t45，t42和t46构成了一个软件任 务序列 t12 — t21 — t24 — t45 — t42 — t46o第三步，人工编写测试脚本，建立测试环境，开始测试，执行软件任务序列。对第二步根据软件任务剖面随机生成的软件任务序列，人工编写测试脚本，建立 好测试环境，然后开始测试，执行软件任务序列。第四步，收集测试数据，对任务状态的覆盖情况进行记录和统计。所述的测试数据 是指任务特征和任务状态数据。所述的任务特征是任务实现过程中相对独立的有特性的行为。软件任务是由一个 或多个任务特征来共同实现，它是这一任务的执行区别于其它任务的执行的标志。任务特 征集合TC (Test Characteristics)信息可以根据软件任务剖面提取，一个软件任务序列中 必包含一个或多个任务特征，任务特征组成的集合为TC = ItciI i = 1，2，· · ·，N}N为任务特征的个数，tCi表示第i个任务特征。满足任务特征之间相互独立，即tCl η tc2 η ... η tCi = φ。所述的任务状态是任务特征的动态属性，用任务状态tsu来刻画和表示任务特 征，同时描述任务特征的具体实现，即某一任务特征由若干个任务状态实现，对于任务特征 集合TC中的第i个任务特征tCi，存在tCi = UsijIj = 1，2，...，Mi}，其中，j表示第i个 任务特征tCi的任务状态序号，Mi表示第i个任务特征tCi所包含的任务状态tsu的个数。嵌入式软件在运行过程中所经历的所有任务状态组成的集合定义为任务状态空 间，用S表示。对嵌入式软件来说，可以通过软件任务序列的运行实现对任务状态空间S的 覆盖。 用S表示嵌入式软件的任务状态空间，tc,表示软件的一个任务特征，则根据上述分析存在关系5= ，同理，某一个任务特征岣=U^。其中，〖(^表示由任务状态tSil，
tci2, ..，tsiMi构成的一个任务特征，假设对每个任务状态tSij(i = 1，2，...，N;j = 1， 2，...，Mi)有 Yij 个取值，则由任务状态 tSij(i = 1,2, ... , N;j = 1,2, ... , Mi)构成的任
N MiM Mi
务状态空间共有ΣΣ个任务状态，ΣΣ&种取值，由任务状态及其取值产生的组合情况更 /=1 j=\ / 1 j-\
加复杂。由此看来，任务状态空间是非常庞大的，但是通过运行由软件任务剖面生成的软件
任务序列可以有规律地实现一定的任务状态覆盖。任务状态覆盖率C是指实际测试中软件经历的不同的状态个数与状态空间中所 有状态个数的比值。以任务状态覆盖率作为确定测试过程是否达到稳定的判据，前面所述用来描述稳 定过程的公式中{I Rj-Ri I < ε，ε — ο. I (| NtrNti | — b) Λ (C > CT)，j > i > 0，b > 0，Ct > 0}Ct即为这里所指的稳定判据。Ct表示当任务状态覆盖率C达到一定程度(软件不 同，Ct不同，通常可认为是0. 85-0. 9之间)会产生饱和效应，可靠性增长会进入到一定的 “停滞期”即增长变得十分缓慢，此时认为软件可靠性测试达到了稳定。但大多数情况下， 此时软件可靠性增长仍然未达到预期的软件可靠性目标值。因此就要进入第二阶段控制过 程。第五步，进入控制过程，施加控制过程的测试策略，同时也收集测试数据。控制过 程是指在稳定过程的基础上的一种追加测试的过程，所应用的测试策略(特别是在软件任 务序列的选择方面)加快了软件缺陷的暴露，随着对暴露的软件缺陷的修改和移除从而进 一步实现软件可靠性的增长以达到预期的软件可靠性目标值。为了提高控制过程的效率，控制过程的测试策略如下(1)对测试过的完全相同的软件任务序列不再测试，同时对测试过的相似软件任 务序列也不再测试。所述的相似软件任务序列是指软件任务序列中的任务的集合相同、时序相同，而 对于其中的某一任务，其任务特征和任务状态可以不同。(2)加入对可靠性影响大的软件任务序列。在测试中，任务状态通常用一个状态变量表示，该状态变量被称为任务状态变量， 对任务状态变量为浮点型的，则将该任务状态变量的取值划分为k个区段，落在这k个区段 中每一段的取值的贡献按Ι/k折合，以此类推，枚举型变量有q个取值，则每个取值的贡献 按Ι/q折合。在测试中，用任务特征对可靠性评估的贡献Mdi)和任务特征的各种任务状态对 可靠性评估的贡献g(su)来衡量对可靠性的影响，所谓加入对可靠性影响大的软件任务序 列等同于加入具有如下特征的软件任务序列(a)任务特征对可靠性评估的贡献f (Cli)F(D) = If(Cli) ^lli = 1,2,... ,η}对F(D)中所有f (Cli)按照从大到小排序，包含相对较大的f (Cli)的软件任务序列 认为是对可靠性影响较大的软件任务序列，一般取F(D)集合中排列前30%的为相对较大的 f (Cli)。(b)任务特征的各种任务状态对可靠性评估的贡献g(Sij)
m 对G(Si)中所有g(su)按照从大到小排序，包含相对较大的g(su)的软件任务序 列认为是对可靠性影响较大的软件任务序列，一般取G(Si)集合中排列前30%的为相对较 大的 g (Sij)。(c)任务状态对任务状态验证进行统计 只要任务状态Su的任务状态变量的取值的所有情况中有一种情况被覆盖到，认 为该任务状态Su已验证，则V (Su) =1。如果任何一种情况都没有被覆盖到，认为该任务 状态Sij没有验证，V(Sij) =0。将没有验证的任务状态Sij作为对可靠性影响较大的软件 任务序列。(3)运行关键的软件任务序列这里关键的软件任务序列是指遍历到关键或重要 的任务特征的软件任务序列，即任务特征对可靠性评估的贡献f(di)大，且含有多个任务 (通常任务个数要大于等于3)的软件任务序列。此外，将运行失败产生后果严重度高的软 件任务序列也看作是关键的软件任务序列，需要在控制过程中优先施加。第六步，对软件可靠性进行工程评估，计算软件的任务可靠度，结束测试。软件的任务可靠度通常定义为软件在软件任务剖面所规定的时间内和规定的条 件下，完成规定任务的能力，为任务可靠性；任务可靠性概率度量为任务可靠度。任务可靠 度分为单任务可靠度和多任务可靠度，对于复杂的嵌入式软件而言，任务可靠度的考量通 常是基于复杂的多个任务的执行结果，因此本发明中的任务可靠度即指多任务可靠度。本发明中利用测试数据即任务特征和任务状态数据的相关信息计算软件的任务 可靠度，给出软件任务可靠度的近似计算式 式中，η为任务特征的个数，Hii为任务特征tCi所包含的任务状态的个数。实施例应用本发明提供的嵌入式软件可靠性加速测试方法对某惯性导航系统(以下简 称INS)的实时控制软件进行软件可靠性加速测试，INS的主要功能包括导航计算、过程控 制、故障处理等。INS软件通过1553B总线与DCMP、DTE、FCS、MC、CADC等11个航电子系统 进行数据交换，通过各设备之间的控制命令数据实时传输保证过程控制和故障处理等，具 体测试过程如下第一步，软件任务剖面的建立。根据本发明中提出的软件任务剖面的生成方法，首先对软件的需求规格说明进行分析，明确软件的功能集，根据各功能的特点以及功能之间的联系，得到软件的任务集(即 INS所有的任务的集合)和子任务集，进而分析得到每个子任务集中的任务，见表1，其中， 导航子任务集中包含系统备份和导航数据人工修改两个子子任务集表IINS的子任务集及任务列表 由表1中可以得到INS的自检测、导航、姿态模式、维护、INS对准、状态监控、进场 数据修改和飞行结束共8个主要子任务集以及各子任务集中所包含的主要任务总共22个， 通过分析各子任务集之间的时序转移关系和概率转移关系以及每个子任务集中任务的时 序转移关系和概率转移关系，就可以得到INS的8个主要子任务集的软件任务剖面，它是由 子任务集组成的INS系统的任务剖面的进一步描述。由于篇幅所限，本实施例中只对导航 和维护两个比较典型的子任务集举例描述，如图5和图6所示，图中的每个椭圆都表示一个任务，对于相对复杂的任务用任务描述图表示；对于类似于只有一个事件的简单任务则可 以直接确定表示事件的变量及取值。第二步，生成软件任务序列。根据表IINS的子任务集及任务列表，归纳得到INS每个子任务集中的任务所具有 的任务特征，从而进一步得到每个任务特征相应的任务状态，用表2给出。表2INS的任务特征和任务状态
对任务进行细化和分解，考虑软件的使用，分析软件的可测任务和相应的软件任 务序列，获得软件任务序列，如表3所示为一个软件任务序列表3某个软件任务序列 注由于被测软件主要是通过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控制过程追加测试用例表 在第26组测试用例运行后，任务状态累积覆盖率达到了 93. 9%，此时控制过程结 束。再挑选运行一组30个软件任务序列，在执行过程中没有发现失效(即无失效运行)。第六步，进行软件可靠性工程近似评估。通过对这30个软件任务序列中任务特征和任务状态的统计，利用任务可靠度的 工程近似算法，得到此时软件的任务可靠度。结果分析说明(1)根据任务可靠度的工程近似算法计算得到INS的任务可靠度。稳定过程中共 测试22组1100个软件任务序列；控制过程中共测试4组120个软件任务序列，过程结束。 此时，任务状态累积覆盖率达到了 93. 9% (最后两组该覆盖率是相同的)，且运行最后一组 软件任务序列不再出现失效，因此经过稳定过程和控制过程后的软件可靠性测试已经在一 定程度上使得被测软件的可靠性得到了比较充分的增长。计算任务可靠度时，挑选运行一 组30个软件任务序列没有发现失效(即无失效运行)通过对这30个软件任务序列中任务特征和任务状态的统计得到软件的任务可靠度，此时得到的评估结果是比较可信的。可靠性测试是面向使用的测试，对于实时嵌入式软件基于任务的测试方法也是这 一思想的一种体现，正是由于可靠性测试的这一特点决定了其测试的用例要多，测试的时 间要长，通常认为由此而产生的重复测试是对某些功能的覆盖，而不同路径下功能的运行 有可能产生不同的效应引发缺陷，这也是可靠性测试与覆盖测试不同之处，因此很多人认 为的软件可靠性测试就该是长时间测试甚至是重复测试。但是通过这个实例可以发现，当 测试用例(软件任务序列)的个数远小于统计最小测试量时，不仅是某些单一任务的覆盖 重复，而且软件任务序列也产生了重复，也就是说会产生同一路径的重复执行，因此如果再 继续进行可靠性测试，势必造成资源的浪费。(2)同时，到有些理论上指导测试的停止准则在工程实践中会产生很大的差异，例 如用统计理论估计最小测试量 当取置信度a 为 0.7，e = 0. 2，Min{pJ = 0. 0108 时，计算得到最小测试量 为此，在稳定过程执行的1100个测试用例的基础上，还是以50个任务序列为一 组继续进行可靠性测试，测试结果记录见表6，当运行2488个软件任务序列后，状态覆盖 率只达到83. 9% ；而稳定过程中在900个软件任务序列执行后，状态覆盖率就已经达到了 83.5%，见表4。也就是说，当用例增加了 1588个而状态覆盖率增加了 0.4%，可以认为这 部分测试的意义是很微乎其微的，另外83. 9%的状态覆盖也并不充分，会同时使得测试结 果的可信性受到一定的质疑。表6 —般可靠性测试过程
(3)实时嵌入式控制软件多为安全关键软件，所谓安全关键软件一方面是对可靠 性的要求较高，而另一方面强调的是某些缺陷一旦发生会产生严重的后果。但是往往诱发 这些有严重后果的关键缺陷的任务在使用中的概率很低，而使用频率高的任务在前期的功 能测试或系统测试中已经经过了充分的测试，从而这些任务引发失效的概率会非常低，因 此对安全关键软件的测试不但要考虑基于使用的统计规律，还要关注有可能引发关键缺陷 的任务，包括这类任务的任务特征及任务状态，因此本发明中在控制过程引入的控制准则， 而且实验结果表明在控制过程中追加测试用例时，运行序号为24即第24组中的任务序号 为1147的关键软件任务序列，在测试过程中确实发现了某重要缺陷(即掉电时DTE数据 传输过程中漏传数据)；在所做的对比实验中，还是以50个软件任务序列为一组作非加速 方法的测试(即一般可靠性测试)，当抽样总数N = 4000时，能够测试到该缺陷的软件任务 序列才出现一次，运行序号为76即第76组软件任务序列中任务序号n = 3787的软件任务 序列在执行的过程中该缺陷才被发现。
18
权利要求
一种嵌入式软件可靠性加速测试方法，其特征在于第一步，建立软件任务剖面；第二步，根据软件任务剖面，通过随机抽取产生软件任务序列，作为实际可靠性测试中施加的完整而有效的测试输入；第三步，人工编写测试脚本，建立测试环境，开始测试；第四步，测试过程中统计收集任务特征和任务状态，根据稳定判据判定测试过程是否达到稳定过程；第五步，进入控制过程，施加测试策略，终止控制过程；第六步，对软件可靠性进行工程评估，结束测试；利用稳定过程和控制过程两个过程中收集到的测试数据计算被测软件的任务可靠度，软件任务可靠度的近似计算式如下 <mrow><mi>R</mi><mo>=</mo><mfrac> <mrow><munderover> <mi>Σ</mi> <mrow><mi>i</mi><mo>=</mo><mn>1</mn> </mrow> <mi>n</mi></munderover><mi>f</mi><mrow> <mo>(</mo> <msub><mi>d</mi><mi>i</mi> </msub> <mo>)</mo></mrow><mo>*</mo><mrow> <mo>(</mo> <munderover><mi>Σ</mi><mrow> <mi>j</mi> <mo>=</mo> <mn>1</mn></mrow><msub> <mi>m</mi> <mi>i</mi></msub> </munderover> <mi>g</mi> <mrow><mo>(</mo><msub> <mi>s</mi> <mi>ij</mi></msub><mo>)</mo> </mrow> <mo>*</mo> <mi>v</mi> <mrow><mo>(</mo><msub> <mi>s</mi> <mi>ij</mi></msub><mo>)</mo> </mrow> <mo>)</mo></mrow> </mrow> <mi>n</mi></mfrac> </mrow>式中，n为任务特征的个数，mi为任务特征tci所包含的任务状态的个数。
2.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于第一步中所 述的建立软件任务剖面，实现流程如下(1)根据软件需求规格说明书和与任务相关的要求，得到任务集合T；(2)进一步将任务集合T划分，得到任务集合T中所包含的子任务集Ti,i = 1,2,3……η ；(3)分别得到各子任务集Ti之间的时序转移关系和概率转移关系；(4)确定每个子任务集Ti中任务的时序转移关系和概率转移关系，画出子任务集转 移图；(5)在每个子任务集中画出任务的转移图，同时按照任务描述方法对任务进行描述；(6)将子任务集逐层分解，如果需要，进一步分解为子子任务集，直到底层的子任务集 或子子任务集直接由一个或几个任务组成，得到被测软件的软件任务剖面。
3.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于第四步中，当 任务状态覆盖率C达到级别Ct时，继续增加测试用例，软件的可靠性水平始终稳定在一个 水平R，其数学描述为 其中，b是规定的较小的正数，Nti表示第i组测试中测试用例的个数，Ntj表示第j组 测试中测试用例的个数，Ri表示第i组测试完成后得到的软件可靠性估计，Rj表示第j组 测试完成后得到的软件可靠性估计，若两组测试的用例个数相差趋近于正数b，而对应的可 靠性估计差值小于规定的正数ε，同时任务状态覆盖率C大于级别Ct时，即认为已到达稳 定过程。
4.根据权利要求3所述的嵌入式软件可靠性加速测试方法，其特征在于所述的级别 Ct选取在0. 85-0. 9之间。
5.根据权利要求1所述的嵌入式软件可靠性加速测试方法，其特征在于第五步中所 述的测试策略是指(1)对测试过的完全相同的软件任务序列不再测试，同时对测试过的相似软件任务序 列也不再测试，所述的相似软件任务序列是指软件任务序列中的任务的集合相同、任务之 间的时序转移关系相同，而对于其中的某一任务，其任务特征和任务状态不同；(2)加入对可靠性影响大的软件任务序列；(3)运行关键的软件任务序列。
6.根据权利要求5所述的嵌入式软件可靠性加速测试方法，其特征在于所述加入对 可靠性影响大的软件任务序列等同于加入具有如下特征的软件任务序列(a)任务特征对可靠性评估的贡献Mdi)F(D) = If(Cli) ^lIi = Li = 1,2, · · ·，η}对F(D)中所有Mdi)按照从大到小排序，包含相对较大的Mdi)的软件任务序列认为 是对可靠性影响较大的软件任务序列，取F(D)集合中排列前30%的为相对较大的Mdi)；(b)任务特征的各种任务状态对可靠性评估的贡献g(Sij) 对G(Si)中所有g(su)按照从大到小排序，包含相对较大的g(su)的软件任务序列认为 是对可靠性影响较大的软件任务序列，取G(Si)集合中排列前30%的为相对较大的g(Sij)；(c)任务状态对任务状态验证进行统计 ν没有验证只要任务状态的任务状态变量的取值的所有情况中有一种情况被覆盖到，认为该 任务状态Su已验证，则ν (Su) = 1，如果任何一种情况都没有被覆盖到，认为该任务状态 没有验证，V(Sij) = 0，将没有验证的任务状态Sij作为对可靠性影响较大的软件任务序列。
7.根据权利要求5所述的嵌入式软件可靠性加速测试方法，其特征在于所述的关键 软件任务序列是指遍历到关键或重要的任务特征的软件任务序列，即任务特征对可靠性评 估的贡献f(di)大，且含有多个任务的软件任务序列；此外，将运行失败产生后果严重度高 的软件任务序列也看作是关键的软件任务序列，需要在控制过程中优先施加。
全文摘要
本发明公开了一种嵌入式软件可靠性加速测试方法，通过建立软件任务剖面，来随机抽取产生软件任务序列，作为实际可靠性测试中施加的完整而有效的测试输入；测试过程中统计收集任务特征和任务状态，测试过程达到稳定过程后进入控制过程，施加测试策略，最后对软件可靠性进行工程评估。本发明控制过程中的测试策略的提出达到了合理高效地加速可靠性测试过程的目的，也拓展了对嵌入式软件进行可靠性测试的思路。基于软件任务剖面生成的软件任务序列，可以满足对复杂的输入条件的描述和覆盖，保证了可靠性测试数据的可信性；评估方法不依赖于失效数据的假设数学分布，适用于对精度没有过高要求的嵌入式软件的可靠性评估。
文档编号G06F11/36GK101894068SQ201010195358
公开日2010年11月24日 申请日期2010年5月31日 优先权日2010年5月31日
发明者刘志方, 吴玉美, 陆民燕 申请人:北京航空航天大学