软件测试规范.docx

软件测试规范.docx

《软件测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试规范.docx（9页珍藏版）》请在冰豆网上搜索。

软件测试规范

软件测试规范

编写人员

张文文

编写完成时间

2015.3.30

目录

1.文档适用范围-3-

2.软件测试基本知识-3-

2.1什么是软件测试-3-

2.2软件测试的目的-3-

2.3测试与软件开发各阶段的关系-3-

2.4测试中权衡的三个重要维度-4-

2.5确认和验证的关系-4-

3.软件测试流程-5-

3.1软件测试流程图-5-

3.2软件测试流程详解-5-

3.2.1单元测试-5-

3.2.2集成测试-6-

3.2.3系统测试-6-

3.2.4验收测试-6-

3.3软件测试类型-6-

3.3.1功能测试-6-

3.3.2界面测试-7-

3.3.3数据处理测试-7-

3.3.4流程测试-7-

3.3.5极限测试-7-

3.3.6并发测试-7-

3.3.7安全测试-7-

3.3.8性能测试-7-

3.3.9安装测试-7-

3.3.10兼容性测试-8-

3.3.11强度测试-8-

3.3.12用户测试-8-

4.问题管理-8-

4.1问题跟踪分析图-8-

4.2问题类型-9-

4.3问题优先级-9-

4.4问题状态-9-

4.5问题解决方式-9-

5.测试停止标准-10-

5.1指标-10-

5.1.1BUG走势图-10-

5.1.2模块覆盖率-10-

5.1.3测试用例执行情况-10-

5.2测试停止标准-11-

1.文档适用范围

本文档的读者对象为：

测试人员。

本文档适用于项目开发过程的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试软件测试流程。

2.软件测试基本知识

2.1什么是软件测试

软件测试的定义是：

为了发现程序中的错误而执行的程序的过程。

软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。

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

2.2软件测试的目的

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

1）测试是为了发现程序中的错误而执行程序的过程；

2）好的测试方案是极可能发现迄今目前为止尚未发现的错误的测试方案；

3）成功的测试是发现了至今为止尚未发现的错误的测试。

2.3测试与软件开发各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排自底向上，逐步集成的过程。

第一集测试为上一级测试准备条件。

首先是对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。

再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。

随后再对照需求，进行确认测试。

最后从系统全体出发，运行系统，看是否满足要求。

2.4测试中权衡的三个重要维度

测试时间、测试成本和测试质量构成测试过程中需要关注的三个重要维度。

三个重要维度相互制约、相互影响。

在测试中，永远无法实现时间、成本和质量的三赢，为其中2个目标所做的努力，都必须以付出第三个目标的损失为代价，此外我们永远都不可能穷尽所有的测试内容。

因此必须综合权衡作出取舍。

2.5确认和验证的关系

确认（validation）：

是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。

它包括需求规格说明的确认和程序的确认，而程序的确认又分为静态确认和动态确认。

静态确认一般不在计算机上实际执行程序，而是通过人工分析或者程序正确性证明来确认程序的正确性；动态确认主要通过动态分析和程序测试来检查程序的执行状态，以确认程序是否有问题。

验证（verification）：

则试图证明在软件生存期各个阶段，以及阶段性的逻辑协调性、完备性和正确性。

确认与验证工作都属于软件测试。

在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表达出来

3.软件测试流程

3.1软件测试流程图

3.2软件测试流程详解

3.2.1单元测试

在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。

因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。

模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。

在这个测试步骤中所发现的往往是编码和详细设计的错误。

在单元测试中主要进行的是功能测试。

3.2.2集成测试

集成测试是把经过单元测试的模块放在一起形成一个子系统来测试。

模块相互间的协调和通信是这个测试过程中的主要问题，因此这个步骤着重测试模块的接口。

在集成测试中主要进行功能测试和简单的业务逻辑测试。

3.2.3系统测试

系统测试是把经过测试的于系统装配成一个完整的系统来测试。

在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。

在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。

在系统测试中主要进行完整的业务逻辑测试、界面测试、兼容性测试、性能测试、安全测试等等。

3.2.4验收测试

把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。

验收测试的目的是验证系统确实能满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。

常用的验收测试方法有：

α测试和β测试。

3.3软件测试类型

3.3.1功能测试

对系统功能满足程度与实现程度的测试，此测试只关心测试对象功能方面的需求，而不考虑其它细节；结束标志：

系统功能满足设计需求

3.3.2界面测试

在测试对象满足功能需求的前提下进行，此测试必须包括通用控件标准的测试。

例如：

数据窗口的滚动条。

——可参考《WEB（UI）设计规范》

3.3.3数据处理测试

