mc/dc实现方法

MC/DC[修订的条件/判定覆盖]实现方法

 

 

摘要

 

商用运输飞机应用软件必须通过MC/DC软件结构的测试 。这个要求让很多涉及航空软件的团体焦虑，

一项对航空软件工业的调查结果显示许多开发人员认为达到MC/DC的要求是很困难的，而且代价昂贵。毋庸置疑，一些学科现有可用资料的不足也造成一些阻力。本篇论文提供了一个评估航空软件产品MC/DC实用的5步途径，以及对在实现MC/DC过程中预期可能遇到的一些错误类型的分析。

 

 

简介

 

软件已经成为高级自动控制在航空中应用实现选择的媒介，同样也适用于为空管[空中交通管理]实现通讯、导航及监视的地面和人造卫星系统。随着以软件为基础的系统的容量、复杂度的增长，检验这些系统能够满足需求，包括安全需求，的挑战也随之增长。对于那些安全和性能要求高的系统，有效广泛的测试是需要的。但是，眼下航空电子设备的巨大性和复杂度对全面的检查也是一个阻碍。

 

RTCA/DO-178B文件[空中系统和设备认证中的软件要求] [注释1] 是航空软件开发者最早用来获得成为FAA[联邦航空局]正式批准的空中计算机软件的方法[注释2]。DO-178B 描述了整个软件生命周期活动和设计的要求，并且列举了一套软件生命周期过程的目标。对于A级软件[既是，软件的反常行为可能导致灾难性的结果的软件]，DO-178B 要求它能够通过MC/DC 软件结构的测试。MC/DC 是一个结构覆盖方法包括四个标准，主要关心的是测试布尔逻辑。MC/DC 标准提供了许多只详尽测试布尔表达式而不用对需求作详尽测试的益处[注释3]

**********************************

 

1999年的一项航空软件工业调查显示，超过75%的接受调查者称：满足MC/DC DO-178B的要求比较困难，74%的人称其代价是真实存在的，也几乎是不可能达到的。[注释4] 。许多检验A级软件的代价通常都要归因于难以达到MC/DC的目标。另外，许多人声称MC/DC 有关发现错误的效力充其量是很微小的。 Dupuy 和Leveson[注释5]的最近一个个案研究发现扩大测试以满足MC/DC，“相对的昂贵，但并不代表真的比达到低级别的代码覆盖更昂贵。 在要求满足MC/DC的另外的测试案例里，发现重大错误(即发现软件没有被黑盒测试覆盖)”

 

 

定义

 

要对MC/DC建立一个有力的理解，知道MC/DC DO-178B 的术语描述以及关于条件和结果的描述是很必要的。

 

条件—一个不包含逻辑算子的布尔表达式

结果—一个由条件和0或者更多的逻辑算子组成的布尔表达式。一个没有逻辑算子的结果就是一个条件。如果一个条件在一个结果中出现多过一次，那么每次出现都是一个独立的条件。

MC/DC—程序中的每一个出口、入口都被调用至少一次， 程序中一个结果的每一个条件都执行所有可能的输出至少一次，程序中每一个结果执行所有可能的输出至少一次，而且一个结果中的每一个条件被显示出独立地影响着这个结果的输出。通过只改变这一个条件，同时锁定其它所有的条件，一个条件就可以独立的影响一个结果的输出

 

 

给了上面的描述，我们再注意一下下面这些常被误解的地方：

 

·MC/DC应用于每一个布尔表达式。就是说，MC/DC　应用于变量声明，例如Z:= A or B，或者来声明例如if A and B then……

·一个已知结果要输入的变量个数可能和条件的变量个数不一样。例如，结果(A and B) or (A and

C)，这里A, B, 还有 C　是布尔变量，包含三个输入(A, B, 以及 C)，和四个条件（第一个A, B, C, 第二个 A），由于Ａ每发生一次都被认为是一个独立的条件。

 

MC/DC 的含义

 

由Chilenski和 Miller开发的MC/DC 准则是为了能在只经过较少的测试就和经过彻底测试的软件相媲美方面获得一定的信心。既是，MC/DC　是想高度自信的来保证基于需求的测试已经证明源码里的每一个结果里的每一个条件都有其适当的作用。

在DO-178B的内容里，MC/DC起着测量基于需求测试的适当程度的作用，尤其是有关逻辑表达式。由此考虑，MC/DC也常被用作基于需求测试得出口规则（或出口规则的一部分）。RTCA/DO-248A文档 第二年澄清DO-178B的报告“空中系统和设备认证中的软件要求”解释结构覆盖分析的目的如下：

 

结构覆盖分析的目的　是补足基于需求的测试，如下示：

