国家标准 GB/T28171一2011 嵌入式软件可靠性测试方法 Embeddedsotwarereliabilitytestingmethodi 2011-12-30发布 2012-06-01实施国家质量监督检验检疫总局发布国家标准化管理委员会国家标准
GB/T28171一2011 目次前言引言范围规范性引用文件术语和定义测试目的测试环境测试内容测试方法总则 7.l 7.2可靠性目标的确定 7.3开发操作剖面 7.4测试准备 7.5执行测试 7.6失效数据的分析评估 7.7可靠性测试报告附录A(资料性附录)可靠性示图绘制附录B(资料性附录可靠性模型选择 15 附录c资料性附录可靠性测试用例分析设计实例 16 参考文献 2
GB/T28171一2011 前言本标准按照GB/T1.1一2009给出的规则起草请注意本文件的某些内容可能涉及专利本文件的发布机构不承担识别这些专利的责任本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口本标准起草单位:电子技术标准化研究所、珠海南方软件产品检测中心、珠海许继电气有限公司、炬力集成电路设计有限公司、上海博为峰软件技术有限公司沈阳软件公共技术服务平台有限公司、深圳市吉阳自动化科技有限公司、上海博泰悦臻电子设备制造有限公司、广东宝莱特医用科技股份有限公司、上海嵌人式系统应用工程技术研究中心,珠海优特电力科技股份有限公司、上海超算并行软件有限责任公司、上海鲁齐信息科技有限公司本标准主要起草人;侯建华、陈勇、秦卫东、杨丽春,王兴念、潘海祥、王忠福、张展新、徐锋光、阳如坤、应臻恺,张肠肠、史旭光 m
GB/28171一2011 引言嵌人式系统是指以应用为中心,以计算机技术为基础,软硬件可勇裁,适应应用系统对功能、可靠性、成本、体积和功耗严格要求的专门计算机系统嵌人式技术并不是一个独立的学科,它是伴随着微电子技术和计算机技术的发展,微控制芯片功能越来越强大,而嵌人微控制芯片的设备和系统越来越多而发展起来的嵌人式系统几乎包括了生活中所有的电器设备,如:MP3、手机、数字电视机、汽车、微波炉、数字相机、电梯、空调、自动售货机、工业自动化仪表与医疗仪器等虽然大多数软件测试方法都可以直接或间接地用于嵌人式软件的测试,但嵌人式软件可靠性测试与通用软件可靠性测试有着较大差别,这是由于嵌人式系统软硬件功能界限模糊,软件对硬件的依赖性和专用性较强，对实时性,安全性要求较高,目前针对嵌人式软件的测试和调试工具较少等这些都使得嵌人式软件的测试相比通用计算机软件测试可继承性较差本标准参考了国内外相关资料,结合嵌人式软件可靠性测试的实践和特点而制定
GB/I28171一2011 嵌入式软件可靠性测试方法范围本标准规定了嵌人式软件生存周期内软件产品的可靠性测试方法,过程和准则本标准适用于嵌人式软件生存周期全过程,可用于嵌人式软件测试中的可靠性增长测试和可靠性确认测试要求规范性引用文件下列文件对于本文件的应用是必不可少的凡是注日期的引用文件,仅注日期的版本适用于本文件凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T9386一2008计算机软件测试文档编制规范 GB/T11457一2006信息技术软件工程术语 GB/T15532一2008计算机软件测试规范 GB/T16260.2一2006软件工程产品质量第2部分:外部度量 GB/T16260.32006软件工程产品质量第3部分;内部度量术语和定义 GB/T1l457一2006界定的以及下列术语和定义适用于本文件 3.1 reliabtity 软件可靠性software 特定数目的自然单元中或特定任务时间内软件无失效执行的概率 3. 2 偏离 deviation 嵌人式软件执行中的系统行为相对预期行为的偏差级联 cascaded 直接由初始行为产生的行为例如,级联偏离、级联失效、级联偏差 3 失效ftailure 系统运行行为对用户要求的偏离 3.5 失效强度failureintensity 单位时间出现的失效次数注，是表示可靠性的另一种方式操作operation 持续一段时间,结束时将控制权还给系统的一种逻辑任务操作与软件的功能或特征相关,例如
GB/28171一2011 用户命令的执行、对输人的响应处理、系统事务处理 lprfile 操作剖面operatonal 操作及其出现的概率的集合 3.8 操作模式operationalmode 随时间或资源与输人的不同而有较大差别的操作的集合测试目的嵌人式软件可靠性测试的目的是通过嵌人式软件可靠性测试有效地发现程序中影响软件可靠性的缺陷,实现可靠性增长; -验证嵌人式软件是否满足嵌人式系统开发合同或项目开发计划、系统与子系统设计文档、软件需求规格说明和软件设计说明所规定的软件可靠性要求、可靠性的定量要求; -评估当前嵌人式软件可靠性的水平,预测未来可能达到的水平,从而为嵌人式软件开发管理提供决策依据 -通过嵌人式软件可靠性测试,为用户平衡可靠性,时间开发和开发费用提供参考测试环境嵌人式软件可靠性测试的测试环境如下 -具备嵌人式软件运行的目标环境,或高度一致(除位置、结构、接口等部分外其他环境与目标环境一致)的仿真环境; 具备与嵌人式系统应用验证相关的必要的测试仪器仪表,例如,频率源、波形发生器、标准电压电流源、规约分析器等; -具备嵌人式系统运行的温度、湿度,电磁兼容,振动、冲击等环境 -具备一些专用的测试工具 -具备操作剖面所需要的全部外部输人输出的环境支持测试内容嵌人式软件可靠性测试的内容主要包括;可靠性增长测试和可靠性确认测试可靠性增长测试以迭代的方式进行,根据测试过程中检出和跟踪的失效,使用基于可靠性增长模型和统计推理的可靠性评估方法,进行失效强度的估计,然后消除缺陷再测试,使可靠性达到目标要求从而结束测试可靠性确认测试是产品发布或交付前为确定合同约定或者具体标准规定的可靠性指标得到满足而组织实施的测试测试方法总则 GB/T15532一2008中确定的系统测试方法适用于本标准，一般采用黑盒测试技术进行嵌人式软
GB/T28171一2011 件可靠性测试项目的测试进行嵌人式软件可靠性测试,首先明确可靠性目标没有规定可靠性目标时,应按照7.2中的方法进行可靠性目标的确定可靠性目标确定后,编制测试计划、开发操作剖面,进行测试准备、执行可靠性测试、分析评估,最后给出可靠性测试报告 7.2可靠性目标的确定 7.2.1确定失效程度对一个嵌人式软件,根据产品的使用范围,对象,确定失效的严重程度一般根据对人员生命,成本和系统能力的影响来区分失效的严重程度;失效严重程度级别用于对失效数据的分析,在测试过程中判定是否需要查找缺陷和解决表1给出失效程度的级别表1嵌入式软件失效的程度级别失效程度级别对失效的描述不能进行一项或多项关键操作不能进行一项或多项重要操作不能进行一项或多项操作,但是有补救办法 -项或多项操作中的小缺陷 7.2.2为嵌入式软件建立失效强度目标根据嵌人式系统的使用对象,为嵌人式软件建立失效强度目标,表2为推荐的失效强度目标,失效间隔时间和失效影响的对照表表2失效强度目标,失效间隔时间与失效影响失效造成的影响典型失效强度目标失效间隔时间造成人员伤亡或千万元以上经济损失 10" 114a 没有人身伤害,10万元以上经济损失 10-" 10000h 没有人身伤害,万元以上经济损失 10" l000h 没有人身伤害,千元以上经济损失 10 100h 没有人身伤害,少量经济损失 10-" 10h 没有人身伤害,轻微或无经济损失 7.2.3选择通用度量由于嵌人式系统一般是连续运行的,因此嵌人式软件在时间度量上,普通时间和执行时间是一致的,所以,选择普通时间作为通用度量,本测试方法采用小时(h)作为时间单位当然也可以采用自然单元作为通用度量表3为1h任务时间的可靠性与特定周期等效失效强度的对照表
GB/28171一2011 表31h任务时间的可靠性与特定周期等效失效强度的对照 1h任务时间的可靠性特定周期失效强度 0.368 每1h1次失效每100h105次失效 0.9 每天1次失效 0.959 0.99 每1000h10次失效 0,994 每周1次失效 0.9986 每月1次失效 0.999 每1000h1次失效每年1次失效 0.99989 失效强度和可靠性转换见式(1)和式(2). lnR 入=- R一 2 =exp(一式中: 失效强度可靠性; R 自然或时间单位数 7.3开发操作剖面 7.3.1综述使用表格或图形方式构造嵌人式软件的操作剖面测试人员在系统体系结构设计人员软件工程师的参与下构造操作剖面开发操作剖面时,确定输人及相关数据域,分析系统的可靠性需求,对所有可能的操作模式进行分类列表;分析影响软件操作模式的全部外界条件及其对软件运行的影响程度;对各种功能需求之间的相关性进行分析和组合,对于密切相关的功能模块进行合并,对于部分相关的功能模块给出相应的输人变量的组合方法 7.3.2确定操作模式对于不同的嵌人式软件,操作模式会显著不同,确定操作模式宜按表4的方法进行表4操作模式的确定确定操作模式确定方法某天或一天的某段时间,处理的事务或事务频度显著不同,处理主要时间和次要时间事务量的显著差别不同的用户类型管理员、一般使用者,新手等大量和多变的输人输人的显著差别电源的极限电源方面的要求
GB/T28171一2011 表4(续确定操作模式确定方法温度的极限温度方面的要求电磁的极限电磁兼容方面要求其他环境的重大变化湿度,振动,噪声等方面的要求行业规范要求的模式电信,电力、银行等行业的要求 7.3.3确定操作的发起者操作的发起者包括用户、外部条件、嵌人式系统自身等,宜按表5的确定方法进行识别表5操作发起者的确定确定发起者确定方法使用者操作、,远程登录等使用用户外部条件外部输人,例如输人一个量、收到输人信号嵌人式系统自身嵌人式系统软硬件判断出的条件,例如内存异常、中断信号、内部变量 7.3.4选择表示方法操作剖面的表示方法有表格法和图示法可根据使用习惯来选择本标准推荐采用表格方法,即用列表的方式,列出所有操作模式、操作发起者、操作、操作出现率等信息 7.3.5创建操作表创建操作表需要参考用户需求、软件使用说明、行业规定及相关标准要求等,通常以操作的启动者来划分在定义输人空间、操作覆盖输人空间时,应考虑全覆盖表6举例说明如何创建一个操作表表6操作表操确定发起者作输出一个信号到外部1 A(外部输人一个信号) 输出一个信号到外部2 以使用者输人一个指令) 显示一行信息提示数据满 C(内部数据存储满系统信号灯亮 7.3.6确定出现率根据用户需求、软件规格、使用说明、经验等信息,确定每种操作的出现率表7举例说明如何确定出现率
GB/28171一2011 表7出现率操作出现率每小时出现次数输出一个信号到外部1 1o 输出一个信号到外部2 10 显示一行信息 1000 提示数据满 0.001 0.001 系统信号灯亮合计 1020.002 7.3.7确定出现概率将每个操作的出现率除以总出现率表8举例说明如何确定出现概率表8出现概率操作出现概率输出一个信号到外部1 0,0098 输出一个信号到外部2 0.0098 0.9804 显示一行信息提示数据满 0.00000098 系统信号灯亮 0.00000098 合计 7.4测试准备 7.4.1 综述本活动主要根据概率分布信息和测试计划生成对应的测试用例输人文件,计算或给出每一测试用例预期的输出结果,构建测试环境,选择或开发测试工具,进行测试用例设计;生成测试用例时,一定要保证测试的覆盖率确定输人及相关数据域,分析系统的可靠性需求,对所有可能的操作模式进行分类列表;分析影响软件操作模式的全部外界条件及其对软件运行的影响程度;对各种功能需求之间的相关性进行分析和组合,对于密切相关的功能模块进行合并,对于部分相关的功能模块给出相应的输人变量的组合方法附录C列举了一些嵌人式软件可靠性测试用例的实例,可作为测试用例设计参考 7.4.2测试用例准备测试用例准备活动主要包括估计当前版本所需的新测试用例的数量在要测试的系统之间分配新测试用例的数量; 在每个系统的新操作之间分配新测试用例的数量; 指定新测试用例;
GB/T28171一2011 -开发新增测试用例,将新测试用例添加到以前版本的测试用例上 -新开发的软件的第一版可靠性测试用例基于前阶段的测试用例来设计 7.4.2.1估计需要测试用例的数量估计需要测试用例的数量,要考虑时间和成本因素,取这两个数量的最小值作为计划准备的测试用例的数量时间的计算,用可用的时间乘以可用的人员数,再除以准备一个测试用例的平均时间成本的计算,用建立测试用例的预算除以每个测试用例的平均准备成本对于再次测试,例如回归测试,只计算新增加的测试用例数量 7.4.2.2分配测试用例为每个操作分配测试用例数量对于回归测试,只分配新修改的操作的测试用例根据操作出现率,进行下列工作确定很少出现的关键操作(概率小但应测到),为每个这样的操作分配测试用例数量关键操作是指失效会造成人身伤害,重大损失的操作,对这些操作要分配充足的测试用例确定偶发性的操作,分配一个测试用例,偶发性的操作是指出现概率非常低的操作,这样做的目的是保证至少为这样的操作分配一个测试用例根据操作概率,把剩下的测试用例分配给剩余的其他操作 7.4.2.3指定测试用例为每个操作指定测试用例从操作的直接输人变量的值域中,找出具有相似失效行为的值域,形成输人变量值域组合在选择了输人变量值域组合之后,从组成值域的集合成员中,随机选择输人变量,作为测试用例选择了测试用例后,编制测试用例的脚本 7.4.3测试过程准备为每个操作模式准备一个测试过程,指定或调整测试操作剖面和操作出现率,调整主要发生在回归测试或需求变更的测试过程 7.5执行测试 7.5.1综述在执行可靠性测试时注意以下方面被测软件的测试环境(包括硬件配置和软件支持环境)和预期的实际使用环境应完全一致测试时按测试计划和顺序对每一个测试用例进行测试,判断软件输出是否符合预期结果测试时应记录测试结果、运行时间和判断结果如果软件失效,那么还应记录失效现象和时间,以供失效分析 7.5.2分配测试时间分配测试时间宜按照以下方法进行在要测试的系统之间分配测试时间; -对进行可靠性增长测试的功能测试、回归测试、负载测试之间分配测试时间;要分配足够的时间进行功能测试,以便充分执行测试用例,并对前一版本进行回归测试,然后把剩下的时间分
GB/T28171一2011 配给负载测试; -对进行负载测试的操作模式之间分配测试时间; 进行确认测试.将所有的时间都分配给负载测试 -时间分配以小时计估计测试需要的时间按式3) 式中 -用自然或时钟时间单元表示的测试时间: 规范化度量(MTTF数),见式(4); T 失效强度目标人R ln T、一式中: 分辨率 -提供商风险,即错误地认为失效强度目标没有达到但实际上已经达到的概率; 客户风险,即错误地认为失效强度目标已经达到,但实际上没有达到的概率 7.5.3调用测试对于可靠性增长测试,首先执行功能测试,然后进行负载测试,按照测试用例进行全覆盖测试在每次对软件做了较大修改后,要进行回归测试功能测试按照分配的测试用例,顺序调用测试用例进行测试回归测试应全面检查需求变化处另外随机测试和回归测试的要求不同,需要注意区分,按影响域调用相关测试用例 7.5.4标识出现的失效在测试中应对测试的输出进行分析,确定失效,失效时间和失效强度 7.5.4.1分析测试输出的偏离采用自动化工具或以人工对测试结果审查,确定执行结果与相对预期行为的偏差在分析偏差的过程中,不计算级联 7.5.4.2确定哪些偏离是失效确定出现的偏离是否为失效硬件错误引起的失效不作为嵌人式软件的失效统计,但对于需要实现软件容错、避免严重错误的失效,应统计在内 7.5.4.3估计失效发生的时间估计失效发生的时间采用统一的时间度量,即普通时间,以小时为单位以出现顺序,累加度量单元,包括所有操作模式的功能测试,回归测试,负载测试对于同时出现的多个失效记录,会导致多个零失效间隔,应在记录的时间间隔内,估计随机的时间用于替代这些零间隔 7.5.4.4指派失效严重程度类对失效,确定出失效的严重等级
GB/T28171一2011 7.5.4.5形成测试记录按照执行的测试用例,记录测试过程、测试结果,运行时间,失效时间、失效现象,形成测试记录表9为测试记录的示例表9测试记录示例件时失效的时间间隔/min" 事间开始测试 2o10年1月1日8时00分失效1 2010年1月1日8时35分 35 失效2 2010年1月1日9时10分 35 失效3 2010年1月1日13时20分 250 失效4 2010年1月1日15时30分 130 测试结束 2010年1月1日16时00分 30 7.6失效数据的分析评估 7.6.1综述本活动进行失效分析,可靠性估计及判定;整理测试记录,并将结果写人测试报告测试结果不满足给定的可靠性目标时,应在完成纠正错误后组织实施回归测试可靠性增长测试 7.6.2 7.6.2.1 失效数据分析在进行失效数据分析时,必须明确以下问题 -对某一失效,决定不查找和解决的,该失效不统计; -重复的失效不统计; -人为操作失误或外界环境异常引起的失效需要统计; -硬件错误引起的失效不统计,但由于软件没有进行冗余、容错的失效应统计可靠性增长测试过程,要根据失效数据定期进行趋势分析和评估可靠性增长测试过程中发现的所有缺陷都应纠正,且纠正时应确保不引人新的缺陷在测试过程中,应详细记录失效的时间、现象,以分析失效的根源和纠正缺陷表10为可靠性增长测试过程中推荐的评估频率表10可靠性增长测试过程的评估频率剩余测试长度分析评估频率 <1个月每天一次 1个月3个月每周二次 >3个月每周一次对失效数据进行趋势分析,以指导可靠性模型的选择,失效强度估计趋势分析采用定期评估 FI/FIO比的方法
GB/T28171一2011 FI/FIO是可证明失效强度与失效强度目标之比，FI/FIO比入n为 T.An D= 1,入F 式中: 已经出现的失效数对应的继续和接受边界的规范化度量(见式(9)) T.n) -测试结束时的时间单位数失效强度目标人R 在可靠性预测和趋势分析时,遵循以下方法 -FI/FIO比估计的精确度取决于样本规模(发生失效的数量); 当FI/FIO比大于2时,检查最近的5个值,查看是否出现稳定,相当明显的上升趋势,如果是，继续测试;不是时,分析原因,做好软件的变更控制和测试控制当规范化失效强度小于0.5时,结束测试; -当F/FIo比大于15,在测试时间内不可能达到失效强度目标时,应推迟发布软件,商议调整失效强度目标,修改错误后再测试在测试过程中,定期评估和预测可靠性,以指导下一步的测试工作,主要有估计当前的可靠性,包括MTTF、当前失效率、当前失效强度等; 预测现在达到的可靠性水平; -预测还需要增加的测试,预测何时能够达到可靠性目标根据分析结果,可适当调整测试资源,增加投人,使可靠性增长测试在预定时间内达到目标 7.6.2.2失效强度估计根据对失效数据的趋势分析,选择可靠性模型,估计失效强度可靠性模型选择可参见附录B 由于可靠性模型较多,在可靠性模型的选择上本方法推荐两种作为参考,这两种模型为;基本(Musa)和对数泊松(Musa.Okumoto)执行时间模型基本和对数泊松执行时间模型,又分别称为指数和对数模型这两种模型都使用执行时间,在嵌人式软件测试估计时,日历时间即为执行时间(这是基于嵌人式软件是连续运行的假设) 出现失效的函数的基本泊松模型的失效强度入为: A(=A- 朵式中开始执行的初始失效强度; A 给定时间点上的平均或预期发生的失效数; n 在无限时间内发生的失效总数出现失效的函数的对数泊松模型的失效强度入为: A(A)=入0exp(一) 式中: 开始执行的初始失效强度; 入，给定时间点上的平均或预期发生的失效数从 9 失效强度延迟参数对于这两种模型,需要在执行开始时,确定入,、,9,应根据嵌人式软件自身的特征预测,如软件的源代码长度,可执行代码的编译效率、软件的复杂度、对失效强度的要求等;也可以在嵌人式软件系统测试阶段,通过收集失效的数量进行估计 10o
GB/T28171一2011 7.6.3可靠性确认测试 7.6.3.1综述可靠性确认测试是为确认在给定统计置信度下,对嵌人式软件当前的可靠性水平是否满足用户需要而进行的测试,即确认是否满足所规定的可靠性目标,本标准推荐采用失效执行时间和可靠性示图来进行确认测试 7.6.3.2失效执行时间确认测试给定客户风险3和MTBF的检验下限0,由式(8)计算出嵌人式软件的可靠性测试时间T 根据T,按照测试用例执行测试,在T时间内无失效时接受软件,发生失效时拒绝软件 8 T=-ng 式中: -MTBF检验下限值; 客户风险这种确认测试适用于MTBF在1000h以内的嵌人式软件可靠性确认测试,对于MTBF大于 1000h的嵌人式软件,应采用可靠性示图确认测试 7.6.3.3可靠性示图确认测试根据客户风险和开发风险级别构造可靠性示图,失效被绘制在图上,根据失效落人的区域,判定被测嵌人式软件被接受、拒绝还是继续测试首先与客户及提供商协商确定提供商风险a和客户风险8,参照附录A的方法,画出可靠性示图提供商风险a和客户风险3一般选取20%以下,最大不宜超过30%;对于可靠性要求很高的嵌人式软件应在10%以内绘制可靠性示图时,需计算出继续和接受边界、继续和拒绝边界,并绘出边界线边界线由式(9)和式(10)求出: r、.(n)=A一ln 9 式中: -已经出现的失效数对应的继续和接受边界的规范化度量; TN. 失效数; 由式(11)计算得出; A -分辨率,即最大可接受失效强度与失效强度目标的比值,?的取值范围1.1一2.0之间可靠性要求越高,取值应越小 B一n2 ** e l0 Ts.a(n)一式中: T 已经出现的失效数对应的继续和拒绝边界的规范化度量， Y.B 失效数由式(12)计算得出; B 分辨率,即最大可接受失效强度与失效强度目标的比值,Y的取值范围1.12.0之间可靠性要求越高,取值应越小 A=ln 11) 1l
GB/28171一2011 且=ia一" 12 图1表示的可靠性示图中客户风险g=0.1,提供商风险a=0.1,分辨率y=2 14 拒绝 12 10 继续接受计算出的规范化的度量图1经过规范化度量(MTF 可靠性示图的绘制方法和不同分辨率、风险的参数计算,参见附录A 根据失效数和失效发生的时间单元,计算出经过规范化的度量(MTTF) 纵坐标为失效数,横坐标为计算出的规范化的度量,标注在可靠性示图上按照下面的方法进行判决该点落在继续区域时,继续测试落在拒绝区域时,结束测试,拒绝软件; -落在接受区域时,结束测试,接受软件; 直到测试结束一直在继续区域时,计算HIFIo比.FI/FIo比大于5而且出现了失效时,拒绝软件;FI/FIO比小于5时则接受软件 7.7 可靠性测试报告可靠性测试完毕,应给出一份可靠性测试报告，一般包括 -测试环境、测试设备情况; 可靠性目标及确定情况; 操作剖面确定和构建情况; 可靠性增长测试过程,时间,测试用例数量,测试覆盖率; 可靠性确认测试过程,时间,测试用例数量,测试覆盖率; 失效强度估计结果和分析; 可靠性模型拟合、拒绝或接受结论测试中发现的问题和处理建议; 被测软件的版本信息测试报告的编制应符合GB/T9386一2008的要求测试覆盖率等指标的计算宜采用GB/T16260.22006和16260.32006的方法度量,在进行可靠性增长测试时,可以按照该标准的计算方法,计算出相应的指标,并加人到报告中 12
GB/T28171一2011 附录A 资料性附录可靠性示图绘制在采用可靠性示图确认测试时,为了绘出可靠性示图,需求出继续和接受边界、继续和拒绝边界,并绘出边界线,推荐按下面的方法绘出可靠性示图 =0时的T,与横轴的交点: 卫= A.1 TN.a(0) TN.n(0y " 刀=16时的T、,与横轴的交点 A二16n TN,A(16 B 6nY TN,.n(16) T、=0时,与纵轴的交点: A (0 A.5 nA( n ng(0 A.6 n T=16时,与纵轴的交点 y A一16 nA(16 ln7 ) B-16 n(16= A.8 n2) 为了使用的方便,给出典型的参数,见表A.1和表A.2. 表A.1区域与边界的各个横轴和纵轴的交点值分辨率7 交点位置川=0点的横轴 -A,一B -2A,一2B -10.A,一10B n=16点的横轴一A11.1,一B+11.1 -2A+13.0,一2B+13.0 -10A+15.2,一10B+15.2 TN=0点的纵轴 1.44A,l.44B 2.47A,2.47B 10,5A,10.5B (A+1.6/0.0953 A+16/0.693， A+8)/0.405， T= -16点的纵轴 B+16)/0.693 B8)/0.405 B+1.6/0.0953 表A.2各种提供商风险和客户风险水平条件下的A值和虽值客户风险提供商风险参数 0.05 0.01 0.001 -2.20 -2.89 -4,50 -6,80 2.20 2.25 2.29 2.30 13
GB/28171一2011 表A.2(续) 客户风险提供商风险参数 0 0.05 0.0 0.001 一4.55 -2.25 -2.94 -6.86 0.05 2.89 2.94 2.99 2.99 -2.29 -2.99 一4.6o 一6,90 0.01 4.50 4.55 4.60 4.60 -2.30 -2.99 -4.60 -6.91 0.001 6,80 6.86 6.90 6.91 可以看出.A随客户风险迅速变化,但随提供商风险变化很小,它决定接受边界与横轴线在n=0的交点,因此接受边界会随客户风险急剧变化,随提供商风险有很小的变化 B随提供商风险迅速变化,但随客户风险变化很小,它决定拒绝边界与纵轴线在T、=0的交点,因此拒绝边界会随提供商风险急剧变化,随客户风险有很小的变化在确认测试时,可以根据需要,画出所需要的客户风险和提供商风险所有组合的可靠性示图,也可以只画出客户和提供商风险对称的可靠性示图当二者不对称时使用足够近似的图随着分辨率,客户风险水平或提供商风险水平的降低,继续区域会拓宽,因此如果要降低在估计失效强度中所能够容忍的错误,或降低错误决策的风险,达到拒绝或接受区域则需要更多的测试 14
GB/T28171一2011 附录 B 资料性附录可靠性模型选择根据对失效数据的趋势分析,选择可靠性模型,估计失效强度表B.1给出了分析结果与可靠性模型选择的参考对照表B.1根据趋势选择模型失效趋势可靠性估计模型选择编号可靠性增长 J-M模型,GO模型,M-O模型等可靠性下降选择允许失效强度上升的模型可靠性先降后升 On、 S模型 Yamada O)saki 可靠性稳定 HPP模型,失效时间服从指数分布的模型 15
GB/28171一2011 附录c 资料性附录可靠性测试用例分析设计实例 C.1故障注入测试故障注人测试是针对嵌人式系统的可靠性测试的常用手段故障注人测试项目的测试顺序应综合考虑该故障出现的概率和测试项目之间的互补关系故障注人测试分为如下几步故障注人在这一步把缺陷,故障和失效插人到代码中去,这时候要确定插人的位置,可能还要添加适当的代码执行测试要用输人必要的数据、产生内部的或外部的事件,发送特定的消息等方法把前面插人的故障激活测试结果收集包括收集测试前设置的观察点处观察到的数据、现象等,另外还要收集被测系统出现的各种异常现象,如死机、复位测试结果评估即根据测试过程中收集到的各种测试数据,结合用户的实际使用需求和设计需求,判断当前出现的各种现象是否属于正常在实际操作中,可以采用下面的两条准则来判断是否需要启动修改流程: 故障注人后引起用户不可接受的严重故障; 故障停止插人后系统无法恢复,仍然处于故障状态 2 针对嵌人式软件可靠性测试的故障注人方法,本附录列举了常用的插人测试项目,通过这些项目可构造大量的可靠性测试用例 c.2内存过载测试当一个计算机系统的内存占用率为80%100%时,视为内存过载内存过载测试主要是测试系统在内存即将用完的时候,系统运行的可靠性故障产生原因有大流量冲击、内存丢失、算法缺陷等故障可能产生的后果如复位、空转、系统内部数据状态不一致等对于一般系统,内存过载时能自动降低业务处理量,如果持续时间过长,则允许单板复位对于高可用系统,要求能区分是大流量冲击还是内存丢失造成的内存过载如果是大流量冲击造成的过载,应能自动降低业务处理量;如果是内存丢失造成的过载,应能复位单板,但对业务不造成影响采用内存丢失的办法实现内存过载的测试步骤: a)丢失空闲内存,使内存占用率达到80%,运行一段时间,观察系统的运行状态 b 在前面的基础上再丢失10%的内存,运行一段时间,观察系统的运行状态; 把剩余的所有内存全部申请出来丢掉,观察系统的运行情况 c c.3CPU过载测试当一个计算机系统的CPU占用率达到80%100%时,称为CPU过载 CPU过载测试主要是测试系统在高CPU占用率状态下系统的可靠性故障产生原因有大流量冲击、算法效率低下,CPU锁死等;故障可能产生的后果有:对实时事件响 16
GB/T28171一2011 应不及时、影响提供业务的能力等通过创建一个任务,用循环的方式强制消耗掉一部分CPU资源,循环次数可以动态调整,以调整 CPU占用率来模拟故障产生 CPU过载时应能自动启动流控,降低业务流量,同时,系统运行的各种业务不应出错,输人输出的各类消息顺序保持不变测试步骤: a 创建一个最高优先级的CPU过载测试任务,调整循环次数,使CPU过载,观察系统的运行情况; b)降低过载测试任务的优先级,使原来优先级较高的任务可以正常运行,优先级较低的任务受到影响,运行一段时间,观察系统的运行情况重复步骤b),使各优先级的任务均受到过载干扰 C.4队列过载测试对于有限长度队列,队列的长度达到最大长度的80%~100%时,称为有限长度的队列过载对于无限长度队列,队列长度远远大于正常运行时队列长度时,例如10倍,称为无限长度的队列过载队列过载测试主要是为了测试队列缓冲造成的延时对系统的影响,对于有限长度队列,还可以验证队列满的情况下程序运行的情况故障产生原因有大流量冲击,处理队列的任务受到阻塞,发生了死锁等;故障可能产生的后果有;系统响应超时、系统内部各模块之间数据状态不一致等在测试中可以采用挂起处理队列的任务的办达实现队列过载队列过载不应造成系统的业务运行出错,造成的延时也应在可以接受的程度,对于有限长度队列能正确处理队列溢出的情况,不会产生内存越界或其他错误测试步骤: a)运行程序,输人各种必要的数据,使被测队列有一个持续的进队列操作挂起处理队列的任务对于有限长度队列,使队列长度达到80%时解挂该任务,恢复运行,对 b 于无限长度队列,使队列长度达到正常队列长度的8倍,然后解挂该任务,观察系统的运行情况过一段时间后,再次挂起该任务对于有限长度队列,使队列长度达到最大长度,此时继续进行人队列的操作,观察系统的运行状态;对于无限长度的队列,使队列长度达到正常长度的 0倍然后解挂该任务,运行一段时间,观察这一过程中系统的运行情况 c.5资源丢失测试资源丢失是指资源没有正在被使用,也不在对应的资源管理程序中,即该资源已经不受控了资源丢失测试的目的是验证在发生资源丢失故障时软件是否能从故障中恢复过来,在故障恢复过程中是否还引人了其他的故障故障产生原因有重人、申请出来的资源使用后没有释放、在某些路径下资源没有释放等;故障可能产生的后果如复位,输出错误、软件内部状态错误、业务无法完成或业务性能降低等采用把资源申请出来后不释放的方法来模拟故障产生对于一般系统,要求在资源耗尽以后能复位,这时要注意耗尽型资源和非耗尽型资源的差异,复位条件的检测要特殊设计;对于高可用系统,要求能恢复资源丢失造成的影响,并且不影响业务的正常运作 17
GB/28171一2011 测试步骤: 申请一个资源 a b)经过一段时间后,检查软件是否能发现出现资源丢失,观察软件是否采取了什么恢复措施,该措施是否有效; 重复申请一批资源但不释放,过一段时间后,检查软件是否能发现出现资源丢失故障,故障软件是否采取了相应的措施,以及该措施是否有效 C.6释放错误资源测试释放错误资源测试就是把伪造的非法资源通过资源释放函数试图加人到空闲资源池的测试过程释放错误资源测试的目的是为了验证资源管理程序是否对非法资源有合理的保护措施故障产生原因有资源在使用过程中修改了资源的标记属性,如地址指针、D号等;故障可能产生的后果有,资徽管理犁序遭到破坏资源丢失、业务中断等采用伪造一个非法的资源并用资源释放丽数释放该非法资源,例如对于内存,可以先申请出一块内存,然后把地址加1再释放,来模拟故障测试过程中,返回了出错信息,资源管理程序内部应没有真正增加这些非法的资源测试步骤 a)伪造非法资源" 用资源释放丽数释放这些非法资源; b 观察资源管理程序是否返回出错,检查资源管理程序的内部数据看是否把非法的资源加进去了重复释放资源测试重复释放资源是指同一个资源被释放两次或两次以上重复释放资源测试的目的是为了验证资源管理程序是否具有处理资源重复释放故障的能力故障产生原因一般是编程错误故障可能产生的后果有;资源管理程序内部存在多个同一资源、软件提供的业务出现错误等采用修改代码,把申请成功的资源释放2次来模拟故障测试过程中,第2次或以后的释放均返回失败,系统应给予告警或提示测试步骤: a)把申请成功的资源释放2次: 检查是否2次都释放成功 b 检查资源管理程序内部的数据记录中是否存在2个相同的资源 C.8资源释放时机错误的测试资源释放时机错误是指资源被提前释放了,即资源被释放后仍然在继续使用这个资源本测试的目的是检查资源被提前释放后对系统造成的影响是否可以接受故障产生原因一般是资源被提前释放;故障可能产生的后果有;数据遭到破坏、资源遗漏、提供的业务出现错误等通过修改代码,把释放资源的操作提前来模拟故障对于一般系统,如果资源提前释放造成了更严重的故障,系统应能复位;对于高可用系统,它能检测 18
GB/T28171一2011 到资源提前释放造成的故障,并对其影响能恢复测试步骤: a)提前释放资源; b)观察对系统的影响 C.9资源申请失败测试测试目的是验证程序对资源申请失败的处理是否正确故障产生原因可能有;资源已经用完了,资源管理程序出现了故障、编程错误等故障可能产生的后果有;业务没有完成、访问了非法资源等采用修改代码,使资源申请丽数在需要的时候可以产生一个异常返回值来模拟故障测试过程中,软件的主要业务不应出现错误测试步骤，修改代码.在代码中增加一个路轻控制开关当开关关闭时,资源可以正常申请,当开关打开 a 时,申请的资源都不成功 b)在系统正常运行后,把上述的控制开关打开,加人故障观察故障对系统的影响 c.10临界资源重入测试由两个或两个以上的任务共享的资源称为临界资源,比如多个任务间共享的内存,全局变量、物理端口等测试目的是验证系统是否具有临界资源重人故障的处理机制以及处理的结果是否符合需求故障产生原因可能有;软件设计时没有考虑临界资源问题、临界资源太多,编码时只对部分临界资源进行了保护等故障可能产生的后果有:软件内部数据状态混乱、业务中断、复位等测试时把已有的临界资源保护措施去掉,强制出现重人问题,来模拟故障对于一般系统,如果内部数据遭到严重破坏,系统应能复位重新启动;对于高可用系统,软件应能处理这一情况而不至于出现失效测试步骤 a)删除代码中的临界资源保护的措施; b 编译运行修改后的软件; c)观察系统的出错情况 C.11栈溢出测试栈溢出是指栈指针越过了栈的边界测试目的是检查程序对栈溢出是否有预防措施,当发生栈溢出后,程序是否有相应的检测、恢复过程故障产生原因可能有;使用了大数组作为局部变量,使用了大数组作为形式参数,递归调用层次过深,函数调用的层次过深等故障可能产生的后果有:内存越界、程序异常等测试时的故障产生方法使用定义大数组的局部变量方法实现栈溢出 a b)使用内存拷贝的方法使栈越界; 使用函数递归调用的方法使栈越界使用方法b)和方法c)时,某些操作系统可能把栈指针回卷到栈底 19
GB/28171一2011 对于一般系统,栈越界后如果造成了更严重的故障,要求能复位系统;对于高可用系统,栈越界后不应对系统提供的业务造成影响，一个可行的办法是采用硬件监视的方法在栈溢出时产生一个异常,防止栈溢出的产生测试步骤: a)在程序正常运行时,使用上面描述的方法使栈越界 b)观察栈越界后的结果 C.12任务强制挂起测试任务强制挂起测试的目的是为了验证软件是否具有任务被异常挂起的检测功能,以及测试任务被异常挂起后软件的整个恢复过程是香正确,是否会引人其他的故障故障产生原因一般为程序设计问题故障可能产生的后果是;被挂起的任务完成的功能无法完成. 还可能引起进一步的其他故障测试时的故障产生方法 a)通过控制台调用挂起函数把被测任务强制挂起; b)修改代码,嵌人挂起任务的代码,重新编译软件;嵌人代码时,注意嵌人的代码应在整个软件正常运行一段时间后才能执行测试过程中,被挂起的任务能在一个合理的时间内解挂,解挂后各个任务之间的内部状态应保持一致,对业务造成的影响尽量小测试步骤， a)通过控制台或嵌人代码使被测任务强制挂起观察系统的运行情况 b c.13任务强制删除测试任务强制删除测试的目的是为了验证软件是否具有任务被异常删除的检测功能,以及测试任务被异常删除后软件的整个恢复过程是否正确,是否会引人其他的故障故障产生原因一般为程序设计问题故障可能产生的后果是;被删除的任务完成的功能无法完成. 还可能引起进一步的其他故障测试时的故障产生方法 a)通过控制台调用任务删除函数把被测任务强制删除 b 修改代码,嵌人删除任务的代码,重新编译软件嵌人代码时,应注意嵌人的代码应在整个软件正常运行一段时间后才能执行对于一般系统,要求能检测到任务被删除,并复位系统;对于高可用系统,要求被删除的任务能在一个比较短的时间内恢复,并对业务造成的影响尽量小,任务恢复后,各个任务之间的内部状态应保持协调一致测试步骤: 通过控制台或嵌人代码使被测任务强制删除 a b)观察系统的运行情况 C.14插入死循环测试插人死循环是指在任务或中断服务程序中加人死循环代码插人死循环测试的目的是为了验证任 20
GB/T28171一2011 务或中断进人死循环后软件的处理是否符合要求故障产生原因可能有:进人了死循环,发生了不能终结的函数递归调用,发生了函数的循环调用等故障可能产生的后果是由任务或中断完成的功能无法完成采用在软件中加人死循环代码来模拟故障对于一般系统,要求能检测到发生死循环故障,并能复位,复位后系统能正常运行;对于高可用系统,要求能检测到发生死循环故障,并要求能重新启动或重新初始化该任务,重启后各个任务的内部状态能保持一致测试步骤: a)在被测任务或中断中加人死循环代码,重新编译程序; 构造测试输人数据,使程序能执行到插人的代码 b 观察软件进人死循环后的处理情况 c C.15任务延时测试任务延时测试是指在被测任务中加人延时代码延长任务执行时间的一种测试过程任务延时测试的目的是为了了解任务延时后对系统造成的影响是否满足要求故障产生原因可能有:程序在处理某些任务时处理量大、花的时间很长;程序在某些路径下需要等待某一事件,造成执行时间有一定程度的不确定性等故障可能产生的后果有:业务性能下降、系统对某些事件的响应速度变慢、模块之间的消息时序上出现错误测试时的故障产生方法 a)在任务中加人空循环作延时处理， b)调用任务延时函数测试过程中,系统不导致严重故障或失效当延时干扰取消后,程序应能恢复正常状态,各模块之间也不应出现时序上的混乱测试步骤， a)在任务中加人空循环作延时处理,重新编译程序 b) 构造测试数据,激活被测任务; e观察系统的性能是否出现明显下降,是否出现其他的故障,任务之间的交互时序是否出现变化以及这个变化带来了什么影响 C.16死锁测试若一个进程集合中的每一个进程都在等待只能由本集合中的另一个进程才能引发的事件,则这种情况被视为死锁死锁测试的目的是为了验证程序是否具有处理死锁的能力死锁的4个条件 a)互斥条件,每一资源或者被分配给一个进程,或者空闲; D 保持和等待条件,已分配到了一些资源的进程可以申请新的资源; 非剥夺条件,已分配给一进程的资源不可剥夺,只能被占有它的进程显式地释放; c d)循环等待条件,系统必然有一条由两个或两个以上的进程组成的循环链,链中的每一个进程都在等待相邻进程占用的资源故障可能产生的后果可能是;所有涉及的任务均被挂起,由这些任务完成的功能全部中断按照上述4个条件,任务A申请资源1和资源2,任务B申请资源2和资源1,为了能进人死锁,在申请完第1个资源后增加一个同步操作,使两个任务进人死锁 21
GB/28171一2011 对于一般系统,程序能检测到软件发生了故障并能复位系统;对于高可用系统,要求能检测到软件发生了故障而且在短时间内能正确恢复,并对业务不造成重大影响测试步骤: a)选择2个任务,按照下列步骤增加相应的代码 b)任务A:申请信号量1一申请信号量3一释放信号量1一等待信号量2一申请信号量4; 任务B;申请信号量2一申请信号量4一释放信号量2一等待信号量1一申请信号量3 c d)重新编译程序并运行,观察程序是否能检测到死锁并采取相应的措施 C.17频繁中断测试当两个中断的间隔时间小于中断服务例程的处理时间时,称为发生了频繁中断测试目的是验证软件在发生颗繁中断情况下的运行是否稳定可靠,验证中断等待、中断嵌套功能是否达到设计要求故障产生原因可能有中断服务例程执行时间过长,同时发生了多个中断、中断发生得太快等故障可能产生的后果有中断丢失、中断挂起、中断异常等,由此带来与该中断相关的业务可能受到影响采用在中断引脚户生朋累中断信号来模拟故障" :生测试过程中,当中断队列不满时,不应发生中断丢失,同时不应发生中断挂起或异常;当取消频繁中断后,程序应能恢复正常运行时的状态测试步骤， a)测试出被测中断的一次正常中断的执行时间(4); 找到中断源对应的引脚,在引脚上插人中断信号发生器的输出信号,调节中断间隔时间(ee). b 使其小于中断服务程序的执行时间(G>>0.54),观察系统运行情况继续降低中断信号的时间间隔,使0.5>>0.25,即在处理中断服务程序时发生2个中断请求,观察系统运行情况; 在中断服务程序中增加中断计数变量,重新编译运行,正常运行后,利用中断信号发生器在很短的时间内快速发送1000个中断,观察系统运行情况 c.18重复中断测试重复中断是指对同一次中断作了多次响应,即执行了多次的中断服务程序重复中断测试的目的是为了测试重复执行中断服务程序对系统造成的影响故障产生原因可能是中断控制器发生了故障故障可能产生的后果有;重复执行由该中断触发的操作,对于数据收发出现重包等采用在响应中断时,调用多次中断服务程序来模拟故障产生测试过程中,重复执行中断的服务程序不应对系统的业务造成影响测试步骤: a)修改代码,在响应中断时,调用多次中断服务程序,重新编译程序; b按照实际条件触发该中断,观察程序的运行情况 C.19中断丢失测试中断的响应次数比中断的触发次数少的情况称为中断丢失测试目的是测试中断丢失对系统造成的影响,验证在发生中断丢失时,系统是否发生重大的功能缺陷故障产生原因可能是中断控制器故障故障可能产生的后果有:对外部事件的响应不完整造成系 22
GB/T28171一2011 统的严重功能失效、对于数据收发造成丢包采用在中断服务程序中有选择性或随机地直接返回的方法来模拟测试测试过程中应不发生重大的功能失效,对后续的中断仍能正常处理测试步骤: a)修改中断服务程序,在人口处有选择性或随机地直接返回,重新编译程序 b)按照实际条件触发该中断,观察系统的运行情况 C.20中断挂起测试中断挂起是指中断控制器由于某些原因造成不能响应新中断中断挂起测试的目的是为了测试系统不能响应部分或全部中断后系统的运行情况故障产生原因可能是中断控制器发生故障故障可能产生的后果是无法响应新产生的中断,因此由这些中断完成的功能均无法完成采用修改中断使能位或中断屏蔽位关闭被测中断来模拟测试程序应能检测到中断出了故障,采取相应的措施,并能在一个较短的时间内恢复正常测试步骤， a)运行程序,使被测程序正常运行,然后清除被测中断的使能位,关闭中断按照实际条件触发该中断,观察系统的运行情况 b c.21中断服务例程延时测试测试目的是为了测试中断处理时间的延长对系统造成的影响故障产生原因可能有;中断服务例程中执行到需要等待某些条件的语句、中断服务例程中某些路径很长导致执行时间大幅增长等故障可能产生的后果有:业务性能下降、系统对某些事件的响应速度变慢、中断与任务之间的输出时序上出现错误等采用在中断服务例程中加人空循环模拟延时来测试测试过程中,中断与任务之间的输出没有出现时序上的问题,业务性能不应出现严重下降,提供的业务不应出现错误测试步骤; a)在中断服务例程中加人空循环,重新编译程序; 按照实际条件触发中断,使被测的中断服务例程能被执行 D 观察系统的运行情况 c C.22单板启动过程中触发所有中断测试测试目的是验证单板启动过程中是否把某些中断打开了故障产生原因可能是单板启动过程中被触发中断故障可能产生的后果是程序会异常运行采用模拟实际情况在单板启动过程中触发单板的每一个中断源来测试测试中程序应不异常,在启动过程中中断不起作用测试步骤: 选择增加测试代码的位置在主函数的初始化部分(主循环之前的代码)选择一个开中断语句之后的位置作为增加测试代码的位置不管在代码中是否真正存在，主函数开始的地方总是默认有一个开中断语句 23
GB/T28171一2011 在步骤a)中选择的位置增加一条死循环语句,死循环内部增加一个计数器或者增加一个闪灯的操作,重新编译程序在程序进人该死循环后,逐一触发所有的中断源,检查是否异常,即检查计数器值是否在增加或者灯是否在继续闪亮选择其他开中断语句之后的位置,重复步骤b)和步骤e),直到所有开中断语句均被测试过 C.23触发未使用中断测试指程序运行过程中触发了没有使用的中断测试目的是验证程序是否关闭了未使用中断故障产生原因是没有把未使用中断关闭或进行处理故障可能产生的后果有:发生程序异常、影响程序的性能、未知故障等采用模拟实际条件触发未使用中断来测试程序不应异常,业务能正常处理,触发未使用中断对系统不造成任何影响,触发未使用中断时不应对中断标志位造成影响测试步骤， a)屏蔽所有未使用的中断源 b) 运行程序,模拟实际条件触发所有未使用中断 e)观察程序运行状态,检查是否发生异常; 检查中断标志位是否被置位 d c.24接口数据长度错误测试长度错误是指消息中各个长度域中的值发生错误测试目的是测试程序对错误长度的消息的处理情况故障产生原因可能有;发送的消息长度有错、消息在传输过程中发生了错误等故障可能产生的后果有;内存越界、使用了错误的数据、死机等采用发送错误长度的消息来模拟故障程序应能忽略消息内容并释放这些非法消息,而且程序的状态不应挂起在某个状态,当长时间收不到期望接收的消息时,应能恢复到初始状态测试步骤: a)修改代码,可以从后台直接发送十六进制格式的消息,重新编译程序并运行; b 发送0长度消息,即长度域的值是0,观察程序的处理情况 e发送超长消息,即长度值超过允许的最大值,观察程序的运行情况; 发送消息内容中的长度域,使其值在允许范围之外,观察程序的运行情况 d C.25接口数据类型错误测试接口数据类型错误是指接口的消息类型发生的错误测试目的是测试程序对错误类型的消息的处理情况故障产生原因可能有:发送的消息类型有错、消息在传输过程中发生了错误等故障可能产生的后果有;使用了错误的数据、状态机故障等采用发送错误类型的消息来模拟故障程序应能忽略消息内容并释放这些非法消息,而且程序的状态不应挂起在某个状态,当长时间收不 2
GB/T28171一2011 到期望接收的消息时,应能恢复到初始状态测试步骤: a 修改代码,可以从后台直接发送十六进制格式的消息,重新编译程序并运行; b)发送消息类型为允许范围外的消息,观察程序的处理情况 C.26数据错误测试数据错误是指传送了错误的消息数据测试目的是测试程序对带有错误数据的消息的处理情况故障产生原因可能有发送的消息类型有错、消息在传输过程中发生了错误等故障可能产生的后果有;软件处理了错误的数据、状态机放障等采用发送错误数据的消息来模拟故障程序应能忽略消息内容并释放这些非法消息,而且程序的状态不应挂起在某个状态,当长时间收不到期望接收的消息时,应能恢复到初始状态测试步骤，修改代码,可以从后台直接发送十六进制格式的消息,重新编译程序并运行; a b)发送消息数据为允许范围外的消息,观察程序的处理情况消息数据的一致性错误测试 C.27 消息数据的一致性错误是指消息中的多个数据之间存在矛盾测试目的是测试程序是否能区分出存在一致性错误的消息数据并给予正确的处理故障产生的原因有内存越界、算法错误,协议缺陷等故障可能产生的后果有模块间配合出现错误,模块失效等采用强制修改消息数据来模拟故障程序应能忽略消息内容并释放这些非法消息,而且程序的状态不应挂起在某个状态,当长时间收不到期望接收的消息时,应能恢复到初始状态测试步骤 a)修改代码,可以从后台直接发送十六进制格式的消息,重新编译程序并运行; b) 发送存在一致性错误数据的消息,观察程序的处理情况 C.28消息丢包测试丢包是指发送模块发送的消息包没有到达该消息包对应的接收模块的现象测试目的是验证丢包对系统造成的影响,是否导致系统出现业务方面的错误故障产生的原因可能有消息发送模块的发送队列满、发送模块出现故障,通信线路出现故障(如误码、链路闪断等)底层驱动程序出现故障、接收队列满、协议缺陷等故障可能产生的后果有影响系统业务,控制等方面的功能,造成模块或单板之间状态不一致,系统空转但不能处理业务等采用在数据流中强制释放消息包来模拟故障丢包不应导致系统内部各模块之间或系统和与之连接的外部系统之间状态的不一致,不应导致业务或控制方面出现失效测试步骤: 在程序中加人适当的代码,从原消息流中截取通过的所有消息,然后按一定的比率强制释放这些消息,比率可以动态调整,重新编译程序; 25
GB/T28171一2011 b 运行程序,构造一些输人,使程序内部有消息流动,从小到大然后再从大到小调整丢包比率，观察系统的运行情况; 关闭丢包功能,消除丢包故障,观察系统的运行情况,检查系统的各模块状态是否一致,是否能恢复回正常运行状态 C.29软误码测试由于软件错误造成传输数据被修改的过程称为软误码软误码测试的目的是为了测试错误的消息数据在系统上层程序中的处理情况故障产生的原因可能有发送消息的模块本身出错导致发送了一个错误的消息,发送、接收消息的子系统出现错误如内存越界传输链路上发生了硬件错误、软件协议缺陷等故障现象可能有内存越界、配置数据错误,执行了错误的命令,模块之间状态不一致等采用消息中的部分数据用其他的值代替,或把其中的某些位取反来模拟故障测试中涉及的模块有足够的保护,使错误的消息得不到执行,内部各模块的状态也保持一致,不出现业务上的故障测试步骤，增加测试代码,截取消息流中的消息包按照一定的比率强制修改消息数据,重新编译程序 a 构造适当的输人,使步骤a)中的消息流中有消息经过; b 观察系统的运行情况,检查系统是否出现告警、内存越界,死机,检查内部的各相关模块状态是 c) 否一致; d)关闭误码程序,观察系统的运行情况,检查系统是否可以恢复正常运行 C.30消息延时测试延长消息传输时间的过程称为消息延时消息延时测试的目的是为了测试消息超时到达接收模块后系统运行的情况故障产生的原因可能有传输通道上发生阻塞,底层驱动程序效率不够高或者发生了故障,系统非常繁忙等故障现象可能有接收模块仍然把超时消息按正常消息处理,系统内部模块之间状态不一致等可以采用从消息通路上截取消息流,把消息发送到延时队列中去,经过一段时间后再把延时队列中的消息发送出去的方法,来模拟故障消息超时不应对程序造成严重影响,超时后程序能退回到一个恰当的状态重新开始,当超时扰动结束后,程序应能恢复正常状态测试步骤: a)修改代码,增加适当的程序,从消息通路上截取消息,把这些消息发送到延时队列中去，经过一段时间后,再把这些延时队列中的消息按原来的时间间隔发送出去,相当于每一个消息都延长了一个相同的时间延时的时间可以调节 b)重新编译程序,构造测试输人数据,使被测的消息流中有消息经过调节消息的延时时间,观察系统的运行情况 C.31消息重包测试重包是指接收模块接收到多个相同消息的现象测试目的是为了测试在接收端接收到多个相同消息后系统处理的情况 26