对测试对象的数据处理过程进行测试，包括输入、处理、输出。

3.3.4流程测试

包括业务流程、数据流程、逻辑流程、正反流程

3.3.5极限测试

对极限值、边界值的测试

3.3.6并发测试

主要指系统在网络环境、并发环境、多用户条件下的运行测试；

3.3.7安全测试

包括加密、解密、数据备份、恢复、病毒检测等测试；

3.3.8性能测试

包括适应性、健壮性、可恢复性、以及灾难恢复能力

3.3.9安装测试

是软件发布前必须进行的测试，确保发布的软件产品为最新

3.3.10兼容性测试

操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性。

3.3.11强度测试

包括大容量数据、极限数据、致命错误操作等

3.3.12用户测试

用户测试是处于系统测试阶段结束和系统试运行阶段开始之前的一个相对独立的阶段。

测试的主体，由开发技术人员转为最终应用者。

用户通过对系统全部功能和工作流程的亲手应用、测试，逐步全面了解系统是否完全实现了需求说明书的要求，从而接受和认可该软件，这是保证系统功能和流程正确性、完整性和实用性的关键。

实践证明，只有用户试用，才能提出合理建议，促使软件实用化和产品化。

4.问题管理

4.1问题跟踪分析图

4.2问题类型

 Bug（缺陷）

测试过程维护过程发现影响系统运行的缺陷 

 NewFeature（新需求）

对系统提出的新功能

 Task（任务）

需要完成的任务

 Improvement（改进）

对现有系统功能的改进

4.3问题优先级

 Blocker（紧急）

 阻塞开发或测试的工作进度，或影响系统无法运行的错误

 Critical（重要）

 系统崩溃，丢失数据或内存溢出等严重错误、或者必需完成的任务

 Major（一般）

 主要的功能无效、新增功能建议

 Minor（次要）

 功能部分无效或对现有系统的改进

Trivial（无关紧要）

 拼写错误，文本未对齐等

4.4问题状态

 Open（打开）

 表示问题被提交等待有人处理

 InProgress

 问题在处理当中,尚未完成

 Resolved

 问题曾解决,但解决结论未获认可,需要重新分配解决

 Reopened

 问题解决,确认结果是问题仍然存在、未解决，置为“reopen”

 Closed

 问题解决,确认结果是问题已不存在、已解决，置为“closed”

Confirm

问题尚待确定/暂时无法解决，置为“confirm”

4.5问题解决方式

 Fixed（已修复）

 问题已经解决 

 Won'tFix（无需修复）

 问题为解决-将不会解决的问题

 Duplicate（重复）

 重复的问题

 Incomplete（不完整）

 问题描述得不够准确,安全. 

 CannotReproduce（无法重现）

 问题重现失败,或者无足够的信息重现问题.

5.测试停止标准

由于软件测试是一项复杂的工程，若对程序进行反复的无休止的测试，无谓地消耗了大量的人力、物力和时间。

为了能合理地利用现有资源，提高工作效率，制定了：

BUG走势图、模块覆盖率和测试用例执行情况三项指标，并根据这三项指标制定出测试停止标准。

5.1指标

5.1.1BUG走势图

该指标以曲线图或者柱形图的形式展现，反映出每天发现提交各种问题类型的情况。

5.1.2模块覆盖率

该指标体现出一套软件中各个模块的测试用例制定情况，是否各个模块或各个模块下的各个功能是否都有测试用例，各模块的测试用例占所有用例的比例。

5.1.3测试用例执行情况

该指标体现出各个模块的测试用例执行情况，统计测试通过的用例数量和测试未通过的用例数量，计算已测试的用例数量和未测试的用例数量。

测试用例通过率=测试通过的用例数/总测试用例数*100%

测试执行覆盖率=已测试的用例数量/总测试用例数*100%

5.2测试停止标准

1.BUG走势图逐渐趋于平缓，趋于水平；

备注：

BUG走势图中，系统错误、功能错误、数据处理错误在连续3个工作日内未出现BUG，其他错误在连续3个工作日内未出现5个以上（含5个）错误。

2.模块覆盖率为100%（即：

系统所有模块及其相关子模块）；

3.测试执行覆盖率为100%，测试用例通过率为90%以上。

此时，可对软件停止测试。

【注】：

需注意缺陷修复标准：

A类BUG级别和B类BUG级别的错误修复率为100%；

C类BUG级别和D类BUG级别的错误修复率为95%；

E类BUG级别的错误修复率应到60%以上。

其中：

问题优先级为“Blocker”：

A类；问题优先级为“Critical”：

B类；问题优先级为“Major”：

C类；问题优先级为“Minor”：

D类；问题优先级为“Trivial”：

E类。