航天应用中的大部分软件都是嵌入式软件，可靠性要求很高，因此，对其进行充分测试显得尤为重要。但是，嵌入式软件运行环境同硬件有着密切的关系，使得嵌入式软件测试过程非常复杂，目前存在的一些测试工具偏重于白盒测试且价格昂贵，针对黑盒测试，目前还是以人工测试为主。由于软件的复杂程度越来越高，导致人为设计测试用例数量巨大且无法保证测试充分性。而对航天软件来说，是否满足任务要求是软件的重点，因此，从用户的角度对软件运行剖面进行数学建模，对系统是怎样的以及它会怎样被使用做出一个定量描述，根据这些量值可以对软件中至关重要的、生命攸关的、关系到系统成败的部分给与充分的测试。通过任务剖面模型可获取测试用例和测试数据的等价类信息，自动生成测试用例，大大减轻测试人员的工作量，提高了测试工作的效率和质量。

1．软件运行剖面

软件运行剖面是用来描述软件的实际使用情况的。1993年，MUSA在IEEE发表了一篇题为《软件可靠性工程中的运行剖面》的文章，开创了软件运行剖面的研究，文中MUSA给出了实施软件运行剖面的一般步骤。MUSA（参考文章[1]）对软件分析的原则，不仅适用于嵌入式软件，对一般的应用软件也适用。首先对软件的使用者进行分类，不同类型的使用者可能以不同的方式来使用软件，根据对使用者的划分将软件划分成不同的模式剖面。其次，模式剖面又可以划分为不同的功能剖面，即每个模式下都有许多不同的功能。最后，每一个功能又由许多运行组成。这些运行的集合便构成了运行剖面。上述的每一次划分都是依据概率发生的，这些概率估计主要是基于如下几个方面： ① 从现有系统收集到的数据， ② 与用户的交谈或对用户进行观察获得的信息， ③ 原型使用与试验分析的结果， ④ 相关领域专家的意见。定义使用概率的最佳方法是使用实际的用户数据，如来自原型系统、前一版本的使用数据；其次是由该软件应用领域的用户和专家提供的预期使用数据。软件的运行剖面是定量描述用户实际使用软件方式的有效方法。MUSA的软件划分原则简单且容易实施，只要按照步骤逐步实行就可以得出软件的比较准确的运行剖面。但是，也要看到，MUSA的软件分析原则只是提供了一个分析软件的方法，在特定的应用中，有些步骤可以简化处理，根据具体的实际情况，灵活运用。

2．运行剖面的构造过程

2.1 运行的表示方法

首先来定义两种图，第一种图用来描述分解后的运行，即运行图，定义为TF={P1，P2，……Pn}，其中，P1，P2……Pn表示构成运行的各个状态，Pi的下一个状态为Pi+1，Pi的上一个状态为Pi-1，这些状态表示的是一个任务从开始到结束的一个过程，即P1-〉P2……-〉Pn。我们可以用这个图来描述经分析得到的运行。当运行图中某个状态中可以有几种不同的路径到达下一个状态时，仅用运行图就不能准确表达该运行，此时，就要用到状态细化图，状态细化图用来描述运行图中状态的内部细节，定义为一个三元组DTF= ，其中，sequence={Bi|Bi=TFi}， i="1"……n。start为此细化图的公共开始节点，end为此细化图的公共终止节点。被测软件中所有的运行，只要划分的足够细，都可以由上面两种图准确的表示出来。

2.2 将由运行图、状态细化图表示的运行剖面转化为Markov链表示

将以上两种图描述的运行剖面转化成Markov链描述主要基于以下考虑：

1．Markov链的特点是下一个状态只和当前状态有关，而与历史状态无关，在这里就是软件的当前状态只和上一状态有关，与更早的历史状态无关，若上一状态正确，则在正确的输入下，软件的当前状态一定正确，否则，软件一定存在缺陷，这对于定位软件测试中的错误是十分方便的，通过Markov链中状态转移概率，还能直观的认识到软件中各个功能的使用频率，给出一个定量的描述。

