软件测试规范管理v11

《软件测试规范管理v11》由会员分享，可在线阅读，更多相关《软件测试规范管理v11（10页珍藏版）》请在金锄头文库上搜索。

1、软件测试规范管理 V1.1 软件测试规范管理软件测试规范管理 （V1.1） 修订历史记录 日期版本作者审核者说明 20123-3-6V1.1 * 初稿 2 目目 录录 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

2、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. 目的目的 本文档是测试和开发团队的日常工作规范，主要侧重测试工作流程的控制，明确软件 工程的各阶段测试应完成的工作以及开发应提供的文档

3、。 1.21.2 适用范围适用范围 本过程适用于软件测试过程中所有活动，即适用于参与项目的所有开发和测试人员。 1.31.3 术语、名词定义术语、名词定义 1.3.11.3.1 开发文档开发文档 开发人员提供给测试人员的开发文档至少包括以下几种：需求文档，概要设计，详细 设计，用户手册等。 1.3.21.3.2 测试文档测试文档 测试文档包括测试计划、测试用例说明、BUG 报告及分析、测试总结，以及测试工作 全部完成后的测试报告等。测试文档由测试人员编写并维护。 1.3.31.3.3 缺陷等级说明缺陷等级说明 1）A 类：致命缺陷，最严重的等级，缺陷会导致网站任何一个主要功能完全丧失， 用户数

4、据受到破坏、系统崩溃、死机等。 2）B 类：严重缺陷，系统的主要功能部分丧失、数据不能完整保存，系统的次要功 能完全丧失，系统所提供的服务和功能受到明显的影响 3）C 类：一般缺陷，系统的次要功能没有完全实现，但不影响用户的正常使用 4）D 类：较小缺陷，界面错误、菜单布局不合理，提示不准确等，在使用过程中跟 用户带来一定的不方便和操作难度 5）E 类：建议缺陷，对网站使用的友好性有影响，如拼写错误、界面布局、文档的 可读性、操作的一致性等 2.2. 测试职责测试职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度

5、提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。 4 编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告供项目组参考。 3.3. 测试流程图测试流程图 4.4. 测试申请测试申请 开发组向测试负责人提交测试申请表 ，该文档要说明：申请测试人员数量，进行哪 些功能的测试，需要提交哪些测试文档，测试周期，测试环境要求。 4.14.1 项目初期项目初期 项目立项初期时需提交需求文档 、 概要设计 、 详细设计 、 开发进度表 4.24.2 迭代功能开发迭代功能开发 开发组提交送测表 ，其中包括可测试内容和测试注意事项 参与需

6、求分析，了解项目需求内 容 制定项目计划 制定测试计划 编写测试用例 执行测试用例 提交 bug，开发进行修 改 回归问题单 修改补充测试用例 提交测试总结报告 软件测试规范管理 V1.1 第第 5 页页 共共 10 页页 否 迭代功能测试流程图 5.5. 测试准备测试准备 5.15.1 文档分析文档分析 测试人员和开发人员均应参加需求评审、设计评审。对需求说明书 、 系统界面原 型和软件设计说明书等进行阅读和审查，与产品经理、项目经理沟通，根据系统功 能复杂度，系统业务复杂度估算开发时间和有效测试执行时间，为项目总计划和测试计划 的制定提供参考和依据。 通过对文档分析，分解各功能模块，各功能

7、点，为测试用例设计提供数据依据。 5.25.2 测试计划测试计划 根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分 配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织 和管理测试项目。测试计划完成后应该在项目组内进行评审。 研发人员提交送测表 测试人员根据测试表以及 关键用例进行冒烟测试 冒烟测试是否通过 正式进入测试，执行测试用例，编 写测试报告，提交 bug 至缺陷库 测试完毕提交报告给开发 开发人员修改 bug，更新缺陷库，重新送测 返回开发进行修改 测试回归问题单 6 5.35.3 测试用例测试用例 测试用例是为实施测试而向被测试系

8、统提供的输入数据、操作或各种环境设置以及期 望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。 依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发 现需求与设计中的问题后，与需求作者及时沟通确认。 5.3.15.3.1 测试用例设计方法测试用例设计方法 测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的 测试、基于状态图的测试、基于场景的测试。 在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。 5.3.25.3.2 测试用例操作步骤测试用例操作步骤 1、 在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例

9、，在原 有测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过 后将使用该测试用例测试被测系统。 2、 在测试的执行过程中和进行回归测试后，对已设计的测试用例进行维护更新。 5.3.35.3.3 测试用例选择准则测试用例选择准则 测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以 及极限的输入数据、操作和环境设置等； 测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的； 测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。 5.45.4 测试软测试软/ /硬件环境硬件环境 根据需求文档提供的内容，和开发部沟通确定测试项目所

