硬件测试及方案定义技术word版本.doc

硬件测试及方案定义技术

精品文档
课程大纲
硬件测试技术
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
2005年9月
硬件测试概述
1、硬件测试的概念
测试是为了发现错误而执行操作的过程
测试是为了证明设计有错，而不是证明设计无错误
一个好的测试用例是在于它能发现至今未发现的错误
一个成功的测试是发现了“至今未发现的错误”的测试
硬件测试概述
2、硬件测试的目的
测试的目的决定了如何去组织测试。如果测试的目的是为了尽
可能多地找出错误，那么测试就应该直接针对设计比较复杂的部分或
是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有
一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经
常用到的商业假设。
综合评估，决定产品的测试方向！
2005年9月
2005年9月

收集于网络，如有侵权请联系管理员删除
硬件测试概述
3、硬件测试的目标——产品的零缺陷
关注点：产品规格功能的实现，性能指标，可靠性，可测试性，易
用性等。
实现的保障：产品的零缺陷构筑于最底层的设计，源于每一个函
数、每一行代码、每一部分单元电路及每一个电信号。测试就是要排
除每一处故障和每一处隐患，从而构建一个零缺陷的产品。
MTBF不是计算出来的，而是设计出来的。
硬件测试概述
4、硬件测试的意义
测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误
的分布特征，可以帮助项目管理者发现当前设计过程的缺陷，以便改
进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善
测试的有效性。
没有发现错误的测试也是有价值的，完整的测试是评定测试质量的
一种方法。
2005年9月
2005年9月
硬件测试概述
5、目前业界硬件测试的开展状况
随着质量的进一步要求，硬件测试工作在产品研发阶
段的投入比例已经向测试倾斜，许多知名的国际企业，硬
件测试人员的数量要远大于开发人员。而且对于硬件测试
人员的技术水平要求也要大于开发人员。
硬件测试概述
6、硬件测试在企业价值链中的地位
——采购——研发——测试——生产——销售——
测试是每项成功产品的必经环节
2005年9月
2005年9月

硬件测试概述
7、硬件测试对公司形象和公司发展的重要性
硬件测试是评估产品质量的重要方法
产品质量是公司的信誉和品牌象征
公司的信誉和质量决定了公司的发展前景
硬件测试概述
8、硬件测试的一般流程和各阶段点的输出文件
2005年9月
2005年9月
课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
测试前准备
1、正规检视
硬件设计审查
原理图检视
PCB检视
发现硬件设计原理缺陷
发现成本浪费问题
发现降额不规范设计
发现布局和布线的缺陷
发现EMC等专项设计缺陷
2005年9月

测试前准备
2、正规检视的流程
检视专家的确定
评审专家预检视
检视问题反馈整理
检视会议召开
检视问题确认，解决
检视问题跟踪
测试前准备
3、FMEA（故障模式影响分析）
分析系统中每一产品所有可能产生的故障模式及其
对系统造成的所有可能影响，并按每一个故障模式的严重
程度、检测难易程度以及发生频度予以分类的一种归纳分
析方法。
2005年9月
2005年9月
测试前准备
FMEA的意义
能帮助设计者和决策者从各种方案中选择满足可靠性要求的最佳方
案；
保证所有元器件的各种故障模式及影响都经过周密考虑；
能找出对系统故障有重大影响的元器件和故障模式，并分析其影响
程度；
有助于在设计评审中对有关措施（如冗余措施）、检测设备等作客
观的评价；
测试前准备
FMEA的意义（续）
能为进一步定量分析提供基础；
能为进一步更改产品设计提供资料；
能为产品可测试方案提供基础材料；
能为技术支援人员提供维修指南；
为基于故障模式的测试提供依据。
2005年9月
2005年9月

测试前准备
FMEA的层次
信号级：对接口信号或某些特殊器件的分析
器件级：对系统内功能模块的可靠性分析
系统级：对系统的整体可靠性分析
测试前准备
严酷度
在某些系统中，最终影响的严重程度等级又称为严酷度（有时也
称为严重度，系指故障模式所产生后果的严重程度）类别。
严重程度等级（严酷度类别）定义应考虑到故障所造成的最坏的
潜在后果来确定。
严酷度的定义是FMEA的前提和基础，有了共识的严酷度才可以保
证FMEA的顺利开展和问题的落实。
2005年9月
2005年9月
测试前准备
功能和可靠性框图
测试前准备
2005年9月
2005年9月

