搜档网
当前位置:搜档网 › 可测试性需求讲解

可测试性需求讲解

可测试性需求讲解
可测试性需求讲解

软件可测试性需求设计

一、引言

1、目的

提高软件的可测试性,加快测试进度,提高测试效率。

2、范围

描述的范围主要是可测性设计的特征,考虑方向及设计方法。

3、读者对象

系统分析员、设计人员、开发人员。

二、测试所需文档

1、需求规格说明书

2、概要设计说明书

3、详细设计说明书

4、系统功能清单

5、系统运行环境搭建指导书

6、系统操作指导书

三、可测试性设计需求

可测试性主要是指被测实体具有如下特征:可控制性、可分解性、稳定性、易理解性、可观察性,该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试。

1、可控制性设计需求

1)全局变量的可控制性设计需求

在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。

2)接口的可控制性设计需求

各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段

主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接,比如构造测试环境模拟接口对接,这里所指的开放接口主要是指相对于被测系统,即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。

3)模块的可控制性设计需求

对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能,在测试运行期间模块异常时能够将其隔离而不影响测试。

4)业务流程的可控制性设计需求

在测试环境满足的情况下能够控制任一单独业务流程,各业务流程具有流通性。

5)场景的可测性设计需求

将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。

2、可分解性设计需求

1)业务流程的可分解性设计需求

对于复杂的业务流程需合理设定分解点,在测试时能够对其进行分解。

2)场景的可测性设计需求

对于复杂的场景需合理设定分解点,在测试时能够对其进行分解。

3、稳定性设计需求

测试模块发布合理,不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。

4、易理解性设计需求

1)设计文档的易理解性

设计参考标准

内容描述主次要分清

依赖关系描述明确

2)接口的易理解性

接口功能明确

参数有意义

3)业务的易理解性

4)场景的易理解性

5、可观察性设计需求

1)业务执行状态和过程可观察性设计需求

2)异常情况可观察性设计需求

6、测试驱动和桩的设置

为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。

7、适合增量式开发的可测性设计

在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。

8、可查询设计

对系统级别的全局变量或者状态设置查询接口;

某一业务或场景调用接口设置接口路径查询。

9、自愈合功能

在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。

10、输出结果

对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等,不管是以什么方式表现,都要有依可寻,在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。

11、提供统一的操作执行面板

操作面板元素主要由输入和输出元素组成,如所执行的操作和对应的输出,但由于被测

系统可能是一个比较复杂的系统,由多个可以独立的模块组成,涉及到的操作和输出比较多,各操作之间的关联也比较复杂。在设计时统一的做一个操作面板,该操作面板成为一个可以执行整个被测系统操作的独立模块,一种是以命令的形式执行操作,直接以printf语句的形式输出查看,另一种是以GUI的形式,输入(执行的操作)输出均在界面上执行和体现,这样比较直观。

特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数,给出一系列可以分析的数据,该场景可以以执行过程分阶段监控,将监控范围内的数据输出以供测试人员分析。

[讨论] 需求的可测试性

需求需求

敏捷模式中强调User Story的可测试性。我觉得在传统模式中,强调需求的可测试性也有非常大的好处。

1. 用户需求以文字性描述居多,如果需求有测试通过标准,那么开发和测试人员都可以有一个容易遵循的规则。

2. 需求有通过标准,说明开发测试以及需求分析人员都达成了共识,减少工作中的分歧。

3. 既然要研究测试通过标准,那么自然就要求QA从需求分析阶段就开始工作。我想这是所有QA都期盼的结果。

4. 如果团队无法设计出需求的通过标准,那可能是需求不够明确或者团队缺乏相关的知识。总之,大家可以在开发前就可以知道这个需求多半是无法完整实现的。

应该还有其他的好处,大家可以来讨论一下。

软件可测试性设计

发布时间: 2009-8-06 17:27 作者: Vince 来源: 文斯测试技术研究中心字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签:软件测试技术

一、概述

随着软件行业的迅猛发展,软件测试也逐渐受到越来越多的软件公司所重视,然而开发出来的软件直接就可以拿出来做测试吗?根据近几年来的实践证明,在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行,直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持,即要求软件具有可测试性。基于可测试性的目标考虑,良好的架构设计,完备的接口,使得软件测试更加高效和可行,同时产品维护也更加便利。

本文描述的范围:可测试性定义、可测试性特征、可测试性设计。

读者对象:系统分析和设计人员、开发人员、测试人员。

参考文献:

1、《软件可测试性需求设计》Vince

2、《高质量C++/C编程指南》林锐

3、《软件工程思想》林锐

二、软件可测试性定义

2.1 可测试性定义

软件的可测试性是指在一定的时间和成本前提下,进行测试设计、测试执行以此来发现软件的问题,以及发现故障并隔离、定位其故障的能力特性。简单的说,软件的可测试性就是一个计算机程序能够被测试的容易程度。

一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件,而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。

2.2 可测试性特征

1、可操作性:“运行得越好,被测试的效率越高。”

1)系统的错误很少;

2)没有阻碍测试执行的错误;

3)产品在功能阶段的演化(允许同时的开发和测试)。

2、可观察性:“你所看见的就是你所测试的。”

1)每个输入有唯一的输出;

2)系统状态和变量可见,或在运行中可查询;

3)过去的系统状态和变量可见,或在运行中可查询(例如:事务日志);

4)所有影响输出的因素都可见;

5)容易识别错误输出;

6)通过自测机制自动侦测内部错误;

7)自动报告内部错误;

8)可获取源代码。

3、可控制性:“对软件的控制越好,测试越能够被自动执行与优化。”

1)所有可能的输出都产生于某种输入组合;

2)通过某种输入组合,所有的代码都可能被执行;

3)测试工程师可直接控制软件和硬件的状态及变量;

4)输入和输出格式保持一致且有结构;

5)能够便利地对测试进行说明、自动化和再生;

6)接口和模块易控制;

7)业务流程和场景易控制。

4、可分解性:“通过控制测试范围,能够更快地分解问题,执行更灵巧的再测试。”

1)软件系统由独立模块构成;

2)能够独立测试各软件模块;

3)业务流程和场景易分解。

5、简单性:“需要测试的内容越少,测试的速度越快。”

1)功能简单性(例如:特性集是满足需求所需的最小集合);

2)结构简单性(例如:将体系结构模块化以限制错误的繁殖);

3)代码简单性(例如:采用代码标准为检查和维护提供方便)。

6、稳定性:“改变越少,对测试的破坏越小。”

1)软件的变化是不经常的;

2)软件的变化是可控制的;

3)软件的变化不影响已有的测试;

4)软件失效后能得到良好恢复和隔离。

7、易理解性:“得到的信息越多,进行的测试越灵巧。”

1)设计能够被很好地理解并遵循行业规范;

2)内部、外部和共享构件之间的依赖性能够被很好地理解;

3)设计的改变被通知;

4)可随时获取技术文档;

5)技术文档组织合理;

6)技术文档明确详细;

7)技术文档精确性稳定;

8)相关环境配置说明与操作指导。

三、软件可测试性设计

3.1 可测试性设计

软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试,采取合适的设计模式对软件进行设计。

1、坚持测试驱动设计(测试先行)的方法。