1. 提供证据说明代码结构已被核实达到了应用软件级别所需求的程度。

2. 提供一个方法来支持无非必须函数的论证。

3. 建立基于需求的测试的健全体制。

有关必须的函数，基于需求的测试（包括普通范围的测试和强健测试）和基于需求测试覆盖分析的结合保证了

测试的严格性和完全性……

 

基本原理是如果基于需求的测试证明了所有必须的函数被适当的执行了，如果结构覆盖分析证明所有存在的代码都是可达成的，并被充分的测试，这两项加起来就为证明没有不必需的函数提供了更多的信心。

 

 

MC/DC 基本原理

 

MC/DC要求一个结果里的每一个条件可以独立产生影响，这使得它区别于其它的结构覆盖方法。根据Chilenski 和Miller的结果,要想使得每一个逻辑条件可以独立地去影响其结果，就需要为每一个逻辑算子明确最小测试目标。在大多数依照MC/DC目标进行测试的案例里，明确和理解某2个逻辑算子的最小测试目标就为整个测试奠定了充分的基础。

 

要理解MC/DC，首先要理解怎样测试一个逻辑与操作符和一个逻辑或操作符。这里，用逻辑操作符来表示逻辑门；并且，“逻辑操作符”和“逻辑门”是可互换的。表一图示了与、或操作符。注意，布尔操作符用粗斜体字符来表示：与，和或；布尔条件由加粗大写字母表示：Ａ，Ｂ，Ｃ……；布尔输出由true 或 false 或 T或 F表示。

表一.基本逻辑门表示

 

图  示

真 值 表

               A

   

                Input

 

           C

          

                 Output

 

        A

                     C

        B   

 

          C =A and B;

   A  B  C

   T  T  T

   T  F  F

   F  T  F

   F  F  F

        A

                     C

        B   

 

          C =A or B;

   A  B  C

   T  T  T

   T  F  T

   F  T  T

   F  F  F

 

接下来的部分将描述一个与门和或门的最小测试准则

 

测试一个与门

 

为达到MC/DC，对一个有n位输入的与门最小测试的需求如下：

(1) 一个测试案例中，若所有的输入都被设为真，则其输出可预测为真。

(2) 测试案中每一个输入都被设为否，则输出可被预测为否。这就需要为n个输入的与门设计n个测试案例。

 

考虑到一个与门怎样工作时，测试准则就显示其意义了。任何一个“否”被输入到一个与门里都会导致输出结果为否。我们怎样证明每一个输入条件能独立影响输出结果呢？通过将一个测试案例的所有输入条件设为真，仅且仅设某一个输入条件为否 直到每一个输入被证明可以独立的影响输出为止。

 

因此，测试一个n输入的与门就需要一套专门的n+1测试案例。这些专门的n+1测试案例能够证明与门的正确执行，从而满足了MC/DC的要求。

 

表二给出了一个对3位输入的与门（如图一示）进行最小测试的例子。在这个例子里，表二中的测试案例1表明（1）的情况，测试案例2-4表明（2）的情况。

 

图一：3输入与门

 

表二：一个３输入与门的最小测试

 

编  号

  1 

  2

3

4

      输入A

T

F

T

T

      输入 B

T

T

F

T

      输入 C

T

T

T

F

      输出 D

T

F

F

F

 

 

至于表现出独立影响，测试案例１和２一起表明了Ａ的独立影响，因为在这两个测试案例里，Ａ的输入值是唯一和输出值一起改变的；同样的，测试案例１和３一起表明Ｂ对输出结果的独立影响；案例１和４一起，表明了Ｃ对结果的独立影响。

 

 

测试一个或门

 

为达到MC/DC，对一个有n位输入的或门最小测试的需求如下：

(1) 一个测试案例中，若所有的输入都被设为否，则其输出可预测为否。

(2) 测试案中每一个输入都被设为真，则输出可被预测为真。这就需要为n个输入的或门设计n个测试案例。

 

这些需求就要以一个或门对“真”值的灵敏度为基础。这里同样，测试一个n输入的或门也需要一套专门的n+1测试案例。这些专门的n+1测试案例通过证明或门的正确执行来满足MC/DC的要求。

 

表三给出了一个对3位输入的或门（如图二示）进行最小测试的例子。在这个例子里，表三中的测试案例1表明（1）的情况，测试案例2-4表明（2）的情况。这些测试对表明每一个输入都独立产生影响跟与门中的情况一样。

 

图二：３输入或门

 

表三：一个３输入或门的最小测试

 

测试案例编号

1

  2

3

  4

输入 A

F

T

F

F

输入 B

F

F

T

F

输入 C

F

F

F

T

输出 D

F

T

T

T

 

关于异或门的注意点

 