测试前准备
环境定义
测试前准备
风险分析
风险分析的目的是按每一故障模式的严重程度及该故障模式发生
的概率所产生的综合影响对系统中的产品划等分类，以便全面评价系
统中各种可能出现的产品故障的影响，它是一种相对定量的分析方
法，通常借助图形工具（如矩阵图）来辅助分析。
风险分析常用的方法有两种，即风险优先数（Risk Priority
Number，RPN）法和危害性分析（Criticality Analysis）法
前者主要用于汽车等民用工业领域，后者主要用于航空、航天等
军用领域。在进行风险分析时可根据具体情况选择一种方法。
2005年9月
2005年9月
测试前准备
F
M
E
A
分
析
步
骤
和
要
点
确定范围
确定功能
失效模式
潜在影响
严酷度
分类
潜在原因
发生频度
控制措施
探测率
RPN
整改措施
如何定义严酷度分类：
对操作者危害最高
失效概率：
每小时，每班次，每天，每星期。。。
潜在影响：
停机：损坏，装备与调整，试机损失
报废：缺陷部件，工具类
安全：
找原因：
1以前FMEA 分析
2失效日志
3接口矩阵（物理干涉，能量传递，物
流，信息转移）
4保证书
5专题研究报告
6测试报告
7现场服务报告
测试前准备
FMEA分析表格
编
号
器件 所属 失
名称 功能 效
单元 率
失效 失效 局部 对功 对系 严
模式 比例 影响 能单 统的 酷
元的 最终 度
影响 影响
已有
的检
测方
法
已有 建议 备
的补 改进 注
偿措 措施
施
2005年9月
2005年9月

测试前准备
4、故障处理
故障检测
故障定位
故障隔离
故障恢复
测试前准备
故障检测
故障检测是指明确到故障已经发生的过程，是故障处理流程的前
提。
这里提到的检测一般是指系统在故障发生后的自动的检测，一般
不需要人进行操作。
在进行故障检测的时候需要结合软、硬件故障检测方法。
某些故障可能需要多次检测确认，避免进行误告警和误操作
2005年9月
2005年9月
测试前准备
故障定位
故障定位是指将故障定位到现场最小可更换单元的过程，是故障
维修的基础。
故障定位的目的是为了便于维修工程人员进行现场的故障维修和
返修件的故障处理。
测试前准备
故障隔离
故障隔离一般是将故障限定到可更换单元内部的过程。故障隔离
的目标是将故障能够限定在越小的功能单元。
故障隔离是为了将故障的影响范围限制在尽可能小的范围之内。
故障是无法避免的，如何将故障产生的影响降到最低，是故障隔
离所要考虑的关键。
2005年9月
2005年9月

测试前准备
故障恢复
故障恢复是将系统的功能状态恢复到故障发生前状态的过程，是
客户最关心的也是系统稳定运行的关键步骤。
常用的故障恢复手段有复位、冗余倒换、重发等。
故障恢复尽量需要做到自动进行，以降低对用户的影响。
测试前准备
5、测试计划
描述该测试计划所应达到的目标如下（可依据项目的实际要求做
适当调整）：
所有测试需求都已被标识出来；
测试的工作量已被正确估计并合理地分配了人力、物力资源；
测试的进度安排是基于工作量估计的、适用的；
测试启动、停止的准则已被标识；
测试输出的工作产品是已标识的、受控的和适用的。
2005年9月
2005年9月
测试前准备
测试计划的内容
测试计划一般应该包含一下的内容：
测试对象，明确版本，范围，任务划分
角色和职责
测试和不被测试的特性原因
测试通过与否的标准
测试任务安排
测试结束的交付件
工作量评估
测试前准备
6、测试用例
测试用例更多的是需要描述测试方法，测试步骤，测试的预期效
果，需要达到的指标。需要更加详细的对每一条测试项目进行描述。
测试用例是直接用来指导测试的，所以对测试项目的描述需要更
具体，更便于参考操作。
2005年9月
2005年9月