优先编写测试代码,这是标准的XP方法。不是说应该一次性编写全部测试代码后,再一次性全部实现。先写验收测试,再写单元测试,编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它,以这种方式编写测试也更少会使人畏缩。

2、尽量做到每个操作对应一个函数,使函数小型化。

使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。否则,在测试这些函数时将不得不构造额外参数,如果参数很大,那么将很快导致代码膨胀。更糟的是,它会诱使你编写比在其它情况下更少的测试。

3、数据的显示与控制分离

把代码移到GUI 视图的外面。然后各种GUI 动作就能成了模型上的简单方法调用。这样,对GUI测试者来说,通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

4、可控制性设计

1)全局变量的可控制性设计

I. 在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等;

II. 可以将全局类型的变量进行分类并封装到一个个接口中操作。

2)接口的可控制性设计

各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接,比如构造测试环境模拟接口对接,这里所指的开放接口主要是指相对于整个被测系统,即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。

3)模块的可控制性设计

对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能,在测试运行期间模块异常时能够将其隔离而不影响测试。

4)业务流程的可控制性设计

在测试环境满足的情况下能够控制任一单独业务流程,各业务流程具有流通性。

5)场景的可测试性设计

将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。

5、可分解性设计

1)业务流程的可分解性设计

对于复杂的业务流程需合理设定分解点,在测试时能够对其进行分解。

2)场景的可分解性设计

对于复杂的场景需合理设定分解点,在测试时能够对其进行分解。

6、稳定性设计

测试模块发布合理,不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。

7、易理解性设计

1)设计文档的易理解性

I. 设计参考标准

II. 内容描述主次要分清

III. 依赖关系描述明确

2)接口的易理解性

I. 接口功能明确

II. 参数有意义

3)业务的易理解性

4)场景的易理解性

8、可观察性设计

1)业务执行状态和过程可观察性设计

2)异常情况可观察性设计

9、测试驱动和桩的设置

为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。

10、适合增量式开发的可测试性设计

在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。

11、可查询设计

1)对系统级别的全局变量或者状态设置查询接口;

2)某一业务或场景调用接口设置接口路径查询

12、自愈合功能

在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。

13、输出结果

对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等,不管是以什么方式表现,都要有依可寻,在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。

14、提供统一的操作执行面板

操作面板元素主要由输入和输出元素组成,如所执行的操作和对应的输出,但可能被测系统是一个比较复杂的系统,由多个可以独立的模块组成,涉及到的操作和输出比较多,各操作之间的关联也比较复杂。在设计时统一的做一个操作面板,该操作面板成为一个可以操

作整个被测系统的独立模块,一种是以命令的形式执行操作,直接以printf语句的形式输出查看,另一种是以GUI的形式,输入(执行的操作)输出均在界面上执行和体现,这样比较直观。如下图所示:

特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数,给出一系列可以分析的数据,该场景可以以执行过程分阶段监控,将监控范围内的数据输出以供测试人员分析。

3.2 可测试性编码

1、注释需要详尽。特别对于接口,要描述清楚功能、实现及参数;

2、使用模块化方法,编码低耦合、高内聚;

3、为集成测试与系统联调准备调测开关及相应打印函数,并且要有详细的说明;

4、为单元测试选择恰当的测试点,并仔细构造测试代码、测试用例,同时给出明确的注释说明。测试代码部分应作为(模块中的)一个子模块,以方便测试代码在模块中的安装与拆卸(通过调测开关);

5、使用断言来发现软件问题,提高代码可测试性;

6、用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况;

7、为测试自动化工具提供所需要的特定“钩子(hook)”;

8、对于每个功能,提供访问、修改“状态”变量的接口,包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印;

9、提供查询系统状态的接口。比如内存使用、程序使用进程数等;

10、对于测试因为环境等因素而可能无法测试的功能,提供接口模拟软件实现该功能的过程;

11、对于修改功能,提供修改功能参数单位的接口,以便于进行如软件性能等的测试;

12、出错及异常处理保存记录,记录具有详细的属性,并且格式统一、意义明确;

13、在程序异常时,除了保留日志,还需要提供观察、恢复的外部方法;

14、对全局变量、特殊结构,提供查询的方法。

3.3 可测试性调试与定位

1、对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改;

2、在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点,便于系统集成和问题范围的定位;

3、在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出,便于测试结果的分析。

3.4 测试所需文档

1、需求规格说明书

2、概要设计说明书

3、详细设计说明书

4、系统功能清单

5、系统运行环境搭建指导书

6、系统操作指导书

可测试性的具体体现(一)

发布时间: 2009-2-17 13:49 作者: 阿七整理来源: 51Testing博客字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签:软件测试功能测试

一. 功能测试

1. 安装测试:

1) 安装过程中对于缺省安装目录及任意指定的安装目录,是否都能正确安装;

2) 若是选择安装,查看能否实现其相应的功能;

3) 在所有能中途退出安装的位置退出安装程序后,验证此程序并未安装成功(没有程序组及程序项产生);

4) 软件安装后,对其它已经安装的软件是否有影响;

5) 裸机安装后,各功能点是否可用;

6) 安装前,安装程序是否判断可用磁盘空间大小,如果不能满足安装空间要求,安装程序能否继续;

7) 安装过程中查看版权声明、版本信息、公司名称、LOGO等是否符合标准;

8) 安装过程中界面显示与提示语言是否准确、友好;

9) 重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存;

10) 是否有注册码或硬件加密狗,在没有它们(或错误)存在的情况下能否顺利安装。

2.配置测试

1) 是否可以按照用户手册的说明,运行于多种操作系统(Windows各版本、Unix 、Linux等);

2) 按系统最低要求进行软件的安装配置,查看能否正常实现各种功能;

3) 数据源等信息配置不正确时能否给出提示信息;

4) 是否可以按照用户手册的说明,支持多种数据库。

3. 卸载测试

1) 卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉;

2) 卸载过程中完全删除共享文件后,看其它程序能否正常运行;

3) 卸载后,是否对其它已经安装的软件有影响;

4) 系统卸载后用户建立文档是否保留;

5) 软件卸载画面上的软件名称及版本信息是否正确;

6) 在所有能中途退出卸载的位置是否能正确退出;

7) 卸载过程中界面显示与提示语言是否准确、友好;

8) 卸载后安装此系统能否打开原来保存的文件,并一切运行正常;

9) 卸载程序如果要求重新启动机器,在重启动之间是否给用户提示以保存现有的己运行的程序的资料;

10) 是否可以选择组件进行卸载;

11) 卸载过程中,对意外情况的处理(掉电等)。

12) 在卸载过程中,是否有终止或者结束按钮。

4. 运行与关闭测试

1) 运行时是否与其它应用程序有冲突(内存冲突);

2) 是否可以同时运行多个程序;

3) 任务栏有无程序运行提示;

4) 若有未保存的数据,关闭系统时是否有提示;

5) 后台服务程序在点击关闭按钮时是否有确认提示;

6) 运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

5. 服务程序的测试:

1) 系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响;

2) 服务程序能否长时间正常运行;

3) 外界异常后,服务程序的自动恢复能力(服务器掉电、网络中断后恢复、数据库异常后恢复…);

4) 在点击关闭按钮时是否有确认提示;

5) 应用程序与其他程序是否兼容(能否避免内存冲突)。

6. 系统管理(参数设置)

