《测试管理办法.docx》由会员分享，可在线阅读，更多相关《测试管理办法.docx（9页珍藏版）》请在第壹文秘上搜索。
1、测试管理办法修订历史记录日期版本作者审核者说明2013-7-10V0. 1Ts初稿1. 概要41. 1.目的42. 2.适用范围42. 职责43. 测试准备43. 1.文档分析43. 2.测试计划53. 3.测试用例53. 3. 1.测试用例设计方法53. 4.测试软/硬件环境64. 5.测试数据准备65. 测试执行61. 1.项目测试周期64. 2.项目测试启动64. 3.项目测试阶段64. 4.项目测试结束75 .测试变更86 .缺陷管理86.1. 缺陷管理流程86. 2.问题提交87. 3.问题分配88. 4.问题修改错误!未定义书签。9. 5.问题关闭错误!未定义书签。7 .回归测试错
2、误!未定义书签。1. 1.回归测试策略错误!未定义书签。7. 2.回归测试基本过程错误!未定义书签。8 .测试结果分析9L概要.目的本过程规范软件测试过程中的各项活动，通过测试活动及早发现软件系统中的缺陷，并 确保缺陷被有效的标识、跟踪、和修改，保证软件系统能够达到要求的质量，符合客户的要 求。1.2. 适用范围本过程适用于软件生命周期中的集成测试、系统测试、性能测试活动和缺陷管理活动。2.职责项目组测试负责人可以由测试经理指定测试组成员其他人员担任。项目组测试负责人以 下简称测试负责人。测试负责人负责： 制定测试计划 参与、跟踪测试过程 对测试活动和结果进行分析，撰写测试分析报告测试人员，由
3、项目组成员担任，负责： 根据测试计划编写测试用例 搭建测试环境，准备测试脚本 执行测试，记录测试结果和缺陷 执行回归测试3.测试准备3.1. 文档分析测试人员应参加需求评审、设计评审。对用户需求说明书、系统界面原型和软 件设计说明书等进行阅读和审查，与需求经理、项目经理沟通，根据系统功能复杂度，系 统业务复杂度进行估算有效测试执行时间，为项目总计划和测试计划的制定提供参考和依 据。通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。3. 2.测试计划根据测试的种类，测试计划分为功能测试和性能测试计划。测试计划旨在说明各测试 阶段任务、人员分配、时间安排、测试要点、工作规范等。
4、测试计划在策略和方法方面说明 如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么 是如何运作的。测试计划不包括测试用例的细节和系统功能的详细信息。测试计划的制定请 参阅测试计划模板。测试计划应附有测试功能点矩阵、测试性能点矩阵。测试计划应在项目组内进行评审。参与测试计划评审的人员包括：项目经理、测试负 责人、开发人员、测试人员。3. 3.测试用例测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期 望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。依据用户需求分析说明书、概要设计文档来设计测试用例，发现需求与设计中的问题 后，与需
5、求作者及时沟通确认。3.3.1. 测试用例设计方法测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的 测试、基于状态图的测试、基于场景的测试。在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。3.3.1.1. 测试用例操作步骤1、在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有 测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过后将 使用该测试用例测试被测系统。2、在测试项目结束后，统计分析所使用过的测试用例，进行分类放到相应的测试用例 库中。为以后测试用例的设计编写提供数据基础。3.3.1.2. 测试用例选择准则
6、测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的， 以及极限的输入数据、操作和环境设置等；测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。3.4.测试软/硬件环境根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测 试项目所需软硬件资源的准备工作，使软硬件资源得到满足。完成对软硬件资源的配置后，要进行对测试项目的软硬件环境进行评审，确认对软硬 件资源配置的有效性。3. 5.测试数据准备完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、 单位
7、组织等信息和测试相关的测试数据。3 . 6.测试执行过程绩效考核为促进测试人员积极主动做好测试执行工作，对测试人员进行测试执行过程进行考核。序号测试准备内容考核评分标准1测试负责人未编写测试计划测试负责人-0.5分2测试人员未编写测试用例测试人员-0 5分以上统计数据由项目经理提供给部门经理。4 .测试执行4.1. 项目测试周期测试项目的测试周期可分为：单元测试、接收测试、集成测试、系统测试、回归测试、 性能测试等。4. 2.项目测试启动软件项目测试活动的正式启动，是在确认软件可测试性后展开的。开发人员需要对产 品进行单元测试，单元测试效果通过接收测试验证。4. 3.项目测试阶段测试人员依据测
8、试计划和测试用例进行测试活动。测试一般分为两个阶段：1、集成测试、系统测试阶段：该阶段测试人员每天提交缺陷，并跟踪缺陷，验证缺陷， 直到提交的缺陷被关闭或被保留。开发人员周期性提交修改过缺陷的新版本，测试人员在新 版本上验证缺陷。2、回归测试阶段：在集成测试、系统测试阶段完成后，产品将进入回归测试阶段。测 试人员对修改后的产品进行重新功能验证，确保修改的正确性，验证在修改缺陷的同时没有 引入新的问题。回归缺陷是指开发人员标示已修改的缺陷，经测试后发现仍未修改正确，或 引入其他缺陷，或在前一个版本中未发现的缺陷，在后一个版本中出现。如产品进行性能测试，则需要在性能测试后，进行一轮回归测试，确保功
9、能的正确性。4 . 4.项目测试结束项目测试结束时应达到测试质量目标所规定的标准。通过评审后结束该项目测试。5 . 5.测试执行过程绩效考核为促进开发人员积极主动做质量工作，对开发人员进行考核。序号开发人员考核内容考核评分标准1开发人员提交的首个产品未通过单元 测试标准，即软件打开崩溃报错、硬件 无法使用等项目经理- 1分2开发人员无故将【严重】、【系统崩溃】 级别无争议的缺陷放置并延期3天修 改。每个缺陷，对应开发人员- 0.5分3一个项目中【已分派】或【未处理】这 类长期未处理的问题超过3天仍未处 理。项目经理- 0.5分4开发人员未能正确修改缺陷，导致状态 为【已修改】的缺陷被【未解决】
10、、【打 InlL每天超过1个。对应开发人员- 0 1分5开发人员通过代码自测试解决缺陷在 项目组中排名第一者对应开发人员+ 0. 5分以上统计数据由测试人员在项目交付后提供给部门经理。对测试人员质量工作进行考核。序号测试人员考核内容考核评分标准1测试人员提出有效bug量周第一对应测试人员+ 0. 5分2由于描述不清楚导致开发人员返回问 题单，周超过5个对应测试人员- 0. 5分3测试人员提出提高测试效率建议对应测试人员+ 0. 5分4由于测试人员测试效率低下,或者未能 按时完成测试任务并且没有开发延期 等原因对应测试人员-0. 5分5由于测试人员出色的表现,使项目测试 任务提前完成对应测试人员
11、+ 0. 5分以上统计数据由测试经理在项目交付后提供给部门经理。6 .测试变更当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更 风险。如变更情况被项目组通过，测试人员将按上述流程进行变更测试。7 .缺陷管理7.1. 缺陷管理流程6. 2.提交缺陷测试人员将缺陷填写到管理工具中，选择指派人为开发组长或相应的开发人员。6. 3.分配缺陷开发人员分别对自己收到的缺陷进行评审。评审后如果对提交的缺陷有疑问，可以与 提交人协商。对未能达成一致的缺陷由项目经理组织项目组成员评审。评审人员可以是项目 组人员。如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开发人员可以将缺陷再次
12、 分配给其他开发人员。但为避免缺陷被多次分配，项目经理应跟踪3天以上未修改的缺陷。 6.4.修改缺陷开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其 他状态。6. 5.关闭缺陷测试人员对已修改的缺陷进行验证。如果已修改完成，测试人员将缺陷状态设置为关 闭。如果没有修改或引起回归问题，将修改缺陷状态为“重新开启”或新增缺陷，由开发工 程师继续修改。7. 6.保留缺陷对于有争议的缺陷进行，将有项目经理最终决定是否修改。如果缺陷是由于技术原因、 版本原因不能修改，则保留该缺陷。8. 测试结果分析测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量, 缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量，性能测试指标情况。测试报告由测试负责人编写并提交给项目经理。测试报告需要经项目组评审通过。