对于MC/DC而言，异或门和与门、或门是不同的。与门或或门都只有一个可能的最小测试装置，而对于异或门，Chilenski 和Miller 为一个2输入的与或门定义了四个可能的最小测试装置：(TT, TF, FT), (TF, FT, FF), (FT, TT, FF), 和 (TT, FF, TF)。

 

注意，仍然，异或操作可以被看作为与操作和或操作的结合；而且与或操作的测试标准源自于与操作和或操作的最小测试标准。表达式：A xor B可以被写成：（A or B） and not (A and B)。MC/DC要求这个异或操作需要四个测试案例（即是详尽测试）。在这个案例里，对异或执行进行分析后，建议谨慎对之进行详细测试。

 

异或操作是用作例子来解释我们评估MC/DC的方法，顺便说明为什么详尽测试更适合异或操作。

 

 

评估方法

 

这部分给出了一个实现方法用来评估一套现有的基于设备的测试案例是否符合MC/DC四个必须要求中的三个。 [注释6：MC/DC四个必须要求中的第四个：出入口测试和许多结构覆盖方法重复，所以，不须考虑进来]。

 

. 程序里的每一个结果都至少取所有可能的输出一次

. 程序中结果的每一个条件都取所有可能的输出至少一次

. 结果中的每一个条件都被证明可以独立影响结果的输出

 

这套评估方法是建立在与门和或门的最小测试案例，使用了两个来自逻辑电路理论的概念：可轧制性和可观察性。[注释７]软件的可轧制性可以简单的被描述为：为测试每一个逻辑算子而设计表达式值的能力（这相应于最小测试准则）。可观察性是指   的能力。 

用一个逻辑门级的方法来评估MC/DC ，源码里所有结果的每一个逻辑算子都需被检测以决定这个基于需求的测试是否已经用最小测试准则检测了这些操作。这个方法包括下面的五个步骤：

(1) 为源码建立一个图示。

(2) 识别使用过的测试输入。测试输入是从软件产品基于需求的测试中获得的。

(3) 排除伪测试案例。某一逻辑门的伪测试案例是指那些案例的输出结果是不可预测的。

(4) 确定MC/DC 要以每一个逻辑算子得最小测试准则为基础。

(5) 最后，检测测试的输出来确认软件的可正确操作性。重点不是重复基于需求测试的结果分析，而是确认源码的图示中提供了相同的输出结果。如果测试案例中一个期望的结果没有匹配基于源码图示的语气结果，则检测到源码和其图示的出错信息。

 

下面将分别分析描述以上各步骤。

 

源码图示

 

在评估过程的第一步，产生了软件的图示。用来描述源码的符号并不重要，只要一直采用同样的就行。下面这个例子说明了从源码图示开始的评估步骤。

 

看下面这一行Ada 源码:

Z := (A or B) and not (A and B);

 

图三既是它的图示。

 

图3. 源码的图示

 

虽然这个示例使用的是Ada 代码，但这个评估方法可以应用于不管是高级语言，例如Ada，还是用汇编语言编写的代码。

 

测试输入鉴定Identification of Test Inputs

 

下一步是从基于需求测试案例中得到输入值，将其绘图成为源码图示。这样做就可以以统一的格式为测试案例和源码提供一个完整的视图。

 

表4给出了示例源码的基于需求测试案例的输入值和预期可得到输出值。

 

表4. 示例的基于需求测试案例

 

案 例 编 号

 1

2

3

输入 A

  T

T

F

输入 B

T

F

T

输出 Z

F

T

T

 

本例的源码是执行一个与或操作。表4所给的测试案例提供了一个依照Chilenski 和 Miller的研究可以测试与或操作MC/DC的方法。因此，表4里的测试用例就是一个合格的基于需求测试。 图4用图示描述了上述测试案例。注意中间结果也是由测试输入所决定的，并在下图中标出。

 

图4：测试案例图示

 

知道中间结果是很重要的，因为它们为区别哪些测试案例能生成合法MC/DC结果提供了基础。测试案例里伪装成对达到MC/DC没有起作用的输出。

 

排除无效测试

 

使用注解图，就可以区分哪些基于需求测试案例对于达到MC/DC是没有起作用的。一旦这些测试案例被排除出考虑范围了，剩下的测试案例就象和最小测试准则一样，来决定它们是否能够满足MC/DC准则。

 

这一步对于达到可观察性是必须的。只有输出是可观察的的测试案例才被认为是值得信任的可能达到MC/DC的。一次电模拟短路多种控制输入，所以 影响输入（input of interest）被允许传送给输出对于描述好几条可观察性的重要原则很有帮助。

 

