软件测试规程标准Word文档下载推荐.docx

软件测试规程标准Word文档下载推荐.docx

《软件测试规程标准Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《软件测试规程标准Word文档下载推荐.docx（27页珍藏版）》请在冰豆网上搜索。

1 .测试范围与内容 10

2 .测试方法 10

3.测试环境与测试辅助工具 10

4 .测试完成准则 10

5 .人员与任务表 11

6 .缺陷管理与改错计划 11

7.测试计划审批意见表 11

附录2.2：

系统测试用例 12

1. 文档介绍 12

1.1文档目的 12

1.2文档范围 12

1.3读者对象 12

1.4参考文献 12

1.5术语与缩写解释 12

2. 测试需求分析 12

2.1被测试对象的介绍 12

2.2测试范围与目的 12

2.3测试环境与测试辅助工具的描述 12

3. 测试用例 12

3.1 功能测试用例 12

3.1.1功能A/B描述 12

3.2 性能测试用例 13

3.2.1性能用例A/B描述 13

3.3安全性测试用例 13

3.3.1安全用例A/B描述 13

3.4界面测试用例 14

3.4.1界面测试考虑几种情况：

14

3.4.2界面测试用例 14

3.5安装与反安装测试 14

3.5.1反装与反安装测试用例 14

3.6升级测试用例 15

3.6.1升级用例 15

3.7压力测试 15

3.7.1 压力测试用例 15

3.8 增、改、删、查询常用用例 16

3.8.1新增用例 16

3.8.2修改用例 16

3.8.3删除用例 16

3.8.4查询用例 17

3.9 用例的审批意见表 17

3.9.1 审批表 17

附录2.3：

系统测试报告 18

附录2.4：

缺陷管理报告 19

1. bug状态 19

2. bug提交表 19

3. bug统计表 19

4. 缺陷管理流程 20

附录2.5测试分析报告 错误！

未定义书签。

22

一.概述

本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。

二.软件测试理论

1 .什么是软件测试

无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。

在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。

我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；

但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。

如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。

测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。

目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。

软件测试在软件生命周期中横跨两个阶段。

通常在编写出每个模块之后就对它做必要的测试（称为单元测试），模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。

在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。

2 .系统测试的简介

系统测试（SystemTest,ST）是将经过测试的子系统装配成一个完整系统来测试。

它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。

测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

系统测试过程域是SPP模型的重要组成部分。

本规范阐述了系统测试的规程，该规程的“目的"

、“角色与职责”、“启动准则”、“输入”、“输出”、“主要步骤”、“完成准则”和“度量”、“产品发布准则”均已定义。

本规范适用于国内IT企业的软件研发与测试项目。

建议用户根据自身情况（如商业目标、研发实力等）适当地进行修改本规范，以推广使用。

三.软件测试流程

1.软件测试流程图

系统测试流程如图1・1所示。

由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束如图1・2所示。

这样可以提高系统测试的效率。

（图1-1）

（图1-2）

2.系统测试细则

项目经理设法组建富有成效的系统测试小组。

系统测试小组的成员主要来源于：

◊机构独立的测试小组（如果存在的话）。

◊邀请其它项目的开发人员参与系统测试。

◊本项目的部分开发人员。

◊机构的质量保证人员。

系统测试小组应当根据当前项目的特征确定测试内容。

一般地，系统测试的主要内容包括：

•功能测试。

即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。

由于正确性是软件最重要的质量因素，所以功能测试必不可少。

•健壮性测试。

即测试软件系统在异常情况下能否正常运行的能力。

健壮性有两层含义：

一是容错能力，二是恢复能力。

•性能测试。

即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考。

•安全测试。

即检查系统对非法侵入的防范能力。

安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。

•用户界面测试。

重点是测试软件系统的易用性和视觉效果等。

•安装与反安装测试。

对软件的全部、部分或升级安装与反安装处理过程的测试。

系统测试过程域产生的主要文档有：

◊ 《系统测试计划》，模板见 ［附录2.1］。