2．这里的Markov链描述相当于编译中的中间语言，即程序的所有处理都是基于Markov链的。使用中间语言便于程序内部处理。

3．当某个节点内部有需要细化的分支时，Markov链会综合内部分支，给出一个整体的综合表述。这对于产生测试用例非常方便。

4.算法1：图描述转化为Markov链描述算法：该算法的输入为运行图、以及状态细化图，将运行图进行化简、并综合其中的状态细化图，将每一个运行都表示为一Markov链。

对每一个运行图，调用以下算法：

1．首先，插入一个开始状态，读入第一个节点

2．对该节点进行以下判断：

3.1.1 该节点是否为分支节点，若是则对该节点调用分枝遍历算法

2.1 其次判断该节点是否有输入，若有则插入一个新状态，并设置新状态的相关属性，并生成一条消息从当前状态指向新插入的状态

4．若还有其他节点，则进入下一个节点，重复步骤2，否则，算法结束

5. 算法2：分支遍历算法：

1．读入一个分支的第一个节点

1．1对该节点进行以下判断：

1．1.1判断该节点是否为分支节点，若是则调用分支遍历算法

2．1.1判断该节点是否有输入，若有则插入一个新状态，设置新状态的相关属性，并生成一条消息从当前状态指向新插入的状态

2．1若还有其他节点，则进入下一个节点，重复步骤1.1

3．1进行以下判断：

1.3.1若当前处理完的为第一个分支，则插入一个新的状态，并使最后一个节点指向这个新插入的节点

2.3.1若不是第一个分支，则使最后一个节点指向第一个分支的最后一个节点

4.1将当前节点置为算法开始时传入的节点，即分支的父节点，进行判断：

1.4.1当前父节点是否有超过1个的子分支，若有则进行判断：若超过一个子分支的下一个节点都是第一个分支的最后一个节点，则将这些子分支合并成一个子分支，即由父状态指向第一个分支的最后一个节点，概率为各个子分支的和

2．若还有其他分支，则进入其他分支，并设置当前分支为算法开始时传入的父节点，重复步骤1

经以上算法作用后，运行剖面可以表示为｛OPi｜OPi=＜Oi,Pi＞，i=1,2,…，N｝，其中Oi表示组成这个运行剖面的其中一个运行，Pi表示这个运行发生的概率。

每一个运行经算法作用后，都表示为一Markov链，根据算法，可以看出，该Markov链之包含了运行中的带有输入的节点以及其中的一些关键节点，该Markov链综合了每个运行的运行图以及其状态细化图，以下的程序处理都基于此Markov链。

3. 测试用例自动生成

测试用例是根据运行剖面随机生成的。在运行剖面中已经规定了每个输入变量的取值类型以及取值范围，并且认为变量在取值范围内均匀分布或分段均匀分布（由于很难确定变量的具体分布，这里假设为均匀分布）。软件可靠性测试是一种随机测试，测试用例的选取方式是随机选取。因此，根据随机测试的原则，在运行剖面给定的输入变量的取值区间内任意抽取一个变量的实际取值。将各个变量按顺序组合起来便生成了测试用例。用于软件可靠性测试的测试用例可以定义为：根据运行剖面生成的、完成对某一功能进行测试的、按顺序输入到被测软件的一系列输入变量的有序组合。

嵌入式系统中，输入可能为硬件信号或者人机接口，这就需要在标示测试输入类型时进行特殊标记，这里，可采用两种方法，一是软件模拟硬件信号，即当需要硬件信号时，由软件模拟此硬件信号，来保证测试的执行。二是对需要的硬件信号进行标示，当需要硬件信号时，系统会提示需要某个硬件信号的触发。

根据运行剖面生成测试用例的过程为：运行剖面由一系列变量的取值区间和该运行发生的概率组成。

首先，要随机抽取一个运行来实现对某一功能的一次测试。抽取运行的过程如下：