1) 参数设置后,能否正确的进行应用;

2) 设置错误参数,系统的容错能力;

3) 修改参数,对与之相关模块的影响;

4) 系统是否有默认的参数,A 有:默认的参数是否起到作用;B 没有:不设置,系统能否运行或者给出提示。

7. 用户、权限管理

1) 赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限);

2) 删除或修改已经登陆系统并正在进行操作的人员的权限,程序能否正确处理;

3) 重新注册系统变更登陆身份后再登录,看程序是否能正确执行,具有权限是否正确;

4) 在有工作组或角色管理的情况下,删除包含用户的工作组或角色,程序能否正确处理;

5) 不同权限用户登录同一个系统,权限范围是否正确;

6) 覆盖系统所有权限设定;

7) 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令);

8) 能否添加长用户名及长口令,如果允许,新用户能否正确登录;

9) 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令,删除或修改后系统的实际情况;

10) 登录用户能否修改自己的权限;

11) 添加用户(有标识或编号):标识相同,用户名不同;标识相同,用户名相同;标识不同,用户名相同;标识不同,用户名不同;

12) 登录用户能否修改本人(或其他人)的信息,删除本人(或其他人);

13) 修改用户的信息(包括权限,口令,基本信息等),对其他模块的影响;

14) 修改用户信息:修改后的用户信息和已经存在的用户信息相同;修改后的用户信息和已经存在的用户信息不同;

15) 不给用户授权,是否允许登录;

15) 改某些设置时,是否会影响具有上级权限及相同权限人员的设置;

16) 系统管理员修改了某些数据,以其他人员身份登录时数据是否改变;

17) 用户能否同时属于多个组,各个组的权限能否交叉;

18) 删除后重新添加的用户是否具有以前的权限;更改用户各项属性(包括权限)看对权限是否有影响。

8. 系统登录测试

1) 使用合法用户登录系统;

2) 用户名、口令错误或漏填时能否登陆;

3) 系统是否容许多次非法登陆,是否有次数限制;

4) 使用已登录账号登录系统系统能否正确处理;

5) 使用禁用帐号登陆系统能否正确处理;

6) 删除或修改后的用户用原用户登录;

7) 不输入用户名和口令,重复点“确定”和“取消”按钮,是否允许登录。

9. 注销

1) 注销为原模块、新模块系统能否正确处理;

2) 中止注销能否返回原模块、原用户;

3) 注销为原用户、新用户系统能否正确处理;

4) 使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

10. 修改口令

1) 正常情况;

2) 输入错误的原口令或新口令与确认口令不一致系统能否正确处理;

3) 修改口令后,用原口令是否能登录(同时验证新口令是否有效);

4) 是否能修改其它用户的口令。

11. 右键功能

1) 右键菜单中的功能是否与菜单(或工具栏)中对应的功能一致;

2) 右键菜单中的功能能否正确实现;

3) 同一菜单下的热键是否相同。

12. 记录列表

1) 增加重复记录、空白记录,系统能否正确处理;

2) 修改后不保存(有保存按钮),系统能否正确处理;

3) 删除或修改正在使用信息,系统能否正确处理;

4) 删除级联记录的上游或下游记录,系统能否正确处理;

5) 删除记录时是否有提示;

6) 记录中包含的缺省系统信息能否删除和修改;

7) 记录列表能否及时反应记录的变化;

8) 记录变化之后系统相关信息能否及时更新;

13. 统计、查询

1) 对非法的时间范围系统能否正确处理;

2) 统计查询语句包含多个与或非条件时,系统能否正确处理;

3) 条件逻辑混乱,系统能否正确处理;

4) 多表查询统计及单表查询统计功能是否正确实现;

5) 分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录;

6) 能否按系统默认的条件进行查询;

7) 当统计时间段为当日、跨日、跨月、跨季、跨年度时,统计查询结果是否正确;

8) 当某些操作被别人取消后,设置条件段为取消前、取消后、包含取消操作的一段时间;

9) 以不同的权限登录时,统计、查询是否正确;

10) 在查询或统计大数据量时,系统是否允许终止操作;

11) 查询、统计按钮是否允许双击或更多的点击,系统做何反映;

12) 查询出的数据是否允许修改。

可测试性的具体体现(二)

发布时间: 2009-2-17 13:52 作者: 阿七整理来源: 51Testing博客字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签:软件测试功能测试

14. 文件操作

a、保存

1) 文件是否能够正确保存在在缺省位置或指定位置(本地、网络);

2) 系统能否正确处理长文件名、特殊字符文件名保存;

3) 文件能否保存为其它扩展名;

4) 如应用程序对文件名区分大小写,当这些文件在导出到介质中时,系统能否正确处理;

5) 介质空间已满时,系统是否给出提示。

b、打开

1) 打开文件是否正确显示上一次保存的内容;

2) 系统能否正确处理非系统默认扩展名的文件;

3) 文件能否被其他程序正确打开;

4) 打开对话框中,是否有默认扩展名的文件类型;

5) 打开对话框时,是否有默认的路径。

c、打印输出

1) 是否按所设置的格式打印;

2) 是否有打印预览,能否设置打印字体,打印效果是否合乎客户要求;

3) 打印预览的内容是否正确,内容是否能够进行拖拽操作,是否影响实际的打印;

4) 安装或不安装打印功能模块,对其它模块是否有影响;

5) 打印机未安装系统有无提示;

6) 打印中途能否进行正常的打印中断,是否可以选择打印的内容。

7) 能否进行本地或网络打印。

d、导入、导出功能

1) 导入的文件格式非要求时,系统如何处理;

2) 导入、导出的有效文件能否完整正确地显示并被使用;

3) 导出后的文件是否允许修改,如果允许,导入后能否使用;如不允许,系统有何限制;

4) 导入,导出是否可以选择路径;

5) 在客户端和服务器端进行导入,导出;

6) 在客户端和客户端之间进行导入,导出;

7) 在本地进行导入,导出;

8) 不同文件格式的导入,导出。

e、检入与检出

1) 单文件、多文件检入与检出;

2) 能否多次检入与检出;

3) 文件检出后其它人能对其做何操作。

15. 界面上对象的功能(文本框,下拉框,按钮,热键等等)

a、工具条

1) 工具条能否正常显示/隐藏;

2) 工具条按钮在不可用时是否置灰,例如在不置灰情况下,重复点击工具条上的按钮,看系统是否能够正常进行操作;

3) 可移动工具条在窗口中间位置其形状是否正确;

4) 工具条船坞状与非船坞状时其上按钮是否相同;

5) 工具栏上工具按钮功能是否能正常实现;

6) 工具按钮显示是否正确、友好、醒目易懂;

7) 工具栏上的工具按钮是否有鼠标悬停提示;

8) 工具栏上的工具按钮是否可以任意定制。

b、下拉列表

1) 列表记录的每一行是否显示完整;

2) 列表记录不能在一页中显示时,是否有纵向滚动栏;

3) 列表滚动栏上滑块能否自由滑动,对应内容显示是否正确;

4) 列表中内容能否自动排序。

c、窗口

1) 打开的窗口不确认关掉,能否再调其它窗口,且连续开窗口系统能否正确处理;

2) 窗口尺寸变化时窗口中控件能否自适应;