测试前准备
测试用例的一般格式
测试用例编号
测试项目（模块或单元）
测试子项目（子项目描述）
测试级别（必测、选测、可测）
测试条件（环境、仪器等相关要求）
测试步骤和方法（具体细致的操作方法）
应达到的指标和预期效果
备注
测试前准备
7、测试需求的来源
一切测试的需求都来自于产品设计的规格，规格来自于用户的需求。
因此我们的测试是针对产品规格的测试。具体可以从以下几方面进行
考虑：
产品设计功能
根据功能的实现，分别对实现该功能的各个环节进行测试，从硬件、
单板软件、高层软件到用户界面，只有各个环节都畅通无阻，才能保
证该功能的正常实现。
可靠性
备份、倒换、插拔、互助、自愈等
2005年9月
2005年9月
测试前准备
测试需求的来源（续）
指标性能需求
指标包括电接口指标、光接口指标、时钟指标、传输指标和指标容
差，
指标一般都有相关的标准可查。性能一般可从容量、处理能力、容限
等方面去考虑，一般是测试异常输入条件下的单元、模块、系统处理
情况。性能测试的异常条件主要是指边界条件、异常条件及故障相关
性。
组网
组网需求：电信网组网、异种厂商的互联
测试前准备
测试需求的来源（续）
应用环境
应用环境一般可从以下几个方面考虑：
高温、低温、高低温交变、盐雾、湿热、防尘
接地、电源、震动、冲击、存储、运输
电磁兼容性
断电恢复性
2005年9月
2005年9月

课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
硬件测试的种类与操作
1、测试设计
测试并不是简单意义上的一些测试操作，在测试前需要有详细的设
计，周密的策划，测试是一项高难度的工作。
测试设计概念的范围很广，大致可以分为以下几类：
设计测试平台，用此测试平台能进行通用项目的测试，或是进行能
用此测试平台作一类测试。
设计测试工具，设计测试软件。
设计测试装备。
设计测试用例，测试方法。
2005年9月
硬件测试的种类与操作
测试设计的好处
良好的测试设计和有效测试工具可减少重复低效的劳动
有效地开发利用测试工具可使测试更深入、更全面
有些复杂的测试只能依靠测试工具进行自动测试
在测试中经常进行测试设计是提升技术水平的有效手段
我们在做测试工作时，不能因循守旧，需要时刻考虑如何改进我们的
测试效果，提高我们的测试效率，在测试点上进行深入研究，开发测
试工具，最终使我们的所有点的测试达到自动化。
硬件测试的种类与操作
良好的测试设计同样也是节约测试成本的手段
现在的测试工作中，经常会遇到一些无法在实验室模拟的情况，可能
在实际现场也无法模拟，并且如果要模拟所花的代价很大，如满配
置、最大负荷的情况，而这些项目的测试通过与否是检验系统性能的
重要手段。这个测试任务便给我们提出了编写测试软件模拟大负荷情
况的要求。不但实现和自动化，而且大幅度的节约了成本。
2005年9月
2005年9月

硬件测试的种类与操作
2、基础指标测试
信号质量测试
基本的信号质量测试是通过测试单板上的各种信号质量，根据信
号种类的不同，用不同的指标来衡量信号质量的好坏，并对信号质量
的分析，发现系统设计中的不足。
开发人员根据已有的信号质量和时序调试和测试方面的规范和指
导书，在单板调试阶段完成对单板信号质量的全面测试并完整记录结
果。
测试仪器——示波器
硬件测试的种类与操作
时序测试
对板内信号时序进行调试，验证信号实际时序关系是否可靠，是
否满足器件要求和设计要求；分析设计余量，评价单板工作可靠性。
开发人员根据已有的信号质量和时序调试和测试方面的规范和指
导书，在单板调试阶段完成对单板时序（包括逻辑外部时序）的全面
调试和测试。
测试仪器——示波器，逻辑分析仪
2005年9月
2005年9月
硬件测试的种类与操作
3、功能测试
功能测试是根据硬件详细设计报告中提及的功能规格进行测试，
验证设计是否满足要求。
功能测试是系统功能实现的基本，是需要严格保证测试通过率
的。如被测对象与其规格说明、总体/详细设计文档之间存在任何差
异的均需要详细描述。
一般包含，电源、CPU、逻辑、复位、倒换、监控、时钟、业务
等。
硬件测试的种类与操作
4、性能测试——容限测试
指使系统正常工作的输入允许变化范围。容限测试的目的是通过
测试明确知道我们的设备到底在什么样的条件范围下能够正常工作，
薄弱环节到底在哪里。
能否发现和验证器件降额的问题，系统工作允许范围内的临界点
上的性能。
2005年9月
2005年9月