① 将运行剖面｛OPi｜OPi=＜Oi,Pi＞，i=1,2,…，N｝中所有运行发生的概率Pi求前j项和，形成一个数列｛Sj｝，Sj=∑Pi，其中，i=1,…j，j=1,2,…，N；N为软件运行剖面中运行总数，规定S0=0,并有S1=P1,Sn=1.0,Sj-Sj-1=Pj。这里运行相互独立。

② 任给一个随机数η∈(0,1.0)，观察η落在哪个区间，若η满足Sj-1＜η≤Sj，则该随机数η与Pj这个概率值对应，那么这次随机抽到的运行为Oj。

③ 确定了抽到的运行为Oi后，就可以确定该运行的输入情况，假设该运行有m个输入，每个输入的可选值分别为I1,I2…Im，将其排列为一个二进制串，若I1有m1个可选输入，I2有m2个可选输入Im有mm个可选输入，则二进制串为(00…0) (00…0)……(00…0)，其中，第一个括号内的0有m1个，第二个括号中的0有m2个，第m个括号中的0有mm个，构造一个布尔类型的数组，数组的大小为2(I1+I2+…+Im)，数组的初始值均为false，每次产生一个测试用例时，从m个输入的I1,I2…Im中每一个输入的可选值中各选一个，并把二进制串中的相应位置1，m个输入都选好后，把对应的标记数组置为true。生成一个测试用例后，首先判断对应的标记数组，若为true，则需要重新生成一个用例。

④ 其中，要进行第二次抽样来确定运行中每个输入的取值区间将取到的实体（即具体取值）。实体的确定将按照输入变量的属性分两种情况进行：

① 对于连续型输入变量，运行剖面给出的是该变量的取值区间的上下限［I.down,I.up］。抽样时将根据输入变量的数据类型，在区间［I.down,I.up］内随机抽取一个满足输入变量数据类型的具体值，作为该输入变量的实体。

② 对于可选离散型输入变量，运行剖面给出的是一组离散点Ii,i=1,2,…,mi;mi为离散点的个数。抽样时将在［1,mi］内随机抽取一个整数j，以确定选哪一个离散点作为该输入变量的实体，并将该实体转化为该输入变量的数据类型。

③ 通过对运行和各个实体两个步骤的抽样，完成一个测试用例的生成。

应用测试用例可以进行软件可靠性测试：

图1 测试系统

系统负责根据以上算法策略等产生测试用例，输入到整个测试系统中，执行可靠性测试，测试系统根据某种判断策略，来决定此用例是否通过测试，若在规定的时间内，规定的输入条件下，所有用例均通过测试，则测试完成，若其中有测试用例没有通过测试，只需要对被测软件进行修改，消除其中的错误，再次进行测试，而整个测试系统不需要任何改动，大大的提高了测试的效率和灵活性。这种测试是统计测试，测试完全根据各个运行所发生的概率以及运行的权重来进行的，在测试中, 优先测试那些最重要或最频繁使用的功能，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。

4．结束语

本文完全从工程应用的角度出发，根据被测软件的需求规格说明书，通过和软件使用人员充分的交流，由测试人员构造出软件的运行剖面，并用文中定义的运行图来描述，经过算法转化为带标记的 Markov链描述，依据该Markov链，可以自动生成测试用例。配合相应的测试环境，进行自动化的可靠性测试，可以极大的提高测试的效率，被测嵌入式系统的可靠性也可以进行更加充分的验证。

今后的工作主要是输入模型的提取与识别以及重组，从本文的前面，可以看出，系统的输入还是比较繁琐的，如果能够直接读取被测软件的UML图，从图中提取各种信息，从而自动构造软件的运行剖面，则可以使整个过程更加高效，符合软件测试的发展趋势。此外，支撑测试环境的搭建，也需要认真的研究。

本文作者创新点：

1．传统的软件测试都是根据软件的源代码进行测试，本文则根据软件的需求规格说明书进行测试，大大提高了测试的效率和灵活性。

2．用带标记的Markov链对软件运行剖面建模，为自动产生测试用例打下了基础。

3．能对产生的测试用例情况进行标记，避免产生相同的测试用例，提高了测试的效率。