3) MDI中,子窗口的平铺、重叠、排列图标功能是否正确;

4) 窗口的标题、图标是否和菜单命令、按钮一致;

5) 子窗口和主窗口的属性是否正确;

6) 窗口中的上下左右滚动条是否能达到预览全部界面的效果。

d、文本框

1) 对输入域的必添项处理是否正确;

2) 输入域是否有长度限制;

3) 输入域如对某些字符禁止输入时,限制是否成功;

4) 中文、英文、空格,数字,字符,下划线、单引号等所有特殊字符的组合;

5) 口令域

●口令为空格或包含空格、特殊字符(所有特殊字符的测试)时系统能否正常处理;

●口令位数是否有限制;

●口令与帐号相同,系统是否有提示;

●口令为字典单词系统能否正确处理;

特殊的对系统安全性要求较高应该注意:

●口令应有最少位数限制;

●口令应为数值、大小写字母、特殊字符的组合;

●口令禁止设为空,不能和要被修改的口令一致;

●口令区分大小写;

6) 时间域

●年度超过4位;

●月份输入0或大于12;

●日期输入0或大于当前月份的天数;

●年度,月份,日期输入负数;

●时间输入大于或小于边缘值的数据;

●进行字符及汉字的输入,看程序能否正确处理;

●系统中所涉及时间是否取服务器时间;

●有范围的输入域,开始时间大于、小于、等于结束时间,系统能否正确处理;

●时间范围同当前时间的关系是否正确;

●是否包含缺省时间且缺省时间意义是否正确;

●系统对闰年,闰月的处理;

●对不同的时间格式(yyyy-dd-mm,yy-dd-mm,yyyy/dd/mm,yy/dd/mm等)是否允许输入;

●输入的时间在与之有关的模块中是否能正确的起到作用及对其他模块的影响;

●对时间点的测试。

7) 货币域

● 输入负值、零、特大数、小数系统能否正确处理;

● 系统对小数点后数位的控制是否正确;

● 系统能否正确处理数值计算;

● 输入非数值型数据(包括特殊字符),系统能否正确处理;

● 系统能处理货币的种类。

8) 身份证(18或15位):

身份证中输入非法的年月日信息(包括超界数字及字符,汉字),程序能否进行检验并正确处理;

由身份证号码计算年龄,系统对出生年份末两位数是00的身份证号码能否正常处理;

在年龄和身份证均作为用户信息输入时,是否具有关联;

在身份证的输入中,是否允许输入字符”x”。

9) 电话号码

● 输入特殊的电话号码,如119,110,800等看程序是否能正确处理;

● 验证-,(,)* # 是否有真正含义;

● 电话号码长度是否有限制;

● 电话号码是否允许输入汉字,英文。

10) 关于时间的其它操作

● 时间的跨月份、年度操作;

● 12小时、24小时制的操作;

● 客户机与服务器时间不同的操作(包括客户机与服务器两地时差不同);

11) 数据字段一致性

不同窗口中同一类数据输入域的数据接口是否一致(如添加用户及用户登录窗口对用户标识和口令的长度是否一致)。

e、图表曲线

首先,在一定的时间段观察曲线走势,如果有类似的软件可对比的话可以进行对比大体趋势,然后,再找关键点,对比关键点的数据。测试中,需要找到曲线的计算公式,找关键点进行计算。(进行对比是必要的,第一,可以节省一些不必要的工作量;第二,也有可能是编码人员所用的公式本身就有问题,而你所有测试所做的计算都是徒劳了。)

f、列表

1) 列表记录不能在一页中显示时,是否有纵向滚动栏;记录长度超过列表宽度时,是否有横向滚动栏;

2) 列表滚动栏上滑块能否自由滑动,滑块滑动时,对应内容显示是否正确;

3) 列表内容是否可直接输入;

4) 列表中每列数据能否按升序、降序排列;

16. 备份与恢复

1) 备份T日的数据,进行操作,然后恢复,查看恢复的数据是否正确;

2) 备份到不同介质上,并考虑介质空间已满的情况;

3) 用系统提供的恢复功能进行恢复:

● 用数据库进行恢复;

● 在备份和恢复还没有结束的时候,终止(掉电,网络不通等)备份和恢复;

● 有操作的时候,进行备份和恢复;

● 没有任何操作的时候,进行备份,恢复;

● 部分备份,全部备份,部分恢复,全部恢复有选择的备份和恢复;

4) 进行备份,恢复操作是否有权限限制A 有: 分别用有权限的用户和没有权限的用户进行操作B 没有:单个用户进行备份,恢复;多个用户同时进行备份和恢复。

17.系统日志的处理

1) 系统能否正确记录日志信息;

2) 系统是否有清空日志的功能;

3) 系统是否有导出日志的功能;

4) 当日志数据超过容量时,系统如何处理。

二.性能测试

具体用例不好设计,下面列出了一些有性能要求的测试点:

1) 查询

2) 保存

3) 统计

4) 刷新

5) 显示

6) 传输

7) 响应

8) 下载

打开网络上其它介质上的文件时,可制造网络拥挤情况下的文件打开操作。主要测试点,集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点;二是数据量积累到一定程度时的查询统计刷新时间,这里的一定程度是根据实际的项目和客户需求来定的。

三.极限压力测试

1) 接收大数据量的数据文件时间;

2) 大数据恢复时间;

3) 大数据导入导出时间;

4) 大批量录入数据时间;

5) 大数据量的计算时间;

6) 多客户机同时进行某一个提交操作;

7) 采用测试工具软件;

8) 编写测试脚本程序;

9) 大数据量的查询统计时间。

四. 容错测试

1) 通过断开网线的强制性停止数据传输以及重新将网线接上,查看提示信息及对系统的影响;

2) 系统断电,恢复后查看对系统的影响程度;

3) 死机后,看程序如何处理;

4) 服务器DOWN掉,客户端程序如何处理。

五.并发测试

1) 登录的并发操作:多人同时登录系统,使用不同或相同账号;

2) 提交的并发操作:多人同时提交相同的工作项、不同的工作项;

3) 对数据库操作的并发操作:多人同时从数据库中读出(或向数据库导入)相同文件、不同文件。************************

附:一些容易出错的地方

************************

一. 有关新建和修改

1. 创建或修改的内容为已经存在的内容,系统是否有提示;

2. 修改正在使用的数据。

二. 删除

DELL 信赖性测试标准(译文)

