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

《TST01T00产品测试各阶段的可测试性需求》由会员分享，可在线阅读，更多相关《TST01T00产品测试各阶段的可测试性需求（13页珍藏版）》请在装配图网上搜索。

1、输出文档格式要求：在按照IPD模板内容执行IPD活动中，当输出文档时，请作者务必套用IPD输出文档格式，以保证文档格式的规范性。Requirements for format of output documents: when you output documents while following IPD template to execute activities, Format of IPD Output Document must be followed to ensure that the format of documents are consistent and standard

2、ized. R&D-Template -Testability Requirements Guideline概念阶段确定可测试性需求指南-03活动号：TE-15 Activity ID: TE-15 Control Section 文档控制Version 版本Date日期Change and reason更改及其理由By责任人Project Manager: _ Project: _ 项目经理： _ 项目： _Project Phase / Decision Checkpoint:项目阶段/决策检查点： XConcept概念 Develop开发 Launch发布 Interim临时 Plan

3、计划 Qualify验证 Life Cycle生命周期该模板仅作为确定可测性需求的指南，实际需求文档模板参照IPD端到端产品包需求模板。1、概述 OVERVIEW目前可测性需求一般有以下几方面的考虑：1、面向产品的可测性需求，是为了提高产品的故障检测定位和隔离能力而考虑的可测性需求，直接影响产品问题故障检测定位和隔离的难易程度。面向产品的可测性需求在评审通过后将作为产品本身的规格特性。2、面向软件验证测试的可测性需求，是为了方便软件验证测试而提出的可测性需求，直接影响测试开发和测试执行的难易程度。3、面向硬件验证测试的可测性需求，是为了方便硬件验证测试而提出的可测性需求，直接影响测试开发和测试

4、执行的难易程度。4、面向生产测试的可测性需求，是为了方便生产测试，提高生产测试效率而提出的可测性需求。面向生产测试的可测性需求参见概念阶段确定可制造性需求指南相应内容。目前公司已经发布了各产品线的可测性需求基线（工程特性需求基线之可测性部分），该需求基线是公司多年来已有可测性经验总结提炼的成果，而且还将不断优化和完善，所以需求基线可以覆盖产品的大部分可测性需求。因此具体产品开发时可测性需求的提出一般按以下操作：1、产品在提可测性需求时首先参照相应可测性需求基线剪裁得到具体产品的需求基线。相应的要求参见可测性需求基线实施规定。2、结合具体产品的特点，充分考虑产品各阶段测试的可能遇到的问题和困难，

5、提出相应的可测性需求。3、参考相关产品的可测性方面的经验案例，提出相应的可测性需求。4、分析参考业界同类产品的可测性设计特点，提出相应的可测性需求。下面的指南主要针对上述24点的需求分析收集给出指导，最后的需求输出格式参照IPD端到端产品包需求模板。对于需求基线的需求剪裁参照可测性需求基线实施规定。1. summarizeTestability requirements could be consider as following aspects:1. Product-oriented testability requirements are proposed to improve the a

6、bility of detecting and isolating defect, in which would affect the ease of detecting and isolating defects during testing. The reviewed product-oriented testability requirements will be treated as a part of the offering requirements of the product under construction. 2. Software-oriented testabilit

7、y requirements are proposed to ease the test development and execution when verifying the software of a product.3. Hardware-oriented testability requirements are proposed to ease the test development and execution when verifying the hardware of a product.4. Production-oriented testability requiremen

8、ts are proposed to ease the testing and improve efficiency during the production of a product. Please refer to for production-oriented testability requirements. The testability requirement baselines for all products are released in our company(part of the engineering feature requirement baseline). T

9、he baselined requirements are summarized from the long term past project experience in our company, and its also being optimize and consumate. Therefore the baselined requirements can cover most testability requirements of most products, and testability requirements could be proposed by the followin

10、g steps:1.The testability requirement of a particular product could be obtained by tailoring the baselined testability requirements to a particular need. For more detail, please refer to the 2. Accompany with the characteristic of the product, think over the problems and difficulties that might be e

11、ncountered during each phase of testing, testability requirements could be proposed for them.3. Referring the past experience of proposed testability requirements from relevant products.4. Analysis and reference to the similar product in the industry, consider their design for testability.The follow

