软件测试流程DOC

1、软件测试流程1. 目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。2. 范围本文适用于软件开发、测试人员，以及软件项目管理人员。3. 参考资料缺陷管理规范测试执行规范文档测试指南项目测试计划模版测试用例设计规范功能测试用例模版集成测试用例模版项目测试报告模版自动化测试计划模版性能测试计划模版4. 测试过程描述4.1 测试流程图 4.2 需求评审 目的从源头把握软件质量，并确保开发结果与实际需求相一致 角色与职责需求人员：需求规格说明书的编写，以及软件开发过程中

2、需求规格说明书的修正；评审人员：评审需求规格说明书，从全面性、完整性、正确性、一致性、可靠性方面检查需求规格说明书，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。 启动标准需求规格说明书编写完成 工作流程图 输入/输出输入：需求规格说明书输出：需求缺陷 规范参见文档评审指南4.3 测试计划 目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。 角色与职责测试负责人：根据项目整体计划、需求规格说明书编制测试计划，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作

3、正常开展，测试计划实际编写内容参见项目测试计划模版。 启动标准需求评审完成，项目整体计划编制完成。  工作流程图  输入/输出输入：需求规格说明书、项目整体计划输出：测试计划 规范测试计划编写内容参加测试计划模版。4.4 测试设计 目的通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。 角色和职责测试人员：采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。评审人员：对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。 启动标准需求文档评审完成且测试计划制定完

4、成。 工作流程图  输入输出输入：需求规格说明书输出：测试用例、测试用例评审缺陷 规范测试用例实际内容参见测试用例模版，测试用例评审规范参见文档测试规范。4.5  功能测试执行 目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。 角色与职责测试人员：依据测试计划，按照测试用例对软件功能进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。开发经理：对测试人员与实际开发人员意见不一的问题进行裁决

5、。 启动标准测试用例编写完成且用例评审完成 工作流程图 输入输出输入：功能测试用例输出：功能测试缺陷 规范测试执行过程需按照测试行为规范进行，缺陷管理需按照缺陷管理规范进行。4.6 集成/性能测试设计 目的为集成测试提供测试依据，记录并保证集成测试覆盖度；依据测试计划及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。 角色和职责测试人员：以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开发。 启动标准功能测试完成 且 软件功能无中断 工作流程图 输入输出输入：功能测试用例、

6、功能测试缺陷、测试计划、性能指标输出：集成测试用例、性能测试计划、性能测试用例、性能测试脚本 规范集成测试用例实际内容参见集成测试用例模版；性能测试计划实际内容参见性能测试计划模版。4.7 集成测试/ 目的以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。 角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。 启动标准集成/性能测试设计完成 工作流程图 输入输出输入：集成测试用例、测试计划之集成测试事项、性能测试

7、计划、性能测试用例输出：集成测试缺陷 规范测试执行过程需按照测试行为规范进行，缺陷管理需按照缺陷管理规范进行。4.8 文档测试 目的保证对客户的指导与实际系统的使用状况相一致。 角色和职责测试人员：对用户操作手册及在线帮助进行测试，记录文档描述缺陷，并跟踪直至缺陷的验证关闭。需求人员：对测试人员提出的文档描述缺陷进行修正。 启动标准用户操作手册或在线帮助编写完成 工作流程图 输入输出输入：用户操作手册、在线帮助输出：文档缺陷 规范参见文档测试指南4.9 测试报告 目的真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。 角色与职责测试

8、负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。 启动标准集成测试完成 工作流程图 输入输出输入：各测试阶段、测试项实际测试情况输出：项目测试报告 规范5 新产品或工程管理流程5.1 需求调研在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入，在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需求达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。5.2 制定测试计划进行每一种测试之前，测试负责

9、人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接收标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。5.3 需求Review开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。5.4 设计Review在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原则，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和

10、详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。5.5 测试设计在设计测试方案时，首先分解测试内容，对于一个复杂的系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果

11、以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的被测系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。每个测试用例必须包括以下几个部分：（1）标题和编号（2）测试的目标和目的（3）输入和使用的数据和操作过程（4）期望的输出结果（5）其他特殊的环境要求、次序要求、时间要求等5.6 开发测试工具和准备测试数据在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本省的优势来提高工作效率。5.7 测试执行当所有必须的测试准备工作都已完成，并且产品已经开发完毕并提交测试

12、，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。5.8 回归测试在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。5.9 测试分析报告测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提

13、交“测试分析报告”。5.10 产品发布测试完毕，整理产品发布和相关文档并发布。对于新产品来说，必要的文档必须包括：（1）安装操作手册（2）产品白皮书（3）管理维护手册（4）用户操作手册（5）测试报告5.11 版本控制新版本软件发布之后，马上对代码进行质量控制。（1）Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2.这样做的一个好处是，在目前的软件的基础上做了修改并发布的新版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag

14、来check out，代码的修改可以在该版本上进行。（2）Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需要修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本与当前最新的发布版本一致。6 工程维护管理流程6.1 收集新需求新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在bug管理系统报bug，但只是记录，不需求马上修改。当然了，对于紧急的工程故障，需要马上修改和测试。6.2 确认新需

15、求与工程人员或客户或产品经理确认新需求，确保需求被理解正确。6.3 需求讨论当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。6.4 bug跟踪管理确认所有需要修改的新功能和需求录入bug跟踪管理系统，并在bug跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关bug列表，交付开发修改。6.5 制定测试计划A、根据用户需求，定义并完善测试需求，作为测试的标准B、确定重点测试事

16、项，哪些功能需要重点测试C、测试时间计划，并详细计划具体测试任务与时间D、风险说明E、测试准备，提前对测试环境和测试资源进行准备F、发布具体时间G、资源需求：测试人员、硬件需求、软件需求和培训计划6.6 编写测试案例根据功能需求编写测试案例6.7 测试开发开发自动测试脚本，补充自动测试案例6.8 测试实施按照测试计划进行测试，发现并申报bug6.9 测试评估A、哪些需求通过了测试B、有哪些遗留问题C、测试效率评估D、开发质量度量和评估E、并根据评估编写测试报告6.10 发布新版本A、编写新功能文档，给工程提供新功能说明B、编写升级文档，给工程提供升级参考方案C、软件发布，包括新版本软件、新功能文档、升级文档和测试报告6.11 代码版本控制新版本软件发布之后，马上对代码进行质量控制。A、Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打