硬件测试的种类与操作
5、容错测试——FIT
指通过冗余设计等手段避免、减小某些故障对系统造成的影响以
及在外部异常条件恢复后系统能够自动恢复正常的能力。容错测试的
目的是要检验系统对异常情况是否有足够的保护，是否会由于某些异
常条件造成故障不能自动恢复的严重后果。
容错测试的一般方法就是采用故障插入的方式，模拟一些在产品
使用过程中可能会产生的故障因素，进而考察产品的可靠性及故障处
理能力的一种测试方法。
硬件测试的种类与操作
5、容错测试——FIT
容错测试项目的来源主要是通过FMEA获得，是验证FMEA分析结果
的一种手段。而且某些通过FMEA分析无法准确获得结论的项目也要通
过FIT来进行模拟。
容错测试还包括的另外一个主要内容就是操作方面的，主要模
拟在用户使用不当的时候系统的容忍错误的能力。
2005年9月
2005年9月
硬件测试的种类与操作
5、容错测试——FIT
容错测试一般允许出现一些功能异常，但是不能出现功能丧失或
故障扩散等严重的安全隐患。
常用的故障插入测试方法有时钟拉偏、误码插入、电源加扰
等，，常用测试工具有些是专用的，有些是内部开发的。
通过容错测试，还可以确定在产品的实际应用过程中哪些错是易
产生的，哪些错是可以避免的，以尽量减少损失。
硬件测试的种类与操作
6、长时间验证测试
由于电子类产品很多是需要长时间运行的，所以进行长时间的验证
测试是很有必要的
某些器件应用不当的设计，更容易在长时间的运行中，才会显露出
来。
系统的散热能力也只有在长时间的大功率运行时才容易暴露。
长时间的运行才容易发生某些被忽略的偶然因素，容易发现某些潜
在问题。
2005年9月
2005年9月

硬件测试的种类与操作
6、长时间验证测试
长时间测试不仅对于系统而言，在进行单元测试和集成测试时，
对于每一个功能模块均需要进行长时间的功能验证。
长时间的验证具体的时间把握同产品的实际使用情况相关，对于
通信产品系统，一般建议测试时间要达到一星期。对于每一个功能模
块的时间要求一般要达到两天。
硬件测试的种类与操作
7、一致性测试
一致性测试是指将不同批次的产品分别取样，进行测试验证，考
察产品功能和性能方面的一致性的测试
为了验证不同生产批次的产品质量和不同批次器件的质量，是否
具有较高的一致性，是否能够满足产品的功能和使用条件要求。
2005年9月
2005年9月
硬件测试的种类与操作
7、一致性测试
测试要点
测试至少要包含3次活以上不同器件批次和生产批次的产品
测试项目要包含所有的功能测试项目，和重要的信号质量和时序等
项目
重点需要验证长时间的稳定性是否一致
如果具备条件，需要验证在环境条件变化时（如高温环境），各样
品的一致性能。
硬件测试的种类与操作
8、可靠性数预计
这里的可靠性数据一般包含MTBF（平均故障间隔时间）、
MTTR（平均修复时间）、失效率、可用度、返修率等。
可靠性数据预计的基础是FMEA分析，通过分析获得。
2005年9月
2005年9月

