嵌入式软件可靠性测试方法标准GB/T28171

免费智能真题库 > 历年试卷 > 嵌入式系统设计师 > 2020年下半年嵌入式系统设计师上午试卷综合知识

第59题

知识点：标准的代号和编号测试方法嵌入式软件可靠性可靠性测试软件可靠性测试

章/节：国际标准、国家标准、行业标准、企业标准基本知识

嵌入式软件可靠性测试方法标准GB/T28171—2011是(59)。

A. 强制性国家标准

B. 推荐性国家标准

C. 强制性行业标准

D. 推荐性行业标准

相关试题：国际标准、国家标准、行业标准、企业标准基本知识

更多>

第53题 2011年下半年

63%

按制定标准的不同层次和适用范围，标准可分为国际标准、国家标准、行业标准和企业标准等。(53)制定的标准是国际标准。

第13题 2011年下半年

64%

(13)既不是图像编码也不是视频编码的国际标准。


知识点讲解
· 标准的代号和编号 · 测试方法 · 嵌入式软件 · 可靠性 · 可靠性测试 · 软件可靠性测试

标准的代号和编号

国际标准ISO的代号和编号

国际标准ISO的代号和编号的格式为ISO+标准号+[杠+分标准号]+冒号+发布年号（方括号中的内容可有可无），例如，ISO 8402：1987和ISO 9000-1：1994是ISO标准的代号和编号。

国家标准的代号和编号

我国国家标准的代号由大写汉语拼音字母构成，强制性国家标准代号为GB，推荐性国家标准的代号为GB/T。

国家标准的编号由国家标准的代号、标准发布顺序号和标准发布年代号（4位数）组成。

（1）强制性国家标准：GB×××××—××××。

（2）推荐性国家标准：GB/T×××××—××××。

行业标准的代号和编号

（1）行业标准代号。行业标准代号由汉语拼音大写字母组成，由国务院各有关行政主管部门提出其所管理的行业标准范围的申请报告，国务院标准化行政主管部门审查确定并正式公布该行业标准代号。已正式公布的行业代号有QJ（航天）、SJ（电子）、JB（机械）和JR（金融系统）等。

（2）行业标准的编号。行业标准的编号由行业标准代号、标准发布顺序及标准发布年代号（4位数）组成，表示方法如下。

.强制性行业标准编号：××××××—××××。

.推荐性行业标准编号：××/T××××—××××。

地方标准的代号和编号

（1）地方标准的代号。由大写汉语拼音DB加上省、自治区、直辖市行政区划代码的前两位数字（如北京市11、天津市12、上海市31等），再加上斜线T组成推荐性地方标准；不加斜线T为强制性地方标准，表示方法如下。

.强制性地方标准：DB××。

.推荐性地方标准：DB××/T。

（2）地方标准的编号。地方标准的编号由地方标准代号、地方标准发布顺序号和标准发布年代号（4位数）3部分组成，表示方法如下。

.强制性地方标准：DB×××××—××××。

.推荐性地方标准：DB××/T×××—××××。

企业标准的代号和编号

（1）企业标准的代号。企业标准的代号由汉语大写拼音字母Q加斜线再加企业代号组成，企业代号可用大写拼音字母、阿拉伯数字或两者兼用组成。企业代号按中央所属企业和地方企业分别由国务院有关行政主管部门或省、自治区、直辖市政府标准化行政主管部门会同同级有关行政主管部门加以规定。例如，Q/×××。企业标准一经制定颁布，即对整个企业具有约束性，是企业法规性文件，没有强制性企业标准和推荐性企业标准之分。

（2）企业标准的编号。企业标准的编号由企业标准代号、标准发布顺序号和标准发布年代号（4位数）组成，表示方法：Q/×××××××—××××。

测试方法

根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。

静态测试和动态测试

静态测试

静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。

静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。

代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。

代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。

对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。

静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。

动态测试

动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。

黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。

白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。

动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。

在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。

黑盒测试

黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。

功能分解

功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。

步骤如下：

（1）使用程序设计中的功能抽象方法把程序分解为功能单元。

（2）使用数据抽象方法产生测试每个功能单元的数据。

功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。

数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。

等价类划分

等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。

步骤如下：

（1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。

（2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。

（3）为每一个等价类定义一个唯一的编号。

（4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。

边界值分析

边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。

