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 standardized.
R&D-Template -Testability Requirements Guideline概念阶段确定可测试性需求指南-03.00.00
活动号：TE-15
Activity ID: TE-15
Control Section
文档控制
VersioDate Change and reason By n 版本 日期 更改及其理由 责任人 Project Manager: __________________ Project: _________________
项目经理： __________________ 项目： _________________
Project Phase / Decision Checkpoint:
项目阶段/决策检查点：
Concept X
概念
Develop
Launch
Interim
开发 发布 临时
Life
Plan
Qualify
Cycle
计划 验证
生命周期
该模板仅作为确定可测性需求的指南，实际需求文档模板参照IPD《端到端产品包需求模板》。 1、概述 OVERVIEW
目前可测性需求一般有以下几方面的考虑： 1、面向产品的可测性需求，是为了提高产品的故障检测定位和隔离能力而考虑的可测性需求，直接影响产品问题故障检测定位和隔离的难易程度。面向产品的可测性需求在评审通过后将作为产品本身的规格特性。 2、面向软件验证测试的可测性需求，是为了方便软件验证测试而提出的可测性需求，直接影响测试开发和测试执行的难易程度。 3、面向硬件验证测试的可测性需求，是为了方便硬件验证测试而提出的可测性需求，直接影响测试开发和测试执行的难易程度。 4、面向生产测试的可测性需求，是为了方便生产测试，提高生产测试效率而提出的可测性需求。面向生产测试的可测性需求参见《概念阶段确定可制造性需求指南》相应内容。 目前公司已经发布了各产品线的可测性需求基线（工程特性需求基线之可测性部分），该需求基线是公司多年来已有可测性经验总结提炼的成果，而且还将不断优化和完善，所以需求基线可以覆盖产品的大部分可测性需求。因此具体产品开发时可测性需求的提出一般按以下操作： 1、产品在提可测性需求时首先参照相应可测性需求基线剪裁得到具体产品的需求基线。相应的要求参见可测性需求基线实施规定。 2、结合具体产品的特点，充分考虑产品各阶段测试的可能遇到的问题和困难，提出相应的可测性需求。 3、参考相关产品的可测性方面的经验案例，提出相应的可测性需求。 4、分析参考业界同类产品的可测性设计特点，提出相应的可测性需求。 下面的指南主要针对上述2～4点的需求分析收集给出指导，最后的需求输出格式参照IPD《端到端产品包需求模板》。对于需求基线的需求剪裁参照可测性需求基线实施规定。 1. summarize
Testability requirements could be consider as following aspects:
1. Product-oriented testability requirements are proposed to improve the ability 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 testability 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 requirements are proposed to ease the testing and improve efficiency during the production of a product. Please refer to The testability requirement baselines for all products are released in our company(part of the engineering feature requirement baseline). The baselined requirements are summarized from the long term past project experience in our company, and it's 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 following 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 encountered 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 following guide is served for the 2~4 shown above, and the final requirement output is in conformity with the IPD< end to end offering requirement template>. To tailoring the baselined testability requirement, please refer to 2、产品测试需求和策略初步考虑 Product testing requirements and strategy overview 初步考虑产品进行哪些测试，可以根据相应测试规范标准、类似产品或前一版本的测试经验而来。 初步考虑产品如何进行这些测试，要说明如下问题： 哪些测试是手动测试、哪些是自动测试？ 测试数据源是内置在系统中，还是外部提供？ 测试数据的采集和处理是内置，还是外置？ 测试数据采集装置的控制是内置，还是外置？ 测试数据源的控制是内置，还是外置？ 测试数据的处理是内置，还是外置？ 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: What 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 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 addressing those tests which have embedded requirements and the test strategy of each test item. 产品各阶段的可测性需求内容应该包括以下几个方面的内容： Testability requirements should include the following contents: 3.1、硬件模块和部件调试和测试的可测性需求 Testability requirements of modules and parts debugging and testing 关注点在于能否提供方便的调试手段和支持调试测试的工具接口，支持模块和部件的单独调试和测试，主要考虑以下几个方面的内容： （1）提供支持模块独立运行必要的信号输入和输出接口数据。 （2）提供信号和数据流的自环和自给设计 （3）提供模块和部件的离线加载功能 （4）提供模块和部件的自测试设计 （5）提供测试仪器和工具的测试接口或兼容性设计 。 （6）提供直观的调试结果信息上报监控 本部分需求来源于以往类似单板硬件和部件的调试经验、采用新的器件和开发技术而带来的新的需求、采用新的方法引申的需求、提高开发调试效率引出的需求以及来自内部访谈和调研分析的相应需求。 例如：产品设计了一块业务板，但需要时钟板提供时钟才能正常工作，而提供时钟的单板也要调试，无法支持本单板的调试，这样为了调试这块单板就需要考虑时钟源的设计，可能我们需要在板内提供一个晶振，或者利用锁相环的压控晶振分压设置提供时钟，以支持单板的独立调试。另外为了调试单板业务是否正常，必要的环回必须要支持，数据源需要有相应的设计考虑。 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, and 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. (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 debugging & 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. 3.2、软件模块的调试和测试中的可测性需求 Testability requirements of software module debugging and testing 关注点主要在于按设置测试控制序列、状态观测点和输入输出机制的需求，主要考虑以下几个方面的内容： （1）提供软件模块调试测试的能控性设计，能通过输入设定的测试序列使系统处于某种特定的状态或满足某种特定条件的状态。 主要考虑软件模块的调试测试控制点的选择和测试序列导入机制的设计。 （2）提供软件模块调试测试的能观性设计，能够通过系统的输出数据判定系统是否处于某种特定的状态或满足某种特定条件的状态。主要考虑软件模块的调试测试观察点的选择和观察装置的设计。 (3)软件可测试性需求分为内建、公共、产品特性等三类，内建测试能力与公共可测试性需求合入产品包需求，在确定设计需求时，对具体产品特性需求分析的基础上，提出相应的特性可测试性需求。三类需求分别说明如下： 特性可测试性需求。针对产品具体特性测试的方便性提出的需求，它们与特性紧密相关，以特性树的方式组织 公共可测试性需求，例如：OS中内存管理这些更具有公共性的部分。它们叫做公共可测试性需求。也是以特性树的方式组织。例如：内存管理特性、队列特性等等 内建测试能力需求。它是最具有公用性的部分。它们叫做内建测试能力可测试性需求。它描述了产品应该具有的支持测试能力的需求。如：跟踪机制需求、测试接口需求等。这些需求的被实现，可以有力的支持前两类需求的实现。例如：我们实现了跟踪机制，就能更好的实现第一类和第二类中的哪些跟踪需求。它们都需要调用这里提供的机制来真正的完成跟踪。 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 special 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 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< end to end offering requirement>, and during analysis of product design 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 of a products, and they are organized by different features. common 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 feature-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 certain 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: 本部分需求主要来源于测试策略、经验总结以及内部访谈和调研分析。 软件可测试性需求的分析详细过程与方法，参见测试部相关支撑流程。 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. 3.3、系统联调中的可测性需求 需求的关注点主要是能够提供一些手段，这些手段是可以暴露问题、发现问题、定位问题产生原因，解决问题、以及验证解决效果的测试手段，主要考虑以下几个方面的内容： （1）测试数据源设计 （2）业务和控制数据流的监控和变更设计 （3）子系统和模块的故障分段环回及定位设计 （4）子系统和模块的自测试设计 （5）测试仪器和工具的测试接口或兼容性设计 （6）测试结果的记录、分析和结果上报设计 例如：系统联调中如何区分不同单板、不同模块之间的故障，出了故障后问题是出在这个单板/模块还是出在与之接口的那个单板/模块，是我们经常遇到的一个问题。需要考虑相应设计支持问题的分段/分层定位。 Testability requirements of joint system debugging The focus here is to provide 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 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 and reporting of testing result. 本部分需求主要来源于联调经验、联调测试策略以及内部访谈和调研分析。 Requirements here usually come from joint debugging experience and strategy, 3.4、系统验证测试中的可测性需求 系统验证测试是验证产品各种指标性能是否达到设计要求，在不同环境下的指标容限如何，包括指标/接口层测试、功能/性能层测试、子系统/模块层测试、应用层测试、用户层测试，其关注点主要在于系统验证测试各种测试项目能否实现、实现是否方便、出现问题是否可以定位。 主要考虑以下几个方面的内容： （1）系统业务功能测试的可实现性和方便性 （2）性能指标测试与瓶颈定位的可实现性和方便性 （3）系统告警功能验证测试的可实现性和方便性 （4）系统容限/容错/极限性能测试的可实现性和方便性 （5）协议跟踪与验证测试的可实现性和方便性。 例如：针对系统验证测试中测试工作量比较大、重复次数较多的问题，往往需要考虑对自动测试的支持，提供自动统计功能或者相应的函数接口，便于自动测试设计和执行。对于异常容错测试往往需要考虑相应的硬件接口或函数接口支持。有时候接口指标测试时需要考虑测试仪器辅助信号的设计，提供测试仪器所需要的时钟等信号接口供测试仪器使用。 Testability Requirements for SVT System 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, 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 reliability 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, error 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. 3.5、整机安装后的上电自测试可测性需求 整机安装后的上电自测试主要是用于验证整机系统的配置正确性、子系统和部件的有效性，以及验证系统的完备性、数据配置的正确性，这里的可测性需求关注点在于如何提高测试自动化程度、缩短测试时间、如何提高测试的故障覆盖率、减少漏测率。 主要考虑以下几个方面的内容： （1）测试数据源设计 （2）业务通路用外部程序控制的设计 （3）业务通路的环回及故障定位设计 （4）各单板自检测试设计 （5）数据自动配置工具设计 （6）运行状态监控及测试结果的记录、分析和上报设计 例如：整机测试的自动化对生产效率提高非常重要，所以一般需要提供整机安装后自测试功能，包括提供各单板的自检测试，系统业务通路的遍历自测试设计支持等等，自测试的问题定位应该尽量定位到板级，而且测试用的数据源应该尽量采用内置设计，避免试用昂贵的外部仪器。 Testability Requirement for Power On Self Test Whole 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 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. (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. 3.6、在线例行测试的可测性需求 在线例测用于实现定时对系统的功能和关键性能进行检测，确保系统和部件运行的正确性。单板更换、软件升级与配置数据变更之后进行系统功能性能的测试，验证变更后系统的正确性。 主要考虑以下几个方面的内容： （1）测试数据源设计 （2）通道的分层逐段环回设计 （3）单板硬件（芯片） 的在线测试设计 （4）测试监控及测试结果的记录、分析和上报设计 例如：提供例测命令，实现对设备的全面在线测试，包括例测启动设置、例测模式范围选择、例测结果记录上报、例测故障诊断定位等。 Testability Requirement for On-line Routine Test The objective of on-line routine test is to conduct 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 contents 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 come from test strategy , experience, interview. 3.7、单板和部件故障诊断测试的可测性需求 单板和部件的故障诊断测试关注点主要是如何提高故障定位的有效性、准确性，方便性。主要考虑以下几个方面的内容： （1）单板和部件的独立运行设计 （2） 通道的分层自环与环回诊断设计 （3）单板硬件初始化及自检诊断设计 （4）测试仪器和测试工具的兼容性设计 （5）故障诊断树及故障定位到芯片级的诊断设计考虑 （6 ）诊断测试监控及测试结果的记录、分析和上报设计 例如：在现场定位时我们系统的故障怎么定位到一块单板，在维修测试怎么定位到一个芯片是我们经常面对的一个问题，需要我们在设计初期进行充分的可测性分析，并提供足够的可测性设计支持，以及考虑提供故障自动诊断设计。 Testability Requirement for Board and Parts Failure Diagnostic Test The 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 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、可测试性需求总结 对以上各方面的可测性设计需求进行统计和总结，完成以下可测性需求列表(参见：《E2E_Template_End to End Offering Requirements Template端到端产品包需求模板》),该过程中主要完成重复需求的合并，并结合业界先进和历史经验对需求列表进行分析，对优先级别高的需求重点说明，给出需求的排序 Testability requirements summary Count up and summarize testability requirements with a table and analyze with reference to the leading companies in the industry and lessons learned. Those with high priority should be especially emphasized.（Using 序号 合并后的可测性需求 该需求的相关好处 基本需求 最好满足的需求 独 ((Y/N) (Y/N) 1 PIC扣板设计专用的调试板，为可以支持单板的独立调试N 这类单板提供业务流、控制或和测试，提高调试和测试接口，以方便该类单板的调测。 效率 Y N2 在单板上提供均匀分布的地针方便信号测试 或接地点 N Y N3 提供上电对关键芯片的自检测便于调测和现场维护 试，测试结果通过指示灯显示并同时上报控制台。 Y N N4 单板提供EERPROM用于系统软硬件版本、生产序列号的集中保存 便于维护和故障定位分析 Y N N5 提供LCD显示板显示系统运行状态和告警信息 便于故障监测和定位 N Y Y6 系统提供例行测试功能，能对便于故障检测 设备的系统、部件、单板等部分的软件和硬件定期进行全面Y N N的检测 7 Serial The requirements Testability No. description from requirements interview should be The affects of Essential Recommentestability requirements (Y/N) (Y/N) requirements requiremembeded in product design. 1 In order to debug In order to test single board N and test Some physical run Y boards (can not be interface card, independently run in depart from special test board for debugging they system) , must be developed and testing special test for supplying data function should be stream , control supplied testing for massages these access path and board, supplying data stream, control massage and access path 2 In PCB design, via Uniformly palce have been reserved ground TP(test for key signals, point) on the but testing ground not be arranged satisfactorily. According to convenience for debugging and testing, ground should be arranged circuit board Easy to test N signals Y 3 Power on self test Power on self test Easy to debug Y for RAMs 、ROM is for key ICs，the and maintain essential. Test test result can be in field N results should be display by LED and display or reported, so that control terminal board can be debug effectively and maintained expediently in field 4 Board’s System Easy to Y N software/hardware software/hardware maintenance version and product serial version and product serial and fault diagnostic number should be number can be stored together stored together by EERPROM 5 LCD display should System be provided, so that main operational operational Easy to detect N and diagnose Y status and alarm fault information can be status and alarm display by LCD information is visible for fault detect and diagnostics 6 The system should Software and Easy to detect Y N be termly tested hardware status in fault automatically or overall system, manually when the components and business not be boards can be affected. By using test termly by termly test, SW/HW using routine test on system, function and components boards level can be test full-scale, find out defects and hidden troubles. 7 ....... ...... 因篇幅问题不能全部显示，请点此查看更多更全内容