4.0 Finish Appearance Requirements 最终表面要求 4.1 Color (ASTM D1729) 颜色(ASTM D1729) Color specifications will be defined by the Industrial Design team (or its approved agent). Color tolerances will be specified in the Dell Color document (example in addendum). Finish color shall be determined from the piece part drawing or other applicable documents, and conform to the following spec: Dell Corporate Cosmetic Specification, P/N 6724U, “SPEC,DELL,COSMETIC,CORP-STD”. 颜色规格将由工业设计团队(或其认可的代理机构)定义。色彩公差将在戴尔色彩文件(如附录)中指定。最终颜色应由零件图纸或其他适用的文件确定,并符合以下规格:戴尔公司外观标准,P /N 6724U,“戴尔外观企业标准”。 Applicator shall measure L*, a* and b* at the locations specified on the piece-part drawing or other applicable document as stipulated in the Dell Corporate Cosmetic Specification, 6724U. If the location is not specified, the locations shall be approved by Dell Mechanical Engineer. 检验员应按零件图或戴尔公司外观标准6724U中规定的其他适用指定位置的文件,测量L *、a *和b *。如果文件未指定,则应由戴尔机械工程师批准。 4.2 Gloss (ASTM D523) 光泽度(ASTM D523) Gloss specifications will be defined by the Industrial Design team (or its approved agent). Gloss tolerance will be specified in the Dell Color document (example in addendum). Finish gloss shall be determined from the piece part drawing or other applicable documents, and conform to the following spec: Dell Corporate Cosmetic Specification, P/N 6724U, “SPEC,DELL,COSMETIC,CORP-STD”. 光泽度规格由工业设计团队(或其认可的代理机构)定义。戴尔的颜色文件中(如附录)中指定了光泽度公差。最终光泽度应由零件图纸或其他适用文件确定,并符合以下规格:戴尔公司外观标准,P /N 6724U,“戴尔外观企业标准”。 Applicator shall measure the gloss at the locations specified on the piece-part drawing or other applicable document. If the location is not specified, the locations shall be approved by Dell Mechanical Engineer. 检验员应测量在零件图或其他适用文件上注明的光泽度。如果位置未指定,则位置应由戴尔机械工程师批准。 4.3 Texture or Roughness, (R a, R z, R pc) 纹理或粗糙度(Ra,Rz,Rpc) Texture or roughness will be defined by the Industrial Design Team (or its approved agent). Applicator shall measure the texture or roughness at the locations specified on the piece-part drawing. If the location is not specified, the locations shall be approved by Dell Mechanical Engineer. R a, R z, & R pc must all be reported. 纹理或粗糙度由工业设计团队(或其认可的代理机构)定义。检验员应测量在零件图上指定位置的纹理或粗糙度。如果位置未指定,则应由戴尔机械工程师批准。Ra,Rz,和Rpc都必须报告。 4.4 Oxide, (ASTM B244), or Dry Film Thickness 氧化物(ASTM B244),或干膜厚度

射频可测试性设计规范

Q/SY 深圳市远望谷信息技术股份有限公司企业标准 Q/SY XXXX–2009 射频可测试性设计规范 2010-XX-X发布 2010-XX-XX实施 深圳市远望谷信息技术股份有限公司发布

目录

前言 本标准的其它系列标准: 与对应的国际标准或其它文件的一致性程度: 本标准参考内容,结合我司实际制定/修订。 本标准由深圳市远望谷信息技术股份有限公司中试部提出。本标准由深圳市远望谷信息技术股份有限公司技术部归口。本标准起草部门:中试部。 本标准主要起草人:彭辉、王文财。 本标准于2010年8月首次发布。

射频可测试性设计规范 1范围和简介 1.1范围 本规范主要规范RF单板ICT DFT 设计和FT DFT 设计,适用于产品设计中的所有成员,特别包括硬件方案设计人员,原理图项目人,RF硬件设计人员,RF 互连设计工程师、ICT 装备工程师。 本规范适用于RF单板ICT 和FT DFT 的设计。 1.2简介 本规范规定了RF单板ICT DFT 设计方法和FT DFT 设计方法,适用在RF单板方案设计阶段、PCB 布局阶段和ICT 软件编程阶段。要求开发工程师和RF CAD 设计工程师在单板方案设计、PCB 布局时遵守此规范进行ICT 测试点和FT可测试性设计,ICT 装备工程师遵守此规范进行ICT 软件编程。 制定本规范的目的之一是收集整理产品设计过程中好的射频FT DFT 设计方法并加以总结、推广,旨在从设计源头加强射频FT DFT 设计的有效性和规范性,帮助DFT 设计人员和产品开发人员更好的实现产品的射频FT DFT 特性。 1.3关键词 RF,DFT,ICT,FT,ICT 测试点。 2规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。 序号编号名称 1 3术语和定义

最新硬件测试标准(最全可靠性测试)

1. 目的 此可靠性测试标准的目的是尽可能地挖掘设计,制造中的潜在性问题,在正式生产之前寻找改善方法并解决上述问题点,为正式生产的产品在质量上做必要的保证;并检测产品是否具备设计上的成熟性、使用上的可靠性.具体包括新产品的试验、物料的试验及例行抽检试验等等。 2. 围 此指引适用于所有诺亚信高科技集团生产的移动产品。 3. 定义 3.1 技术员:设定仪器,完成相关测试项目,并记录测试结果.解决检测过程中的问题;并向工程师反 馈检测方法的缺陷和不足。 3.2 工程师:判断测试结果是否可接受;跟进问题的解决情况;改善检测方法。 4. 抽样方案 4.1 以具体的实验项目要求为准。 5. 检验容 5.1 环境可靠性试验 5.1.1 高温运行试验 试验目的:验证手机在高温环境的适应性。 试验样品:2sets 试验容:55℃,手机配齐SIM卡/T卡,装电池开机,进行12小时测试,运行时间从到达 55℃温度始算起.试验后在箱检查,要求产品的功能、外观正常.受测前样机胶塞必须安装 归位.射频指标符合国家标准.对于翻/滑盖手机,1台开盖,1台合盖.(若屏/主板不同供 应商,则样机各选2pcs,共4pcs)。 判定标准: 1、壳体外观检查,缝隙,镜片以及使用背胶固定的装饰件等粘贴牢固度。 2、功能检查(注意屏的显示是否有黑影,坏点等异常)。 3、触摸屏划写,点压准确性(如有触摸不准偏位等现象,进行屏幕校准看是否 可恢复)。 4、MP3,FM,耳机,充电,滚轮…。 5、实网通话一次,看送话和受话是否正常。

5.1.2 低温运行试验 试验目的:验证手机在低温环境下的适应性。 试验样品: 2 sets 试验容: -20℃,手机配齐SIM卡/T卡,装电池开机并运行老化软件,进行12小时测试,运行时间从到达-20℃温度始算起.试验后在箱检查,要求产品的功能、外观正常.受测前样机胶塞必须安装归位.射频指标符合国家标准.对于翻/滑盖手机,2台开盖,1台合盖.(若屏/主板不同供应商,则样机各选2pcs,共4pcs)。 特别注意:俄罗斯项目需要测试低温下的充电功能(电池电压是否会升高)。 判定标准:1、壳体外观检查,缝隙,镜片以及使用背胶固定的装饰件等粘贴牢固度。 2、功能检查(注意屏的显示是否有黑影,坏点等异常)。 3、触摸屏划写,点压准确性(如有触摸不准偏位等现象,进行屏幕校准看是否 可恢复)。 4、MP3,FM,耳机,充电,滚轮…。 5、实网通话一次,看送话和受话是否正常。 5.1.3 高温贮存试验 试验目的: 应力释放和加速材料的老化。 试验样品:2 sets 试验容:80℃,手机配电池关机,存储时间24小时,贮存时间从温度到达80℃开始算起. 在进行存储到24小时后,直接进行外观检查.受测前样机胶塞必须安装归位.再进行2小时回温后,开机进行电性能检查.对于翻/滑盖手机,2台开盖,1台合盖.(若屏/主板不同供应商,则样机各选2pcs,共4pcs)。 判定标准:1、壳体外观检查,缝隙,LENS以及使用背胶固定的装饰件等粘贴牢固度。 2、功能检查(注意屏的显示是否有黑影,坏点等异常)。 3、触摸屏划写,点压准确性(如有触摸不准偏位等现象,进行屏幕校准看是否 可恢复)。 4、MP3,FM,耳机,充电,滚轮…。 5、实网通话一次,看送话和受话是否正常。 5.1.4 低温贮存试验 试验目的:加速材料的脆化。 试验样品:2 sets

