完整word版软件测试流程DOC.docx

完整word版软件测试流程DOC.docx

《完整word版软件测试流程DOC.docx》由会员分享，可在线阅读，更多相关《完整word版软件测试流程DOC.docx（18页珍藏版）》请在冰豆网上搜索。

完整word版软件测试流程DOC

软件测试流程

1.目的

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

2.范围

本文适用于软件开发、测试人员，以及软件项目管理人员。

3.参考资料

《缺陷管理规范》

《测试执行规范》

《文档测试指南》

《项目测试计划模版》

《测试用例设计规范》

《功能测试用例模版》

《集成测试用例模版》

《项目测试报告模版》

《自动化测试计划模版》

《性能测试计划模版》

4.测试过程描述

4.1测试流程图

 4.2需求评审

4.2.1目的

从源头把握软件质量，并确保开发结果与实际需求相一致

4.2.2角色与职责

需求人员：

《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；

评审人员：

评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。

4.2.3启动标准

《需求规格说明书》编写完成

4.2.4工作流程图

4.2.5输入/输出

输入：

《需求规格说明书》

输出：

需求缺陷

4.2.6规范

参见《文档评审指南》

4.3测试计划

4.3.1目的

明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。

4.3.2角色与职责

测试负责人：

根据《项目整体计划》、《需求规格说明书》编制《测试计划》，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写内容参见《项目测试计划模版》。

4.3.3启动标准

需求评审完成，《项目整体计划》编制完成。

4.3.4 工作流程图

 4.3.5输入/输出

输入：

《需求规格说明书》、《项目整体计划》

输出：

《测试计划》

4.3.6规范

测试计划编写内容参加《测试计划模版》。

4.4测试设计

4.4.1目的

通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。

4.4.2角色和职责

测试人员：

采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。

评审人员：

对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。

4.4.3启动标准

需求文档评审完成且测试计划制定完成。

4.4.4工作流程图

4.4.5输入输出

输入：

《需求规格说明书》

输出：

《测试用例》、测试用例评审缺陷

4.4.6规范

测试用例实际内容参见《测试用例模版》，测试用例评审规范参见《文档测试规范》。

4.5 功能测试执行

4.5.1目的

依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。

4.5.2角色与职责

测试人员：

依据测试计划，按照测试用例对软件功能进行测试。

对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。

在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。

开发人员：

对于测试人员提交的缺陷进行确认、修复。

开发经理：

对测试人员与实际开发人员意见不一的问题进行裁决。

4.5.3启动标准

测试用例编写完成且用例评审完成

4.5.4工作流程图

4.5.5输入输出

输入：

功能测试用例

输出：

功能测试缺陷

4.5.6规范

测试执行过程需按照《测试行为规范》进行，缺陷管理需按照《缺陷管理规范》进行。

4.6集成/性能测试设计

4.6.1目的

为集成测试提供测试依据，记录并保证集成测试覆盖度；依据《测试计划》及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。

4.6.2角色和职责

测试人员：

以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开发。

4.6.3启动标准

功能测试完成且软件功能无中断

4.6.4工作流程图

4.6.5输入输出

输入：

《功能测试用例》、功能测试缺陷、《测试计划》、性能指标

输出：

《集成测试用例》、《性能测试计划》、《性能测试用例》、性能测试脚本

4.6.6规范

《集成测试用例》实际内容参见《集成测试用例模版》；

《性能测试计划》实际内容参见《性能测试计划模版》。

4.7集成测试/性能测试

4.7.1目的

以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。

4.7.2角色和职责

测试人员：

以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。

4.7.3启动标准

集成/性能测试设计完成

4.7.4工作流程图

4.7.5输入输出

输入：

《集成测试用例》、《测试计划》之集成测试事项、《性能测试计划》、《性能测试用例》

输出：

集成测试缺陷

4.7.6规范

测试执行过程需按照《测试行为规范》进行，缺陷管理需按照《缺陷管理规范》进行。

4.8文档测试

4.8.1目的

保证对客户的指导与实际系统的使用状况相一致。

4.8.2角色和职责

测试人员：

对《用户操作手册》及在线帮助进行测试，记录文档描述缺陷，并跟踪直至缺陷的验证关闭。

需求人员：

对测试人员提出的文档描述缺陷进行修正。

4.8.3启动标准

