1、ICS 35.080L77 中 华 人 民 共 和 国 国 家 标 准GB/T XXXXXXXXX嵌入式软件可靠性测试方法Embedded software reliability testing method“在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上”（征求意见稿）（本稿完成日期：2010-06-18）XXXX - XX - XX 发布 XXXX - XX - XX 实施GB/T XXXXXXXXXI目 次前言 .III引言 IV1 范围 12 规范性引用文件 13 术语和定义 14 测试目的 25 测试环境 26 测试内容 37 测试方法 37.1 一般原则 37.2
2、可靠性目标的识别 37.3 开发操作剖面 47.4 测试准备 67.5 执行测试 77.6 失效数据的分析评估 97.7 可靠性测试报告 .128 测试流程 .138.1 操作剖面构造 .138.2 测试方案制定 .138.3 测试准备 .138.4 测试执行 .138.5 测试评估 .13附录 A（资料性附录） 可靠性示图绘制 14附录 B（资料性附录） 可靠性模型选择 16参考文献 17GB/T XXXXXXXXXII前 言本标准由全国信息技术标准化技术委员会（SAC/TC28）提出并归口。本标准起草单位：中国电子技术标准化研究所、珠海南方软件产品检测中心、珠海许继电气有限公司、珠海炬力集
3、成电路设计有限公司。本标准主要起草人：GB/T XXXXXXXXXIII引 言嵌入式系统是指以应用为中心，以计算机技术为基础，软硬件可裁剪，适应应用系统对功能、可靠性、成本、体积和功耗严格要求的专门计算机系统。嵌入式技术并不是一个独立的学科，它是伴随着微电子技术和计算机技术的发展，微控制芯片功能越来越强大，而嵌入微控制芯片的设备和系统越来越多而发展起来的。嵌入式系统几乎包括了生活中所有的电器设备，如：mp3、手机、数字电视、汽车、微波炉、数码相机、电梯、空调、自动售货机、工业自动化仪表与医疗仪器等。虽然大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但嵌入式软件可靠性测试与通用软件可
4、靠性测试有着较大差别，这是由于嵌入式系统软硬件功能界限模糊，软件对硬件的依赖性和专用性较强，对实时性、安全性要求较高，目前针对嵌入式软件的测试和调试工具较少等等，这些都使得嵌入式软件的测试比通用计算机软件测试的复杂性、可继承性较差。本标准参考了国内外相关资料,结合嵌入式软件可靠性测试的实践以及嵌入式软件可靠性测试的特点制订的，着重于嵌入式软件的可靠性测试。既可作为嵌入式软件测试中的可靠性增长测试要求，也可作为软件交付时验收方的验证测试要求。GB/T XXXXXXXXX1嵌入式软件可靠性测试方法1 范围本标准规定了嵌入式软件生存周期内软件产品的可靠性测试方法、过程和准则。本标准适用于嵌入式软件生
5、存周期全过程。本标准适用于嵌入式计算机软件的测试机构和测试人员。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 9386 -2008 计算机软件测试文档编制规范GB/T 11457 -2006 信息技术 软件工程术语GB/T 15532-2008 计算机软件测试规范GB/T 16260.1-2006 软件工程 产品质量 第1部分：使用质量的度量GB/T 16260.2-2006 软件工程 产品质量 第2部分：内部模型GB/T 16260.3-2006 软件工
6、程 产品质量 第3部分：外部度量GB/T 16260.4-2006 软件工程 产品质量 第4部分：质量模型3 术语和定义GB/T 11457中界定的以及下列术语和定义适用于本文件。3.1 软件可靠性 software reliability特定自然单元数或特定任务时间内软件无失效执行的概率。3.2 偏离 deviation嵌入式软件执行中的系统行为相对预期行为的偏差。3.3 失效 failure系统运行行为对用户要求的偏离，是一种面向用户的概念。3.4 失效强度 failure intensityGB/T XXXXXXXXX2是表示可靠性的另一种方式，是指单位时间出现的失效次数。3.5 操作
7、operation一种逻辑概念，与软件功能或特征相关，如用户命令的执行、对输入的响应处理、系统内事务处理等，是持续一段时间，结束时将控制权还给系统的一个逻辑任务。3.6 操作剖面 operational profile操作的集合及其出现的概率。3.7 操作模式 operational mode随时间或资源、输入有较大差别的操作的集合。3.8 水平 level是指具有相似性，预期操作产生相同失效行为的一组输入变量。4 测试目的嵌入式软件可靠性测试的目的是：通过嵌入式软件可靠性测试有效地发现程序中影响软件可靠性的缺陷，实现可靠性增长；验证嵌入式软件是否满足嵌入式系统开发合同或项目开发计划、系统/子
8、系统设计文档、软件需求规格说明和软件设计说明所规定的软件可靠性要求；通过对嵌入式软件可靠性测试中观测到的失效情况进行分析，验证嵌入式软件可靠性的定量要求是否得到满足；评估当前嵌入式软件可靠性的水平，预测未来可能达到的水平，从而为嵌入式软件开发管理提供决策依据；通过嵌入式可靠性测试平衡用户对可靠性、时间开发和开发费用的需要。5 测试环境嵌入式软件可靠性测试的测试环境应具备如下条件：在被测试的嵌入式软件单元测试之后，或经过验证和集成使得嵌入式系统操作可以完全执行。具备嵌入式软件运行的目标环境，或高度一致的仿真环境。具备与嵌入式系统应用验证相关的必要的测试仪器仪表，如频率源、波形发生器、标准电压电流
9、源、规约分析器等。具备嵌入式系统运行的温度、湿度、电磁兼容环境。具备一些专用的测试工具。GB/T XXXXXXXXX3具备操作剖面所需要的全部外部输入和输出的环境支持。6 测试内容嵌入式软件可靠性测试的内容包括：可靠性增长测试和可靠性验证测试。可靠性增长测试以迭代的方式进行，根据测试过程中检出和跟踪的失效，使用基于可靠性增长模型和统计推理的可靠性评估方法，进行失效强度的估计，然后消除缺陷再测试，使可靠性达到目标要求从而结束测试。可靠性验证测试是产品发放或交付前为确定在风险范围内的可接收程度而组织实施的最终测试。7 测试方法7.1 一般原则GB/T 15532-2008 计算机软件测试规范中确定
10、的系统测试方法适用于本标准，一般采用黑盒测试手段进行嵌入式软件可靠性测试项目的测试。进行嵌入式软件可靠性测试，首先明确可靠性目标。如果没有规定可靠性目标时，应按照7.2节中的方法进行可靠性目标的识别。识别出可靠性目标后，进行操作剖面开发工作，然后进行测试准备，最后进行可靠性测试、分析评估、验证。7.2 可靠性目标的识别不同的嵌入式软件，应用场合的不同，对可靠性的要求不同，应根据实际需要定义合适可靠性目标。按照7.2.1至7.2.3节的通用方法识别可靠性目标。7.2.1 识别失效程度对一个嵌入式软件，根据产品的使用范围、对象，识别出失效的严重程度。一般根据对人员生命、成本和系统能力的影响来区分失
11、效的严重程度；失效严重程度级别用于对失效数据的分析，在测试过程中判定是否需要查找缺陷和解决。表1给出失效严重程度的级别。表 1 嵌入式软件失效的严重程度级别失效严重程度级别 失效的描述1 不能进行一项或多项关键操作2 不能进行一项或多项重要操作3 不能进行一项或多项操作，但是有补救办法4 一项或多项操作中的小缺陷7.2.2 为嵌入式软件建立失效强度目标根据嵌入式系统的使用对象，为嵌入式软件建立失效强度目标，表2为推荐的失效强度目标、失效间隔时间和失效影响的对照表。表 2 失效强度目标、失效间隔时间与失效影响对照表GB/T XXXXXXXXX4失效造成的影响 典型失效强度目标 失效间隔时间造成人
12、员伤亡或千万元以上经济损失610114 年没有人身伤害，10 万元以上经济损失410000 小时没有人身伤害，万元以上经济损失3106 周没有人身伤害，千元以上经济损失2100 小时没有人身伤害，少量经济损失 1010 小时没有人身伤害，轻微或无经济损失1 小时7.2.3 选择通用度量由于嵌入式系统一般是连续运行的，因此嵌入式软件在时间度量上，普通时间和执行时间是一致的，所以，选择普通时间作为通用度量，本测试方法采用以小时作为时间单元数的测量。也可以采用自然单元作为通用度量。表3为1小时任务时间的可靠性与等效失效强度的对照表。表 3 等效的可靠性和失效强度1 小时任务时间的可靠性 失效强度0.
13、368 每小时 1 个失效0.9 每 1000 小时 105 个失效0.959 每天 1 个失效0.99 每 1000 小时 10 个失效0.994 每周 1 个失效0.9986 每月 1 个失效0.999 每 1000 小时 1 个失效0.99989 每年 1 个失效失效强度和可靠性转换的公式：(1)tRln(2)texp式中：失效强度； 可靠性； R自然或时间单元数。t7.3 开发操作剖面GB/T XXXXXXXXX57.3.1 识别操作模式对于不同的嵌入式软件，操作模式会显著不同，识别操作模式推荐按照表4的方法进行。表 4 操作模式的识别识别操作模式 识别方法主要时间和次要时间 某天或一
14、天的某段时间，处理的事务或事务频度显著不同，处理事务量的显著差别不同的用户类型 管理员、一般使用者、新手等输入的显著差别 大量和多变的输入电源的极限 电源方面的要求温度的极限 温度方面的要求电磁的极限 电磁兼容方面要求其它环境的重大变化 如湿度、震动、噪声等方面要求行业规范要求的模式 如电信、电力、银行等行业要求7.3.2 确定操作的发起者操作的发起者包括用户、外部条件、嵌入式系统自身等，按照表 5 的识别方法进行识别。表 5 操作发起者的识别识别发起者 识别方法使用用户 使用者操作、远程登陆等外部条件 外部输入，如输入一个开关量、收到输入信号嵌入式系统自身 嵌入式系统软硬件判断出的条件，如内
15、存异常、中断信号、内部变量等7.3.3 选择表示方法操作剖面的表示方法有表格法和图形法。可以根据使用习惯来选择。本标准推荐采用表格方法。即用列表的方式，列出所有操作模式、操作发起者、操作、操作出现率等信息的表示方法。7.3.4 创建操作表创建操作表需要参考用户需求、软件使用说明、行业规定及相关标准要求等，通常以操作的启动者来划分。在定义输入空间、操作覆盖输入空间时，应考虑全覆盖。表6举例说明如何创建一个操作表。表 6 创建操作表识别发起者 操作输出一个信号到外部 1A（外部输入一个开关信号）输出一个信号到外部 2GB/T XXXXXXXXX6B（使用者输入一个指令） 显示一行信息提示数据满C（
16、内部数据存储满）系统告警信号灯亮7.3.5 确定出现率根据用户需求、软件规格、使用说明、经验等信息，确定每种操作的出现率。表7举例说明如何确定出现率。表 7 确定出现率操作 出现率（每小时出现次数）输出一个信号到外部 1 10输出一个信号到外部 2 10显示一行信息 1000提示数据满 0.001系统告警信号灯亮 0.001合计 1020.0027.3.6 确定出现概率将每个操作的出现率除以总出现率。表 8 举例说明如何确定出现概率。表 8 确定出现概率操作 出现概率输出一个信号到外部 1 0.0098输出一个信号到外部 2 0.0098显示一行信息 0.9804提示数据满 0.0000009
17、8系统告警信号灯亮 0.00000098合计 17.4 测试准备包括：测试用例准备和测试过程准备。7.4.1 测试用例准备测试用例准备过程主要包括：估计当前版本所需的新测试案例的数量；在要测试的系统之间分配新测试用例的数量；在每个系统的新操作之间分配新测试用例的数量；指定新测试用例；开发新增测试用例，将新测试用例增加到以前版本的测试用例上。GB/T XXXXXXXXX77.4.1.1 估计需要测试用例的数量估计需要测试用例的数量，要考虑时间和成本因素，取这两个数量的最小值作为计划准备的测试用例的数量。时间的计算，用可用的时间乘以可用的人员数，除以准备一个测试用例的平均时间。成本的计算，用建立测
18、试用例的预算除以每个测试用例的平均准备成本。对于再次测试，如回归测试，只计算新增加的测试用例数量。7.4.1.2 分配测试用例为每个操作分配测试用例数量。对于回归测试，只分配新修改的操作的测试用例。根据操作出现率，进行下面的工作：识别很少出现的关键操作，确定为每个这样的操作分配测试用例数量。关键操作是指失效会造成人身伤害、重大损失的操作，对这些操作要分配充足的测试用例；识别不经常性的操作，分配一个测试用例，不经常性的操作是指出现概率非常低的操作，这样作的目的是保证至少为这样的操作分配一个测试用例；根据操作概率，把剩下的测试用例分配给剩余的其它操作。7.4.1.3 指定测试用例为每个操作指定测试
19、用例。为由操作的直接输入变量的可能组合水平定义的在所有选项中具有相等概率的操作选择每个测试用例。在选择了水平组合之后，以相等概率，从组成水平的集合成员中，随机选择输入变量。选择了测试用例后，准备测试用例的脚本。7.4.2 测试过程准备为每个操作模式准备一个测试过程，指定或调整测试过程剖面和操作出现率，调整主要发生在回归测试或新增加功能的测试过程。7.5 执行测试7.5.1 分配测试时间分配测试时间按照以下方法进行：在要测试的系统之间分配测试时间；对进行可靠性增长测试的功能测试、回归测试、负载测试之间分配测试时间。对进行负载测试的操作模式之间分配测试时间。对嵌入式软件进行可靠性增长测试，首先要分
20、配足够的时间进行功能测试，以便充分执行测试用例，并对前一版本进行回归测试。然后把剩下的时间分配给负载测试。进行确认测试，将所有的时间都分配给负载测试。时间分配按小时度量。估计测试需要的时间按下式：(3)FNTt式中：GB/T XXXXXXXXX8用自然或时钟时间单元表示的测试时间；t规范化度量（MTTF数）；NT失效强度目标。F.(4)1lnNT式中：分辨率；提供商风险；客户风险。7.5.2 调用测试对于可靠性增长测试，首先执行功能测试，然后进行负载测试，按照测试用例进行全覆盖测试。在每次对软件作了较大修改后，要进行回归测试。功能测试按照分配的测试用例，顺序调用测试用例进行测试。回归测试应全面
21、检查新功能，随机调用测试用例。7.5.3 标识出现的失效在测试中应对测试的输出进行分析，确定失效、失效时间和失效强度。7.5.3.1 分析测试输出的偏离采用自动化工具或人工对测试结果审查，确定执行结果与相对预期行为的偏差。在分析变差的过程中，不计算级联偏差。7.5.3.2 确定哪些偏离是失效确定出现的偏离是否为失效。硬件错误引起的失效不作为嵌入式软件的失效统计，但要协商，对于需要实现软件容错、避免严重错误的失效，应统计在内。7.5.3.3 估计失效发生的时间估计失效发生的时间采用统一的时间度量，即普通时间。以出现顺序，累加度量单元，包括所有操作模式的功能测试、回归测试、负载测试。对于同时出现的
22、多个失效记录，会导致多个零失效间隔，应估计一个随机的的时间间隔，用于替代这些零间隔。7.5.3.4 指派失效严重程度类对失效，确定出失效的严重等级。7.5.3.5 形成测试日志GB/T XXXXXXXXX9按照执行的测试用例，记录测试过程、测试结果、运行时间、失效时间、失效现象，形成测试日志。表9为测试日志的举例。表 9 测试日志举例事件 时间 到最近失效的时间间隔（分钟）开始测试 2010 年 1 月 1 日 8 时 00 分 0失效 1 2010 年 1 月 1 日 8 时 35 分 35失效 2 2010 年 1 月 1 日 9 时 10 分 35失效 3 2010 年 1 月 1 日
23、13 时 20 分 250失效 4 2010 年 1 月 1 日 15 时 30 分 130测试结束 2010 年 1 月 1 日 16 时 00 分 307.6 失效数据的分析评估7.6.1 可靠性增长测试可靠性增长测试，是通过发现失效，消除缺陷，再测试发现失效，消除缺陷的迭代过程，使嵌入式软件的可靠性达到预期的目标，从而终止可靠性测试。7.6.1.1 失效数据分析在进行失效数据分析时，必须明确以下问题：如果对某一失效，决定不查找和解决的，该失效不统计；重复的失效不统计；人为操作失误或外界环境异常引起的失效需要统计；硬件错误引起的失效不统计，但对于需要软件进行冗余、容错的除外；可靠性增长测试
24、过程，要根据失效数据，定期进行趋势分析和评估。可靠性增长测试过程中发现的所有缺陷都必须纠正，且纠正时应确保不引入新的缺陷。在测试过程中，应详细记录失效的时间、现象，以分析失效的根源和纠正缺陷。表10为可靠性增长测试过程中推荐的评估频率。表 10 可靠性增长测试过程的评估频率剩余测试长度 分析评估频率3 个月 每周一次对失效数据进行趋势分析，以指导可靠性模型的选择，进行失效强度估计。趋势分析采用定期评估FI/FIO比的方法。FI/FIO是可证明失效强度与失效强度目标的比， FI/FIO比 为：D.(5)FtNDnT)(GB/T XXXXXXXXX10式中：已经出现的失效数对应的继续接受边界的规范
25、化度量（公式9）；)(nTN测试结束时的自然或时间单元数；t失效强度目标。F在可靠性预测和趋势分析时，遵循以下方法：FI/FIO 比估计的精确度取决于样本规模（发生失效的数量）；当 FI/FIO 比大于 2 时，检查最近的 5 个值，查看是否出现稳定、相当明显的上升趋势，继续测试，如果不是，分析原因，做好软件的变更控制和测试控制；当规范化失效强度小于 0.5 时，结束测试；当 FI/FIO 比大于 15，在测试时间内不可能达到失效强度目标时，应推迟发布软件，商议调整失效强度目标，修改错误后再测试。在测试过程中，定期评估和预测可靠性，以指导下一步的测试工作，主要有：估计当前的可靠性，包括 MTT
26、F、当前失效率、当前失效强度等；预测现在达到的可靠性水平；预测还需要增加的测试，预测何时能够达到可靠性目标。根据分析结果，可适当调整测试资源，增加投入，使可靠性增长测试在预定时间内达到目标。7.6.1.2 失效强度估计根据对失效数据的趋势分析，选择可靠性模型，进行失效强度估计，可靠性模型选择参考附录B。由于可靠性模型较多，在可靠性模型的选择上本方法推荐两种作为参考，这两种模型为：基本（Musa）和对数泊松（MusaOkumoto）执行时间模型。基本和对数泊松执行时间模型，又称为指数和对数模型。这2种模型都使用执行时间，在嵌入式软件测试估计时，日历时间即为执行时间（这是基于嵌入式软件是连续运行的
27、的假设）。出现失效的函数的基本泊松模型的失效强度 为：(6)01式中：开始执行的初始失效强度；0给定时间点上的平均或预期发生的失效数；在无限时间内发生的失效总数。0出现失效的函数的对数泊松模型的失效强度 为：(7)exp0式中：开始执行的初始失效强度；0GB/T XXXXXXXXX11给定时间点上的平均或预期发生的失效数；失效强度延迟参数。对于这两种模型，需要在执行开始时，确定 、 、 ，应根据嵌入式软件自身的特征预测，0如软件的源代码长度、可执行代码的编译效率、软件的复杂度、对失效强度的要求等。也可以在嵌入式软件系统测试阶段，通过收集失效的数量进行估计。7.6.2 确认测试可靠性确认测试是为
28、验证在给定统计置信度下，对嵌入式软件当前的可靠性水平是否满足用户需要而进行的测试，即确定是否满足所规定的可靠性目标，本标准推荐采用无失效执行时间和可靠性示图的确认验证测试。7.6.2.1 无失效执行时间验证测试给定客户风险 和MTBF的检验下限 ，由下面的公式计算出嵌入式软件的可靠性测试时间T。根据T，按照测试案例执行测试，在T时间内无失效，接收软件，发生了失效，拒绝软件。.(8)ln式中：MTBF检验下限值；客户风险。这种验证测试适用于MTBF在一千小时以内的嵌入式软件可靠性验证测试，对于MTBF大于一千小时的嵌入式软件，应采用可靠性示图验证测试。7.6.2.2 可靠性示图验证测试根据客户风
29、险和开发风险级别构造可靠性示图，失效被绘制在图上，根据失效落入的区域，判定被测嵌入式软件被接收、拒绝或继续测试。首先与客户及提供商协商确定提供商风险 和客户风险 ，参照附录A的方法，画出可靠性示图。是提供商风险，即错误的认为失效强度目标没有达到但实际上已经达到的概率， 是客户风险， 即错误的认为失效强度目标已经达到，但实际上没有达到的概率。提供商风险 和客户风险 一般选取20%以下，最大不宜超过30%；对于可靠性要求很高的嵌入式软件，应在10%以内。画出可靠性示图时，需求出继续和接受边界、继续和拒绝边界，并画出边界线，边界线由下式求出：(9)1ln)(ATNGB/T XXXXXXXXX12式中
30、：发生失效时继续和接受边界的规范化度量。NT.(10)1ln)(BTN式中：发生失效时继续和拒绝边界的规范化度量；NT失效数； n分辨率，即最大可接受失效强度与失效强度目标的比值， 的取值范围1.12.0之间，可 靠性要求越高，取值应越小。A和B由下式计算得出：(11)1lnA(12)lB图1表示的可靠性示图为客户风险=0.1，提供商风险=0.1，分辨率=2。失效数 接 受继 续拒 绝图 1 经过规范化的度量（MTTF）可靠性示图的绘制方法和不同分辨率、风险的参数计算，参考附录A。根据失效数和失效发生的时间单元，计算出经过规范化的度量（MTTF），纵坐标为失效数，横坐标为计算出的规范化的度量，
31、标注在可靠性示图上。按照下面的方法进行判决：GB/T XXXXXXXXX13若该点落在继续区域，则继续测试；若落在拒绝区域，结束测试，拒绝软件；若落在接受区域，则结束测试，接受软件；若直到测试结束一直在继续区域，则计算 FI/FIO 比，FI/FIO 比大于 5 而且出现了失效，拒绝软件；FI/FIO 比小于 5 则接受软件。7.7 可靠性测试报告可靠性测试完毕，应给出一份可靠性评估报告，一般包括：测试环境、测试设备情况；可靠性目标及识别情况；操作剖面识别和构建情况；可靠性增长测试过程、时间，测试案例数量，测试覆盖率；可靠性验证测试过程、时间，测试案例数量，测试覆盖率；失效强度估计结果和分析；
32、可靠性模型拟合、拒绝或接受结论；测试中发现的问题和处理建议。评估报告的编制应符合GB/T 9386 -2008的要求。测试覆盖率等指标的计算宜采用GB/T 16260.14 -2006的方法，在进行可靠性增长测试时，可以按照该标准的计算方法，计算出相应的指标，加入到报告中。8 测试流程嵌入式软件测试流程划分为操作剖面构造、测试方案制定、测试准备、测试执行和测试评估五个阶段。8.1 操作剖面构造使用表格或图形方式构造嵌入式软件的操作剖面。测试人员在系统体系结构设计人员、软件工程师的参与下构造操作剖面。8.2 测试方案制定嵌入式软件可靠性测试方案制定包括：识别软件可靠性需求，触发对应的输入和数据域
33、，确定相关的概率分布，生成测试计划。按以下步骤进行测试案例的制定：识别输入及相关数据域，分析系统的可靠性需求，对所有可能的操作模式进行分类列表；分析影响软件操作模式的全部外界条件及其对软件运行的影响程度；对各种功能需求之间的相关性进行分析和组合，对于密切相关的功能模块进行合并，对于部分相关的功能模块给出相应的输入变量的组合方法。定义失效强度等级。识别是否存在出现危害度较大的 1 级和 2 级失效的可能性。若这种可能性存在，则应进行故障树分析，标识出所有可能造成严重失效的功能需求和其相关的输入域，进行严格的强化测试。对引起 3 级失效的功能可按其发生概率选择测试用例。4 级失效可不查找原因,可在
34、以后的版本中处理。按下面方法确定概率分布： 确定各种不同操作模式的发生概率，对不同的操作模式进行分别测试。 确定各种操作模式下各数据域的概率分布；或确定各数据域的概率分布。GB/T XXXXXXXXX14 确定需要强化测试的某些功能。整理概率分布的信息，将这些信息编码送入数据库。进行测试用例设计。编写测试计划。8.3 测试准备根据概率分布信息和测试计划生成对应的测试用例输入文件，计算或给出每一测试用例预期的输出结果，构建测试环境，选择或开发测试工具，生成测试用例时，一定要保证测试的覆盖率。8.4 测试执行本阶段进行软件可靠性测试。测试时注意以下方面：被测软件的测试环境（包括硬件配置和软件支撑环
35、境）应和预期的实际使用环境应完全一致。测试时按测试计划和顺序对每一个测试实例进行测试，判断软件输出是否符合预期结果。测试时应记录测试结果、运行时间和判断结果。如果软件失效，那么还应记录失效现象和时间，以供失效分析。8.5 测试评估进行失效分析，可靠性估计及判定。整理测试记录，并将结果写成报告。如果测试结果不满足给定的可靠性目标，应在完成纠正错误后组织实施回归测试。GB/T XXXXXXXXX15A A附 录 A（资料性附录）可靠性示图绘制在采用可靠性示图验证测试时，为了画出可靠性示图，需求出继续和接受边界、继续和拒绝边界，并画出边界线，推荐按下面的方法画出可靠性示图：n=0时的 ，与横轴的交点
36、：NT.(附 录 A.1)1)0(ATN.(附 录 A.2)(BNn=16时的 ，与横轴的交点：NT(附 录 A.3)1ln6)(ATN(附 录 A.4)l)6(BN=0时，与纵轴的交点：NT(附 录 A.5)ln)0(A(附 录 A.6)l)(B=16时，与纵轴的交点：NT.(附 录 A.7)ln)1(6)(AGB/T XXXXXXXXX16.(附 录 A.8)ln)1(6)(B为了使用的方便，本方法给出典型的参数如下：表 A.1 区域与边界的各个横轴和纵轴的交点值：分辨率 交点位置2 1.5 1.1n=0 点的横轴 -A，-B -2A,-2B -10A,-10Bn=16 点的横轴 -A+1
37、1.1,-B+11.1 -2A+13.0,-2B+13.0 -10A+15.2,-10B+15.2=0 点的纵NT轴1.44A,1.44B 2.47A,2.47B 10.5A,10.5B=16 点的纵轴(A+16)/0.693,(B+16)/0.693(A+8)/0.405, (B+8)/0.405(A+1.6)/0.0953, (B+1.6)/0.0953表 A.2 各种提供商风险和客户风险水平条件下的 A 和 B 值：客户风险提供商风险 参数0.1 0.005 0.01 0.001A -2.20 -2.89 -4.50 -6.800.1B 2.20 2.25 2.29 2.30A -2.2
38、5 -2.94 -4.55 -6.860.05B 2.89 2.94 2.99 2.99A -2.29 -2.99 -4.60 -6.900.01B 4.50 4.55 4.60 4.60A -2.30 -2.99 -4.60 -6.910.001B 6.80 6.86 6.90 6.91可以看出，A随客户风险迅速变化，但随提供商风险变化很小，它决定接受边界与横轴线在n0的交点，因此接受边界会随客户风险急剧变化，随提供商风险有很小的变化。B随提供商风险迅速变化，但随客户风险变化很小，它决定拒绝边界与纵轴线在 =0的交点，因NT此拒绝边界会随提供商风险急剧变化，随客户风险有很小的变化。在确认测试
39、时，可以根据需要，画出所需要的客户风险和提供商风险所有组合的可靠性示图，也可以只画出客户和提供商风险对称的可靠性示图，当二者不对称时使用足够近似的图。随着分辨率、客户风险水平或提供商风险水平的降低，继续区域会拓宽，因此，如果要降低在估计失效强度中所能够容忍的错误，或降低错误决策的风险，达到拒绝或接受区域需要更多的测试。GB/T XXXXXXXXX17GB/T XXXXXXXXX18B B附 录 B（资料性附录）可靠性模型选择根据对失效数据的趋势分析，选择可靠性模型，进行失效强度估计，表B.1给出了分析结果与可靠性模型选择的参考对照。表 B.1 根据趋势选择模型失效趋势 可靠性估计模型选择1 可靠性增长 J-M 模型、G-O 模型、M-O 模型等2 可靠性下降 选择允许失效强度上升的模型3 可靠性先降后升 Yamada、 Ohba、 Osaki S 模型4 可靠性稳定 HPP 模型、失效时间服从指数分布的模型GB/T XXXXXXXXX19参 考 文 献1软件可靠性工程 John D.Musa 著 韩柯 译 机械工业出版社2软件可靠性工程 孙志安 裴晓黎 宋昕 戴忠健 编著 北京航空航天大学出版社_
