1、ICS 35.080 L77 GB 中华人民共和国国家标准GB/T 28171-2011 嵌入式软件可靠性测试方法Embedded software reliability testing method 2011-12-30发布2012-06-01实施数码防伪/ 中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会发布G/T 28171-2011 目次EWHI-2222234679uuumm 例头计设析分制择例绘选用图型试示模测性性性估靠靠靠评可可可析告的面uu分报)件标剖uu的式录录录目作备试据则附附附用义HHHHH性操准测数性性性性引定的境容法则靠发试行效靠料料料性和目环内方总可
2、开测执失可喷喷喷眈围范语试试试试言言范规术测测测测川口川MMM川刺刺扛较前引1234567附附附参I GB/T 28171-20门前言本标准按照GB/T1. 1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口。本标准起草单位:中国电子技术标准化研究所、珠海南方软件产品检测中心、珠海许继电气有限公司、炬力集成电路设计有限公司、上海博为峰软件技术有限公司、沈阳软件公共技术服务平台有限公司、深圳市吉阳自动化科技有限公司、上海博泰悦臻电子设备制造有限公司、广东宝莱特医用科技股份有限
3、公司、上海嵌入式系统应用工程技术研究中心、珠海优特电力科技股份有限公司、上海超算并行软件有限责任公司、上海鲁齐信息科技有限公司。本标准主要起草人:侯建华、陈勇、秦卫东、杨丽春、王兴念、潘海洋、王忠福、张展新、徐锋光、阳如坤、应臻皑、张场肠、史旭光。阳山G/T 28171-2011 sl 嵌入式系统是指以应用为中心，以计算机技术为基础，软硬件可剪裁，适应应用系统对功能、可靠性、成本、体积和功耗严格要求的专门计算机系统。嵌入式技术并不是一个独立的学科，它是伴随着微电子技术和计算机技术的发展，微控制芯片功能越来越强大，而嵌入微控制芯片的设备和系统越来越多而发展起来的。嵌入式系统几乎包括了生活中所有的
4、电器设备，如:MP3、手机、数字电视机、汽车、微波炉、数字相机、电梯、空调、自动售货机、工业自动化仪表与医疗仪器等。虽然大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但嵌入式软件可靠性测试与通用软件可靠性测试有着较大差别，这是由于嵌入式系统软硬件功能界限模糊，软件对硬件的依赖性和专用性较强，对实时性、安全性要求较高，目前针对嵌入式软件的测试和调试工具较少等。这些都使得嵌入式软件的测试相比通用计算机软件测试可继承性较差。本标准参考了国内外相关资料，结合嵌入式软件可靠性测试的实践和特点而制定。四G/T 28171-2011 嵌入式软件可靠性测试方法1 范围本标准规定了嵌入式软件生存周期
5、内软件产品的可靠性测试方法、过程和准则。本标准适用于嵌入式软件生存周期全过程，可用于嵌入式软件测试中的可靠性增长测试和可靠性确认测试要求。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB/T 9386-2008 计算机软件测试文档编制规范GB/T 11457-2006信息技术软件工程术语GB/T 15532-2008 计算机软件测试规范GB/T 16260.2-2006软件工程产品质量第2部分:外部度量GB/T 16260.3-2006软件工程产品质量第3部分:内部
6、度量3 术语和定义3. 1 3.2 3.3 3.4 3.5 3.6 GB/T 11457-2006界定的以及下列术语和定义适用于本文件。软件可靠性software reliability 特定数目的自然单元中或特定任务时间内软件元失效执行的概率。偏离deviation 嵌入式软件执行中的系统行为相对预期行为的偏差。级联cascaded 直接由初始行为产生的行为。例如，级联偏离、级联失效、级联偏差。失效failure 系统运行行为对用户要求的偏离。失效强度failure intensity 单位时间出现的失效次数。注:是表示可靠性的另一种方式。操作operation 持续一段时间，结束时将控制权
7、还给系统的一种逻辑任务。操作与软件的功能或特征相关，例如，GB/T 28171-2011 用户命令的执行、对输入的响应处理、系统事务处理。3. 7 3.8 操作剖面operalional profile 操作及其出现的概率的集合。操作模式operalional mode 随时间或资源与输入的不同而有较大差别的操作的集合。4 测试目的嵌入式软件可靠性测试的目的是:一一通过嵌入式软件可靠性测试有效地发现程序中影响软件可靠性的缺陷，实现可靠性增长;一一验证嵌人式软件是否满足嵌入式系统开发合同或项目开发计划、系统与子系统设计文档、软件需求规格说明和软件设计说明所规定的软件可靠性要求、可靠性的定量要求;
8、评估当前嵌入式软件可靠性的水平，预测未来可能达到的水平，从而为嵌入式软件开发管理提供决策依据;一一通过嵌入式软件可靠性测试，为用户平衡可靠性、时间开发和开发费用提供参考。5 测试环境嵌入式软件可靠性测试的测试环境如下z一一具备嵌入式软件运行的目标环境，或高度一致(除位置、结构、接口等部分外其他环境与目标环境一致)的仿真环境;一一-具备与嵌入式系统应用验证相关的必要的测试仪器仪表，例如，频率源、波形发生器、标准电压电流源、规约分析器等;具备嵌人式系统运行的温度、湿度、电磁兼容、振动、冲击等环境;具备一些专用的测试工具;一一具备操作剖面所需要的全部外部输入输出的环境支持。6 测试内容嵌入式软件可靠
9、性测试的内容主要包括:可靠性增长测试和可靠性确认测试。可靠性增长测试以迭代的方式进行，根据测试过程中检出和眼踪的失效，使用基于可靠性增长模型和统计推理的可靠性评估方法，进行失效强度的估计，然后消除缺陷再测试，使可靠性达到目标要求从而结束测试。可靠性确认测试是产品发布或交付前为确定合同约定或者具体标准规定的可靠性指标得到满足而组织实施的测试。7 测试方法7.1 总则GB/T 15532-2008中确定的系统测试方法适用于本标准，一般采用黑盒测试技术进行嵌入式软2 G/T 28171-2011 件可靠性测试项目的测试。进行嵌入式软件可靠性测试，首先明确可靠性目标。没有规定可靠性目标时，应按照7.2
10、中的方法进行可靠性目标的确定。可靠性目标确定后，编制测试计划、开发操作剖面、进行测试准备、执行可靠性测试、分析评估，最后给出可靠性测试报告。7.2 可靠性目标的确定7.2. 1 确定失效程度对一个嵌入式软件，根据产品的使用范围、对象，确定失效的严重程度。一般根据对人员生命、成本和系统能力的影响来区分失效的严重程度;失效严重程度级别用于对失效数据的分析，在测试过程中判定是否需要查找缺陷和解决。表1给出失效程度的级别。表1嵌入式软件失效的程度级别失效程度级别对失效的描述1 不能进行一项或多项关键操作2 不能进行一项或多项重要操作3 不能进行一项或多项操作，但是有补救办法4 一项或多项操作中的小缺陷
11、7.2.2 为嵌入式软件建立失效强度目标根据嵌入式系统的使用对象，为嵌入式软件建立失效强度目标，表2为推荐的失效强度目标、失效间隔时间和失效影响的对照表。表2失效强度目标、失效间隔时间与失效影响失效造成的影响典型失效强度目标失效间隔时间造成人员伤亡或千万元以上经济损失10-6 114a 没有人身伤害，10万元以上经济损失10- 10 000 h 没有人身伤害，万元以上经济损失10-3 1 000 h 没有人身伤害，千元以上经济损失10-2 100 h 没有人身伤害，少量经济损失10-1 10 h 没有人身伤害，轻微或元经济损失1 1 h 7.2.3 选择通用度量由于嵌入式系统一般是连续运行的，
12、因此嵌入式软件在时间度量上，普通时间和执行时间是一致的，所以，选择普通时间作为通用度量，本测试方法采用小时Ch)作为时间单位。当然也可以采用自然单元作为通用度量。表3为1h任务时间的可靠性与特定周期等效失效强度的对照表。3 GB/T 28171-2011 表31 h任务时间的可靠性与特定周期等效失效强度的对照1 h任务时间的可靠性特定周期失效强度0.368 每1h 1次失效0.9 每1000 h 105次失效0.959 每天1次失效0.99 每1000 h 10次失效0.994 每周1次失效0.998 6 每月1次失效0.999 每1000 h 1次失效0.999 89 每年1次失效失效强度和
13、可靠性转换见式(1)和式(2): A一lnR二-t 、，/、BJ1iqu r，、，、. . . . . . . . . . . . . . . . . . . . . R = exp(- t) 式中:一一失效强度;R 可靠性;t 自然或时间单位数。7.3 开发操作剖面7.3. 1 综述使用表格或图形方式构造嵌入式软件的操作剖面。测试人员在系统体系结构设计人员、软件工程师的参与下构造操作剖面。开发操作剖面时，确定输入及相关数据域，分析系统的可靠性语求，对所有可能的操作模式进行分类列表;分析影响软件操作模式的全部外界条件及其对软件运行的影响程度;对各种功能需求之间的相关性进行分析和组合，对于密切相
14、关的功能模块进行合并，对于部分相关的功能模块给出相应的输入变量的组合方法。7.3.2 确定操作模式对于不同的嵌入式软件，操作模式会显著不同，确定操作模式宜按表4的方法进行。表4操作模式的确定确定操作模式确定方法主要时间和次要时间某天或一天的某段时间，处理的事务或事务频度显著不同，处理事务量的显著差别不同的用户类型管理员、一般使用者、新手等输入的显著差别大量和多变的输入电源的极限电源方面的要求4 GB/T 28171-2011 表4(续)确定操作模式确定方法温度的极限温度方面的要求电磁的极限电磁兼容方面要求其他环境的重大变化湿度、振动、噪声等方面的要求行业规范要求的模式电信、电力、银行等行业的要
15、求7.3.3 确定操作的发起者操作的发起者包括用户、外部条件、嵌入式系统自身等，宜按表5的确定方法进行识别。表5操作发起者的确定确定发起者确定方法使用用户使用者操作、远程登录等外部条件外部输入，例如输入一个盐、收到输入信号嵌入式系统自身嵌入式系统软硬件判断出的条件，例如内存异常、中断信号、内部变量7.3.4 选择表示方法操作剖面的表示方法有表格法和图示法。可根据使用习惯来选择。本标准推荐采用表格方法，即用列表的方式，列出所有操作模式、操作发起者、操作、操作出现率等信息。7.3.5 创建操作表创建操作表需要参考用户需求、软件使用说明、行业规定及相关标准要求等，通常以操作的启动者来划分。在定义输入
16、空间、操作覆盖输入空间时，应考虑全覆盖。表6举例说明如何创建一个操作表。表6操作表确定发起者操作输出个信号到外部1A(外部输入一个信号)输出一个信号到外部2B(使用者输入个指令)显不行信息提不数据满C(内部数据存储满)系统信号灯亮一7.3.6 确定出现率根据用户需求、软件规格、使用说明、经验等信息，确定每种操作的出现率。表7举例说明如何确定出现率。5 G/T 28171-2011 表7出现率操作出现率(每小时出现次数)输出一个信号到外部110 输出一个信号到外部210 显示一行信息1000 提示数据满0.001 系统信号灯亮0.001 合计1 020.002 7.3.7 确定出现概率将每个操作
17、的出现率除以总出现率。表8举例说明如何确定出现概率。表8出现概率操作出现概率输出一个信号到外部10.009 8 输出一个信号到外部20.009 8 显示一行信息0.980 4 提示数据满0.000 000 98 系统信号灯亮0.000 000 98 合计1 7.4 测试准备7.4. 1 综述本活动主要根据概率分布信息和测试计划生成对应的测试用例输入文件，计算或给出每一测试用例预期的输出结果，构建测试环境，选择或开发测试工具，进行测试用例设计;生成测试用例时，一定要保证测试的覆盖率。确定输入及相关数据域，分析系统的可靠性需求，对所有可能的操作模式进行分类列表;分析影响软件操作模式的全部外界条件及
18、其对软件运行的影响程度;对各种功能需求之间的相关性进行分析和组合，对于密切相关的功能模块进行合并，对于部分相关的功能模块给出相应的输入变量的组合方法。附录C列举了一些嵌入式软件可靠性测试用例的实例，可作为测试用例设计参考。7.4.2 测试用例准备6 测试用例准备活动主要包括:一一估计当前版本所需的新测试用例的数量;一一在要测试的系统之间分配新测试用例的数量;一一在每个系统的新操作之间分配新测试用例的数量;指定新测试用例;GB/T 28171-2011 一一一开发新增测试用例，将新测试用例添加到以前版本的测试用例上;一新开发的软件的第一版可靠性测试用例基于前阶段的测试用例来设计。7.4.2. 1
19、 估计需要测试用例的数量估计需要测试用例的数量，要考虑时间和成本因素，取这两个数量的最小值作为计划准备的测试用例的数量。时间的计算，用可用的时间乘以可用的人员数，再除以准备一个测试用例的平均时间。戚本的计算，用建立测试用例的预算除以每个测试用例的平均准备成本。对于再次测试，例如回归测试，只计算新增加的测试用例数量。7.4.2.2 分配测试用例为每个操作分配测试用例数量。对于回归测试，只分配新修改的操作的测试用例。根据操作出现率，进行下列工作:一一确定很少出现的关键操作(概率小但应测到)，为每个这样的操作分配测试用倒数量。关键操作是指失效会造成人身伤害、重大损失的操作，对这些操作要分配充足的测试
20、用例。确定偶发性的操作，分配一个测试用例，偶发性的操作是指出现概率非常低的操作，这样做的目的是保证至少为这样的操作分配一个测试用例。一一根据操作概率，把剩下的测试用例分配给剩余的其他操作。7.4.2.3 指定测试用例为每个操作指定测试用例。从操作的直接输入变量的值域中，找出具有相似失效行为的值域，形成输入变量值域组合。在选择了输入变量值域组合之后，从组成值域的集合成员中，随机选择输入变量，作为测试用例。选择了测试用例后，编制测试用例的脚本。7.4.3 测试过程准备为每个操作模式准备一个测试过程，指定或调整测试操作剖面和操作出现率，调整主要发生在回归测试或需求变更的测试过程。7.5 执行测试7.
21、5.1 综述在执行可靠性测试时注意以下方面:-被测软件的测试环境(包括硬件配置和软件支持环境)和预期的实际使用环境应完全致。测试时按测试计划和顺序对每一个测试用例进行测试，判断软件输出是否符合预期结果。一一测试时应记录测试结果、运行时间和判断结果。如果软件失效，那么还应记录失效现象和时间，以供失效分析。7.5.2 分配测试时间分配测试时间宜按照以下方法进行:一一一在要测试的系统之间分配测试时间;一一对进行可靠性增长测试的功能测试、回归测试、负载测试之间分配测试时间;要分配足够的时间进行功能测试，以便充分执行测试用例，并对前一版本进行回归测试，然后把剩下的时间分7 GB/T 28171-2011
22、 配给负载测试;一一对进行负载测试的操作模式之间分配测试时间;一一进行确认测试，将所有的时间都分配给负载测试;一一时间分配以小时计。估计测试需要的时间接式(3):N-F T一一一( 3 ) 式中zt 一一用自然或时钟时间单元表示的测试时间;TN 规范化度量(MTTF数)，见式(4);F一一失效强度目标。ln TN=. _ l一一川l-y. ( 4 ) 式中zy一一分辨率;一一提供商风险，即错误地认为失效强度目标没有达到但实际上已经达到的概率;卢一客户风险，即错误地认为失效强度日标已经达到，但实际上没有达到的概率。7.5.3 调用测试对于可靠性增长测试，首先执行功能测试，然后进行负载测试，按照测
23、试用例进行全覆盖测试。在每次对软件做了较大修改后，要进行回归测试。功能测试按照分配的测试用例，顺序调用测试用例进行测试。回归测试应全面检查需求变化处。另外随机测试和回归测试的要求不同，需要注意区分，按影响域调用相关测试用例。7.5.4 标识出现的失效在测试中应对测试的输出进行分析，确定失效、失效时间和失效强度。7.5.4. 1 分析测试输出的偏离采用自动化工具或以人工对测试结果审查，确定执行结果与相对预期行为的偏差。在分析偏差的过程中，不计算级联。7.5.4.2 确定哪些偏离是失效确定出现的偏离是否为失效。硬件错误引起的失效不作为嵌入式软件的失效统计，但对于需要实现软件容错、避免严重错误的失效
24、，应统计在内。7.5.4.3 估计失效发生的时间估计失效发生的时间采用统一的时间度量，即普通时间，以小时为单位。以出现顺序，累加度量单元，包括所有操作模式的功能测试、回归测试、负载测试。对于同时出现的多个失效记录，会导致多个零失效间隔，应在记录的时间间隔内，估计随机的时间，用于替代这些零间隔。7.5.4.4 指派失效严重程度类对失效，确定出失效的严重等级。8 GB/T 28171-20门7.5.4.5 形成测试记录按照执行的测试用例，记录测试过程、测试结果、运行时间、失效时间、失效现象，形成测试记录。表9为测试记录的示例。表9测试记录示例事件时间失效的时间间隔/min开始测试2010年1月1日
25、8时00分。失效12010年1月1日8时35分35 失效22010年1月1日9时10分35 失效32010年1月1日13时20分250 失效42010年1月1日15时30分130 测试结束2010年1月1日16时00分30 7.6 失效数据的分析评估7.6.1 综述本活动进行失效分析、可靠性估计及判定;整理测试记录，并将结果写入测试报告。测试结果不满足给定的可靠性目标时，应在完成纠正错误后组织实施回归测试。7.6.2 可靠性增长测试7.6.2. 1 失效数据分析在进行失效数据分析时，必须明确以下问题:对某一失效，决定不查找和解决的，该失效不统计;-一重复的失效不统计;一一人为操作失误或外界环境
26、异常引起的失效需要统计;一一硬件错误引起的失效不统计，但由于软件没有进行冗余、容错的失效应统计。可靠性增长测试过程，要根据失效数据定期进行趋势分析和评估。可靠性增长测试过程中发现的所有缺陷都应纠正，且纠正时应确保不引人新的缺陷。在测试过程中，应详细记录失效的时间、现象，以分析失效的根源和纠正缺陷。表10为可靠性增长测试过程中推荐的评估频率。表10可靠性增长测试过程的评估频率剩余测试长度分析评估频率3个月每周一次对失效数据进行趋势分析，以指导可靠性模型的选择、失效强度估计。趋势分析采用定期评估FI/FIO比的方法。9 G/T 28171-2011 FI/FIO是可证明失效强度与失效强度目标之比，
27、FI/FIO比D为zn _ T N A (n) 一一-U t, F 式中zT N.A (n) 已经出现的失效数对应的继续和接受边界的规范化度量(见式(9);t, 一一测试结束时的时间单位数;F 失效强度目标。在可靠性预测和趋势分析时，遵循以下方法:一-FI/FIO比估计的精确度取决于样本规模(发生失效的数量h( 5 ) 一一当FI/FIO比大于2时，检查最近的5个值，查看是否出现稳定、相当明显的上升趋势，如果是，继续测试;不是时，分析原因，做好软件的变更控制和测试控制;一一当规范化失效强度小于0.5时，结束测试;一一当FI/FIO比大于15，在测试时间内不可能达到失效强度目标时，应推迟发布软件
28、，商议调整失效强度目标，修改错误后再测试。在测试过程中，定期评估和预测可靠性，以指导下一步的测试工作，主要有:一一估计当前的可靠性，包括MTTF、当前失效率、当前失效强度等;一预测现在达到的可靠性水平;预测还需要增加的测试，预测何时能够达到可靠性目标。根据分析结果，可适当调整测试资源，增加投入，使可靠性增长测试在预定时间内达到目标。7.6.2.2 失效强度估计根据对失效数据的趋势分析，选择可靠性模型，估计失效强度b可靠性模型选择可参见附录B。由于可靠性模型较多，在可靠性模型的选择上本方法推荐两种作为参考，这两种模型为:基本(Musa)和对数泊松(Musa-Okumoto)执行时间模型。基本和对
29、数泊松执行时间模型，又分别称为指数和对数模型。这两种模型都使用执行时间，在嵌入式软件测试估计时，日历时间即为执行时间(这是基于嵌入式软件是连续运行的假设出现失效的函数的基本泊松模型的失效强度A为:()=。(1-) 式中:。一一开始执行的初始失效强度; 给定时间点上的平均或预期发生的失效数;。一一在元限时间内发生的失效总数。出现失效的函数的对数泊松模型的失效强度为:() =oexp(中)式中:。一一开始执行的初始失效强度;一一给定时间点上的平均或预期发生的失效数;。一一失效强度延迟参数。( 6 ) . ( 7 ) 对于这两种模型，需要在执行开始时，确定A。、o，rJ，应根据嵌入式软件自身的特征预
30、测，如软件的源代码长度、可执行代码的编译效率、软件的复杂度、对失效强度的要求等;也可以在嵌入式软件系统测试阶段，通过收集失效的数量进行估计。10 GB/T 28171-20门7.6.3 可靠性确认测试7.6.3.1 综述可靠性确认测试是为确认在给定统计置信度下，对嵌入式软件当前的可靠性水平是否满足用户需要而进行的测试，即确认是否满足所规定的可靠性目标，本标准推荐采用失效执行时间和可靠性示图来进行确认测试。7.6.3.2 失效执行时间确认测试给定客户风险卢和MTBF的检验下限。，由式(8)计算出嵌入式软件的可靠性测试时间T。根据T，按照测试用例执行测试，在T时间内元失效时接受软件，发生失效时拒绝
31、软件。式中zO一-MTBF检验下限值zF一客户风险。T=-ln . ( 8 ) 这种确认测试适用于MTBF在1000 h以内的嵌入式软件可靠性确认测试，对于MTBF大于1 000 h的嵌入式软件，应采用可靠性示图确认测试。7.6.3.3 可靠性示图确认测试根据客户风险和开发风险级别构造可靠性示图，失效被绘制在图上，根据失效落人的区域，判定被测嵌入式软件被接受、拒绝还是继续测试。首先与客户及提供商协商确定提供商风险和客户风险卢，参照附录A的方法，画出可靠性示图。提供商风险和客户风险卢一般选取20%以下，最大不宜超过30%;对于可靠性要求很高的嵌入式软件应在10%以内。绘制可靠性示图时，需计算出继
32、续和接受边界、继续和拒绝边界，并绘出边界线。边界线由式(9)和式(10)求出:式中=A - nlnY TNA()=一一一一一川，_ 1 - Y TNA一已经出现的失效数对应的继续和接受边界的规范化度量zn 失效数;A 一一-由式(11)计算得出; ( 9 ) Y 一分辨率，即最大可接受失效强度与失效强度目标的比值，的取值范围1.1 2. 0之间。可靠性要求越高，取值庇越小。式中:B-nln TN.R(n)=一-一-一一川.D,._ 1一T N B 已经出现的失效数对应的继续和拒绝边界的规范化度量;n 一一失效数;B -由式(12)计算得出;. ( 10 ) Y 一一分辨率，即最大可接受失效强度
33、与失效强度目标的比值，的取值范围1.12. 0之间。可靠性要求越高，取值应越小。A=ln 1- . ( 11 ) 11 GB/T 28171-2011 B =ln I二2 图1表示的可靠性示图中客户风险卢=0.1，提供商风险=0.1，分辨率Y=2016 毒草罢1412 10 8 6 4 2 2 4 6 8 10 12 14 16 计算出的规范化的度量图1经过规范化度量(MTTF)可靠性示图的绘制方法和不同分辨率、风险的参数计算，参见附录A。( 12 ) 根据失效数和失效发生的时间单元，计算出经过规范化的度量(MTTF)。纵坐标为失效数，横坐标为计算出的规范化的度量，标注在可靠性示图上。按照下面
34、的方法进行判决:一一该点落在继续区域时，继续测试;一一落在拒绝区域时，结束测试，拒绝软件;一一落在接受区域时，结束测试，接受软件;-一直到测试结束一直在继续区域时，计算FI/FIO比，FI/FIO比大于5而且出现了失效时，拒绝软件;FI/FIO比小于5时则接受软件。7.7 可靠性测试报告可靠性测试完毕，应给出一份可靠性测试报告，一般包括:测试环境、测试设备情况;一一一可靠性目标及确定情况;一一一操作剖面确定和构建情况;一可靠性增长测试过程、时间，测试用例数量，测试覆盖率;可靠性确认测试过程、时间，测试用例数量，测试覆盖率;一一失效强度估计结果和分析;可靠性模型拟合、拒绝或接受结论;一一测试中发
35、现的问题和处理建议;一被测软件的版本信息。测试报告的编制应符合GB/T9386-2008的要求。测试覆盖率等指标的计算宜采用GB/T16260.2-2006和16260.3-2006的方法度量，在进行可靠性增长测试时，可以按照该标准的计算方法，计算出相应的指标，并加入到报告中。12 GB/T 28171-2011 附录A(资料性附录)可靠性示图绘制在采用可靠性示图确认测试时，为了绘出可靠性示图，需求出继续和接受边界、继续和拒绝边界，并绘出边界线，推荐按下面的方法绘出可靠性示图。n=O时的TN，与横轴的交点:一-vA二B二-咆EA-唱EA-一一nunU AARU NN TT .( A. 1 )
36、.( A.2 ) n=16时的TN，与横轴的交点:一一n-n一-yd-y l一-1二一一1二lA-B一一一一一、E/、/Fhuphu 唱i唱i，、，、AB NN TT .( A.3 ) .( A.4 ) TN=O时，与纵轴的交点:nA(O)=iL lnY nB(O)= ,B_ lnY ( A.5 ) .( A.6 ) TN=16时，与纵轴的交点:A-16(1- y) nA (16) = lnY B -16(1- y) 71E(16)=，一InT 为了使用的方便，给出典型的参数，见表A.1和表A.2o表A.l区域与边界的各个横轴和纵轴的交点值.( A.7 ) .( A.8 ) 分辨率Y交点位置2
37、 1. 5 1. 1 n=O点的横轴-A,-B -2A,-2B -10A, 10B n=16点的横轴-A十l1.l，-B+ll.1一2A十13.0，一2B+13.。一10A十15.2，一10B+15.2TN=O点的纵轴1. 44A , 1. 44B 2. 47A ,2. 47B 10. 5A ,10. 5B TN=16点的纵轴(A+16)/0.693 , (A十8)/0.405，(A+1.的/0.0953 , (B+ 16) /0. 693 (B+8) /0.405 (B十1.6) /0.095 3 表A.2各种提供商风险和窑户风险水平条件下的A值和B值客户风险提供商风险参数O. 1 0.05
38、 0.01 0.001 A 一2.202.89 4.50 -6.80 O. 1 B 2.20 2.25 2.29 2. 30 13 GB/T 28171-2011 表A.2(续)客户风险提供商风险参数0.1 0.05 0.01 0.001 A 2.25 一2.94-4.55 -6.86 0.05 B 2.89 2.94 2.99 2.99 A 一2.29一2.99-4.60 -6.90 0.01 B 4.50 4.55 4.60 4.60 A 一2.30-2.99 -4.60 一6.910.001 B 6.80 6.86 6. 90 6.91 可以看出，A随客户风险迅速变化，但随提供商风险变化
39、很小，它决定接受边界与横轴线在n=O的交点，因此接受边界会随客户风险急剧变化，随提供商风险有很小的变化。B随提供商风险迅速变化，但随客户风险变化很小，它决定拒绝边界与纵轴线在TN=O的交点，因此拒绝边界会随提供商风险急剧变化，随客户风险有很小的变化。在确认测试时，可以根据需要，画出所需要的客户风险和提供商风险所有组合的可靠性示图，也可以只画出客户和提供商风险对称的可靠性示图。当二者不对称时使用足够近似的图。随着分辨率、客户风险水平或提供商风险水平的降低，继续区域会拓宽，因此如果要降低在估计失效强度中所能够容忍的错误，或降低错误决策的风险，达到拒绝或接受区域则需要更多的测试。14 附录B(资料性
40、附录)可靠性模型选择GB/T 28171-2011 根据对失效数据的趋势分析，选择可靠性模型，估计失效强度。表B.l给出了分析结果与可靠性模型选择的参考对照。表B.1根据趋势选择模型编号失效趋势可靠性估计模型选择1 可靠性增长J-M模型、G-O模型、M-O模型等2 可靠性下降选择允许失效强度上升的模型3 可靠性先降后升Yamada、Ohba、OsakiS模型4 可靠性稳定HPP模型、失效时间服从指数分布的模型15 GB/T 28171-2011 附录C(资料性附录)可靠性测试用例分析设计实例C.1 故障注入测试故障注入测试是针对嵌入式系统的可靠性测试的常用手段。故障注人测试项目的测试顺序应综合
41、考虑该故障出现的概率和测试项目之间的互补关系。故障注人测试分为如下几步:a) 故障注人。在这一步把缺陆、故障和失效插入到代码中去，这时候要确定插入的位置，可能还要添加适当的代码。b) 执行测试。要用输入必要的数据、产生内部的或外部的事件、发送特定的消息等方法把前面插入的故障激活。c) 测试结果收集。包括收集测试前设置的观察点处观察到的数据、现象等，另外还要收集被测系统出现的各种异常现象，如死机、复位。d) 测试结果评估。即根据测试过程中收集到的各种测试数据，结合用户的实际使用需求和设计需求，判断当前出现的各种现象是否属于正常。在实际操作中，可以采用下面的两条准则来判断是否需要启动修改流程:1)
42、 故障注入后引起用户不可接受的严重故障;2) 故障停止插入后系统无法恢复，仍然处于故障状态。针对嵌入式软件可靠性测试的故障注入方法，本附录列举了常用的插入测试项目，通过这些项目可构造大量的可靠性测试用例。C.2 内存过载测试当一个计算机系统的内存占用率为80%100%时，视为内存过载。内存过载测试主要是测试系统在内存即将用完的时候，系统运行的可靠性。故障产生原因有大流量冲击、内存丢失、算法缺陷等。故障可能产生的后果如复位、空转、系统内部数据状态不一致等。对于一般系统，内存过载时能自动降低业务处理量，如果持续时间过长，则允许单板复位。对于高可用系统，要求能区分是大流量冲击还是内存丢失造成的内存过
43、载。如果是大流量冲击造成的过载，应能自动降低业务处理量;如果是内存丢失造成的过载，应能复位单板，但对业务不造成影响。采用内存丢失的办法实现内存过载的测试步骤:a) 丢失空闲内存，使内存占用率达到80%，运行一段时间，观察系统的运行状态;b) 在前面的基础上再丢失10%的内存，运行一段时间，观察系统的运行状态;c) 把剩余的所有内存全部申请出来丢掉，观察系统的运行情况。C.3 CPU过载测试当一个计算机系统的CPU占用率达到80%100%时，称为CPU过载。CPU过载测试主要是测试系统在高CPU占用率状态下系统的可靠性。故障产生原因有大流量冲击、算法效率低下、CPU锁死等;故障可能产生的后果有:
44、对实时事件响16 GB/T 28171-20门应不及时、影响提供业务的能力等。通过创建一个任务，用循环的方式强制消耗掉一部分CPU资源，循环次数可以动态调整，以调整CPU占用率来模拟故障产生。CPU过载时应能自动启动流控，降低业务流量，同时，系统运行的各种业务不应出错，输入输出的各类消息顺序保持不变。测试步骤za) 创建一个最高优先级的CPU过载测试任务，调整循环次数，使CPU过载，观察系统的运行情况pb) 降低过载测试任务的优先级，使原来优先级较高的任务可以正常运行，优先级较低的任务受到影响，运行一段时间，观察系统的运行情况;c) 重复步骤b)，使各优先级的任务均受到过载干扰。C.4 队列过
45、载测试对于有限长度队列，队列的长度达到最大长度的80%100%时，称为有限长度的队列过载。对于元限长度队列，队列长度远远大于正常运行时队列长度时，例如10倍，称为无限长度的队列过载。队列过载测试主要是为了测试队列缓冲造成的延时对系统的影响，对于有限长度队列，还可以验证队列满的情况下程序运行的情况。故障产生原因有大流量冲击、处理队列的任务受到阻塞、发生了死锁等;故障可能产生的后果有:系统响应超时、系统内部各模块之间数据状态不一致等。在测试中可以采用挂起处理队列的任务的办法实现队列过载。队列过载不应造成系统的业务运行出错，造成的延时也应在可以接受的程度，对于有限长度队列，能正确处理队列溢出的情况，
46、不会产生内存越界或其他错误。测试步骤:a) 运行程序，输入各种必要的数据，使被测队列有一个持续的进队列操作。b) 挂起处理队列的任务。对于有限长度队列，使队列长度达到80%时解挂该任务，恢复运行;对于无限长度队列，使队列长度达到正常队列长度的8倍，然后解挂该任务，观察系统的运行情况。c) 过一段时间后，再次挂起该任务。对于有限长度队列，使队列长度达到最大长度，此时继续进行人队列的操作，观察系统的运行状态z对于无限长度的队列，使队列长度达到正常长度的10倍。然后解挂该任务，运行一段时间，观察这一过程中系统的运行情况。C.5 资源丢失测试资源丢失是指资源没有正在被使用，也不在对应的资源管理程序中，
47、即该资源已经不受控了。资源丢失测试的目的是验证在发生资源丢失故障时软件是否能从故障中恢复过来，在故障恢复过程中是否还引入了其他的故障。故障产生原因有重人、申请出来的资源使用后没有释放、在某些路径下资源没有释放等;故障可能产生的后果如复位、输出错误、软件内部状态错误、业务无法完成或业务性能降低等。采用把资源申请出来后不释放的方法来模拟故障产生。对于一般系统，要求在资源耗尽以后能复位，这时要注意耗尽型资源和非耗尽型资源的差异，复位条件的检测要特殊设计;对于高可用系统，要求能恢复资源丢失造成的影响，并且不影响业务的正常运作。17 GB/T 28171-2011 测试步骤za) 申请一个资源;b) 经
48、过一段时间后，检查软件是否能发现出现资源丢失，观察软件是否采取了什么恢复措施，该措施是否有效30 重复申请一批资源但不释放，过一段时间后，检查软件是否能发现出现资源丢失故障，故障软件是否采取了相应的措施，以及该措施是否有效。C.6 释放错误资源测试释放错误资源测试就是把伪造的非法资源通过资源释放函数试图加入到空闲资源池的测试过程。释放错误资源测试的目的是为了验证资源管理程序是否对非法资源有合理的保护措施。故障产生原因有资源在使用过程中修改了资源的标记属性，如地址指针、ID号等;故障可能产生的后果有z资源管理程序遭到破坏、资源丢失、业务中断等。采用伪造一个非法的资源并用资源释放函数释放该非法资源
49、，例如对于内存，可以先申请出一块内存，然后把地址加1再释放，来模拟故障。测试过程中，返回了出错信息，资源管理程序内部应没有真正增加这些非法的资源。测试步骤za) 伪造非法资源;b) 用资源释放函数释放这些非法资源;c) 观察资源管理程序是否返回出错，检查资源管理程序的内部数据看是否把非法的资源加进去了。C.7 重复释放资源测试重复释放资源是指同一个资源被释放两次或两次以上。重复释放资源测试的目的是为了验证资源管理程序是否具有处理资源重复释放故障的能力。故障产生原因一般是编程错误。故障可能产生的后果有:资源管理程序内部存在多个同一资源、软件提供的业务出现错误等。采用修改代码，把申请成功的资源释放2次来模拟故障。测试过程中，第2次或以后
