收藏 分销(赏)

测试管理办法.docx

上传人:鱼** 文档编号:9981527 上传时间:2025-04-15 格式:DOCX 页数:17 大小:83.80KB 下载积分:5 金币
下载 相关 举报
测试管理办法.docx_第1页
第1页 / 共17页
测试管理办法.docx_第2页
第2页 / 共17页


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

开通  VIP会员、SVIP会员  优惠大
下载10份以上建议开通VIP会员
下载20份以上建议开通SVIP会员


开通VIP      成为共赢上传

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        抽奖活动

©2010-2025 宁波自信网络信息技术有限公司  版权所有

客服电话:4009-655-100  投诉/维权电话:18658249818

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :微信公众号    抖音    微博    LOFTER 

客服