步骤如下：

（1）通过分析需求规格说明，找出所有可能的边界条件。

（2）对每一个边界条件，给出满足和不满足边界值的输入数据。

（3）设计相应的测试用例。

对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。

判定表

判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。

条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。

建立并优化判定表，把判定表中每一列表示的情况写成测试用例。

该方法的使用有以下要求：

（1）需求规格说明以判定表形式给出，或是很容易转换成判定表。

（2）条件的排列顺序不会影响执行哪些操作。

（3）规则的排列顺序不会影响执行哪些操作。

（4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

（5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。

因果图

因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。

步骤如下：

（1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。

（2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。

（3）在因果图上标明约束条件。

（4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。

（5）把判定表中每一列表示的情况生成测试用例。

如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。

随机测试

随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。

猜错法

猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。

正交实验法

正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。

利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。

白盒测试

白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。

控制流测试

控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：

（1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。

（2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。

（3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。

（4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。

对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。

（5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。

（6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。

以上各种覆盖的控制流测试步骤如下：

（1）将程序流程图转换成控制流图。

（2）经过语法分析求得路径表达式。

（3）生成路径树。

（4）进行路径编码。

（5）经过译码得到执行的路径。

（6）通过路径枚举产生特定路径的测试用例。

控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。

控制流图基本结构

数据流测试

数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。

数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。

数据流测试步骤：

（1）将程序流程图转换成控制流图。

（2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。

（3）选定数据流测试策略。

（4）根据测试策略得到测试路径。

（5）根据路径可以获得测试输入数据和测试用例。

动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。

程序变异

程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。

程序插装

程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。

有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。

域测试

域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。

符号求值

符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。

嵌入式软件

软件实际上是客观世界问题空间与解空间的具体实现，也是人类知识的提炼、抽象和固化。软件是计算机相关的：

（1）完成预定功能和性能的可执行的指令（计算机程序）序列。

（2）程序操作的信息或数据结构。

（3）描述程序操作、数据和使用的文档。

嵌入式软件是为完成某特定用途而开发的、驻留在预先定义的嵌入式计算机平台上的软件。随着微电子技术飞速发展带来的智能化需求的不断扩展，嵌入式软件无处不在，规模也越来越大。

近三十年来，随着现代化战争信息化程度的不断提高，随着装备由机械化向信息化的战略转型，军用软件已经渗透到军事应用的各个方面，成为装备及其体系中不可或缺的组成部分，其发展和应用水平代表着一个国家的装备实力。美国国防部在2002年的《国防科学技术领域计划》中就把军用软件设计和改进作为重要研究领域，制定了军用软件发展的近、中、远期目标。2011年，美国政府、国防部、海陆空三军、洛克希德·马丁公司等26个组织组成工作组，专题研究军事装备中软件研制和部署存在的问题，形成《美国国防部与国防工业领域软件工程的重大问题报告》，对军用软件的发展提出建议。这些都说明了军用软件在现代化战争中的重要地位和作用。

随着飞机机载计算机的广泛使用，机载软件从无到有、规模从小到大、复杂度从低到高。软件负责数据的采集、存储和处理。实时进行各种逻辑判断、数学运算、行为推导、状态转换等处理，帮助飞行员优化各种操作，实现飞行航路计算、姿态控制、环境控制、燃油输送、任务计算、状态监控、信息显示报警、人机界面控制等功能，不夸张地说，飞行员每一个操作、飞机的每一个动作的完成都离不开软件运行。而软件的复杂性、重要性还体现在：

（1）从计算机理论和技术发展趋势来说，硬件和软件没有明确界限，原来使用硬件实现的功能在尽可能地向软件迁移，技术进步越来越显现在软件方面。

（2）软件直接和飞机安全功能相关，而且这种相关性越来越高，如电传飞控软件。

（3）软件的特殊性导致了需要有特殊的规则保证系统的安全性、可靠性。

与硬件不同，软件至今尚未摆脱手工方式。更严重的是，软件在开发过程中涉及到了各行各业的工作人员，其中包括业务定义人员、系统分析员、系统设计人员、软件架构师、软件工程师、软件测试工程师以及质量工程师等。实际上这些人员中只有软件工程师是专业软件开发人员，其他人员都需要同时具备软件和其他行业的背景。因此与其他行业比较，软件行业具有以下鲜明的特点：

