软件测试流程v10

《软件测试流程v10》由会员分享，可在线阅读，更多相关《软件测试流程v10（23页珍藏版）》请在文档大全上搜索。

1、软件测试流程1目的本文是对项目软件测试流程的梳理，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行了简单的描述。2范围本文适用于软件开发、测试人员，以及软件项目管理人员。3参考资料缺陷管理规范测试执行规范文档测试指南项目测试计划模版测试用例设计规范功能测试用例模版集成测试用例模版项目测试报告模版自动化测试计划模版性能测试计划模版4测试基本阶段划分软件测试的基本阶段主要划分为测试计划阶段、测试设计阶段、测试执行阶段、测试评估阶段以测试验收阶段几部分。4.1测试计划阶段此阶段主要是测试前的准备工作，也即是计划如何去做测试工作，因此需要有一个

2、完善的“测试计划书”。测试计划的内容：1、测试范围：描述本次测试中要做的测试范围，如：测试软件功能范围、测试种类(功能测试、界面测试等等)等2、简单的描述如何搭建测试平台以及测试的潜在的风险。3、 项目信息：说明要测试的项目的相关资料，如：输入输出文档，产品描述，软件主要功能4、人力资源的分配测试计划和测试设计要分开编写，要有充分的时间去明确测试需求 测试需求：笼统的说，就是测试中的所有设计和需求文档作为本次测试的依据4.1.1测试计划考虑的问题： 1、要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性（必须对需求有透彻的理解）。编写测试计划的目

3、的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。（1）测试内容：即对一个软件来说测试计划中要明确本次测试要做哪些测试？如：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等等）（2）测试目的：主要是为保证产品质量是否达到预期的指标。即是要说明测试发布的质量目标。如测试计划中所有测试方法和模块已经执行通过，所有的测试案例已经执行过，所有的重要等级的bug已经解决并由测试验证。（3）测试标准：需要考虑本次测试需要输入那些文档，该项目结束标准定

4、义、测试结束标准的定义，bug级别定义、优先级定义、bug管理流程定义。这些都需要在执行测试时明确。测试计划中应该包含这些内容。（4）资源分配：这里分为人力资源、软硬件资源等划分。一般会把人力资源的利用写入一个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果。软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具，列出清单。例如：CPU、内存、硬盘、数据库、IE/版本、服务器、凭条、操作系统/版本等等。（5）测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。（6）

5、测试策略：即是对于每一种类型的测试该如何进行，如对于功能测试来说可按照以下策略进行：首先要划分功能范围（划分出各自负责的功能模块），其次确定要使用的测试方法（等价类、边界值等），最后要给出测试标准（如要符合设计、需求和规范文档对该功能的描述）。  2、要坚持“5W1H”的原则，明确测试内容与过程。 明确测试的范围和内容（WHAT）； 明确测试的目的（WHY）； 明确测试的开始和结束日期（WHEN）； 明确给出测试文档存放位置（WHERE）； 明确测试人员的任务分配（WHO）； 明确指出测试的方法和测试工具（HOW）。4.2测试设计阶段测试用例设计的主要来源为：需求说明书及文

6、档；相关的设计说明文档(概要设计和详细设计等)；与开发组交流过程中对需求理解的记录；已经基本成型的UI等等。在设计测试方案时，如果是一个复杂系统，则首先分解测试内容，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，从而可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试。并将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，最重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计。根据对具体的被测系统的分析和测试要求，逐步细化测

7、试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。每个测试用例必须包括以下几个部分： （1） 标题和编号 （2） 测试的目标和目的 （3） 输入和使用的数据和操作过程 （4） 期望的输出结果 （5） 其他特殊的环境要求、次序要求、时间要求等4.3测试执行阶段当测试用例的设计和测试脚本的开发完成之后，提交测试版本、部署测试环境以后就开始执行测试。主要包括手工测试和自动化测试。  手工测试；在合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数

8、据：对系统进行操作，比较实际结果和测试用例的所描述的期望结果，以确定系统是否正常运行或正常表现。自动化测试：通过测试工具，运行测试脚本，得到测试结果。 执行测试时需要先搭建测试，搭建完环境之后就开始执行测试。主要包括多轮的测试。每一轮测试中都要把测试bug提交给开发人员进行修改，需要的时候还要对测试用例进行修改和增加，还要对修改的bug进行回归测试，如此反复指导缺陷率满足用户需求。 4.4测试评估阶段执行阶段结束了进入测试评估阶段，这时会出一个总的测试报告对测试的整个过程和版本的质量做一个详细的评估。  测试总结报告文档的输出主要包括以下内容：1、可以让具体的任务

9、负责人对该本次测试中个人负责的模快进行评价，提出相关建议。给出总体的评估2、整体上的bug按照不同等级统计出来、用例数量、用例执行数量3、对项目中测试人力资源的统计。（单位：人/天）4、项目中软硬件资源统计。5、提出软件总体的评价4.5测试验收阶段   最后进入验收阶段，会输出用户手册，操作指引等文档。并且每一个测试阶段的输出都有一个严格的评审阶段，以确保我们每一步的输出都是有效的，保证测试的顺利进行。一般分为alpha测试和beta测试。5测试过程描述5.1测试流程图5.2需求评审5.2.1目的从源头把握软件质量，并确保开发结果与实际需求相一致。5.2.2角色与

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