硬件测试的种类与操作
可用度（A-availability）：
产品在一未知时刻，需要执行任务时，处于可工作或可使用状
态的概率。
硬件测试的种类与操作
平均拆卸间隔时间（MTBR-mean time between removals)
系统寿命单位总数与从该系统上拆下的产品总次数之比。
平均修复时间（MTTR-mean time to repair）：
是在规定的时间内，修复性维修所造成的累积工作时间除以在同
一时间内所完成的修复维修活动总数得到的结果。
拆卸时间＋定位时间＋修理时间＋安装时间
平均故障间隔时间（MTBF-mean time between failure）：
指相邻失效间隔工作时间的平均值。
平均失效前时间（MTTF-mean time to failure） ：
表示观察到下次失效的期望的时间。
2005年9月
2005年9月
硬件测试的种类与操作
可靠度
R（t）：
硬件测试的种类与操作
可用度A(Availability)
产品工作时间与总时间之比。若不考虑产品的储存时间和闲置时
间，则 ：
A=MTBF/（MTBF＋MTTR）
在规定的条件下，规定的时间内，完成规定功能的概率。
失效率（λ）
失效率＝1/MTBF
单位Fits
1Fits＝1×10－9 1/h
可用度A
可靠性
维修性
2005年9月
2005年9月

硬件测试的种类与操作
返修率
年返修率＝1/MTBF×8760
硬件测试的种类与操作
练习
系统M的器件使用情况如下表，请计算M的MTBF，A和年返修率
注：MTTR=1小时
器件种类
电阻
电容
电感
接插件
集成电路
其他
器件数量
150
200
25
3
5
10
单个器件失效率（单位：Fits）
2
2
6
50
400
100
2005年9月
2005年9月
硬件测试的种类与操作
器件种类
电阻
电容
电感
接插件
集成电路
其他
总计
器件数量
150
200
25
3
5
10
单个器件失效率（单
位：Fits）
2
2
6
50
400
100
失效率总和
300
400
150
150
2000
1000
4000
课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
MTBF=1/4000× 109 =250000小时＝28.54年
A＝250000/（250000＋1）＝99.9996%
返修率＝1/250000×8760＝3.5％
2005年9月

硬件测试的级别
1、黑盒测试与白盒测试
黑盒测试注重于测试功能性需求，将测试对象看成一黑盒，对外
只有输入、输出。
设计黑盒测试用例只对于表现在外接口的各种输入，对不同的输入，
测试其表现出来的输出，从而达到测试功能的目的。
白盒测试主要测试模块内部的逻辑细节，各个独立的逻辑路径，
黑盒测试不管多么全面，都可能忽略这些错误。
设计白盒测试用例需要构造到信号、逻辑或消息级。
硬件测试的级别
具体测试时结合使用
白盒测试与黑盒测试各有优势，设计测试用例时应结合使用
举例：
对于开关电的测试，一般采用黑盒测试，设计的测试用例为：快速
上、下电，频繁上、下电等；
对于时钟电路、锁相环等的测试，就需要设计白盒测试用例，如锁相
范围、静态相差、固有抖动、抖动容限等。
2005年9月
2005年9月
硬件测试的级别
2、测试的级别
硬件测试按照系统的复杂程度，一般分为：
单元测试——针对独立功能单元的测试
集成测试——针对具有一定集成度的功能子系统的测试
系统测试——针对完整的系统整体的测试
硬件测试的级别
分层测试的行为方式
测试不能仅仅在一个层次进行，而是应该打破层次之间的界限问题出
现较多的地方一般都是在层与层之间的配合上，如硬件逻辑与单板软
件的配合，单板软件与高层软件的配合。
按照子系统来划分是打破物理层次的较好的方法。
如一个系统中的时钟系统，它可能与系统中的各块单板都相关，并可
能贯穿高层软件、底层软件及硬件。对这个时钟系统测试需要将其首
先划分为各个子模块，对各模块进行测试，然后将其贯穿为整个时钟
系统进行测试
2005年9月
2005年9月

