测试文档和缺陷等级.docVIP

本人自己整理的测试相关文档资料： 一、测试过程中都需要哪些文档： 测试方案(主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用表) 测试执行策略(可以主要包括哪些可以先测试，哪些可以放在一起测试之类的) 测试用例(主要根据测试用例列表，写出每一个用例的操作步骤和紧急程度，和预置结果)， BUG描述报告(主要可以包括测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息)， 整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)。 二、软件缺陷等级划分： A类——致命错误，包括以下各种错误： 由于程序所引起的死机，非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误 B类——严重错误，包括一些各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件 C类——一般错误，包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给提示 数据库表中有过多的空字段 D类——提示错误，包括以下各种错误： 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 三、测试用例级别： Level1基本： 该类用例设计系统基本功能，1级用例的数量应受到控制 划分依据：该用例执行的失败会导致多数重要功能无法运行的，如：表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的而经常这样使用的一些功能用例。 该级别的测试用例在每一轮版本测试中都必须执行 Level2重要： 1.2级测试用例设计系统的重要功能，2级用例的数量较多。 2.划分依据：主要包括一些功能交互相关、各个应用场景、使用频率较高的正常功能测试用例 3.在非回归的系统测试版本中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排进行测试。 Level3一般： 1.3级测试用例设计系统的一半功能，3级用例数量也较多。 2.划分依据：使用频率较低于2级用例。例如：数值或数组的便捷情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。 3.在非回归的系统测试版本中不一定都进行验证，而且在系统测试的中后期并不一定需要每个版本进行测试 Level4生僻：如果没有可以不适用该级别 该级别用例一般非常少 划分依据：该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的出发条件非常特殊，仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。 在版本测试中有某些正常原因（包括：环境、人力、时间等）经过测试经理同意可以不进行测试。 四、测试用例模板 模板一： 测试用例 项目编号 项目名称 项目负责人 用例编号 用例作者 编写日期 覆盖模块 业务逻辑 用例编号 前置条件 操作步骤 预期结果 执行结果 Pass/Fail 备注 模板二： 功能测试用例 测试用例编号 测试优先级 测试用例名称 软件版本号 版本日期 编写人员 编写日期 测试类型 ?功能 ?性能 ?边界?可靠性 ?安全性 ?强度 ?人机界面 ?其他 测试方法 测试目的 前置条件 操作步骤 输入数据 预期结果 实际结果 附： 项目编号规则 1． 项目编号为15位：xx_yyyyzzz_abcd2． xx 表示项目类别： 内部的产品项目：PI 对外的工程项目：PO3． yyyy 表示年份， 如 20014． zzz 表示项目序号，如 0015． abcd 时项目的英文缩写。 测试用例编号规则 [用例类型编号]-[模块名称缩写]-序号 用例类型编号 含义 ST 系统测试用例 IT 集成测试用例 UT 单元测试用例 模块名称缩写：此编号由项目确定，参考功能列表和用例规范 序号：从0001开始，一个项目中用例序号唯一 五、测试计划和明细模板 测试项目工作计划模板 项目名称： 项目编号： 内容概述： 项目周期20101020 序号 状态 功能说明 安排计划 人员 工作量（人日） 备注