11、责测试负责人：根据项目整体计划、需求规格说明书编制测试计划，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写内容参见项目测试计划模版。5.3.3 启动标准需求评审完成，项目整体计划编制完成。5.3.4 工作流程图5.3.5 输入/输出输入：需求规格说明书、项目整体计划输出：测试计划5.3.6规范测试计划编写内容参加测试计划模版。5.4测试设计5.4.1目的通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。5.4.2角色和职责测试人员：采用多种测试方

12、法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。评审人员：对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。5.4.3启动标准需求文档评审完成且测试计划制定完成。5.4.4 工作流程图5.4.5输入输出输入：需求规格说明书输出：测试用例、测试用例评审缺陷5.4.6规范测试用例实际内容参见测试用例模版，测试用例评审规范参见文档测试规范。5.5功能测试执行5.5.1 目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。5.5.2角色与职责测试人员：依据测试计划，按照测试用例对软件功能进行测试。对于发现的

13、缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。开发经理：对测试人员与实际开发人员意见不一的问题进行裁决。5.5.3 启动标准测试用例编写完成 且 用例评审完成5.5.4工作流程图5.5.5 输入输出输入：功能测试用例输出：功能测试缺陷5.5.6 规范测试执行过程需按照测试行为规范进行，缺陷管理需按照缺陷管理规范进行。5.6集成/性能测试设计5.6.1目的为集成测试提供测试依据，记录并保证集成测试覆盖度；依据测试计划及性能指标制定性能测

14、试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。5.6.2角色和职责测试人员：以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开发。5.6.3启动标准功能测试完成 且 软件功能无中断。5.6.4工作流程图5.6.5输入输出输入：功能测试用例、功能测试缺陷、测试计划、性能指标输出：集成测试用例、性能测试计划、性能测试用例、性能测试脚本。5.6.6规范集成测试用例实际内容参见集成测试用例模版；性能测试计划实际内容参见性能测试计划模版。5.7集成测试/性能测试5.7.1目的以整个软件为对象，以测试

15、计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。5.7.2角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。5.7.3 启动标准集成/性能测试设计完成5.7.4工作流程图5.7.5 输入输出输入：集成测试用例、测试计划之集成测试事项、性能测试计划、性能测试用例。输出：集成测试缺陷。5.7.6 规范测试执行过程需按照测试行为规范进行，缺陷管理需按照缺陷管理规范进行。5.8文档测试5.8.1目的保证对客户的

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

17、况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。5.9.3 启动标准集成测试完成5.9.4工作流程图5.9.5 输入输出输入：各测试阶段、测试项实际测试情况输出：项目测试报告5.9.6 规范6缺陷管理6.1目的为规范QC(Quality Center)的合理使用，方便各项目组管理测试工程，测试管理人员正确使用QC而编写。6.2角色与职责测试经理：申请QC项目建立，分配有关人员权限测试人员：登记测试缺陷，跟踪和修改缺陷状态，并进行复测开发人员：从QC中获取缺陷信息，修复缺陷，并修改QC缺陷状态及分析记录缺陷相关内容。6.3缺陷状态关系6.4缺陷流转的过程

18、及处理参与缺陷流转的角色有三个：测试经理、测试人员和开发人员。缺陷的处理步骤如下：6.4.1新建缺陷测试人员负责在QC中新建缺陷，并对缺陷的基本情况进行描述。缺陷的基本信息主要包括：缺陷描述、紧急程度、严重程度、处理子系统等。测试人员在登记缺陷时，必须确定所输入的缺陷内容要描述描述清楚，产生缺陷的步骤描述要完整，使缺陷能够被重现出来。在描述缺陷产生的步骤上，务必简易清楚。测试人员可以利用错误抓图等方式进行补充描述。6.4.2修复缺陷当有多个缺陷同时打开时，开发人员应首先修复紧急才程度更高的缺陷。开发人员首先分析缺陷，并将缺陷状态更改为“处理”中。当该缺陷不是有效的缺陷时，则将“缺陷状态”更改为

19、“拒绝”，并在“缺陷详细信息”模块中的“分析和修改内容”中使用“添加注释”按钮详细填写拒绝的原因。当确认该缺陷有效时，开发人员应按照要求修复缺陷。缺陷修复后，开发人员需在“缺陷详细信息”模块中的“分析和修改内容”中使用“添加注释”按钮详细填写修复的内容，并填写缺陷起源、缺陷归属于子系统，更改“缺陷状态”为“待验证”。当确认缺陷不是本系统引起，需要其它项目组协同进行分析解决，开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理子系统”改为相应的项目组或系统，以便缺陷能及时流转。6.4.3验证缺陷测试人员负责 验证缺陷是否已解决，如已解决则由缺陷提出人关闭缺陷，否则将“缺陷状态”更改为“重现”，以便开发人员重新对此缺陷进行处理。6.5缺陷相关字段解释缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。 包括：提出、处理、拒绝、待验证、重现、关闭 。 缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，开发人员负责确认。 包括：严重、一般、轻微。缺陷紧急程度：指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以项目组具体协商约定紧急程度的具体含义。包括：高、中、低。缺陷起源：指引起缺陷的起因。 包括：需求、架构、设计、编码、测试、环境、数据、拒绝 。