可靠性测试规范

手机可靠性测试规范 1. 目的 此可靠性测试检验规范的目的是尽可能地挖掘由设计,制造或机构部件所引发的机构部分潜在性问题,在正式生产之前寻找改善方法并解决上述问题点,为正式生产在产品质量上做必要的报证。 2. 范围 本规范仅适用于CECT通信科技有限责任公司手机电气特性测试。 3. 定义 UUT (Unit Under Test) 被测试手机 EVT (Engineering Verification Test) 工程验证测试 DVT (Design Verification Test) 设计验证测试 PVT (Product Verification Test) 生产验证测试 4. 引用文件 GB/T2423.17-2001 盐雾测试方法 GB/T 2423.1-2001 电工电子产品环境试验(试验Ab:低温) GB/T 2423.2-1995 电工电子产品环境试验(试验Bb:高温) GB/T 2423.3-1993 电工电子产品环境试验(试验Ca:恒定湿热) GB/T 2423.8-1995 电工电子产品环境试验(自由跌落) GB/T 2423.11-1997 电工电子产品环境试验(试验Fd: 宽频带随机振动) GB 3873-83 通信设备产品包装通用技术条件 《手机成品检验标准》XXX公司作业指导书 5. 测试样品需求数 总的样品需求为12pcs。 6. 测试项目及要求 6.1 初始化测试 在实验前都首先需要进行初始化测试,以保证UUT没有存在外观上的不良。如果碰到功能上的不良则需要先记录然后开始试验。在实验后也要进行初始化测试,检验经过实验是否造成不良。具体测试请参见《手机成品检验标准》。 6.2 机械应力测试 6.2.1 正弦振动测试 测试样品: 2 台

可测试性需求讲解

软件可测试性需求设计 一、引言 1、目的 提高软件的可测试性,加快测试进度,提高测试效率。 2、范围 描述的范围主要是可测性设计的特征,考虑方向及设计方法。 3、读者对象 系统分析员、设计人员、开发人员。 二、测试所需文档 1、需求规格说明书 2、概要设计说明书 3、详细设计说明书 4、系统功能清单 5、系统运行环境搭建指导书 6、系统操作指导书 三、可测试性设计需求 可测试性主要是指被测实体具有如下特征:可控制性、可分解性、稳定性、易理解性、可观察性,该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试。 1、可控制性设计需求 1)全局变量的可控制性设计需求 在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。 2)接口的可控制性设计需求 各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段

主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接,比如构造测试环境模拟接口对接,这里所指的开放接口主要是指相对于被测系统,即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。 3)模块的可控制性设计需求 对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能,在测试运行期间模块异常时能够将其隔离而不影响测试。 4)业务流程的可控制性设计需求 在测试环境满足的情况下能够控制任一单独业务流程,各业务流程具有流通性。 5)场景的可测性设计需求 将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。 2、可分解性设计需求 1)业务流程的可分解性设计需求 对于复杂的业务流程需合理设定分解点,在测试时能够对其进行分解。 2)场景的可测性设计需求 对于复杂的场景需合理设定分解点,在测试时能够对其进行分解。 3、稳定性设计需求 测试模块发布合理,不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。 4、易理解性设计需求 1)设计文档的易理解性 设计参考标准 内容描述主次要分清 依赖关系描述明确 2)接口的易理解性

CMTBF信赖性测试评估准则

光宝科技股份有限公司 文件名称:信赖性测试评估准则 信赖性测试评估准则 ( Reliability Review Guideline ) 1 目的: 1.1 为确保产品设计的信赖性,以及加强产品在市场之竞争力,建立〝零件额定使用率〞 ( Component Stress Test ) 及〝机种预估寿命〞(MTBF Prediction) 之信赖性准则, 用以为厂内设计验证之依据。 1.2 提早介入及加速产品之成熟度。 1.3 避免上市后之风险。 2. 范围: 凡是本公司电源事业部所开发之产品均适用之。 3. 权责: 3.1 零件额定使用率 ( Component Stress Test ) 及机种预估寿命 (MTBF Prediction) 由信赖性 工程师负责测试,Component Stress De-rating 之定义由设计部及信赖性共同定义。 3.2 测试样品由设计工程师负责提供,且须经过Bench Test 测试,或有机种之验证报告。 3.3 信赖性完成之测试报告须会签设计部及其部门主管认可后,才可对外发行。 3.4 信赖性完成之测试报告文件,均须透过DOC 才能对外发行。 4. 参考标准: 4.1. 零件额定使用率参考准则 : ISO 9001 NPS-MD-P-013。 4.2. 机种预估寿命( MTBF )参考准则: MIL-STD-217F, Bellcore TR332 ISSUE 6。 5. 定义: MTBF ( Mean Time Between Failure ) :平均间隔失效时间。 MTBF = 1/p λ(p λFAILURE RATE)610* HOURS 6. 作业流程图: 6.1 信赖性测试评估作业流程图如 附件1 7. 作业内容: 7.1 新产品导入会议 ( Kickoff Meeting ): 7.1.1 新机种由业务主导之新产品会议中决定: 7.1.1.1. 决定样品 ( SAMPLE ) 及其它资料日期. 7.1.1.2. BLUE BOOK 发出之日期. 7.1.1.3. 信赖性工程师应于EVT 阶段开始执行评估, 且必须于Pilot run PCB 修改定案之前 完成零件额定使用率之测试与评估, 以符合量产及客户的需求。

可靠性测试标准

