BUG測试规范(draft)-V0.2.doc

Rocket Service测试规范 Version 0.1 联想研究院 2009年八月  修改记录 时间 章节 修改类型 描述 作者 版本 2009-08-20 全部 A 文档新建 张跃华 0.1 2009-09-18 5.3.35.3.4 M 修改难检度与频度定义 邱双稳 0.2 *修改类型分为 A - ADDED M - MODIFIED D – DELETED 评审记录 评审编号 评审组长 评审日期 结论 评审形式 评审报告 Content 1 介绍 4 1.1 目的 4 1.2 适用范围 4 2 测试过程中工具约束 4 3 测试需求管理 4 3.1 创建测试需求规格 4 3.2 创建测试需求 5 4 测试用例规范 5 4.1 用例级别属性（Keywords） 5 4.2 用例书写规范 6 4.3 测试用例的执行 7 4.4 测试用例的执行的结果 7 5 Bug的提交和管理规范 8 5.1 BUG的属性 8 5.2 BUG的状态属性 8 5.3 BUG的等级属性 9 5.3.1 故障等级分类 9 5.3.2 严重度（S） 9 5.3.3 难检度（D） 10 5.3.4 频度（O） 10 5.3.5 BUG的等级属性 10 5.4 BUG解决优先级别的属性 10 5.5 BUG解决状态定义 11 5.6 BUG填写规范 11 5.7 BUG跟踪 12 6 附录：需求和Bug的示例 13  介绍 目的 为了测试人员在进行测试过程中，能够高质量的完成工作，特制订此规范。从而让测试人员在撰写用例、测试用例和提交Bug等测试环节和过程中，有可以依照的标准，同时也规范了测试人员在这些测试环节和过程中的行为。 适用范围 本文档的针对对象主要是Rocket Service项目的测试人员，同时也是开发人员和项目经理的参考依据。 测试过程中工具约束 测试管理工具：TestLink Bug管理工具：Bugzilla 测试需求管理 测试需求是我们开展测试的依据。首先，我们对产品的测试需求进行分解和整理。一个产品可以包含多个测试需求规格，一个测试需求规格可以包含多个测试需求。 在开展一个测试的首要任务是对测试需求进行分解和整理并录入到Test Link中，当需求和用例完成后，需求和用例必须做相应的关联。录入需求主要包含两个步骤: 创建测试需求规格 首先要创建需求规格，需求规格比较简单，主要包含以下两个部分： 项目 说明 标题 所填需求规格的标题 范围 所填需求规格的内容范围 创建测试需求 一个测试需求主要包含以下几个方面： 项目 说明 需求ID 所填需求的编号 需求名称 所填需求的简要说明 需求范围 所填需求的内容 需求状态 共有两种状态：正确的（Valid）、不可测试的（not testable）Keywords） 此字段主要是用来标识用例的级别，通过对用例的级别定义，可以使整个测试过程分级式管理，从而指导测试流程的顺序、突出重点问题、选择性测试，节约了测试成本，同时也便于更好的表述和分析测试结果。也是我们定义开始测试标准、停止测试标准以及回归测试标准的一个依据。所有的用例将被定义的状态如下： 1、Base（基础，可测用例） 此级别为基础型，表述了能保证系统可以运行的基本条件，同时也定义了此安装包可以进行下一步测试的标准。 如：是否有遗漏功能、安装测试、基本功能点是否没有问题、各项服务是否都是正常运行、提交制品是否相符等等。 2、Important （重要，可测用例） 此级别为重要型，在完全通过了Base类型用例的测试后，首先要测试的用例，这些用例表述了系统能正常运行的条件和此版本发布必需要满足的条件。此类型的用例将符合以下标准之一： 涉及整个功能模块的用例，如果此用例不通过，将导致功能模块不可使用或功能不正常的用例。如：注册用户、注册服务等等。 能表明某项功能基本满足需求的用例。 涉及到共性问题的用例，如： 发送消息等。 在release Note声明解决的bug。 用户在正常使用中，出现频繁情况的用例。 3、Normal（普通用例） 此级别为普通型，测试用例的主体。该类型的用例主要针对在保证系统正常运行的前提下，对功能行用例进行完善，对功能性用例进行扩展。另外还有测试系统对特殊情况、异常情况、异常操作情况的处理能力，从细微找出系统漏洞，从而更加完善系统的抗压性和稳定性。 4、Extend（扩展用例） 此级别为建议型，该类型用例针对不影响系统正常运行的建议，力图完善系统现有功能或提出对系统功能的展望。如：界面显示信息明确、系统退信的语言规范等 用例书写规范 1、Test Cas