（1）抽象性：软件直接反映了人的思维逻辑实体，同时几乎没有具体物理实体，且没有明显的制造过程。

（2）客观问题越来越复杂，软件也随之越来越复杂，而且软件技术的进步速度落后于需求增长的速度。

（3）相对于通用硬件，软件开发成本昂贵，随着问题规模的加大、成本急剧增加。

（4）软件运行和使用没有磨损或老化现象。

（5）软件对硬件和环境有着不同程度的依赖性。

（6）大多数软件是新开发的，通过已有构件组装技术尚不成熟。

（7）软件工作结果涉及到许多社会因素。

以上特点使得软件开发进展情况较难衡量，软件质量不易评价，从而使软件产品的生产管理、过程控制及质量保证都相当困难。

对于嵌入式软件而言，它除了具有通用软件的一般特性，同时还具有一些与嵌入式系统密切相关的特点。这些特点包括：

（1）软件受资源的限制。由于嵌入式系统的资源一般比较有限，所以嵌入式软件必须尽可能地精简，才能适应这种状况。

（2）开发难度大。嵌入式软件的运行环境和开发环境一般比较复杂，从而加大了它的开发难度。首先，由于硬件资源有限，使得嵌入式软件在时间和空间上都受到严格的限制，但要想开发出运行速度快、存储空间少、维护成本低的软件，需要开发人员对编程语言、编译器和操作系统有深刻的了解。其次，嵌入式软件一般都要涉及到底层软件的开发，应用软件的开发也是直接基于操作系统的，这就需要开发人员具有扎实的软、硬件基础，能灵活运用不同的开发手段和工具，具有较丰富的开发经验。最后，对于嵌入式软件来说，它的开发环境与运行环境是不同的。嵌入式软件是在目标系统上运行，但开发工作要在另外的开发系统中进行，当编程人员将应用软件调试无误后，再把它放到目标系统上去。

（3）实时性和可靠性要求高。实时性是嵌入式系统的一个重要特征，许多嵌入式系统要求具有实时处理的能力，这种实时性主要是靠软件层来体现的。软件对外部事件做出反应的时间必须要快，在某些情况下还要求是确定的、可重复实现的，不管系统当时的内部状态如何，都是可以预测的。同时，对于事件的处理一定要在限定的时间期限之前完成，否则就有可能引起系统的崩溃。例如，火箭飞行控制系统就是实时的，它对飞行数据采集和燃料喷射时机的把握要求非常的准确，否则就难以达到精确控制的目的，从而导致飞行控制的失败。

与实时性相对应的是可靠性，因为实时系统往往应用在一些比较重要的领域，如航天控制、核电站、工业机器人等等，如果软件出了问题，那么后果是非常严重的，所以要求这种嵌入式软件的可靠性必须非常高。

（4）要求固化存储。为了提高系统的启动速度、执行速度和可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是像通常的计算机系统那样，存储在磁盘等载体中。

可靠性

（1）完备性。完备性评价指标及测量，如下表所示。

完备性评价指标及测量

（2）连续性。连续性评价指标及测量，如下表所示。

连续性评价指标及测量

（3）稳定性。稳定性评价指标及测量，如下表所示。

稳定性评价指标及测量

（4）有效性。有效性评价指标及测量，如下表所示。

有效性评价指标及测量

（5）可追溯性。可追溯性评价指标及测量，如下表所示。

可追溯性评价指标及测量

可靠性测试

软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。

可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。

软件可靠性测试

软件的可靠性测试概述

软件测试者可以使用很多方法进行软件测试，如按行为或结构来划分输入域的划分测试，纯粹随机选择输入的随机测试，基于功能、路径、数据流或控制流的覆盖测试等。对于给定的软件，每种测试方法都局限于暴露一定数量和一些类别的缺陷。通过这些测试能够查找、定位、改正和消除某些缺陷，实现一定意义上的软件可靠性增长。但是，由于它们都是面向错误的测试，测试所得的结果数据不能直接用于软件可靠性评价，必须经过一定的分析处理后方可使用可靠性模型进行可靠性评价。

软件可靠性测试由可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等主要活动组成。

软件可靠性测试还必须考虑对软件开发进度和成本的影响，最好是在受控的自动测试环境下，由专业测试机构完成。