12、ing guide is served for the 24 shown above, and the final requirement output is in conformity with the IPD. To tailoring the baselined testability requirement, please refer to .2、产品测试需求和策略初步考虑Product testing requirements and strategy overview初步考虑产品进行哪些测试，可以根据相应测试规范标准、类似产品或前一版本的测试经验而来。 初步考虑产品如何进行这些测试

13、，要说明如下问题：哪些测试是手动测试、哪些是自动测试？测试数据源是内置在系统中，还是外部提供？测试数据的采集和处理是内置，还是外置？测试数据采集装置的控制是内置，还是外置？测试数据源的控制是内置，还是外置？测试数据的处理是内置，还是外置？Summarize what tests are to be conducted. This can be summarized from testing requirements. Describe in general how these testing are conducted, the following should be explained:Wh

14、at are manual testing and what are automated testing?Is testing data source embedded in the system or provided from outside?Is the collection and processing of testing data achieved from inside or outside?Is the control of testing data collection device achieved from inside or outside?Is the control

15、 of testing data source achieved from inside or outside?Is the processing of testing data achieved from inside or outside?3、产品测试各阶段的可测试性需求根据测试需求和策略（如具有内置要求的测试），通过对具体产品特点的分析、内部访谈、参考公司内部经验案例并分析调研业界同类产品，提出可测试性需求。Testability requirements should be listed with reference to test requirements and strategy

16、addressing those tests which have embedded requirements and the test strategy of each test item.产品各阶段的可测性需求内容应该包括以下几个方面的内容：Testability requirements should include the following contents:、硬件模块和部件调试和测试的可测性需求Testability requirements of modules and parts debugging and testing关注点在于能否提供方便的调试手段和支持调试测试的工具接口

17、，支持模块和部件的单独调试和测试，主要考虑以下几个方面的内容：（1）提供支持模块独立运行必要的信号输入和输出接口数据。（2）提供信号和数据流的自环和自给设计（3）提供模块和部件的离线加载功能 （4）提供模块和部件的自测试设计（5）提供测试仪器和工具的测试接口或兼容性设计 。（6）提供直观的调试结果信息上报监控本部分需求来源于以往类似单板硬件和部件的调试经验、采用新的器件和开发技术而带来的新的需求、采用新的方法引申的需求、提高开发调试效率引出的需求以及来自内部访谈和调研分析的相应需求。例如：产品设计了一块业务板，但需要时钟板提供时钟才能正常工作，而提供时钟的单板也要调试，无法支持本单板的调试，这

18、样为了调试这块单板就需要考虑时钟源的设计，可能我们需要在板内提供一个晶振，或者利用锁相环的压控晶振分压设置提供时钟，以支持单板的独立调试。另外为了调试单板业务是否正常，必要的环回必须要支持，数据源需要有相应的设计考虑。The focus here is whether easy debugging & testing measures and debugging & testing equipment interface is available, which makes it easy to verify and locate where the problem comes from, an

19、d support the independent debugging & testing of modules and parts. The following contents should be taken into consideration:(1)Provide input & output data sources necessary for independent debugging & testing of modules and parts.(2)Provide loop back design and embedded data source for data flow.(

20、3)Support off-line loading of modules and parts.(4)Provide self-tests of modules and parts.(5)Provide interface or compatibility design necessary for testing equipment and tools.(6)Provide visual way for reporting of debug results.Requirements here usually come from past board hardware and parts deb

21、ugging & testing experience, new requirements brought about by using new components and development technology, requirements brought about by new method, requirements brought about by raising development efficiency.、软件模块的调试和测试中的可测性需求Testability requirements of software module debugging and testing关注

22、点主要在于按设置测试控制序列、状态观测点和输入输出机制的需求，主要考虑以下几个方面的内容：（1）提供软件模块调试测试的能控性设计，能通过输入设定的测试序列使系统处于某种特定的状态或满足某种特定条件的状态。 主要考虑软件模块的调试测试控制点的选择和测试序列导入机制的设计。（2）提供软件模块调试测试的能观性设计，能够通过系统的输出数据判定系统是否处于某种特定的状态或满足某种特定条件的状态。主要考虑软件模块的调试测试观察点的选择和观察装置的设计。(3)软件可测试性需求分为内建、公共、产品特性等三类，内建测试能力与公共可测试性需求合入产品包需求，在确定设计需求时，对具体产品特性需求分析的基础上，提出相