10、需的软硬件环境，完成对测 试项目所需软硬件资源的准备工作，使软硬件资源得到满足。 5.55.5 测试数据测试数据准备准备 完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、 单位组织等信息和测试相关的测试数据。 6. 测试执行测试执行 6.16.1 测试准入条件测试准入条件 1、 不接受无详细需求文档和开发说明的项目 软件测试规范管理 V1.1 第第 7 页页 共共 10 页页 2、 需要测试的项目至少提前 2 个工作日提交测试进行需求分析 3、 开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是 可以正常使用 6.26.2 项目测试阶段项目测试阶

11、段 测试人员依据测试计划和测试用例进行测试活动。 测试一般分为两个阶段： 1、测试执行阶段：该阶段测试人员测试出 bug 后将缺陷提交至缺陷管理库。 2、回归问题单：开发修改完 bug 之后，测试进行验证回归。 6.36.3 测试退出标准测试退出标准 1、 测试对可回归缺陷的回归率达到 100%。 2、 全部的测试用例集执行完毕。 3、 缺陷处理达到 100%。 6.46.4 测试测试变更变更 当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更 风险。如变更情况被项目组通过，测试人员将按上述流程进行变更测试。 8 7.7. 缺陷管理缺陷管理 7.17.1 缺陷管理流程缺

12、陷管理流程 测试人员开发人员项目经理 提交BUG 否否 是否描述清晰 修改BUG 是是 关闭BUG 是否修改正确 正正确确 不不正正确确 BUG是否有争议 否否 是否需要修改 是是 是是 是是 是否需要延期 修改 保留BUG 是是 否否 7.27.2 提交提交缺陷缺陷 测试人员将缺陷填写到缺陷管理库中，将缺陷分配给为开发组长或相应的开发人员。 7.37.3 分配分配缺陷缺陷 开发人员分别对自己收到的缺陷进行评审。评审后如果对提交的缺陷有疑问，可以与 提交人协商。对未能达成一致的缺陷由项目经理组织项目组成员评审。评审人员可以是项 目组人员。 如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开

13、发人员可以将缺陷再次 分配给其他开发人员。 如果开发对测试提出的 bug 不理解或者不能重现时，可以要求测试复现 bug。 7.47.4 修改缺陷修改缺陷 开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其 他状态。修改完后开发应对修改后会影响的其他功能模块做个说明，还需对缺陷产生的原 软件测试规范管理 V1.1 第第 9 页页 共共 10 页页 因和解决方法做个备注，以便日后追溯。 开发人员认为该缺陷可以不予修改或者不是缺陷的，可与测试人员协商后将状态改为 “已否决”或由测试人员直接关闭缺陷。并要注明原因。 7.57.5 关闭缺陷关闭缺陷 测试人员对已修改的缺陷进行验

14、证。如果已修改完成，测试人员将缺陷状态设置为关 闭。如果没有修改或引起回归问题，将修改缺陷状态为“重新打开”或新增缺陷，由开发 人员继续修改。 7.67.6 保留缺陷保留缺陷 对于有争议的缺陷进行，将有项目经理最终决定是否修改。如果缺陷是由于技术原因、 版本原因等不能修改，则保留该缺陷并加以注释。 8.8. 测试结果分析测试结果分析 测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量， 缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量等情况。 测试报告由测试人员编写并提交给项目经理。测试报告需要经项目组评审通过。 9.9. 约定约定 就测试与开发人员就测试过程中的交互，

15、约定如下： 1.每次迭代开发后的正式送测必须编写送测表。 2.如送测后的功能执行关键测试用例不能通过，则测试人员有权利中止测试。待开发修 改完并自测确定无阻塞性问题后再提交测试。 3.测试人员测试过程中，必须依据所有的 BUG 都体现在测试报告中的原则，保证所发现 的 BUG 都已添加到测试报告中。 4.测试人员测试完毕后，必须通知相关的负责人及程序人员。 5.开发人员必须明确写明 BUG 引起的原因及解决方法 ，以方便以后做追溯。 6.开发人员如对测试人员所填写的 BUG 不理解或不能重现，可请求测试人员解释或重现， 而不能直接拒绝修改。 7.在修改送测功能时，开发人员做的任何代码上的改动（非针对明确写出的 BUG 时） ，都 10 必须同时通知测试人员，以便进行针对性的回归测试。 10.10.标准文档标准文档 测试申请单 送测表 测试计划 测试用例 测试报告