软件测试规范管理V11.docVIP

软件测试规范管理 （V1.1） 修订历史记录 日期 版本 作者 审核者 说明 2015-7-17 V1.1 张生亮 初稿 目 录 1. 概要 3 1.1. 目的 3 1.2适用范围 3 1.3 术语、名词定义 3 2. 测试职责 3 3. 测试流程图 4 4.1项目初期 4 4.2 迭代功能开发 4 5. 测试准备 5 5.1文档分析 5 5.2测试计划 5 5.3测试用例 6 5.4测试软/硬件环境 6 5.5测试数据准备 6 6. 测试执行 6 6.1测试准入条件 6 6.2 项目测试阶段 6 6.3 测试退出标准 7 6.4测试变更 7 7. 缺陷管理 7 7.1缺陷管理流程 7 7.2提交缺陷 7 7.3分配缺陷 8 7.4修改缺陷 8 7.5关闭缺陷 8 7.6保留缺陷 8 8. 测试结果分析 8 概要 目的 本文档是测试和开发团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试应完成的工作以及开发应提供的文档。 1.2适用范围 本过程适用于软件测试过程中所有活动，即适用于参与项目的所有开发和测试人员。 1.3 术语、名词定义 1.3.1 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种：需求文档，概要设计，详细设计，用户手册等。 1.3.2 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护。 1.3.3 缺陷等级说明 1）A类：致命缺陷，最严重的等级，缺陷会导致网站任何一个主要功能完全丧失，用户数据受到破坏、系统崩溃、死机等。 2）B类：严重缺陷，系统的主要功能部分丧失、数据不能完整保存，系统的次要功能完全丧失，系统所提供的服务和功能受到明显的影响 3）C类：一般缺陷，系统的次要功能没有完全实现，但不影响用户的正常使用 4）D类：较小缺陷，界面错误、菜单布局不合理，提示不准确等，在使用过程中跟用户带来一定的不方便和操作难度 5）E类：建议缺陷，对网站使用的友好性有影响，如拼写错误、界面布局、文档的可读性、操作的一致性等 测试职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： 在需求文档确立基线后，从用户体验和测试的角度提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。 编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告为版本质量提供量化的参考依据，归档项目总结，归档测试经验与技术，分析经典bug。 测试流程图 转系统测试条件 开发组已经完成开发及集成测试，提交集成测试报告、版本发布说明、版本部署说明和需求规格说明书邮件告知测试组人员。 4.1项目初期 项目立项初期时需提交《需求文档》、《概要设计》、《详细设计》、《开发进度表》 4.2 迭代功能开发 开发组提交《送测表》，其中包括可测试内容和测试注意事项 否 迭代功能测试流程图 测试准备 5.1文档分析 测试人员和开发人员均应参加需求评审、设计评审。对《需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查，与产品经理、项目经理沟通，根据系统功能复杂度，系统业务复杂度估算开发时间和有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。 通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。 5.2测试计划 根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划完成后应该在项目组内进行评审。 5.3测试用例 测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。 依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求作者及时沟通确认。 5.3.1测试用例设计方法 计测试用例，可以基于以下方法进行设计： 等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。 测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的； 测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。 5.4测试软/硬件环境 根据需