23、应的特性可测试性需求。三类需求分别说明如下：特性可测试性需求。针对产品具体特性测试的方便性提出的需求，它们与特性紧密相关，以特性树的方式组织公共可测试性需求，例如：OS中内存管理这些更具有公共性的部分。它们叫做公共可测试性需求。也是以特性树的方式组织。例如：内存管理特性、队列特性等等 内建测试能力需求。它是最具有公用性的部分。它们叫做内建测试能力可测试性需求。它描述了产品应该具有的支持测试能力的需求。如：跟踪机制需求、测试接口需求等。这些需求的被实现，可以有力的支持前两类需求的实现。例如：我们实现了跟踪机制，就能更好的实现第一类和第二类中的哪些跟踪需求。它们都需要调用这里提供的机制来真正的完成

24、跟踪。The focus here is the requirements of setting up test control order, status observe point and input & output mechanism, The following contents should be taken into consideration:(1)Test controller of software module debugging & testing, which can make the system coming into or satisfying some spe

25、cial states.(2)The observation of software module debugging & testing, usually the observation points and observation equipment are considered here, through which the system state can be visible by the output message, and we can know whether the system is under the certain state we need. （3）Software

26、 testability requirements are classified into three type, and they are product feature-oriented testability requirements, build-in test capability and common testability requirements. build-in test capability and common testability requirments will be add into IPD, and during analysis of product des

27、ign requirements, product feature-oriented testability requirements will be analyzed based on analysis of product feature requirements.feature-oriented testability requirements, which are proposed according to the actual features of a product. Such requirements are strongly relative to the feature o

28、f a products, and they are organized by different mon testability requires. such as memory management functions in a OS, they are common to the public and not feature-oriented to a particular product, they are called the common testability requirements. such requirements could be organized by a feat

29、ure-tree as well, such as memory management feature, queue feature, and etc.build-in-test capability requirements. they are the most common part of a testing facility, and be called build-in-test capability requirements. such requirements depicted the product under construction should support a cert

30、ain kind of testing capability. for example, if we implement a tracking facility, it could well support the tracking and interfacing requirements from the above two kind of testability requirements. as the figure shown below are the infrastructure of the build-in-test facilities:本部分需求主要来源于测试策略、经验总结以

31、及内部访谈和调研分析。 软件可测试性需求的分析详细过程与方法，参见测试部相关支撑流程。Requirements here usually come from test strategy ,experience, interview. from R&D test dept., you can get detailed supporting process and technical guide for software testability requirements. 、系统联调中的可测性需求需求的关注点主要是能够提供一些手段，这些手段是可以暴露问题、发现问题、定位问题产生原因，解决问题、以及

32、验证解决效果的测试手段，主要考虑以下几个方面的内容：（1）测试数据源设计（2）业务和控制数据流的监控和变更设计（3）子系统和模块的故障分段环回及定位设计（4）子系统和模块的自测试设计（5）测试仪器和工具的测试接口或兼容性设计（6）测试结果的记录、分析和结果上报设计例如：系统联调中如何区分不同单板、不同模块之间的故障，出了故障后问题是出在这个单板/模块还是出在与之接口的那个单板/模块，是我们经常遇到的一个问题。需要考虑相应设计支持问题的分段/分层定位。Testability requirements of joint system debuggingThe focus here is to pr

33、ovide some means, which can help us to learn about and find out the problems, find the reason of the problem, as well as solving methods and effectiveness of the problems. The following contents should be taken into consideration:(1)The design of testing data source .(2)The design for inspection and

34、 modification of system business flow and control data flow.(3)Segment loop and diagnose design for sub-systems and modules.(4)The self-test design for sub-systems and modules. (5)The design of interface or compatibility design necessary for testing equipment and tools.(6)The recording, analyzing an

35、d reporting of testing result.本部分需求主要来源于联调经验、联调测试策略以及内部访谈和调研分析。Requirements here usually come from joint debugging experience and strategy, 、系统验证测试中的可测性需求系统验证测试是验证产品各种指标性能是否达到设计要求，在不同环境下的指标容限如何，包括指标/接口层测试、功能/性能层测试、子系统/模块层测试、应用层测试、用户层测试，其关注点主要在于系统验证测试各种测试项目能否实现、实现是否方便、出现问题是否可以定位。 主要考虑以下几个方面的内容：（1）系统业

