产品可测试性需求分析

产品可测试性需求报告

文档修订记录

目录

1目的.................................. 错误!未指定书签。2范围.................................. 错误!未指定书签。3术语.................................. 错误!未指定书签。4引用文件.............................. 错误!未指定书签。5测试文档.............................. 错误!未指定书签。

5.1测试参考文档 ...................... 错误!未指定书签。

5.2测试提交文档 ...................... 错误!未指定书签。6测试安排和计划........................ 错误!未指定书签。

6.1测试重点.......................... 错误!未指定书签。

6.2测试难点.......................... 错误!未指定书签。

6.3测试计划.......................... 错误!未指定书签。7测试资源.............................. 错误!未指定书签。

7.1人力资源.......................... 错误!未指定书签。8功能测试方案.......................... 错误!未指定书签。

8.1XXX功能........................... 错误!未指定书签。

8.1.1功能测试需求分析

错误!未指定书签。

8.1.2主要功能描述

错误!未指定书签。

8.1.3测试点分析

错误!未指定书签。

8.1.4测试所需工具

错误!未指定书签。

9性能测试方案.......................... 错误!未指定书签。

9.1XXX性能........................... 错误!未指定书签。

9.1.1性能测试需求分析

错误!未指定书签。

9.1.2主要性能指标

错误!未指定书签。

9.1.3测试点分析

错误!未指定书签。

9.1.4测试所需工具

错误!未指定书签。

10可靠性试验方案........................ 错误!未指定书签。

10.1可靠性试验需求分析

错误!未指定书签。

10.2可靠性试验参照标准

错误!未指定书签。

10.3可靠性试验分析

错误!未指定书签。

11环境实验方案.......................... 错误!未指定书签。

11.1环境实验需求分析

错误!未指定书签。

11.2环境实验参照标准

错误!未指定书签。

11.3环境实验分析

错误!未指定书签。

12附录.................................. 错误!未指定书签。

1 目的

描述本文档的目的，如解决什么问题，满足什么需要等。

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

2 范围

描述本文档适用的范围。

3 术语

4 引用文件

5 需求设计操作指导

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

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

来提出产品的可测试性需求。

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

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

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

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

求信息，及时对可测试性进行相应更改。

g）在设计可测试性需求时可参考本文挡“定义产品可测试性需求”的五方面内容。在具体设计产品的可测试性需求时，可根据产品的实际情况考

虑选用具体条目。如在定义中没有列出需求，设计人员可自行增加需求。

总之，在产品中定义可测试性需求时需要慎重。过多的考虑可测试性需

求可能会增加产品的成本和开发时间。

h）对可测试性需求需要进行优先级排序，方便系统设计工程师进行判定和设计。

i）设计可测试性需求要考虑节约成本的预测。

j）完成需求设计后需要与系统工程师进行沟通，对可测试性需求的内容和优先级进行确认。

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

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

6 定义产品可测试性需求

6.1 用于硬件模块调试的可测试性需求

a）在单板上的建立故障指示灯，对灯闪烁定义不同的含义，方便从灯的状态中看出故障原因；

b）在单板上的建立通讯指示灯，对灯闪烁定义不同的含义，方便从灯的状态中看出通讯状态；

c）在单板上建立电源测试点及主电源指示灯，能够方便测试各部分电源的电压、纹波、功耗等；

d）在单板上建立CBB接口测试点，能够方便测试各CBB单元的信号波形；

e）提供报警检测点，能够检测报警信号波形，方便对系统故障进行判断。

6.2 用于软件模块调试的可测试性需求

a）提供可以和PC串口进行Modbus通信的测试平台，可通过串口读取信息进行调试；

b）底层软件增加可视化测试平台，可直接修改寄存器内容等，以方便发生故障时判断问题所在。

6.3 用于系统测试的可测试性需求

a）提供参数表数据出厂值、限值的合法性自动检查机制；

b）提供内存、任务、接口详细、关键资源的查询机制。