深圳市共创力资深顾问 杨学明/文

     由于市场及产品用户对产品质量的要求越来越高,  各大企业加强了对产品可测试性需求的收集和控制,本文用于指导TSE及系统设计人员进行可测试性需求分析活动。

     目前可测性需求一般有以下几方面的考虑:

1、面向产品的可测性需求,是为了提高产品的故障检测定位和隔离能力而考虑的可测性需求,直接影响产品问题故障检测定位和隔离的难易程度。面向产品的可测性需求在评审通过后将作为产品本身的规格特性。

2、面向软件验证测试的可测性需求,是为了方便软件验证测试而提出的可测性需求,直接影响测试开发和测试执行的难易程度。

3、面向硬件验证测试的可测性需求,是为了方便硬件验证测试而提出的可测性需求,直接影响测试开发和测试执行的难易程度。

4、面向生产测试的可测性需求,是为了方便生产测试,提高生产测试效率而提出的可测性需求。面向生产测试的可测性需求参见《概念阶段确定可制造性需求指南》相应内容。


                                      如何提出可测试性需求?


       目前很多公司已经发布了各产品线的可测性需求基线(工程特性需求基线之可测性部分),该需求基线是公司多年来已有可测性经验总结提炼的成果,而且还将不断优化和完善,所以需求基线可以覆盖产品的大部分可测性需求。因此具体产品开发时可测性需求的提出一般按以下操作:

1、产品在提可测性需求时首先参照相应可测性需求基线剪裁得到具体产品的需求基线。相应的要求参见可测性需求基线实施规定。

2、结合具体产品的特点,充分考虑产品各阶段测试的可能遇到的问题和困难,提出相应的可测性需求。

3、参考相关产品的可测性方面的经验案例,提出相应的可测性需求。

4、分析参考业界同类产品的可测性设计特点,提出相应的可测性需求。


                                  可测试性需求提出的步骤


1、产品测试需求和策略初步考虑

哪些测试是手动测试、哪些是自动测试?

测试数据源是内置在系统中,还是外部提供?

测试数据的采集和处理是内置,还是外置?

测试数据采集装置的控制是内置,还是外置?

测试数据源的控制是内置,还是外置?

测试数据的处理是内置,还是外置?

2、产品测试各阶段的可测试性需求

根据测试需求和策略(如具有内置要求的测试),通过对具体产品特点的分析、内部访谈、参考公司内部经验案例并分析调研业界同类产品,提出可测试性需求。

产品各阶段的可测性需求内容应该包括以下几个方面的内容:

  •     硬件模块和部件调试和测试的可测性需求

关注点在于能否提供方便的调试手段和支持调试测试的工具接口,支持模块和部件的单独调试和测试,主要考虑以下几个方面

(1)提供支持模块独立运行必要的信号输入和输出接口数据。

(2)提供信号和数据流的自环和自给设计

(3)提供模块和部件的离线加载功能

(4)提供模块和部件的自测试设计

(5)提供测试仪器和工具的测试接口或兼容性设计。

(6)提供直观的调试结果信息上报监控  

      例如:产品设计了一块业务板,但需要时钟板提供时钟才能正常工作,而提供时钟的单板也要调试,无法支持本单板的调试,这样为了调试这块单板就需要考虑时钟源的设计,可能我们需要在板内提供一个晶振,或者利用锁相环的压控晶振分压设置提供时钟,以支持单板的独立调试。另外为了调试单板业务是否正常,必要的环回必须要支持,数据源需要有相应的设计考虑,

  • 软件模块的调试和测试中的可测性需求

     关注点主要在于按设置测试控制序列、状态观测点和输入输出机制的需求,主要考虑以下几个方面的内容:

(1)提供软件模块调试测试的能控性设计,能通过输入设定的测试序列使系统处于某种特定的状态或满足某种特定条件的状态。主要考虑软件模块的调试测试控制点的选择和测试序列导入机制的设计。

(2)提供软件模块调试测试的能观性设计,能够通过系统的输出数据判定系统是否处于某种特定的状态或满足某种特定条件的状态。主要考虑软件模块的调试测试观察点的选择和观察装置的设计。

(3)软件可测试性需求分为内建、公共、产品特性等三类,内建测试能力与公共可测试性需求合入产品包需求,在确定设计需求时,对具体产品特性需求分析的基础上,提出相应的特性可测试性需求。三类需求分别说明如下:

      特性可测试性需求。针对产品具体特性测试的方便性提出的需求,它们与特性紧密相关,以特性树的方式组织;

      公共可测试性需求,例如:OS中内存管理这些更具有公共性的部分。它们叫做公共可测试性需求。也是以特性树的方式组织。例如:内存管理特性、队列特性等等;

      内建测试能力需求。它是最具有公用性的部分它们叫做内建测试能力可测试性需求。它描述了产品应该具有的支持测试能力的需求。如:跟踪机制需求、测试接口需求等。这些需求的被实现,可以有力的支持前两类需求的实现。例如:我们实现了跟踪机制,就能更好的实现第一类和第二类中的哪些跟踪需求。它们都需要调用这里提供的机制来真正的完成跟踪。

     本部分需求主要来源于测试策略、经验总结以及内部访谈和调研分析。软件可测试性需求的分析详细过程与方法,参见测试部相关支撑流程。

  • 系统联调中的可测性需求

需求的关注点主要是能够提供一些手段,这些手段是可以暴露问题、发现问题、定位问题产生原因,解决问题、以及验证解决效果的测试手段,主要考虑以下几个方面的内容

(1)测试数据源设计