介绍第一个原则，考虑一个与门。由于我们将每次集中精力于某一个输入，所以实验输入是指像影响输入和其他输入，例如控制输入。表5所示与门真值表显示，如果与门的控制输入为真，则与门的输出同影响输入的值总是相同的；控制输入为否时，影响输入的值则对输出没有影响。

 

表5，一个与门的控制输入

 

   影响输入

控制输入

输出

T

T

T(影响输入)

F

T

F(影响输入)

T or F(无所谓)

F

  F

 

这证明了原理1：W and True= W

 

这样，任何与门都可以被看成一个从影响输入到输出的直接通道，只要另外的输入为真。

 

对或门使用相同的方法就得出了第二个准则。表6所示的或门真值表显示或门的输出总和影响输入值一样，如果控制输入为否。若控制输入的值为真，，则影响输入的值对输出值没有影响。

 

表6， 或门的控制输入

 

   影响输入

控制输入

输出

T

F

T(影响输入)

F

F

F(影响输入)

T or F(无所谓)

T

  T

 

既是，任何或门都可以被看成 一个丛影响输入到输出得直接通道，只要另外的输入为否。

 

为了区分哪些测试用例是不可用的，总简单的是通过向后观察示意图。再看图4所示的表达式(A or B)

and not (A and B)，输入到标志为 and2逻辑门的否掩盖了来自或门的相应输入。既是，测试案例1的或门的输出并不是通过观察Z栏中的结果就能得到。因此，测试案例1的或门不能通过MC/DC。图5显示的测试案例1由于或门被排除。注意，没有测试案例掩盖标记为and1的逻辑门。

 

图5，测试案例掩盖图示

 

 

那些没有被定义为掩盖测试案例的测试案例就被认为是MC/DC合格的。图5中，测试案例1，2和3对and1门，非门，和and2门是合格的。但是，只有测试案例2和3对或门是合格的。

 

MC/DC 测定（确定）

 

接下来一步是决定 合格测试案例是否能够证明MC/DC。这里，是否能够 取决于检测每一个逻辑门。从and1门开始，合格测试案例同为这个逻辑门设计的最小测试准则相比较，测试包括了TT, TF, 和 FT。在示例中，测试案例1提供了TT测试，测试案例2提供了TF测试，测试案例3提供了FT测试。因此，测试案例1、2和3可以为and1门证明MC/DC。

 

接下来就需要包含FF, TF, and FT的测试案例来测试或门。在这个例子当中，测试案例2提供了TF测试，测试案例3提供了FT测试。但是没有FF测试。  

 

MC/DC 和非门也是相关的——但只是和表明输入了所有可能值相关。表明独立影响并没有关系，因为非操作符只有一个参数。在这个例子里，测试案例1提供了一个真输入，测试案例2和3给非门提供否输入。这可以为非操作符证明MC/DC。

 

最后，and2门的输入被检测出和最小测试需求冲突。在这个案例里，测试案例2和3都提供了TT输入，测试案例1提供了一个FT输入。但是，表4中的测试案例不能为此次执行的异或操作证明MC/DC。表6总结了这些结果。

 

表6，最小测试和和法测试的对照

逻辑门

合法测试输入

缺省测试案例

and1

TT 案例1

TF 案例2

FT  案例3

 

无

or

TF 案例2

FT案例3

      FF

not

T 案例1

F 案例2或3

      无

and2

TT 案例2或3

FT 案例1

      FF

 

表4中的一组测试应该补充一个测试案例FF，来提供源码的MC/DC。一个FF测试案例就可以提供一个FF输入给and2门。加上这个FF测试案例意味着此例的详尽测试输入被提供给MC/DC了——但是，更好的建议是先对异或操作进行详尽测试要来得合理。

 

输出确认Output Confirmation

 

评估过程的最后一步是证明预期的结果在测试中都获得了。包括了输出确认这一步，是起一个提醒的作用，核实对MC/DC目标的实现，及适当的基于需求测试结果已一起完成。在示例中，由通过逻辑门、跟着测试输入决定的输出和预期结果吻合。

 

评估方法的五个步骤可以被用来作为评估任何源码的MC/DC分析方法。但是，如果手动完成整个工程，那这个方法就显得太耗费劳动力了。

 

这个方法的目的是想要给权威证明或确认分析家一个简单的方法可以人工确认测试案例或工具给出了恰当的结果。这些步骤也可以被用来帮助确认使用一个自动化工具来恰当的评估MC/DC。《 A Practical Tutorial on Modified Condition/Decision Coverage 》提供了这五个步骤的更多细节和示例。这本指南也讨论了考虑到精选和资质的结构覆盖工具和提示来评估一个申请者相关MC/DC的生命周期数据的重要因素。