硬件测试的级别
3、测试项目的等级划分
表明该用例的重要性。用例的重要性并不对应用例可能造成的后
果，而是对应用例的基本程度，一个可能导致死机的用例未必是高级
别的，因为其触发条件可能相当生僻。测试用例的级别分4级：
级别“1”：基本。该类用例涉及系统基本功能，用于版本提交时作
为“版本通过准则”。如存在不通过的项目时可考虑重新提交版本。
级别“2”：重要。该类用例涉及单个版本特性，例如某新业务的使
用情况，可定义为2级用例。2级用例所对应的问题可作为重要或一般
问题提交问题报告单，视具体情况决定是否进行更高级别的反馈。
硬件测试的级别
测试项目的等级划分（续）
级别“3”：详细。该类用例仅影响某单项功能的某一细节方面。例
如某新业务的登记和使用正常，但和另一个新业务发生不应有的冲
突。有关性能、极限等方面的测试可归入3级用例。有关用户界面的
基本规范等方面的测试可归入3级用例。
级别“4”：生僻。该类用例对应较生僻的预置条件和数据设置。虽
然某些测试用例发现过较严重的错误，但是那些用例的触发条件非常
特殊，仍然应该被置入4级用例中。 有关用户界面的优化等方面的测
试可归入4级用例。
2005年9月
2005年9月
课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
可靠性测试
1、EMC电磁兼容性
电磁骚扰测试
• 辐射骚扰测试（RE）
• 传导骚扰测试（CE）
• 谐波电流骚扰测试（Harmonic）
• 电压波动与闪烁测试（Fluctuctions and flicker）
2005年9月

可靠性测试
EMC电磁兼容性
电磁敏感度测试
• 射频电磁场辐射抗扰度测试（RS）
• 传导骚扰抗扰度测试（CS）
• 电快速瞬变脉冲群抗扰度测试（EFT/B）
• 静电放电抗扰度测试（ESD）
• 电压跌落、短时中断抗扰度测试（DIP/interruption）
• 工频磁场抗扰度测试（PMS）
• 浪涌抗扰度测试（SURGE）
可靠性测试
EMC电磁兼容性
• 电力线感应测试
• 电力线接触测试
2005年9月
2005年9月
可靠性测试
2、安规
输入测试
耐压测试
接地连续性测试
元件异常测试
TNV电路和地的隔离测试
电容放电测试
TNV电路和其它电路的隔离测试
温升测试
接触电流测试
异常温升测试
激光辐射测试
TNV电路电压测试
单板安规审查
可靠性测试
3、环境试验
一般电子类产品涉及的环境测试有以下种类：
气候类
低温贮存
低温工作
热测试
交变湿热
高温极限试验
高温贮存
高温工作
温度循环
低温极限试验
噪声测试
2005年9月
2005年9月

可靠性测试
环境试验
机械振动类
包装随机震动试验
包装跌落
模拟包装运输试验
随机振动
工作正弦震动
地震试验
包装碰撞试验
包装冲击
实地跑车
冲击试验
工作冲击试验
可靠性测试
环境试验注意事项
整个系统根据实际情况进行接地，否则不能模拟实际使用情况。
保持测试仪器的良好接地，以保证测试人员安全。
对于耐受性测试，试验工程师必须在试验现场看守，以防止试验
故障导致的意外事故。并且必须在试验区加危险警告标识。
2005年9月
2005年9月
可靠性测试
环境试验时产品工程师的职责
完成测试计划中产品功能部分的描述。
准备和搭建系统的工作环境。
协助制定试验判据。
对测试不通过项提出解决措施并实施。
每天试验结束后切断系统的电源，并清理试验场地的环境。
试验结束后清理实验环境。
可靠性测试
环境试验时环境工程师的职责
完成测试计划中测试项部分的描述。
准备和搭建EUT的测试环境。
和产品工程师制定试验判据。
操作试验仪器。
对测试不通过项提出解决措施，并协助产品工程师实施。
给出实验结果判断并输出实验报告。
创建测试计划和测试报告评审及归档。
2005年9月
2005年9月

可靠性测试
4、HALT
HALT（Highly Accelerated Life Test）的全称是高加速寿命
试验，是一种试验方法（思想），采用的环境应力比加速试验更加严
酷。
主要应用于产品开发阶段，它能以较短的时间促使产品的设计
和工艺缺陷暴露出来，从而为我们做设计改进，提升产品可靠性提供
依据。
可靠性测试
HALT的基本特点
试验前无法给定环境应力值；无依据标准；
以加速暴露缺陷为目的；
直接有助于提高产品可靠性；
结论是发现的缺陷和改进方法。
2005年9月
2005年9月
可靠性测试
HALT试验的优点
试验时间短；
相对可靠性鉴定试验费用更低；
效果明显，快速发现设计和工艺的局限性；
缩短开发时间和费用；
评估产品更改的有力支撑工程工具
可靠性测试
HALT试验施加的应力和顺序
一、温度步进应力
低温步进应力
高温步进应力
二、快速温度循环应力
三、振动步进应力
四、组合环境应力
2005年9月
2005年9月