(2)业务和控制数据流的监控和变更设计

(3)子系统和模块的故障分段环回及定位设计

(4)子系统和模块的自测试设计

(5)测试仪器和工具的测试接口或兼容性设计

(6)测试结果的记录、分析和结果上报设计

例如:系统联调中如何区分不同单板、不同模块之间的故障,出了故障后问题是出在这个单板/模块还是出在与之接口的那个单板/模块,是我们经常遇到的一个问题。需要考虑相应设计支持问题的分段/分层定位。

  • 系统验证测试中的可测性需求

     系统验证测试是验证产品各种指标性能是否达到设计要求,在不同环境下的指标容限如何,包括指标/接口层测试、功能/性能层测试、子系统/模块层测试、应用层测试、用户层测试,其关注点主要在于系统验证测试各种测试项目能否实现、实现是否方便、出现问题是否可以定位。主要考虑以下几个方面的内容:

(1)系统业务功能测试的可实现性和方便性

(2)性能指标测试与瓶颈定位的可实现性和方便性

(3)系统告警功能验证测试的可实现性和方便性

(4)系统容限/容错/极限性能测试的可实现性和方便性

(5)协议跟踪与验证测试的可实现性和方便性。

例如:针对系统验证测试中测试工作量比较大、重复次数较多的问题,往往需要考虑对自动测试的支持,提供自动统计功能或者相应的函数接口,便于自动测试设计和执行。对于异常容错测试往往需要考虑相应的硬件接口或函数接口支持。有时候接口指标测试时需要考虑测试仪器辅助信号的设计,提供测试仪器所需要的时钟等信号接口供测试仪器使用。

  • 整机安装后的上电自测试可测性需求

     整机安装后的上电自测试主要是用于验证整机系统的配置正确性、子系统和部件的有效性,以及验证系统的完备性、数据配置的正确性,这里的可测性需求关注点在于如何提高测试自动化程度、缩短测试时间、如何提高测试的故障覆盖率、减少漏测率。主要考虑以下几个方面的内容:

(1)测试数据源设计

(2)业务通路用外部程序控制的设计

(3)业务通路的环回及故障定位设计

(4)各单板自检测试设计

(5)数据自动配置工具设计

(6)运行状态监控及测试结果的记录、分析和上报设计

例如:整机测试的自动化对生产效率提高非常重要,所以一般需要提供整机安装后自测试功能,包括提供各单板的自检测试,系统业务通路的遍历自测试设计支持等等,自测试的问题定位应该尽量定位到板级,而且测试用的数据源应该尽量采用内置设计,避免试用昂贵的外部仪器。

本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。

  • 在线例行测试的可测性需求

      在线例测用于实现定时对系统的功能和关键性能进行检测,确保系统和部件运行的正确性。单板更换、软件升级与配置数据变更之后进行系统功能性能的测试,验证变更后系统的正确性。

主要考虑以下几个方面的内容:

(1)测试数据源设计

(2)通道的分层逐段环回设计+

(3)单板硬件(芯片)的在线测试设计

(4)测试监控及测试结果的记录、分析和上报设计

例如:提供例测命令,实现对设备的全面在线测试,包括例测启动设置、例测模式范围选择、例测结果记录上报、例测故障诊断定位等。

本部分可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。

  • 单板和部件故障诊断测试的可测性需求

   单板和部件的故障诊断测试关注点主要是如何提高故障定位的有效性、准确性,方便性。主要考虑以下几个方面的内容:

(1)单板和部件的独立运行设计

(2)通道的分层自环与环回诊断设计

(3)单板硬件初始化及自检诊断设计

(4)测试仪器和测试工具的兼容性设计

(5)故障诊断树及故障定位到芯片级的诊断设计考虑

(6)诊断测试监控及测试结果的记录、分析和上报设计

例如:在现场定位时我们系统的故障怎么定位到一块单板,在维修测试怎么定位到一个芯片是我们经常面对的一个问题,需要我们在设计初期进行充分的可测性分析,并提供足够的可测性设计支持,以及考虑提供故障自动诊断设计。

本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。

     对以上各方面的可测性设计需求进行统计和总结,完成以下可测性需求列表,该过程中主要完成重复需求的合并,并结合业界先进和历史经验对需求列表进行分析,对优先级别高的需求重点说明,给出需求的排序。


                          谁来主导可测试性需求分析?


      TSE(测试系统工程师)是可测试性需求分析的主要责任人,其它各个模块的测试组长协助TSE建立可测试性需求基线(如软件、硬件、结构等)。如果需要了解TSE的角色与职责,请参考另一篇文章。

      什么是测试系统工程师(TSE)? https://www.cnblogs.com/mikeyond/p/11604611.html

作者简介:

杨学明  清华大学MBA,深圳市共创力企业管理咨询有限公司总经理,深圳市汇成研发管理咨询有限公司董事长,资深研发管理专家,国内首席研发管理专家,曾服务于华为,阿里巴巴等知名企业,杨老师先后在国内开设研发类公开课100多场,服务内训客户1000多家,为数百家企业提供了研发咨询服务,典型的客户如深圳迈瑞、华立仪表、步步高、英威腾、雷赛智能、埃斯顿、华工科技、中国科学院、电力科学研究院、中国工商银行、重邮信科、从兴电子、浙大网新、联迪商用等。近两年服务的客户如中电海康、网易、苏宁云商、烽火科技、29所、华为技术、中兴通讯、广联达、大唐电力、招商局、京信通信、航盛电子、国电南瑞、中航工业、维力医疗、寒武纪科技、海南邮政、京仪股份、海尔集团等。