测试体系建设与软件测试流程.doc

江苏物合智联科技有限公司测试体系建设与软件测试流程（初稿)江苏物合智联科技有限公司修改历史日期版本修改内容作者2016/7/111。0新建沙莎正式批准角色签名日期备注目录1.目的42.范围53。测试过程描述63。1 测试流程图63.2 活动说明73.2。1 需求评审73.2。2 测试计划83。2。3 测试设计93。2.4 功能测试执行113。2.5集成/性能测试设计123。2。6集成测试/性能测试143。2.7 文档测试163.2.8 测试报告174.缺陷管理184.1 概述184.1。1 编写目的184.1。2 适用范围194。1。3 角色和职责194.1。4 名词解释194。2 缺陷状态关系示意图194.3 缺陷流转的过程及处理204.4 缺陷页面部分字段详解215。配置管理226.人员培养221.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。2.范围本文适用于所有软件测试人员.3。测试过程描述3.1 测试流程图3.2 活动说明3.2。1 需求评审3。2。1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致3.2。1.2角色与职责需求人员：需求规格说明书的编写，以及软件开发过程中需求规格说明书的修正;评审人员：评审需求规格说明书，从全面性、完整性、正确性、一致性、可靠性方面检、查需求规格说明书，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。3.2。1.3启动标准软件需求规格说明书SRS编写完成3。2。1。4工作流程图3。2.1。5输入/输出输入：需求规格说明书输出:需求缺陷3。2.2 测试计划3。2.2.1目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅,有效控制和跟踪测试进度，应对测试过程中的各种变更。3.2。2。2角色与职责测试负责人:根据软件开发计划、需求规格说明书编制测试计划，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写内容参见项目测试计划模版.3.2。2。3启动标准需求评审完成，项目整体计划编制完成。3.2。2.4工作流程图3.2.2。5输入/输出输入:软件需求规格说明书、软件开发计划输出：测试计划、测试方案3.2。3测试设计3。2.3。1目的通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。3.2.3。2角色和职责测试人员：采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。评审人员:对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。3。2.3。3启动标准需求文档评审完成 且 测试计划制定完成3。2.3.4工作流程图3。2。3。5输入输出输入：软件需求规格说明书、测试计划、测试方案输出：测试用例、测试用例评审缺陷3.2。4 功能测试执行3。2.4.1目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度.3.2。4.2角色与职责测试人员：依据测试计划,按照测试用例对软件功能进行测试.对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性.开发人员：对于测试人员提交的缺陷进行确认、修复。开发经理:对测试人员与实际开发人员意见不一的问题进行裁决.3。2。4.3启动标准测试用例编写完成 且 用例评审完成3.2.4。4工作流程图3。2。4。5输入输出输入：功能测试用例输出:功能测试报告，缺陷报告单3.2。5集成/性能测试设计3.2。5。1目的为集成测试提供测试依据，记录并保证集成测试覆盖度;依据测试计划及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行.3.2.5.2角色和职责测试人员:以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计;依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开发.3。2。5。3启动标准功能测试完成 且 软件功能无中断3。2.5。4工作流程图3.2。5.5输入输出输入：功能测试用例、功能测试缺陷、测试计划、性能指标输出:集成测试用例、性能测试计划、性能测试用例、性能测试脚本3。2。6集成测试/性能测试3.2。6.1目的以整个软件为对象,以测试计划为指导,按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。3。2。6.2角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。3。2.6。3启动标准集成/性能测试设计完成3。2。6。4工作流程图3.2.6.5输入输出输入：集成测试用例、测试计划之集成测试事项、性能测试计划、性能测试用例输出：集成测试缺陷3.2.7 文档测试3.2.7.1目的保证对客户的指导与实际系统的使用状况相一致.3.2。7。2角色和职责测试人员：对用户操作手册及在线帮助进行测试，记录文档描述缺陷，并跟踪直至缺陷的验证关闭。需求人员：对测试人员提出的文档描述缺陷进行修正。3.2.7.3启动标准用户操作手册或在线帮助编写完成3。2。7.4工作流程图3。2.7。5输入输出输入:用户操作手册、在线帮助输出：文档缺陷3。2。8 测试报告3。2.8。1目的真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。3。2。8。2角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。3.2。8。3启动标准集成测试完成3.2。8。4工作流程图3。2.8。5输入输出输入:各测试阶段、测试项实际测试情况输出:项目测试报告4.缺陷管理4.1 概述4.1.1 编写目的为规范QC的合理使用，方便各项目组管理测试过程，测试管理人员正确使用QC而编写.4.1。2 适用范围适用于功能测试有关工作，功能测试中的缺陷要求全部采用QC进行管理。4。1。3 角色和职责角色名称职责描述测试经理申请QC项目建立,分配有关人员权限测试人员登记测试缺陷，跟踪和修改缺陷状态，并进行复测开发人员从QC中获取缺陷信息，修复缺陷，并修改QC缺陷状态及分析记录缺陷相关内容4.1.4 名词解释QC：QC(Quality Center），也被称为MQC（Mercury Quality Center）。不仅可以在一个项目组内进行质量控制和管理,也可以在跨地域的不同项目组内部进行质量控制和管理，从而可以保证应用系统的质量。通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等，QC可以地加速测试过程执行。4.2 缺陷状态关系示意图4。3 缺陷流转的过程及处理参与缺陷流转的角色有三个:测试经理、测试人员和开发人员.缺陷的处理步骤如下:4。3.1 新建缺陷测试人员负责在QC中新建缺陷，并对缺陷的基本情况进行描述。缺陷的基本信息主要包括:缺陷描述、紧急程度、严重程度、处理子系统等。测试人员在登记缺陷时,必须确定所输入的缺陷内容要描述清楚，产生缺陷的步骤描述要完整，使缺陷能够被重现出来。在描述缺陷产生的步骤上,务必简易清楚。测试人员可以利用错误抓图等方式进行补充描述.4。3.2 修复缺陷当有多个缺陷同时打开时，开发人员应首先修复紧急程度更高的缺陷.开发人员首先分析缺陷，并将缺陷状态更改为“处理中.当该缺陷不是有效的缺陷时，则将“缺陷状态”更改为“拒绝”，并在“缺陷详细信息” 模块中的“分析和修改内容”中使用“添加注释”按钮详细填写拒绝的原因。当确认该缺陷有效时，开发人员应按照要求修复缺陷.缺陷修复后，开发人员需在“缺陷详细信息” 模块中的“分析和修改内容”中使用“添加注释”按钮详细填写修复的内容，并填写缺陷起源、缺陷归属子系统，更改“缺陷状态”为“待验证”。当确认该缺陷不是本系统引起,需要其它项目组协同进行分析解决，开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理子系统”改为相应的项目组或系统,以便缺陷能及时流转.4.3。3 验证缺陷测试人员负责验证缺陷是否已解决，如已解决则由缺陷原提出人关闭缺陷,否则将“缺陷状态”更改为“重现”,以便开发人员重新对此缺陷进行处理。4.4 缺陷页面部分字段详解u 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。 包括：新建、打开、已修改、重新打开、关闭、拒绝、延迟u 缺陷严重程度：是指因缺陷引起的故障对系统的影响程度.由提出人初步指定，开发人员负责确认。 包括:致命、严重、一般、轻微u 缺陷紧急程度:指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以项目组具体协商约定紧急程度的具体含义。 包括:高、中、低提出、处理、拒绝、待验证、重现、关闭u 缺陷起源:指引起缺陷的起因. 包括:需求、架构、设计、编码、测试、环境、数据、拒绝缺陷起源类型含义需求由于需求定义或需求分析引起的缺陷架构由于企业架构设计的问题引起的缺陷 设计由于本系统设计原因引起的缺陷编码 由于编码的问题引起的缺陷测试 由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷环境 由于测试环境的问题引起的缺陷数据 由于测试数据的问题引起的缺陷拒绝 重复。表示该缺陷已经被其它提交人找出来了（纯粹重复),或者开发认为原因是相同的(但从测试来看，认为出现的地方有所不同、表现有所不同等） 不可复现。不能重现（如因缺陷出现的环境重现不了）,或以前出现的某个缺陷自动消失了（可能是在处理其他缺陷的时候把这个缺陷 一并修复掉了） 是按照需求和设计实现的，不属于缺陷延后解决。由于时间、进度、重要程度或者技术/需求等方面的原因,认为目前不能解决或由于时间关系，须延期解决或者本版暂不解决留待到后续版本解决的缺陷这个缺陷是一个错误，但非常轻微,对系统几乎无影响,可以忽略不计 5.配置管理软件测试过程是一个复杂性的劳动，测试过程中会产生大量测试文档，主要通过相关管理工具的方式实行对文档的管理.在文档的管理方面，按照公共类、项目类、软件缺陷类、开发人员类、测试工具类等:1）公共类主要放置测试模板及测试规程说明,测试经验共享文档，开发技术规范等。2）项目类主要包括项目各阶段文档，如需求分析、测试计划、测试用例设计、分析报告等.3)开发人员类是针对每个开发人员易犯错误的总结。4）测试工具类主要放置常用的测试工具svn。6。人员培养一个优秀的测试团队的形成并非一朝一夕能形成。软件测试和软件开发一样，是一项高智力的活动.在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、怀疑精神、洞察力、有条理和注意细节八方面进行考虑。对于新进入的测试人员，无论是否有测试经验或编程经验,都应进行测试的技术和管理规范培训，同时根据他们以往知识和个人特点给他们定位合适的测试方向。16