嵌入式软件可靠性测试方法GB/T28171-2011

1. 基本概念

嵌入式软件可靠性是指在一定条件下，系统或设备正常运行时，嵌入式软件所保持的功能正确性和稳定性的能力。

嵌入式软件可靠性测试是为了验证嵌入式软件是否能够满足用户需求并具有高可靠性而进行的测试活动。其中，用户需求包括基本功能需求、性能需求、安全需求等。

2. 测试流程

GB/T28171-2011将嵌入式软件可靠性测试分为计划、设计、执行和评估四个阶段。

2.1 计划阶段

在计划阶段，需要对测试目标、测试范围、测试资源、测试进度等进行规划和安排。同时需要编制测试计划、测试用例、测试场景等文档。

2.2 设计阶段

在设计阶段，需要根据测试计划和测试用例，编写测试脚本，并进行测试环境的搭建。测试脚本是指以程序代码的形式编写的测试用例自动化执行脚本。

2.3 执行阶段

在执行阶段，需要按照测试计划和测试用例，执行测试脚本，并记录测试结果。同时需要及时处理测试过程中发现的缺陷和问题。

2.4 评估阶段

在评估阶段，需要对测试结果进行分析和总结，编制测试报告。测试报告应包括测试结果、测试覆盖率、测试缺陷等信息。

3. 测试指标

GB/T28171-2011中定义了多项可靠性测试指标，主要包括：

错误检出率：指测试用例中的错误是否被测试工具或人员正确地检出的比率。
误报率：指测试工具或人员在测试过程中，将正确的软件行为误判成错误的比率。
漏测率：指测试用例中的错误是否被测试工具或人员漏测的比率。
可靠性指标：包括故障密度、平均无故障时间、可用性等。

这些指标能够全面反映嵌入式软件的可靠性情况，有助于保证软件质量和稳定性。