36、务功能测试的可实现性和方便性（2）性能指标测试与瓶颈定位的可实现性和方便性（3）系统告警功能验证测试的可实现性和方便性（4）系统容限/容错/极限性能测试的可实现性和方便性（5）协议跟踪与验证测试的可实现性和方便性。 例如：针对系统验证测试中测试工作量比较大、重复次数较多的问题，往往需要考虑对自动测试的支持，提供自动统计功能或者相应的函数接口，便于自动测试设计和执行。对于异常容错测试往往需要考虑相应的硬件接口或函数接口支持。有时候接口指标测试时需要考虑测试仪器辅助信号的设计，提供测试仪器所需要的时钟等信号接口供测试仪器使用。Testability Requirements for SVT Sys

37、tem verification test is used for verifying whether the different standard performance can meet design requirements and what is the standard limit tolerance level in different environment. The system verification test generally include specification and interface test, function and performance test,

38、 sub-system and module test, application test and consumer test. The focus here is whether the different system verification test items can be achieved, as well as the convenience for achieving, and whether problems can be diagnosed. The following contents should be taken into consideration:(1)The r

39、eliability and convenience of system function test.(2)The reliability and convenience of specification test, system performance test and bottleneck positioning.(3)The reliability and convenience of system alarm function verification test.(4)The reliability and convenience of system tolerance test, e

40、rror tolerance and limit performance test.(5)The reliability and convenience of protocol tracking and verification test.本部分需求主要来源于测试策略、经验总结以及内部访谈和可测性调研分析。Requirements here usually come from debugging experience and strategy, interview. 、整机安装后的上电自测试可测性需求整机安装后的上电自测试主要是用于验证整机系统的配置正确性、子系统和部件的有效性，以及验证系统的

41、完备性、数据配置的正确性，这里的可测性需求关注点在于如何提高测试自动化程度、缩短测试时间、如何提高测试的故障覆盖率、减少漏测率。 主要考虑以下几个方面的内容： （1）测试数据源设计（2）业务通路用外部程序控制的设计（3）业务通路的环回及故障定位设计（4）各单板自检测试设计（5）数据自动配置工具设计（6）运行状态监控及测试结果的记录、分析和上报设计例如：整机测试的自动化对生产效率提高非常重要，所以一般需要提供整机安装后自测试功能，包括提供各单板的自检测试，系统业务通路的遍历自测试设计支持等等，自测试的问题定位应该尽量定位到板级，而且测试用的数据源应该尽量采用内置设计，避免试用昂贵的外部仪器。Te

42、stability Requirement for Power On Self TestWhole set power on self test after installation not only verify the configuration correctness of the whole set system, effectiveness of subsystem and part, but also the completeness of system and correctness of data configurations. The focus here is how to

43、 improve the degree of test automation, how to shorten the test time, improve the test coverage, and reduce the problems missed out in test. The following contents should be taken into consideration:(1)The design of testing data source.(2)The design of external program control for business channels.

44、(3)The loop back and troubleshooting design . for business channels.(4)Self-test of different board or card.(5)The design of data automatic configuration tools.本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。 Requirements here usually come from test strategy , experience, interview.、在线例行测试的可测性需求在线例测用于实现定时对系统的功能和

45、关键性能进行检测，确保系统和部件运行的正确性。单板更换、软件升级与配置数据变更之后进行系统功能性能的测试，验证变更后系统的正确性。 主要考虑以下几个方面的内容：（1）测试数据源设计（2）通道的分层逐段环回设计（3）单板硬件（芯片） 的在线测试设计（4）测试监控及测试结果的记录、分析和上报设计例如：提供例测命令，实现对设备的全面在线测试，包括例测启动设置、例测模式范围选择、例测结果记录上报、例测故障诊断定位等。Testability Requirement for On-line Routine TestThe objective of on-line routine test is to co

46、nduct test on the system function and key performance regularly to ensure the correctness of system and parts operation. System function performance test when board change, software upgrade and configuration data change happen to verify the system correctness after the changes. The following content

47、s should be taken into consideration:(1)The design of testing data source.(2)The design of layered and segmented loop back.(3)The on-line routine test for board hardware(chip).(4)The recording, analyzing and reporting of testing result.本部分可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。 Requirements here usually com

48、e from test strategy , experience, interview.、单板和部件故障诊断测试的可测性需求单板和部件的故障诊断测试关注点主要是如何提高故障定位的有效性、准确性，方便性。主要考虑以下几个方面的内容：（1）单板和部件的独立运行设计（2） 通道的分层自环与环回诊断设计（3）单板硬件初始化及自检诊断设计（4）测试仪器和测试工具的兼容性设计（5）故障诊断树及故障定位到芯片级的诊断设计考虑（6 ）诊断测试监控及测试结果的记录、分析和上报设计例如：在现场定位时我们系统的故障怎么定位到一块单板，在维修测试怎么定位到一个芯片是我们经常面对的一个问题，需要我们在设计初期进行充分

