软件测试停止标准

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件测试停止标准

1. 简介

1.1 目的

本文档的目的是为软件单元测试、集成测试、系统测试提供停止标准。

1.2 范围

本文档适用于使用RUP 的软件项目的测试活动。

1.3 文档结构

第一部分:

简介,介绍软件停止标准的目的,本标准的适用范围,以及在本文档中使用的词汇的解释。第二部分:

描述软件单元测试、集成测试、系统测试停止标准。

第三部分:

列出本标准使用的参考文献。

第四部分:

附录

1.4 词汇表

缺陷(Defect)

缺陷是对软件产品预期属性的偏离现象。

覆盖率(Coverage rate)

语句覆盖率、测试用例执行覆盖率,测试需求覆盖率等的总称。

2. 软件测试停止标准

2.1 软件测试停止标准

1) 软件系统经过单元、集成、系统测试,分别达到单元、集成、系统测试停止标准。

2) 软件系统通过验收测试,并已得出验收测试结论。

3) 软件项目需暂停以进行调整时,测试应随之暂停,并备份暂停点数据。

4) 软件项目在其开发生命周期内出现重大估算,进度偏差,需暂停或终止时,测试应随之暂停或

终止,并备份暂停或终止点数据。

2.2 单元测试停止标准

1) 单元测试用例设计已经通过评审

2) 按照单元测试计划完成了所有规定单元的测试

3) 达到了测试计划中关于单元测试所规定的覆盖率的要求

4) 被测试的单元每千行代码必须发现至少3 个错误

5) 软件单元功能与设计一致

6) 在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准

软件测试停止标准.doc

2

2.3 集成测试停止标准

1) 集成测试用例设计已经通过评审

2) 按照集成构件计划及增量集成策略完成了整个系统的集成测试

3) 达到了测试计划中关于集成测试所规定的覆盖率的要求

4) 被测试的集成工作版本每千行代码必须发现2 个错误

5) 集成工作版本满足设计定义的各项功能、性能要求

6) 在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准

2.4 系统测试停止标准

1) 系统测试用例设计已经通过评审

2) 按照系统测试计划完成了系统测试

3) 达到了测试计划中关于系统测试所规定的覆盖率的要求

4) 被测试的系统每千行代码必须发现1 个错误

5) 系统满足需求规格说明书的要求

6) 在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准

2.5

1)一级致命错误(可对应目前BUG体系中的“非常严重”):

致命性问题主要为:系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

具体基本上可分为:

○严重花屏

○内存泄漏

○用户数据丢失或破坏

○系统崩溃/死机/冻结/死循环

○模块无法启动或异常退出

○严重的数值计算错误

○功能设计与需求严重不符

○其它导致无法测试的错误

2)二级严重(可对应目前BUG体系中的“严重”)

严重性问题主要为:影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性。

具体基本上可分为:

○功能未实现

○功能错误

○系统刷新错误

○语音或数据通讯错误

○轻微的数值计算错误

○系统所提供的功能或服务受明显的影响

3)三级一般(可对应于目前BUG体系中的“普通”)

一般性问题主要为:界面、性能缺陷

具体基本上可分为:

○操作界面错误(包括数据窗口内列名定义、含义是否一致)

○边界条件下错误

○提示信息错误(包括未给出信息、信息提示错误等)

○长时间操作无进度提示

○系统未优化(性能问题)

○数据库中有过多的空字段

○不同浏览器测试,IE,谷歌,火狐,opera浏览器(希望程序员自己下这个4个跑一哈)

○光标跳转设置不好,鼠标(光标)定位错误

○下载东西时候,迅雷下载一定要通过,后台不能出错

● 提示(可对应于目前BUG体系中的“轻微及建议”)

4)四级小错误

○界面不规范

○辅助说明不清楚

○输入输出不规范

○提示窗口未用行业术语

○可输入区域和制度区域没有明显的区别标志

5)测试建议

2.6 缺陷修复率标准

1) 一、二级错误修复率应达到100%(是否应该对一、二、三级错误进行定义?)

2) 三、四级错误修复率应达到80%以上

3) 五级错误修复率应达到60%以上

2.7 覆盖率标准

语句覆盖率最低不能小于80%

测试用例执行覆盖率应达到100%

1。是否达到原先定义的覆盖标准。

比如原先定义测试95%的功能条目,测试100%的需求条目,只对接口类做集成测试等等。达到标准了就停。

2。所发现的缺陷(bug或者功能不足等等)低于预先定义的上限。

比如定义每周发现的缺陷少于5个,即可停止。

3。找到缺陷耗费的代价超过这个缺陷可能导致的损失

这个的依据是:权限开始好找,越到后面越难找。具体操作的时候可以根据公司实际情况来定义什么样的情况算是“花费的代价大”

4。团队集体同意(开发,管理,测试,市场,销售人员)

由于利益和市场的原因,必须推出产品了。哪怕有bug也得上了。

是个关于软件测试结束标准的问题,我是这么回答的:

(在这里回答过/viewthread.php?tid=245&extra=page%3D1)

就我个人经验来看:

就时间而言,毫无疑问测试是需要在规定的时间内(验收之前)要完成的。

就软件而言,测试却不会结束,因为你交给用户的时候,实际上他也是在测试,只是这时候叫做bata测试

了。

这个也扯不清,楼主需要的我明白。那么给几个通用的标准吧:

1、所有测试用例执行完成。

2、所有缺陷均关闭或者在商定的范围内

3、依据项目组或高层的要求结束

4、可能由于时间因素,依据客户的需求结束测试

5、通过测试过程的执行,系统已经满足了指定的功能和非功能性的需求了

6、如果是回归测试的话,这个测试已经验证BUG被修复

------------------------

相关文档
最新文档