可靠性测试
HALT试验失效发生处理方式
暂停试验，记录失效模式和应力水平
采用适当的隔离方法定位失效部分
记录失效位置
分析根本失效原因
(可能需进行深入的调查和失效分析)
进行暂时性修复
继续HALT暴露其它问题
课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
2005年9月
测试问题解决
1、测试问题的危害确认
站在用户的角度看待测试问题，小问题也是问题。
产品的最终使用者是用户
对于一个疑点是否属于问题，最有发言权的是用户
测试工程师应该站在用户的角度来看待每一个小问题，假设用户看
到问题表现后的反应
测试问题解决
2、测试问题的界别划分
致命：引起系统死机或系统崩溃的问题
严重：引起系统某一功能失效且不能简单恢复（如插拔单板）的
问题
一般：引起系统某一功能失效但可简单恢复或较难重现的问题
提示：从操作或维护的角度发现的问题或建议
2005年9月
2005年9月

测试问题解决
3、测试问题的种类确认
可重现问题
每次重现（每次测试故障现象均会重复发生的问题）
偶尔重现（不定期出现的问题，暂时没有发现触发条件）
不可重现问题
问题只出现过一次，在后续的测试过程中没有再次发生
测试问题解决
4、测试问题的定位
定位方法
自动定位——系统通过自动检测等手段，可以直接产生相关告警
人为定位——指通过人的现场观察或是借助一定的测试手段可以即可
定位。
不可定位——指在现场无法定位，需要借助专用的测试工具，或是专
业的人员才有可能定位的问题
恢复方式
自动恢复、手动恢复、不可恢复（定义参考定位方法）
2005年9月
2005年9月
测试问题解决
5、测试问题反馈方式和注意事项
测试工程师发现的任何问题都应该以问题反馈单的形式反馈
尽量不要测试人员直接协调开发人员解决问题，如果是为了保留测
试环境或解决某些难以重现的问题，可以先通知开发人员了解故障现
象，同时需要尽快补交问题反馈单。
问题反馈时应尽量将故障现象、触发条件、环境因素、组网情况等
信息描述清楚，以便问题的处理
养成保留现场的习惯。
测试问题解决
6、测试问题跟踪和解决流程
测试工程师提交问题反馈单
测试经理审批，并转给相应处理部门经理
受理部门经理审批，转给开发工程师处理
开发工程师处理问题，并返还受理部门经理审批
返还测试经理审批
测试经理返回测试工程师
测试工程师回归测试
2005年9月
2005年9月

测试问题解决
问题反馈注意事项
流程中间的任何环节都可以通过正当的理由返回上一级处理
禁止跨流程，跨人员审批
每个环节都应该有相应的时间要求，不允许无故拖延时间
测试人员在进行回归测试时要严格把关，问题处理流程不可以随便
关闭
流程处理过程中对事不对人，要按照事实说话
问题报告单应该最为测试人员测试绩效考核的一部分
课程大纲
硬件测试概述
测试前准备
硬件测试的种类与操作
硬件测试的级别
可靠性测试
测试问题解决
测试效果评估
硬件测试参考的通信技术标准
测试规范制定
测试人员的培养
2005年9月
2005年9月
测试效果评估
1、测试报告
测试报告一般需要包含以下内容：
测试时间、地点、人员
测试环境
测试数据统计
• 测试人员等工作量统计
• 测试项目通过情况统计
• 缺陷统计
• 覆盖率统计
测试效果评估
测试评估
• 测试活动评估
总结经验教训，评估工作量
• 测试对象评估
给出被测对象的的客观评价
• 测试设计评估
描述对测试设计的改进建议和理由
遗留问题
2005年9月
2005年9月