软件可靠性测试是一种有效的软件测试和软件可靠性评价技术。尽管软件可靠性测试也不能保证软件中残存的缺陷数最少，但经过软件可靠性测试可以保证软件的可靠性达到较高的要求，对于开发高可靠性与高安全性软件系统很有帮助。

软件可靠性测试要在工程上获得广泛应用，还有许多实际问题需要解决。

定义软件运行剖面

定义运行剖面首先需要为软件的使用行为建模，建模可以采用马尔可夫链来完成。用马尔可夫链将输入域编码为一个代表用户观点的软件使用的状态集。弧用来连接状态并表示由各种激励导致的转换。这些激励可能由硬件、人机接口或其他软件等产生。将转换概率分配给每个弧，用来代表一个典型用户最有可能施加给系统的激励。这种类型的马尔可夫链是一个离散的有限状态集。这类模型可以用有向图或转换矩阵表示。

定义运行剖面的下一步是开发使用模型，明确需要测试的内容。软件系统可能会有许多用户和用户类别，每类用户都可能以不同的方式使用系统。开发使用模型涉及到将输入域分层。有两种类型的分层形式：用户级分层和用法级分层。用户级分层依赖于谁或什么能激励系统。用法级分层依赖于在测试状态下系统能做什么。换句话说，用户级分层考虑各种类型的用户以及他们如何使用系统，用法级分层则要求考虑系统能够提供的所有功能。一旦用户和用法模型被开发出来，弧上的概率将被分配。这些概率估计主要是基于如下几个方面。

. 从现有系统收集到的数据；

. 与用户的交谈或对用户进行观察获得的信息；

. 原型使用与测试分析的结果；

. 相关领域专家的意见。

定义使用概率的最佳方法是使用实际的用户数据，如来自系统原型、前一版本的使用数据；其次是由该软件应用领域的用户和专家提供的预期使用数据；在没有任何数据可用的情况下，只能是将每个状态现有的弧分配相同的概率，这是最差的一种方法。

由于软件可靠性行为是相对于软件实际的运行剖面而言的，同一软件在不同运行剖面下其可靠性表现可能大不相同，所以用于可靠性测试准备的运行剖面的开发与定义必须充分分析和考虑软件的实际运行情况。

软件可靠性测试假设每个操作的数据输入都有同样的发生错误的概率，这样最频繁出现的操作和输入将表现出最高的故障率。对于特定的操作环境这是正确的，但无法贯穿系统的全部操作集合。典型的例子是飞机的飞行控制软件，在正常飞行、起飞、降落、地面运动和地面等待这五个状态中，尽管起飞和降落在运行剖面上只占有很小的百分比，但是它们却占有很大的故障比例。对于高安全性要求的软件，一个看起来很少使用的代码路径也可能带来灾难性的后果。因此，对于边界、跃迁情况和关键功能不应该用简单的运行剖面来对待，应该构造专门的运行剖面，补充统计模型之外的测试用例。在覆盖率水平不够时，可根据具体空白，进行适当的补充测试，如果补充测试发现了错误，就可分析这些错误，估计其对可靠性产生的影响。

一个产品有可能需要开发多个运行剖面，这取决于它所包含的运行模式和关键操作，通常需要为关键操作单独定义运行剖面。

可靠性测试用例设计

为了对软件可靠性进行良好的预计，必须在软件的运行域上对其进行测试，首先定义一个相应的剖面来镜像运行域，然后使用这个剖面驱动测试，这样可以使测试真实地反映软件地使用情况。

由于可能的输入几乎是无限的，测试必须从中选择出一些样本，即测试用例。测试用例要能够反映实际的使用情况，反映系统的运行剖面。将统计方法运用到运行剖面开发和测试用例生成中去，并为在运行剖面中的每个元素都定量地赋予一个发生概率值和关键因子，然后根据这些因素分配测试资源，挑选和生成测试用例。

在这种测试中，优先测试那些最重要或最频繁使用的功能，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障，以保证软件的按期交付。

设计测试用例就是针对特定功能或组合功能设计测试方案，并编写成文档。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

一个典型的测试用例应该包括下列组成部分。

. 测试用例标识；

. 被测对象；

. 测试环境及条件；

. 测试输入；

. 操作步骤；

. 预期输出；

. 判断输出结果是否符合的标准；

. 测试对象的特殊需求。

