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

《测试体系建设与软件测试流程.doc》由会员分享，可在线阅读，更多相关《测试体系建设与软件测试流程.doc（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、- -测试体系建立与软件测试流程初稿XX物合智联科技XX修改历史日期版本修改内容作者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 缺陷流

2、转的过程及处理204.4 缺陷页面局部字段详解215.配置管理226.人员培养221.目的本文是对工程软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进展总体标准，以有效保证软件质量。2.范围本文适用于所有软件测试人员。3.测试过程描述3.1 测试流程图3.2 活动说明3.2.1 需求评审3.2.1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致3.2.1.2角色与职责需求人员：?需求规格说明书?的编写，以及软件开发过程中?需求规格说明书?的修正；评审人员：评审?需求规格说明书?，从全面性、完整性、正确性、一

3、致性、可靠性方面检、查?需求规格说明书?，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。3.2.1.3启动标准?软件需求规格说明书SRS?编写完成3.2.1.4工作流程图3.2.1.5输入/输出输入：?需求规格说明书?输出：需求缺陷3.2.2 测试方案3.2.2.1目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。3.2.2.2角色与职责测试负责人：根据?软件开发方案?、?需求规格说明书?编制?测试方案?，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正

4、常开展，测试方案实际编写内容参见?工程测试方案模版?。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.

5、3.3启动标准需求文档评审完成 且 测试方案制定完成3.2.3.4工作流程图3.2.3.5输入输出输入：?软件需求规格说明书?、?测试方案?、?测试方案?输出：?测试用例?、测试用例评审缺陷3.2.4 功能测试执行3.2.4.1目的依据测试方案，按照测试用例对软件进展测试，验证软件功能与需求的实际匹配程度。3.2.4.2角色与职责测试人员：依据测试方案，按照测试用例对软件功能进展测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进展确认、修复。开发经理：对测

6、试人员与实际开发人员意见不一的问题进展裁决。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启动标准功能测试完成

7、 且 软件功能无中断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.

8、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目的真实、客观反映测试过程中各测试

9、阶段、测试项的情况，并将结果进展数字化/图像化进展分析，真实反映软件质量实际情况。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 角色和

10、职责角色名称职责描述测试经理申请QC工程建立，分配有关人员权限测试人员登记测试缺陷，跟踪和修改缺陷状态，并进展复测开发人员从QC中获取缺陷信息，修复缺陷，并修改QC缺陷状态及分析记录缺陷相关内容4.1.4 名词解释QC：QCQuality Center，也被称为MQCMercury Quality Center。不仅可以在一个工程组内进展质量控制和管理，也可以在跨地域的不同工程组内部进展质量控制和管理，从而可以保证应用系统的质量。通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等，QC可以地加速测试过程执行。4.2 缺陷状态关系示意图4.3 缺陷流转的过程及处理参与缺陷流转的

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

12、息 模块中的“分析和修改内容中使用“添加注释按钮详细填写拒绝的原因。当确认该缺陷有效时，开发人员应按照要求修复缺陷。缺陷修复后，开发人员需在“缺陷详细信息 模块中的“分析和修改内容中使用“添加注释按钮详细填写修复的内容，并填写缺陷起源、缺陷归属子系统，更改“缺陷状态为“待验证。当确认该缺陷不是本系统引起，需要其它工程组协同进展分析解决，开发人员应保持缺陷状态为“处理，并将该缺陷的“处理子系统改为相应的工程组或系统，以便缺陷能及时流转。4.3.3 验证缺陷测试人员负责验证缺陷是否已解决，如已解决那么由缺陷原提出人关闭缺陷，否那么将“缺陷状态更改为“重现，以便开发人员重新对此缺陷进展处理。4.4

13、缺陷页面局部字段详解u 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。 包括：新建、翻开、已修改、重新翻开、关闭、拒绝、延迟u 缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，开发人员负责确认。 包括：致命、严重、一般、轻微u 缺陷紧急程度：指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以工程组具体协商约定紧急程度的具体含义。包括：高、中、低提出、处理、拒绝、待验证、重现、关闭u 缺陷起源：指引起缺陷的起因。包括：需求、架构、设计、编码、测试、环境、数据、拒绝缺陷起源类型含义需求由于需求定义或需求分析引起的缺陷架构由于企业架构设计的问题引起的缺陷 设计由于本系统

14、设计原因引起的缺陷编码由于编码的问题引起的缺陷测试由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷环境由于测试环境的问题引起的缺陷数据由于测试数据的问题引起的缺陷拒绝重复。表示该缺陷已经被其它提交人找出来了纯粹重复，或者开发认为原因是一样的但从测试来看，认为出现的地方有所不同、表现有所不同等 不可复现。不能重现如因缺陷出现的环境重现不了，或以前出现的某个缺陷自动消失了可能是在处理其他缺陷的时候把这个缺陷 一并修复掉了 是按照需求和设计实现的，不属于缺陷延后解决。由于时间、进度、重要程度或者技术/需求等方面的原因，认为目前不能解决或由于时间关系，须延期解决或者本版暂不解决留待到后续版本

15、解决的缺陷这个缺陷是一个错误，但非常轻微，对系统几乎无影响，可以忽略不计 5.配置管理软件测试过程是一个复杂性的劳动，测试过程中会产生大量测试文档，主要通过相关管理工具的方式实行对文档的管理。在文档的管理方面，按照公共类、工程类、软件缺陷类、开发人员类、测试工具类等：1公共类主要放置测试模板及测试规程说明，测试经历共享文档，开发技术标准等。2工程类主要包括工程各阶段文档，如需求分析、测试方案、测试用例设计、分析报告等。3开发人员类是针对每个开发人员易犯错误的总结。4测试工具类主要放置常用的测试工具svn。6.人员培养一个优秀的测试团队的形成并非一朝一夕能形成。软件测试和软件开发一样，是一项高智力的活动。在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、疑心精神、洞察力、有条理和注意细节八方面进展考虑。对于新进入的测试人员，无论是否有测试经历或编程经历，都应进展测试的技术和管理标准培训，同时根据他们以往知识和个人特点给他们定位适宜的测试方向。- word.zl-