测试效果评估
2、评审——评审角色
开发工程师
评审前需要提供相关的设计文档《总体设计方案》、《详细设计
报告》
评审会议做简单的原理和功能介绍
评审完成后，根据评审会议确认的问题做相应的更改
测试效果评估
2、评审——评审角色
硬件项目经理
明确设计责任，将评审会议确定的问题按照指责分配给相关的责
任人
公开评审会完成后，确认并保证会议上的问题做了妥善解决
2005年9月
2005年9月
测试效果评估
2、评审——评审角色
硬件测试工程师
介绍测试过程和采用的测试方法
阐述测试过程发现的问题
详细描述测试问题发生的条件，问题现象
整理汇总测试问题，出具《测试报告》
评审会议结束后，跟踪问题的后续解决情况，进行回归测试
测试效果评估
2、评审——评审角色
硬件项目经理
对测试问题进行确认
组织评审会议
确定评审专家
汇总评审意见
不放过任何一个可能的问题，站在测试的立场坚持一切可能的问
题，不随便放过一个可能存在的问题，为测试工程师撑腰
2005年9月
2005年9月

测试效果评估
2、评审——评审角色
评审专家
在问题后续阶段结束时，即本次评审完成时，将评审结果归档
正确归档组织者和开发者提供的归档资料
测试效果评估
2、评审——评审角色
归档员
提前一天反馈评审意见
对测试问题进行确认
准时参加评审会议，提出有针对性，有价值的评审意见
给出问题的建议解决方法
2005年9月
2005年9月
测试效果评估
2、评审——评审原则
开发和测试人员介绍长度10--20分钟为宜，评审人员只听，不要打
断设计人员介绍。
资料袋下发到评审专家不少于5个小时
所有的评审人员都必须要参加，如有特殊情况，要指定同等资历的
专家加入
评审需要建立打分机制，根据评审专家的意见数量和质量进行打
分，分数同评审专家的任职资格和考评相结合
测试效果评估
2、评审——评审效果
测试问题得到及时的解决
产品质量得到提高
测试问题和经验得到收集和积累
为后续类似产品提供测试等经验
2005年9月
2005年9月

测试效果评估
3、经验的总结
测试经验总结是我们共同的财富，也是我们提高自身的手段。经验总
结的形式：
审查规范
测试规范
checklist
案例
技术报告
总结可避免重复劳动，平时工作中需要有总结的意识。
测试效果评估
4、测试经验的获取
从测试过程中获取
直接
印象深刻
深入
正确程度？
从问题攻关中获取
直接
印象深刻
深入
数量少
从他人的经验总结中获取
较深入
数量大
间接
大量的经验应来自于获取他人的测试经验并加以自己实践的验证，从
而加深印象，成为自己的经验。
2005年9月
2005年9月
测试效果评估
如何增长测试经验
测试过程中深入分析，挖掘到本质
积极参与问题攻关
多从网上获取他人经验
多与他人进行技术交流
参与测试技术的开发
增长测试经验即提高技术能力，优秀的测试工程师肯定可以是优秀的
开发工程师。
测试效果评估
5、遗留问题处理
遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解
决的测试问题。测试报告时已经得到解决，并已经过回归验证的测试
问题不记入其中。
遗留问题的划分需要非常谨慎，必须是长时间无法重现的问题，
或者由于某些特定的因素（成本等），且问题并不严重的才可以通过
流程中各环节人员的认可被列为遗留问题。
遗留问题需要定时跟踪清理，且对于一款产品需要制定一个遗留
问题的数量限制。
2005年9月
2005年9月

测试效果评估
遗留问题处理
即使是遗留问题也要明确跟踪的责任人
遗留问题是可以在后续被重新激活的，一旦问题重现或者条件允
许，需要重新激活解决
测试效果评估
6、市场规模应用跟踪
产品推向市场后需要持续跟踪产品的质量问题，并建立相应的流
程，所有在市场上出现的问题必须有专人跟踪，并对照测试报告，以
确定是否是试验室出现过的问题，分清问题种类：器件品质问题、遗
留问题、发现但未解决问题、未发现问题。并明确原因，对于各类问
题要明确责任人，尽量避免实验室漏测，并同相关人员的绩效考核建
立关系。
2005年9月
2005年9月
测试效果评估
7、测试覆盖率统计