49、的可测性分析，并提供足够的可测性设计支持，以及考虑提供故障自动诊断设计。Testability Requirement for Board and Parts Failure Diagnostic TestThe requirement of board and parts failure diagnostic test covers mainly troubleshooting which is located to chip level, independent operation requirement of board and parts as well as the layered

50、loop back, board hardware initialization and self test, board auto loop and loop back. In addition, the compatibility of test equipment and test tools should be taken into consideration.本部分其可测性需求主要来源于测试策略、经验总结以及内部访谈和调研分析。Requirements here usually come from test strategy , experience, interview.4、可测试

51、性需求总结对以上各方面的可测性设计需求进行统计和总结，完成以下可测性需求列表(参见：E2E_Template_End to End Offering Requirements Template端到端产品包需求模板),该过程中主要完成重复需求的合并，并结合业界先进和历史经验对需求列表进行分析，对优先级别高的需求重点说明，给出需求的排序Testability requirements summaryCount up and summarize testability requirements with a table and analyze with reference to the leadin

52、g companies in the industry and lessons learned. Those with high priority should be especially emphasized.（Using , Lotus 1-2-3 Table）.序号合并后的可测性需求该需求的相关好处该项需求所带来的好处，如不满足将带来的危害和不利的后果。基本需求就是在产品必须满足的可测性需求，不能作取舍。在QFD分析中就是MUST项。(Y/N)最好满足的需求就是可以进行折中和排序取舍的可测性需求。在QFD分析中就是WANTS项(Y/N)独特之处该项需求可以成为市场卖点的独特点，在QFD分

53、析中就是卖点(Y/N)重要性(1-5 )测试需求的重要性，该项需求重要性的分值1-5，其中5最重要优先级(1-5 )根据产品的具体情况确定每项需求实现的优先级，该项需求重要性的分值1-5，其中5最重要1PIC扣板设计专用的调试板，为这类单板提供业务流、控制或接口，以方便该类单板的调测。可以支持单板的独立调试和测试，提高调试和测试效率NYN452在单板上提供均匀分布的地针或接地点方便信号测试NYN353提供上电对关键芯片的自检测试，测试结果通过指示灯显示并同时上报控制台。便于调测和现场维护YNN544单板提供EERPROM用于系统软硬件版本、生产序列号的集中保存便于维护和故障定位分析YNN455

54、提供LCD显示板显示系统运行状态和告警信息便于故障监测和定位NYY456系统提供例行测试功能，能对设备的系统、部件、单板等部分的软件和硬件定期进行全面的检测便于故障检测YNN537Serial No.The requirements description from interviewTestability requirements should be embeded in product design.The affects of testability requirementsEssential requirements(Y/N)Recommended requirements(Y/N)U

55、nique feature(Y/N)Significance(1-5 )Priority(1-5 )1In order to debug and test Some boards (can not be run in depart from they system) , special test function should be supplied for testing these board, supplying data stream, control massage and access pathIn order to test physical interface card, sp

56、ecial test board must be developed for supplying data stream , control massages and access pathsingle board run independently for debugging and testingNYN452In PCB design, via have been reserved for key signals, but testing ground not be arranged satisfactorily. According to convenience for debuggin

57、g and testing, ground should be arranged Uniformly palce ground TP(test point) on the circuit boardEasy to test signals NYN353Power on self test for RAMs 、ROM is essential. Test results should be display or reported, so that board can be debug effectively and maintained expediently in fieldPower on

58、self test for key ICs，the test result can be display by LED and control terminalEasy to debug and maintain in fieldYNN544Boards software/hardware version and product serial number should be stored together System software/hardware version and product serial number can be stored together by EERPROMEa

59、sy to maintenance and fault diagnosticYNN455LCD display should be provided, so that main operational status and alarm information is visible for fault detect and diagnosticsSystem operational status and alarm information can be display by LCDEasy to detect and diagnose faultNYY456The system should b

60、e termly tested automatically or manually when the business not be affected. By using termly test, SW/HW on system, components and boards level can be test full-scale, find out defects and hidden troubles.Software and hardware status in overall system, components and boards can be test termly by using routine test functionEasy to detect faultYNN537.