《用户操作手册》或在线帮助编写完成

4.8.4工作流程图

4.8.5输入输出

输入：

《用户操作手册》、在线帮助

输出：

文档缺陷

4.8.6规范

参见《文档测试指南》

4.9测试报告

4.9.1目的

真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。

4.9.2角色与职责

测试负责人：

真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。

4.9.3启动标准

集成测试完成

4.9.4工作流程图

4.9.5输入输出

输入：

各测试阶段、测试项实际测试情况

输出：

《项目测试报告》

4.9.6规范

5新产品或工程管理流程

5.1需求调研

在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入，在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需求达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

5.2制定测试计划

进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接收标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。

5.3需求Review

开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。

5.4设计Review

在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原则，并对概要设计和详细设计提出自己的见解。

设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。

5.5测试设计

在设计测试方案时，首先分解测试内容，对于一个复杂的系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。

然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的被测系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。

每个测试用例必须包括以下几个部分：

（1）标题和编号

（2）测试的目标和目的

（3）输入和使用的数据和操作过程

（4）期望的输出结果

（5）其他特殊的环境要求、次序要求、时间要求等

5.6开发测试工具和准备测试数据

在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本省的优势来提高工作效率。

5.7测试执行

当所有必须的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。

在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。

为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。

5.8回归测试

在测试中发现的任何问题和错误都必须有一个明确的解决方法。

一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。

另一方面，对于版本更新后的软件也必须进行同样的测试过程。

5.9测试分析报告

测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。

5.10产品发布

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

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

（1）安装操作手册

（2）产品白皮书

（3）管理维护手册

（4）用户操作手册

（5）测试报告

5.11版本控制

新版本软件发布之后，马上对代码进行质量控制。

（1）BuildMaster给新版本的源代码打一个cvstag，方便代码回滚checkout。

比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tagp2p3.3.2.这样做的一个好处是，在目前的软件的基础上做了修改并发布的新版本后，如果需要checkout某个版本的源代码，则可以通过这个版本的tag来checkout，代码的修改可以在该版本上进行。

（2）BuildMaster对新发布的软件源代码进行cvslock，不允许开发人员在软件发布之后commit源代码，直到有新版本需要修改再给开发人员开放commit权限。

这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本与当前最新的发布版本一致。

6工程维护管理流程

6.1收集新需求

新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在bug管理系统报bug，但只是记录，不需求马上修改。

当然了，对于紧急的工程故障，需要马上修改和测试。

6.2确认新需求

与工程人员或客户或产品经理确认新需求，确保需求被理解正确。

6.3需求讨论

当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。

6.4bug跟踪管理

确认所有需要修改的新功能和需求录入bug跟踪管理系统，并在bug跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关bug列表，交付开发修改。

6.5制定测试计划

A、根据用户需求，定义并完善测试需求，作为测试的标准

B、确定重点测试事项，哪些功能需要重点测试

C、测试时间计划，并详细计划具体测试任务与时间

D、风险说明

E、测试准备，提前对测试环境和测试资源进行准备

F、发布具体时间

G、资源需求：

测试人员、硬件需求、软件需求和培训计划

6.6编写测试案例

根据功能需求编写测试案例

6.7测试开发

开发自动测试脚本，补充自动测试案例

6.8测试实施

按照测试计划进行测试，发现并申报bug

6.9测试评估

A、哪些需求通过了测试

B、有哪些遗留问题

C、测试效率评估

D、开发质量度量和评估

E、并根据评估编写测试报告

6.10发布新版本

A、编写新功能文档，给工程提供新功能说明

B、编写升级文档，给工程提供升级参考方案

C、软件发布，包括新版本软件、新功能文档、升级文档和测试报告

6.11代码版本控制

新版本软件发布之后，马上对代码进行质量控制。

A、BuildMaster给新版本的源代码打一个cvstag，方便代码回滚checkout。

比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tagp2p3.3.2.这样做的一个好处是，在目前的软件的基础上做了修改并发布的新版本后，如果需要checkout某个版本的源代码，则可以通过这个版本的tag来checkout，代码的修改可以在该版本上进行。

B、BuildMaster对心发布的软件源代码进行cvslock，不允许开发人员在软件发布之后commit源代码，直到有新版本需要修改再给开发人员开放commit权限。

这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本与当前最新的发布版本一致。