可测试性需求操作指导书

　 可测试性需求操作指导书

　目录 1 目点 ..................................................................................................................................... 2 2 需求设计操作指导 ............................................................................................................. 2 3 定义产品可测试性需求 ..................................................................................................... 3 3.1 用于硬件模块调试的可测试性需求 ................................................................... 3 3.2 用于软件模块调试的可测试性需求 ................................................................... 3 3.3 用于系统测试的可测试性需求 ........................................................................... 4 3.4 用于系统安装后上电自测的可测试性需求 ....................................................... 4 3.5 用于在线例行测试的可测试性需求 ................................................................... 4 3.6 用于制造的可测试性需求 ................................................................................... 5

　 1 目点 本模板的目的是定义产品设计的可测试性需求，要审视以前开发项目的测试经验教训以便理解产品设计中可能需要的改进。

　2 需求设计操作指导 a）确保产品可测试性需求能够在产品设计中得以体现。任何与公司规范不符之处及其原因要在产品需求规格中加以说明。

　b）早期应收集各项目组成员提出的产品需求的概念，并结合公司已往同类产品的开发和测试经验，从产品的使用情况、如何组网等实际情况出发进行分析，来提出产品的可测试性需求。

　c）如果公司内部没有相关产品的测试经验，可调查或购买竞争对手的同类产品进行分析，提出产品的可测试性需求。

　d）分析产品在实际应用中会可能出现的一些故障，分析地理位置对产品可能会产生的影响。在定义可测试性需求中必须要对各种情况进行详细考虑。

　e）为了提高产品的测试质量，需要对出现的所有故障问题进行记录、判断和分析。在测试中尽量使每一个故障能够测试或定位。

　f）设计可测试性需求，需要与 PDT 项目组各成员进行充分沟通，重点要与系统工程师进行交流，收集相关产品开发设计文档，了解最新的产品需求信息，及时对可测试性进行相应更改。

　g）在设计可测试性需求时可参考本文挡第三部分“定义产品可测试性需求”的六方面内容。在具体设计产品的可测试性需求时，可根据产品的实际情况考虑选用具体条目。如在定义中没有列出需求，设计人员可自行增加需求。总之，在产品中定义可测试性需求时需要慎重。过多的考虑可测试性需求可能会增加产品的成本和开发时间 h）对可测试性需求需要进行优先级排序，方便系统设计工程师进行判定和设计； i）设计可测试性需求要考虑节约成本的预测（如果可能的话）； j）完成需求设计后需要与系统工程师进行沟通，对可测试性需求的内容和优先级进行确认。

　 k）指派扩展组 PDT 测试成员与相关的研发工程师和开发人员协作，确保可测试性需求得到实施。

　l）进行跟踪并监控研发认同的可测试性需求的进展。

　3 定义产品可测试性需求 3.1 用于硬件模块调试的可测试性需求 a）

　对各个模块、单板上的灯闪烁定义的不同的含义，方便从灯的状态中看出故障原因。

　b）在单板上建立测试点，能够方便测试各部分电源等功耗。

　c）

　提供告警监测功能，能够对系统进行故障判断； d）单板全部使用标准的数据接口，满足与其它设备的对接和兼容性测试. e）

　系统业务接口需要具备对测试仪器的兼容性； f）

　器件尽量使用能够提供自检、环回的功能，以便于进行测试； g）设备提供在线、离线等故障的诊断、隔离和保护功能，并能够进行跟踪和记录； h）尽量提供统一的本地调试串口和网口各一个，以便于调试； i）

　提供测试诊断信息的存储功能；

　3.2 用于软件模块调试的可测试性需求 a）

　提供可以和单片机串口通信的测试平台，可通过串口读取信息进行调试； b）底层软件增加可视化测试平台，可直接修改寄存器内容等，以方便发生故障时判断问题所在； c）

　网管中增加数据校验出错报告功能； d）提供查看底层内存测试方法，以便知道设备内存是否有效释放； e）

　提供统一的测试控制台； f）

　提供对业务接口环回控制，进行环回和解除； g）提供系统版本监控上报功能（包括硬件、软件版本）

　h）提供统一的系统、单板测试及交互控制命令集；

　 3.3 用于系统测试的可测试性需求 a）FPGA、CPU 程序模块化，提高可移植性，减少重复测试； b）板卡上如有各种选择项，增加简洁而明白的注释，注意方向的一致性； c）

　各种测试点形状、位置、规格统一化； d）提供调试控制命令，在测试时将执行的过程和结果信息进行输出； e）

　提供对业务通道协议/消息的监控上报功能； f）

　提供对业务通道的监测功能； g）提供软、硬件版本的查询功能；提供软件加载监控，可对本端、远端进行升级和维护； h）

　能够把各种告警输出到网管进行记录，便于网管统计；

　i）

　提供关键器件和模块的监测，如发生错误，可上报进行复位； j）

　提供远程诊断功能，便于测试设备的运行情况； k）提供对业务通道协议/消息的监控上报功能。提供单板业务和信令状态监测，便于记录、分析信令情况； l）

　提供系统环境监控上传网管功能，便于随时监控； m）

　提供系统内部资源监控维护，如温度、工作电压等系统资源运行情况；

　3.4 用于系统安装后上电自测的可测试性需求 a）

　关键芯片的自检； b）处理器及外围存储器的自检； c）

　存储器的自测试； d）关键芯片、套片的自测试； e）

　业务通道的自测试； f）

　控制通道的自测试；

　3.5 用于在线例行测试的可测试性需求 a）

　提供常规测试的定时控制执行，如每天、每月定时执行； b）网管可记录日志并能够进行统计、输出；

　 c）

　提供对设备的例行自测试，以确认通信情况是否良好； d）提供对各单板、各主要功能模块的例行自检，自检结果可上报和保存； e ）

　提供对运行中暂未使用的控制通道的例行测试；

　 3.6 用于制造的可测试性需求 a）

　提供生产单板的批量测试要求，方便单板的批量生产和检测； b）根据测试覆盖率的分析来调整测试探针接触的测试点数量和位置； c）

　测试点有 T32 型、T40 型及 Drill hole 三种； d）PCB 上的 ICT 测试点应在 PCB 板的焊接面； e）

　两个单独测试点的最小间距为 60mils(1.5mm) ； f）

　PCB 的对角上要设计两个 125mils 的非金属化的孔作为 ICT 测试定位； g）每个网络在焊锡面提供一个测试点； h）测试点密度最高为每平方英寸 30 个点（平均数）/每平方厘米 4~5 个点； i）

　每根测试针最大可承受 2A 电流，每增加 2A，对电源和地都要求多提供一个测试点； j）

　每 5 个 IC 应再提供一个地线点，地线点要求比较均匀分布在单板上； k）测试点到 PCB 板边的间距应大于等于 125mll/3.175mm； l）

　焊接面的条码、标签、丝印、拉手条等不要挡住测试点；

推荐访问:指导书 性需求 操作