(修改后)软件测试规范管理V1.1.doc

软件测试规范管理 V1 1 公司以前没有测试部 但是据我的上司说公司意识到了测试的重要 所以把我招聘进去 希望我帮他们健全测试体质 然后让我写的测试管理流程 主要是开发要怎么配合 需要 提供什么东西 测试完成后需要提交什么东西 公司做的是 web 测试 测试环境和开发环 境必须要共用一套 这个也是比较纠结的地方 以前都是做简单的功能测试 没写过这些 第一次写 在网上找了些然后结合自己的理解写了一份初稿 请大家帮忙多提提意见 感 激不尽 软件测试规范管理软件测试规范管理 V1 1 修订历史记录 日期版本作者审核者说明 20123 3 6V1 1 初稿 软件测试规范管理 V1 1 第第 2 页页 共共 10 页页 目目 录录 1 1 概要概要 3 3 1 1 目的 3 1 2 适用范围 3 1 3 术语 名词定义 3 2 2 测试职责测试职责 3 3 3 3 测试流程图测试流程图 4 4 4 4 测试申请测试申请 4 4 4 1 项目初期 4 4 2 迭代功能开发 5 5 5 测试准备测试准备 5 5 5 1 文档分析 5 5 2 测试计划 5 5 3 测试用例 6 5 4 测试软 硬件环境 6 5 5 测试数据准备 6 6 6 测试执行测试执行 7 7 6 1 测试准入条件 7 6 2 项目测试阶段 7 6 3 测试退出标准 7 6 4 测试变更 7 7 7 缺陷管理缺陷管理 8 8 7 1 缺陷管理流程 8 7 2 提交缺陷 8 7 3 分配缺陷 8 7 4 修改缺陷 8 7 5 关闭缺陷 9 7 6 保留缺陷 9 8 8 测试结果分析测试结果分析 9 9 9 9 约定约定 9 9 10 10 标准文档标准文档 1010 软件测试规范管理 V1 1 第第 3 页页 共共 10 页页 1 1 概要概要 1 1 1 1 目的目的 本文档是测试和开发团队的日常工作规范 主要侧重测试工作流程的控制 明确软件 工程的各阶段测试应完成的工作以及开发应提供的文档 1 21 2 适用范围适用范围 本过程适用于软件测试过程中所有活动 即适用于参与项目的所有开发和测试人员 1 31 3 术语 名词定义术语 名词定义 1 3 11 3 1 开发文档开发文档 开发人员提供给测试人员的开发文档至少包括以下几种 需求文档 概要设计 详细 设计 用户手册等 1 3 21 3 2 测试文档测试文档 测试文档包括测试计划 测试用例说明 BUG 报告及分析 测试总结 以及测试工作 全部完成后的测试报告等 测试文档由测试人员编写并维护 1 3 31 3 3 缺陷等级说明缺陷等级说明 1 A 类 致命缺陷 最严重的等级 缺陷会导致网站任何一个主要功能完全丧失 用户数据受到破坏 系统崩溃 死机等 2 B 类 严重缺陷 系统的主要功能部分丧失 数据不能完整保存 系统的次要功 能完全丧失 系统所提供的服务和功能受到明显的影响 3 C 类 一般缺陷 系统的次要功能没有完全实现 但不影响用户的正常使用 4 D 类 较小缺陷 界面错误 菜单布局不合理 提示不准确等 在使用过程中跟 用户带来一定的不方便和操作难度 5 E 类 建议缺陷 对网站使用的友好性有影响 如拼写错误 界面布局 文档的 可读性 操作的一致性等 Comment 微微微微1 确定是前景 Comment 微微微微2 是对需求文档测 试后才可以进行极限 的意思吗 请 参看 需求文档经测试人员评审后 方可基线化 Comment 微微微微3 为版本质量提供 量化的参考依据 Comment 微微微微4 归档项目总结 归档测试经验与技术 分析经典 bug Comment 微微微微5 开发人员没有权 利决定测试内部工作 可以给出测试 建议 Comment 微微微微6 说明应测特性 和暂不测试特性 重点测试哪些 需 要注意什么 Comment 微微微微7 测试周期应该是 早就规定好的 不是这里确定的 在 这里再次提示下 也可以 软件测试规范管理 V1 1 第第 4 页页 共共 10 页页 2 2 测试职责测试职责 测试是软件开发过程中的重要组成部分 肩负着如下责任 在项目的前景 需求文档确立基线前对文档进行测试 从用户体验和测试的角度 提出自己的看法 编写合理的测试计划 并与项目整体计划有机地整合在一起 编写覆盖率高的测试用例 针对测试需求进行相关测试技术的研究 认真仔细地实施测试工作 并提交测试报告供项目组参考 3 3 测试流程图测试流程图 4 4 测试申请测试申请 开发组向测试负责人提交 测试申请表 该文档要说明 申请测试人员数量 进行哪 些功能的测试 需要提交哪些测试文档 测试周期 测试环境要求 参与需求分析 了解项目需求内 容 制定项目计划 制定测试计划 编写测试用例 执行测试用例 提交 bug 开发进行修 改 回归问题单 修改补充测试用例 提交测试总结报告 Comment 微微微微8 没有必要要这个 吧 测试完毕提交报告给开发 软件测试规范管理 V1 1 第第 5 页页 共共 10 页页 4 14 1 项目初期项目初期 项目立项初期时需提交 需求文档 概要设计 详细设计 开发进度表 4 24 2 迭代功能开发迭代功能开发 开发组提交 送测表 其中包括可测试内容和测试注意事项 否 迭代功能测试流程图 5 5 测试准备测试准备 5 15 1 文档分析文档分析 测试人员和开发人员均应参加需求评审 设计评审 对 需求说明书 系统界面原 型 和 软件设计说明书 等进行阅读和审查 与产品经理 项目经理沟通 根据系统功 能复杂度 系统业务复杂度估算开发时间和有效测试执行时间 为项目总计划和测试计划 的制定提供参考和依据 通过对文档分析 分解各功能模块 各功能点 为测试用例设计提供数据依据 研发人员提交送测表 测试人员根据测试表以及 关键用例进行冒烟测试 冒烟测试是否通过 正式进入测试 执行测试用例 编 写测试报告 提交 bug 至缺陷库 测试完毕提交报告给开发 开发人员修改 bug 更新缺陷库 重新送测 返回开发进行修改 测试回归问题单 Comment 微微微微9 设计测试用例 可以基于以下方法进行设计 Comment 微微微微10 没有必要要 可以删除 Comment 微微微微11 测试用例的设 计 Comment 微微微微12 如果是新开发 的软件 哪里有用例呢 1 设计用例采用公司统一模板 严 格按照用例模板进行设计 Comment 微微微微13 在测试期间 发现用例描述不清 或需求变更 或 用例设计有误 及时在统一的文档中 记录 待本轮测试结束后 更新基线 用例 Comment 微微微微14 本人觉得这里 可以删除 可以在用例设计指导中 或是用例设计标准文档中说明 文档 自己写 Comment 微微微微15 我觉得吧 这 些需要再测试计划后 设计用例前 设计测试方案中分析 分析测试组网 测试要点 性能 自动化 软件测试规范管理 V1 1 第第 6 页页 共共 10 页页 5 25 2 测试计划测试计划 根据需求文档和项目计划制定测试计划 测试计划旨在说明各测试阶段任务 人员分 配 时间安排 测试要点 工作规范等 测试计划在策略和方法方面说明如何计划 组织 和管理测试项目 测试计划完成后应该在项目组内进行评审 5 35 3 测试用例测试用例 测试用例是为实施测试而向被测试系统提供的输入数据 操作或各种环境设置以及期 望结果的一个特定的集合 解决要测什么 怎么测和如何衡量的问题 依据用户需求分析说明书 概要设计文档和开发详细设计说明书来设计测试用例 发 现需求与设计中的问题后 与需求作者及时沟通确认 5 3 15 3 1 测试用例设计方法测试用例设计方法 测试用例的设计方法有等价类测试 边界值分析 基于判定表的测试 基于因果图的 测试 基于状态图的测试 基于场景的测试 在设计测试用例时常用的设计方法有等价类测试 边界值分析两种方法 5 3 25 3 2 测试用例操作步骤测试用例操作步骤 1 在设计编写测试用例时 首先要从测试用例库中选择相应功能的测试用例 在原 有测试用例的基础上依据系统需求文档对测试用例的进行修改 更新 评审通过 后将使用该测试用例测试被测系统 2 在测试的执行过程中和进行回归测试后 对已设计的测试用例进行维护更新 5 5 3 3 3 3 测试用例选择准则测试用例选择准则 测试用例的代表性 能够代表各种合理和不合理的 合法的和非法的 边界和越界的 以 及极限的输入数据 操作和环境设置等 测试结果的可判定性 即测试执行结果的正确性是可判定的或可评估的 测试结果的可再现性 即对同样的测试用例 系统的执行结果应当是相同的 5 45 4 测试软测试软 硬件环境硬件环境 根据需求文档提供的内容 和开发部沟通确定测试项目所需的软硬件环境 完成对测 试项目所需软硬件资源的准备工作 使软硬件资源得到满足 5 55 5 测试数据测试数据准备准备 完成对测试项目基本数据的准备操作 包括数据库连接 用户信息 用户角色权限 单位组织等信息和测试相关的测试数据 Comment 微微微微16 转测试需要提 交转测试申请 2 开发需要提交自测报告 3 预测试通过 冒烟测试通过 转测试时测试用例需要评审通过并基 线化 如果前期没有投入测试 恐怕 测试不能及时进行测试或不能走测试 的正规流程 Comment 微微微微17 功能需求 性 能需求覆盖 100 2 所有 1 2 级用例执行率 100 3 4 级用例执行率 80 以上 3 分析缺陷的趋势是收敛的 且遗 留问题符合公司定义的质量标准 4 测试过程中缺陷率达到公司系统 测试质量标准 Comment 微微微微18 软件测试规范管理 V1 1 第第 7 页页 共共 10 页页 6 测试执行测试执行 6 16 1 测试准入条件测试准入条件 1 不接受无详细需求文档和开发说明的项目 2 需要测试的项目至少提前 2 个工作日提交测试进行需求分析 3 开发人员经过自测通过 至少保证程序可以正常运行 对应的功能在正常流程下是 可以正常使用 6 26 2 项目测试阶段项目测试阶段 测试人员依据测试计划和测试用例进行测试活动 测试一般分为两个阶段 1 测试执行阶段 该阶段测试人员测试出 bug 后将缺陷提交至缺陷管理库 2 回归问题单 开发修改完 bug 之后 测试进行验证回归 6 36 3 测试退出标准测试退出标准 1 测试对可回归缺陷的回归率达到 100 2 全部的测试用例集执行完毕 3 缺陷处理达到 100 6 46 4 测试测试变更变更 当需求变更 功能变化 测试人员根据变更情况 评估测试变更所需时间 提出变更 风险 如变更情况被项目组通过 测试人员将按上述流程进行变更测试 6 56 5 测试变更测试变更 Comment 微微微微19 顺序有问题 都推出 怎么才写缺陷管理呢 Comment 微微微微20 是否需要修改 没有 否 2 延期一周 2 周 3 个月 还是下 个版本 还是下轮测试 软件测试规范管理 V1 1 第第 8 页页 共共 10 页页 7 7 缺陷管理缺陷管理 7 17 1 缺陷管缺陷管理流程理流程 测试人员开发人员项目经理 提交BUG 否否 是否描述清晰 修改BUG 是是 关闭BUG 是否修改正确 正正确确 不不正正确确 BUG是否有争议 否否 是否需要修改 是是 是是 是是 是否需要延期 修改 保留BUG 是是 否否 7 27 2 提交提交缺陷缺陷 测试人员将缺陷填写到缺陷管理库中 将缺陷分配给为开发组长或相应的开发人员 7 37 3 分配分配缺陷缺陷 开发人员分别对自己收到的缺陷进行评审 评审后如果对提交的缺陷有疑问 可以与 提交人协商 对未能达成一致的缺陷由项目经理组织项目组成员评审 评审人员可以是项 目组人员 如果缺陷初次分配的开发人员无法修改该缺陷 初次分配的开发人员可以将缺陷再次 分配给其他开发人员 如果开发对测试提出的 bug 不理解或者不能重现时 可以要求测试复现 bug 7 47 4 修改缺陷修改缺陷 开发人员对已确认的缺陷进行修改 填写修改记录 修改缺陷状态为 已修改 或其 他状态 修改完后开发应对修改后会影响的其他功能模块做个说明 还需对缺陷产生的原 Comment 微微微微21 漏设用例的 bug 遗测漏的 bug 上一轮没有发现 在下一轮或他人发现 缺陷的趋势 Comment 微微微微22 文档归档 产 品交付 1 计划 方案 用例 用例规程 项目总结 经验总结 bug 分享 缺 陷分析 测试报告 Comment 微微微微23 约定好像都在 前面吧 软件测试规范管理 V1 1 第第 9 页页 共共 10 页页 因和解决方法做个备注 以便日后追溯 开发人员认为该缺陷可以不予修改或者不是缺陷的 可与测试人员协商后将状态改为 已否决 或由测试人员直接关闭缺陷 并要注明原因 7 57 5 关闭缺陷关闭缺陷 测试人员对已修改的缺陷进行验证 如果已修改完成 测试人员将缺陷状态设置为关 闭 如果没有修改或引起回归问题 将修改缺陷状态为 重新打开 或新增缺陷 由开发 人员继续修改 7 67 6 保留缺陷保留缺陷 对于有争议的缺陷进行 将有项目经理最终决定是否修改 如果缺陷是由于技术原因 版本原因等不能修改 则保