丝印、喷油产品测试要求 1.0目的 指导检查员正确地进行可靠性测试,保证本公司产品满足客户品质要求。 2.0适用范围 适用于本公司生产的所有需丝印、喷油加工产品的可靠性测试。 3.0定义 3.1.可靠性:即产品在规定条件下进行的环境模拟测试,其品质特性和耐受性能达到规定的要求。 3.2.测试周期,即在往返测试中,往返各一次为一个测试周期。 3.3.单项测试:即每一个产品有多项测试要求时每一个部件只完成其中的一项测试。 3.4.多项测试:即每一个产品有多项测试要求时,每一个部件要完成2个或以上的测试项目。4.0职责 检查员应按此指引作业,保证产品达到客户的品质要求。 5.0工作步骤 5.1产品的丝印、喷油可靠性测试(包括没有明确测试要求的产品) 5.1.1测试材料及工具 5.1.1.1 78%浓度的酒精 5.1.1.2 95%浓度的酒精 5.1.1.3 200g的铁锤 5.1.1.4 粗纹的干净白布 5.1.1.5 3M 600测试胶纸 5.1.1.6 界刀 5.1.1.7 恒温恒湿炉 5.1.1.8 RCA纸带测试机 5.1.1.9 测试专用纸带 5.1.1.10 热熔胶 5.1.1.11剪钳 5.1.2 酒精测试(每次测试1—2PCS) 5.1.2.1 把粗纹的干净白布包在200g的铁锤上,包好之后用95%浓度的酒精浸润,然后将此浸润后的铁锤在丝印字钮上水平移动来回摩擦,行程30mm,频率20周期(40次)/分钟,连续摩擦50周期(100次),(移印字钮用95%浓度的酒精进行测试)。 5.1.2.2 字钮之外的其它物料用78%浓度的酒清进行测试,方法同5.1.2.1 5.1.2.3 酒清测试接受标准:测试样品测试后不褪色,不脱油,无臌胀。 5.1.3 胶纸测试(每次测试2—4PCS) 5.1.3.1 胶纸测试方法:取样品平坦部分,用界刀纵横划100个1mmX1mm的小方格(如图1),丝印也需要划方格,深度以能见底材为准,不宜过深,过深刀口附近漆膜将会翻起,影响测试,然后用3M测试胶纸紧贴在上面,用手指肉体部分或橡皮压平,然后拉着胶纸尾部以90°角方向突然向上提起同一部位连续测试10次(如图2)。 5.1.3.2 胶纸测试接受标准: a.附著力=未脱落漆膜的方格数/100; b.每小格内如果漆膜脱落面积小于方格面积的1/5可视为未脱落(如图3) c.按前a,b点判定胶纸测试接受标准:附著力为100/100方为合格 5.1.4 高温高湿测试(每种货每天平均取样不少于测试3PCS,此测试当客户有要求时才做) 5.1.4.1 将塑胶喷油试样在过炉烘干4小时后存在温度为60±2°C,温度90%±3%之恒温恒湿炉中存放48H 5.1.4.2 高温高湿测试接受标准:室温后观察漆膜无皱纹、起泡、裂纹、剥落及明显的失光等现象 为合格(由于底材老化引起的变色,失色应不影响判定)。 5.1.5 RCA测试(现只有中建产品需做此项测试) 5.1.5.1 测试方法:用剪钳将需测试之胶件取较平坦处剪下2—3cm2 ,用热熔胶纸将其固定在RCA 纸带测试机上,将测试头对需测试位置,装好纸带,根据各种胶件测试规格的不同相应的

通用可靠性测试指引(General reliability test instruction)

通用可靠性测试指引(General reliability test instruction) 制作人(Prepare By) :David Tsang 批准人(Approve By):Carrie Chueng 发出日期(Issue Date):Aug. 05, 2010

1. 目的(Purpose) 根据一般行业标准的可靠性测试要求及判定基准, 本文件旨在建立可靠性的一些测试项目、要求和操作说明来规范和指导PDP业务的可靠性。 (Basing on the general reliability test requirements and judgment criteria in industrial standard, this document aims to set up the some test items, requirements and operation instruction for standardization of reliability test of PDP business). 2. 适用范围(Scope) 本程序文件适用于与PDP有业务的产品. 如顾客没有提供测试标准或产品本身无特别安全测试要求,PDP及生产商可根据本程序内文的测试标准或指定的文件来进行可靠性测试。 (This document is applicable to the products which related to PDP business. PDP and subcontractor can conduct reliability test referring to this instruction if no specified testing instruction supplied by customer.) 3. 参考文件(Reference) 3.1 产品规格(Product specification) 3.2 电气规格(Available electrical specification) 3.3 QP-RTI-002 (NOA Accessory Testing Guideline) 4. 操作程序(Operation Procedure) 4.1 首先根据产品的物料特性、设计的要求选取下面合适的测试项目进行测试。 (First select suitable reliability test items in this document to fulfill the reliability test according to the material feature and design requirement of products) 4.2 部分测试项目只需要某个部件即可,不需整个产品或配件。 (Some test items may need a certain component/parts only, not whole product or accessory to achieve) 4.3 对于部分测试项目,除了产品要达到最低要求以外,还需提高测试要求去测试,反映产品 的实际情况,特别是在设计试产阶段。 (For some test items, the products not only meet the low limit requirement, but also test them with tightened requirements of reliability test to show the actual quality of the products for monitoring, especially the products are in initial development and pilot run stage) 4.4 测试员记录有关测试数据,完成可靠性测试后,发出测试报告。 (Operator obtain and record relative test data and release reliability test report after completed test) 5. 可靠性测试项目及要求(Reliability test items and requirements) 5.1 环境测试(Environment test) a. 低温储存测试(Low temp storage test) 温度条件(Temp condition): -20℃±5℃

华为客户可靠性测试标准

1 测试标准框架 1.1 整体框架 1.2 测试样品数 1.3 不同工艺测试项选择 2 外观等级面划分 2.1 外观等级面定义 3 测量条件及环境的要求 3.1 距离 3.2 时间 3.3 位置 3.4 照明 3.5 环境 4 表面处理可靠性测试方法 4.1 膜厚测试 4.1.1 试验目的 4.1.2 试验条件 4.1.3 合格判据 4.2 抗MEK(丁酮)测试 4.2.1 试验目的 4.2.2 试验条件 4.2.3 程序 4.2.4 合格判据 4.3 附着力测试 4.3.1 试验目的 4.3.2 试验条件 4.3.3 程序 4.3.4 合格判据 4.3.5 等级描述说明 4.3.6 测试工具 4.4 RCA纸带耐磨测试 4.4.1 试验目的 4.4.2 试验条件 4.4.3 程序 4.4.4 合格判据 4.5 酒精摩擦测试 4.5.1 试验目的 4.5.2 试验条件 4.5.3 程序 4.5.4 合格判据 4.6 橡皮摩擦测试 4.6.1 试验目的 4.6.2 试验条件 4.6.3 程序 4.6.4 合格判据 4.7 振动摩擦测试 4.7.1 试验目的 4.7.2 试验条件 4.7.3 程序 4.7.4 合格判据 4.7.5 说明 4.8 铅笔硬度测试

4.8.1 试验目的4.8.2 试验条件4.8.3 程序 4.8.4 合格判据4.8.5 测试工具4.9 抗脏污测试 4.9.1 试验目的4.9.2 试验条件4.9.3 程序 4.9.4 合格判据4.10 牛顿笔测试 4.10.1 试验目的4.10.2 试验条件4.10.3 程序 4.10.4 合格判据4.10.5 说明 4.11 显微维氏硬度测试4.11.1 试验目的4.11.2 试验条件4.11.3 程序 4.11.4 合格判据4.12 耐化妆品测试 4.12.1 试验目的4.12.2 试验条件4.12.3 程序 4.12.4 合格判据4.13 耐手汗测试 4.13.1 试验目的4.13.2 试验条件4.13.3 程序 4.13.4 合格判据4.13.5 说明 4.14 低温存储 4.14.1 试验目的4.14.2 试验条件4.14.3 程序 4.14.4 合格判据4.15 高温存储 4.1 5.1 试验目的4.15.2 试验条件4.15.3 程序 4.1 5.4 合格判据4.16 交变湿热 4.16.1 试验目的4.16.2 试验条件4.16.3 程序 4.16.4 合格判据4.17 温度冲击 4.17.1 试验目的4.17.2 试验条件4.17.3 程序

可靠性测试标准

Q/GSXH.Q. 质量管理体系第三层次文件1004.03-2001 可靠性试验规范

