该模板仅作为确定可测性需求的指南，实际需求文档模板参照IPD《端到端产品包需求模板》。
1、概述 OVERVIEW
目前可测性需求一般有以下几方面的考虑：
1、面向产品的可测性需求，是为了提高产品的故障检测定位和隔离能力而考虑的可测性需求，直接影响产品问题故障检测定位和隔离的难易程度。面向产品的可测性需求在评审通过后将作为产品本身的规格特性。
2、面向软件验证测试的可测性需求，是为了方便软件验证测试而提出的可测性需求，直接影响测试开发和测试执行的难易程度。
3、面向硬件验证测试的可测性需求，是为了方便硬件验证测试而提出的可测性需求，直接影响测试开发和测试执行的难易程度。
4、面向生产测试的可测性需求，是为了方便生产测试，提高生产测试效率而提出的可测性需求。面向生产测试的可测性需求参见《概念阶段确定可制造性需求指南》相应内容。
目前公司已经发布了各产品线的可测性需求基线（工程特性需求基线之可测性部分），该需求基线是公司多年来已有可测性经验总结提炼的成果，而且还将不断优化和完善，所以需求基线可以覆盖产品的大部分可测性需求。因此具体产品开发时可测性需求的提出一般按以下操作：
1、产品在提可测性需求时首先参照相应可测性需求基线剪裁得到具体产品的需求基线。相应的要求参见可测性需求基线实施规定。
2、结合具体产品的特点，充分考虑产品各阶段测试的可能遇到的问题和困难，提出相应的可测性需求。
3、参考相关产品的可测性方面的经验案例，提出相应的可测性需求。
4、分析参考业界同类产品的可测性设计特点，提出相应的可测性需求。
下面的指南主要针对上述2～4点的需求分析收集给出指导，最后的需求输出格式参照IPD《端到端产品包需求模板》。对于需求基线的需求剪裁参照可测性需求基线实施规定。
2、产品测试需求和策略初步考虑
初步考虑产品进行哪些测试，可以根据相应测试规范标准、类似产品或前一版本的测试经验而来。
初步考虑产品如何进行这些测试，要说明如下问题：
哪些测试是手动测试、哪些是自动测试？
测试数据源是内置在系统中，还是外部提供？
测试数据的采集和处理是内置，还是外置？
测试数据采集装置的控制是内置，还是外置？
测试数据源的控制是内置，还是外置？
测试数据的处理是内置，还是外置？
3、产品测试各阶段的可测试性需求
根据测试需求和策略（如具有内置要求的测试），通过对具体产品特点的分析、内部访谈、参考公司内部经验案例并分析调研业界同类产品，提出可测试性需求。
产品各阶段的可测性需求内容应该包括以下几个方面的内容：
3.1、硬件模块和部件调试和测试的可测性需求
关注点在于能否提供方便的调试手段和支持调试测试的工具接口，支持模块和部件的单独调试和测试，主要考虑以下几个方面的内容：
（1）提供支持模块独立运行必要的信号输入和输出接口数据。
（2）提供信号和数据流的自环和自给设计
（3）提供模块和部件的离线加载功能
（4）提供模块和部件的自测试设计
（5）提供测试仪器和工具的测试接口或兼容性设计 。
（6）提供直观的调试结果信息上报监控
本部分需求来源于以往类似单板硬件和部件的调试经验、采用新的器件和开发技术而带来的新的需求、采用新的方法引申的需求、提高开发调试效率引出的需求以及来自内部访谈和调研分析的相应需求。
例如：产品设计了一块业务板，但需要时钟板提供时钟才能正常工作，而提供时钟的单板也要调试，无法支持本单板的调试，这样为了调试这块单板就需要考虑时钟源的设计，可能我们需要在板内提供一个晶振，或者利用锁相环的压控晶振分压设置提供时钟，以支持单板的独立调试。另外为了调试单板业务是否正常，必要的环回必须要支持，数据源需要有相应的设计考虑。
3.2、软件模块的调试和测试中的可测性需求
关注点主要在于按设置测试控制序列、状态观测点和输入输出机制的需求，主要考虑以下几个方面的内容：
（1）提供软件模块调试测试的能控性设计，能通过输入设定的测试序列使系统处于某种特定的状态或满足某种特定条件的状态。 主要考虑软件模块的调试测试控制点的选择和测试序列导入机制的设计。
（2）提供软件模块调试测试的能观性设计，能够通过系统的输出数据判定系统是否处于某种特定的状态或满足某种特定条件的状态。主要考虑软件模块的调试测试观察点的选择和观察装置的设计。
(3)软件可测试性需求分为内建、公共、产品特性等三类，内建测试能力与公共可测试性需求合入产品包需求，在确定设计需求时，对具体产品特性需求分析的基础上，提出相应的特性可测试性需求。三类需求分别说明如下：
特性可测试性需求。针对产品具体特性测试的方便性提出的需求，它们与特性紧密相关，以特性树的方式组织
公共可测试性需求，例如：OS中内存管理这些更具有公共性的部分。它们叫做公共可测试性需求。也是以特性树的方式组织。例如：内存管理特性、队列特性等等
内建测试能力需求。它是最具有公用性的部分。它们叫做内建测试能力可测试性需求。它描述了产品应该具有的支持测试能力的需求。如：跟踪机制需求、测试接口需求等。这些需求的被实现，可以有力的支持前两类需求的实现。例如：我们实现了跟踪机制，就能更好的实现第一类和第二类中的哪些跟踪需求。它们都需要调用这里提供的机制来真正的完成跟踪。
本部分需求主要来源于测试策略、经验总结以及内部访谈和调研分析。 软件可测试性需求的分析详细过程与方法，参见测试部相关支撑流程。
3.3、系统联调中的可测性需求
需求的关注点主要是能够提供一些手段，这些手段是可以暴露问题、发现问题、定位问题产生原因，解决问题、以及验证解决效果的测试手段，主要考虑以下几个方面的内容：
（1）测试数据源设计
（2）业务和控制数据流的监控和变更设计
（3）子系统和模块的故障分段环回及定位设计
（4）子系统和模块的自测试设计
（5）测试仪器和工具的测试接口或兼容性设计
（6）测试结果的记录、分析和结果上报设计
例如：系统联调中如何区分不同单板、不同模块之间的故障，出了故障后问题是出在这个单板/模块还是出在与之接口的那个单板/模块，是我们经常遇到的一个问题。需要考虑相应设计支持问题的分段/分层定位。
本部分需求主要来源于联调经验、联调测试策略以及内部访谈和调研分析。
3.4、系统验证测试中的可测性需求
系统验证测试是验证产品各种指标性能是否达到设计要求，在不同环境下的指标容限如何，包括指标/接口层测试、功能/性能层测试、子系统/模块层测试、应用层测试、用户层测试，其关注点主要在于系统验证测试各种测试项目能否实现、实现是否方便、出现问题是否可以定位。 主要考虑以下几个方面的内容：
（1）系统业务功能测试的可实现性和方便性
（2）性能指标测试与瓶颈定位的可实现性和方便性
（3）系统告警功能验证测试的可实现性和方便性
（4）系统容限/容错/极限性能测试的可实现性和方便性
（5）协议跟踪与验证测试的可实现性和方便性。
例如：针对系统验证测试中测试工作量比较大、重复次数较多的问题，往往需要考虑对自动测试的支持，提供自动统计功能或者相应的函数接口，便于自动测试设计和执行。对于异常容错测试往往需要考虑相应的硬件接口或函数接口支持。有时候接口指标测试时需要考虑测试仪器辅助信号的设计，提供测试仪器所需要的时钟等信号接口供测试仪器使用。
本部分需求主要来源于测试策略、经验总结以及内部访谈和可测性调研分析。
3.5、整机安装后的上电自测试可测性需求
整机安装后的上电自测试主要是用于验证整机系统的配置正确性、子系统和部件的有效性，以及验证系统的完备性、数据配置的正确性，这里的可测性需求关注点在于如何提高测试自动化程度、缩短测试时间、如何提高测试的故障覆盖率、减少漏测率。 主要考虑以下几个方面的内容：
（1）测试数据源设计
（2）业务通路用外部程序控制的设计
（3）业务通路的环回及故障定位设计
（4）各单板自检测试设计
（5）数据自动配置工具设计
（6）运行状态监控及测试结果的记录、分析和上报设计
例如：整机测试的自动化对生产效率提高非常重要，所以一般需要提供整机安装后自测试功能，包括提供各单板的自检测试，系统业务通路的遍历自测试设计支持等等，自测试的问题定位应该尽量定位到板级，而且测试用的数据源应该尽量采用内置设计，避免试用昂贵的外部仪器。
本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。
3.6、在线例行测试的可测性需求
在线例测用于实现定时对系统的功能和关键性能进行检测，确保系统和部件运行的正确性。单板更换、软件升级与配置数据变更之后进行系统功能性能的测试，验证变更后系统的正确性。
主要考虑以下几个方面的内容：
（1）测试数据源设计
（2）通道的分层逐段环回设计
（3）单板硬件（芯片） 的在线测试设计
（4）测试监控及测试结果的记录、分析和上报设计
例如：提供例测命令，实现对设备的全面在线测试，包括例测启动设置、例测模式范围选择、例测结果记录上报、例测故障诊断定位等。
本部分可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。
3.7、单板和部件故障诊断测试的可测性需求
单板和部件的故障诊断测试关注点主要是如何提高故障定位的有效性、准确性，方便性。主要考虑以下几个方面的内容：
（1）单板和部件的独立运行设计
（2） 通道的分层自环与环回诊断设计
（3）单板硬件初始化及自检诊断设计
（4）测试仪器和测试工具的兼容性设计
（5）故障诊断树及故障定位到芯片级的诊断设计考虑
（6 ）诊断测试监控及测试结果的记录、分析和上报设计
例如：在现场定位时我们系统的故障怎么定位到一块单板，在维修测试怎么定位到一个芯片是我们经常面对的一个问题，需要我们在设计初期进行充分的可测性分析，并提供足够的可测性设计支持，以及考虑提供故障自动诊断设计。
本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。
4、可测试性需求总结
对以上各方面的可测性设计需求进行统计和总结，完成以下可测性需求列表(参见：《E2E_Template_End to End Offering Requirements Template端到端产品包需求模板》),该过程中主要完成重复需求的合并，并结合业界先进和历史经验对需求列表进行分析，对优先级别高的需求重点说明，给出需求的排序
序号 | 合并后的可测性需求 | 该需求的相关好处 | 基本需求 (Y/N) | 最好满足的需求 (Y/N) | 独特之处 (Y/N) | 重要性(1-5 ) | 优先级(1-5 ) | |||||||||
1 | PIC扣板设计专用的调试板，为这类单板提供业务流、控制或接口，以方便该类单板的调测。 | 可以支持单板的独立调试和测试，提高调试和测试效率 | N | Y | N | 4 | 5 | |||||||||
2 | 在单板上提供均匀分布的地针或接地点 | 方便信号测试 | N | Y | N | 3 | 5 | |||||||||
3 | 提供上电对关键芯片的自检测试，测试结果通过指示灯显示并同时上报控制台。 | 便于调测和现场维护 | Y | N | N | 5 | 4 | |||||||||
4 | 单板提供EERPROM用于系统软硬件版本、生产序列号的集中保存 | 便于维护和故障定位分析 | Y | N | N | 4 | 5 | |||||||||
5 | 提供LCD显示板显示系统运行状态和告警信息 | 便于故障监测和定位 | N | Y | Y | 4 | 5 | |||||||||
6 | 系统提供例行测试功能，能对设备的系统、部件、单板等部分的软件和硬件定期进行全面的检测 | 便于故障检测 | Y | N | N | 5 | 3 | |||||||||
7 | ||||||||||||||||
联系我们
Contact us
战略解码