由于可靠性测试的主要目的是评估软件系统的可靠性，因此，除了常规的测试用例集仍然适用外，我们还要着重考虑和可靠性密切相关的一些特殊情况。在测试中，可以考虑进行“强化输入”，即比正常输入更恶劣（合理程度的恶劣）的输入。

下表给出一些参考例子：

可靠性测试用例设计时重点考虑的一些特殊情况

可靠性测试的实施

在进行应用软件的可靠性测试前有必要检查软件需求与设计文档是否一致，检查软件开发过程中形成的文档的准确性、完整性以及与程序的一致性，检查所交付程序和数据以及相应的软件支持环境是否符合要求。

这些检查虽然增加了工作量，但对于在测试早期发现错误和提高软件的质量是非常必要的。

软件可靠性测试必须是受控测试，在运行此类测试时，为了保证统计数据的有效性，测试过程中的每个测试用例必须施加于相同的软件版本，新的软件版本意味着新测试的开始。

在有些情况下，不能进行纯粹的可靠性测试。因为客户的要求、合同的规定或者标准的约束，需要补充其他形式的非统计测试。这时的最佳选择是既执行可靠性测试，也执行非统计测试（如覆盖测试）。如果非统计测试在可靠性测试之前完成，由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试，可能会影响软件可靠性评估的准确性。

软件可靠性测试同样依赖于软件的可测试性。可靠性测试难点就在于判断测试用例的运行是成功还是失败。在控制系统及类似的软件中，失效由详细说明、时间（通常是CPU时间或时钟时间）来客观地定义。而在一般应用系统中，失效的定义更主观些，它不仅依赖于程序是否符合规格说明的要求，也取决于指定的性能是否能够达到用户的期望，但是否达到期望没有确定的标准。在一些科学计算中，计算结果只能由计算机给出，在这种情况下，如果软件只是输出了错误的结果而不是整个系统发生失效，错误就不可能被发现。此时可以将测试分成两个阶段进行。第一阶段运行较少量的测试用例，并对照规范进行仔细检查。第二阶段再运行大量测试用例。第二阶段不用人工检查输出的每项内容，而是找失效现象，包括错误信息、断电、崩溃和死机。也可把输出记录到文件中，采用搜索或过滤方法进行处理。如果软件有足够的可测试性，这种方法不会漏掉很多的严重失效。如果计算的正确性无法验证，就需要对软件进行一些形式化的证明。

开发方交付的任何软件文档中与可靠性质量特性有关的部分、程序以及数据都应当按照需求说明和质量需求进行测试。在项目合同、需求说明书和用户文档中规定的所有配置情况下，程序和数据都必须进行测试。

软件可靠性数据是可靠性评价的基础。为了获得更多的可靠性数据，应该使用多台计算机同时运行软件，以增加累计运行时间。应该建立软件错误报告、分析与纠正措施系统。按照相关标准的要求，制定和实施软件错误报告和可靠性数据收集、保存、分析和处理的规程，完整、准确地记录软件测试阶段的软件错误报告和收集可靠性数据。

用时间定义的软件可靠性数据可以分为4类，具体如下。

. 失效时间数据，记录发生一次失效所累积经历的时间；

. 失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；

. 分组时间内的失效数，记录某个时间区内发生了多少次失效；

. 分组时间的累积失效数，记录到某个区间的累积失效数。

这4类数据可以互相转化。

在测试过程中必须真实地进行记录，每个测试记录必须包含如下信息。

. 测试时间；

. 含有测试用例的测试说明或标识；

. 所有与测试有关的测试结果，包括失效数据；

. 测试人员。

测试活动结束后要编写《软件可靠性测试报告》，对测试用例及测试结果在测试报告中加以总结归纳。编写时可以参考GJB 438A-97中提供的《软件测试报告》格式，并应根据情况进行剪裁。测试报告应具备如下内容。

. 软件产品标识；

. 测试环境配置（硬件和软件）；

. 测试依据；

. 测试结果；

. 测试问题；

. 测试时间。

把可靠性测试过程进行规范化，有利于获得真实有效的数据，为最终得到客观的可靠性评价结果奠定基础。

对于软件可靠性测试用例的设计，有关更详细的内容可以参照本书中“黑盒测试用例设计”部分。

题号导航 2020年下半年嵌入式系统设计师上午试卷综合知识

本试卷我的完整做题情况



	第59题在手机中做本题