◊ 《系统测试用例》，模板见 ［附录2.2］。

◊ 《系统测试报告》，模板见 ［附录2.3］。

◊ 《缺陷管理报告》，模板见 ［附录2.4］。

3 •系统测试注意事项

根据《软件开发规范》仔细检查软件的界面是否合乎要求。

（每一个子界面也应如此）其中，应注意提示信息和软件开发商信息是否正确。

小的图标是否合乎要求。

检查菜单当中的各项功能和功能按钮是否能正确使用。

根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例。

（以边界值法、等价类划分法为主）。

对功能界面要求注意与功能相关的信息显示及显示位置是否正确。

数据输入界面应注意文字格式及数字和文字的区别。

是否能够正确保存信息。

数据查询（显示）界面应注意显示信息是否正确和完整。

是否能正确查询。

对打印功能要求注意打印出的报表是否正确。

（包括报表各项信息、数据信息和报表字体等）。

这一项测试主要是对软件的错误处理功能进行测试。

就是进行错误的操作或输入错误的数据，检杏软件对这些情况是否能做出判断并予以提示。

特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

对测试错误结果一定要有一个确认的过程。

一般有A测试出来的错误，一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。

制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

"

I归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

四.系统测试规程

软件系统测试的基本规程由下述几个步骤组成：

1. 目的

对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

2. 角色与职责

• 项目经理组建系统测试小组，并指定一名成员任测试组长。

• 系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档。

测试组长管理上述事务。

• 开发人员及时解决测试人员发现的缺陷。

3. 启动准则

• 产品需求和系统设计文档完成之后。

4. 输入

• 产品需求和系统设计文档

5. 主要步骤

［Stepl］制定系统测试计划

系统测试小组各成员共同协商测试计划。

测试组长按照指定的模板起草《系统测试计划》。

该计划主要包括：

•测试范围（内容）

•测试方法

•测试环境与辅助工具

•测试完成准则

•人员与任务表

项目经理审批《系统测试计划》。

该计划被批准后，转向EStep2］o

［Step2］设计系统测试用例

•系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》0

•测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。

该测

试用例通过技术评审后，转向［Step3］o

［Step3］执行系统测试

•系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。

•将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。

［Step4］缺陷管理与改错

•从［Stepl］至［Step3］,任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。

该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。

•开发人员及时•消除已经发现的缺陷。

•开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。

6. 输出

• 消除了缺陷的最终软件系统

• 系统测试用例

• 系统测试报告

• 缺陷管理报告

7. 结束准则

• 对于非严格系统可以采用“基于测试用例”的准则：

◊ 功能性测试用例通过率达到100%;

◊非功能性测试用例通过率达到80%时。

• 对于严格系统，应当补充“基于缺陷密度”的规则：

◊ 相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m0例如n大于10,m小于等于1。

• 木规程所有文档已经完成。

8. 度量

测试人员和开发人员统计测试和改错的工作量、文档的规模、以及缺陷的个数与类型，并将此度量数据汇报给项目经理,也就是《系统测试报告》。

1）测试度量类型：

A：

项目度量：

规模、测试工作量、测试进度、测试生产率

B：

质量度量：

缺陷率（阶段）、缺陷排除率、可靠性等

2） 测试用例设计阶段的度量

规模：

测试方案数量、测试用例数量、测试工具设计数景、测试用例/人月

工作量：

文档的草稿编写工作量、评审前阅读工作量、评审工作量、修改工作量

C：

进度：

每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率

D：

缺陷：

评审过程中出现的错误数量、缺陷数量，级别

3） 测试执行阶段的度量：

1测试用例执行率 2测试用例通过率

3测试用例问题发现率 4BUG数量

5BUG级别统计 6BUG分布统计（模块）

7BUG分布统计（阶段） 8BUG密度

9.产品发布准则

测试完毕，整理产品发布包和相关文档并发布。

对于新产品来说，必要的文档必须包括：

（1） 安装操作手册

（2） 产品说明书

（3） 管理维护手册