拟制:审核:批准: 海锝电子科技有限公司版次:C版 可靠性试验规范 1. 主题内容和适用范围 本档规定了可靠性试验所遵循的原则,规定了可靠性试验项目,条件和判据。 2. 可靠性试验规定 2.1 根据IEC国际标准,国家标准及美国军用标准,目前设立了14个试验项 目(见后目录〕。 2.2 根据本公司成品标准要求,用户要求,质量提高要求及新产品研制、工艺 改进等加以全部或部分采用上述试验项目。 2.3 常规产品规定每季度做一次周期试验,试验条件及判据采用或等效采用产 品标准;新产品、新工艺、用户特殊要求产品等按计划进行。 2.4 采用LTPD的抽样方法,在第一次试验不合格时,可采用追加样品抽样方 法或采用筛选方法重新抽样,但无论何种方法只能重新抽样或追加一次。 2.5 若LTPD=10%,则抽22只,0收1退,追加抽样为38只,1收2退。 抽样必须在OQC检验合格成品中抽取。 3.可靠性试验判定标准。

环境条件 (1)标准状态 标准状态是指预处理, 后续处理及试验中的环境条件。论述如下: 环境温度: 15~35℃ 相对湿度: 45~75% (2)判定状态 判定状态是指初测及终测时的环境条件。论述如下: 环境温度: 25±3℃ 相对湿度: 45~75% 4.试验项目。 目录 4.1 高温反向偏压试验------------------------------------ 第4页4.2 压力蒸煮试验------------------------------------ 第6页4.3 正向工作寿命试验------------------------------------ 第7页4.4 高温储存试验------------------------------------ 第8页4.5 低温储存试验------------------------------------ 第9页4.6 温度循环试验------------------------------------ 第10页4.7 温度冲击试验------------------------------------ 第11页4.8 耐焊接热试验------------------------------------ 第12页4.9 可焊性度试验------------------------------------ 第13页4.10 拉力试验------------------------------------ 第14页

产品可测试性需求分析模板

产品可测试性需求报告

文档修订记录

目录 1目的............................................................................................................................. - 1 -2范围............................................................................................................................. - 1 -3术语............................................................................................................................. - 1 -4引用文件 ..................................................................................................................... - 1 -5测试文档 ..................................................................................................................... - 2 - 5.1测试参考文档............................................................................... 错误!未定义书签。 5.2测试提交文档............................................................................... 错误!未定义书签。6测试安排和计划 .......................................................................................................... - 3 - 6.1测试重点.................................................................................................................... - 3 - 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附录.................................................................................................. 错误!未定义书签。

信赖性测试标准指引

信赖性试验标准 文件编号AL-3-07-006 制定部门品保部文件版本 1.0 生效日期 制定批准

目录 1.前言------------------------------03 2.职责------------------------------04 3.盐雾试验-----------------------------03 4.百格试验-----------------------------04 5.酒精试验-----------------------------06 6.RCA耐磨试验--------------------------11 7.耐高压试验----------------------------19 8.裸机跌落试验--------------------------12 9.包装振动试验--------------------------13 10.包装跌落试验--------------------------14 11.高温工作试验--------------------------15 12.低温工作试验--------------------------16 13.高温储存试验--------------------------1 14.低温储存试验--------------------------1 15.高低温冲击试验-------------------------17 16.老化试验----------------------------18 17.静电试验----------------------------20 18.吊重试验----------------------------21 19.线材摇摆试验--------------------------20 20.成品模拟测试--------------------------20

产品可靠性测试规范

产品可靠性测试规范 Standardization of sany group #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

产品可靠性测试规范 1.目的 本文制定产品可靠性测试的要求和方法,确保产品符合可靠性测试要求。 2. 范围 本文件适用于此CPIT有限公司所生产的所有产品。 3. 定义 N/A 4. 职责 品控部QC/QA人员负责本文件所规定的通讯产品的可靠性测试内 容要求在检查过程中的实施. 品控部经理或其授权人负责本文件所规定的内容与实际情况相符并正确,并监督品控部QC/QA人员对本文件的实施. 5.内容 实验顺序 除非特殊要求,试验样品进行试验时,一般按下表的顺序进行: 实验条件及容差: 5.2.1 实验条件:

5.2.2 试验条件容差: a.温度容差:试验样品除必要的支承点外,应完全被空气包围。试 验区测量系统的温度和包围试验样品空气各处的温度容差:高温为 +/-2℃,低温为+/-3℃. b.湿度容差:+/-5%. c.振动振幅容差:+/-15%. d.振动频率容差:+/-1Hz. 5.2.3落地实验标准 5.2.3.1 落地实验应以箱体一角三棱六面按规定高度自由落下的方式进行。

重量高度 0~10kg以内 75cm 10~20kg以内 60 cm 20kg以上 53 cm 5.2.3.2 注意事项: 5.2.3. 体内机台及包材在每个步骤后应该检验。 5.2.3. 任一步骤发现部件有损坏的应立即更换。 5.2.3. 详细记录。 5. 3 样品数量: 测试时机: 6.4.1 产品处于PP时. 6.4.2 第一次量产. 6.4.3 当产品的材质,设计等变更时. 6.4.5 生产出现异常时. 6.4.6 新客户需重新进行产品评估时. 6.4.7 客户投诉与之相关时. 6.程序 从QA PASS的成品机中随机抽取20台,重新检查其外观及功能,确保其为合格产品方可进行以下步骤. 按试验顺序分别完成各项测试.对于每个测试中所出现的不合格品交测试组或相关技术部门分析其原因. 对于不合格品必须有相应的备份成品机进行补充或进行修理使其重新达到合格要求.

软件的测试要求规范

软件测试标准规范 1目的 为了确保软件产品质量,使产品能够顺利交付和通过验收,特编写本文档,以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 项目测试负责人组织编制《测试计划》、《测试方案》,指导和督促测试人员完成各阶段的测试工作。 项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务,并按要求填写《问题报告及维护记录》。 测试经理依照确认规程和准则对工作产品进行确认,提出对确认规程和准则的修改意见 项目负责人组织测试环境的建立。 项目经理审核负责控制整个项目的时间和质量。 研发人员确认修改测试人员提交的bug。 4工作流程 4.1测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读,真正弄懂系统需求和详细设计。 4.2制订《测试方案》

在测试之前,由项目负责人根据《测试计划》的要求,组织人员编制相应的《测试方案》,《测试方案》应包括以下内容: 测试目的; 所需人员及相应培训要求; 测试环境、工具和测试软件; 测试用例、测试数据和预期的结果。 4.3单元测试 项目开发实现过程中,每个程序单元(程序单元的划分视具体开发工具而定,一般定为函数或子程序级)编码调试通过后,要及时进行单元测试。 单元测试由单元开发者自己进行,使用白盒测试方法,根据程序单元的控制流程,争取达到分支覆盖。对于交互式运行的产品,不便于进行自动测试的,可以采用功能测试的方法进行。 单元测试针对程序模块,从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等; 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试; 单元测试停止标准:完成了所有规定单元的测试,单元测试中发现的bug已经得到修改。 4.4集成测试 编码开发完成,项目组内部应进行组装测试。 集成测试由项目负责人组织策划(编写测试计划、测试用例)并实施。集成测试着重对各功能模块之间的接口进行测试,验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法,即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》,测试结果应形成《测试报告》。 4.5系统测试

相关主题