测试管理规范20110620.doc

测试管理规范 编制： 日期： 审核： 日期： 批准： 日期：  版本修订记录 编号 修订日期 版本 修订人 修 订 内 容 目 录 1 附录 1-4 1.1 BUG优先级与严重级别定义 1-4 4.1.1 BUG优先级 (Priority)定义 1-4 4.1.2 BUG严重级别(Severity)定义 1-5 1.2 TD中角色变更BUG状态对应说明 1-6 4.2.1 测试人员可以改变的bug状态 1-6 4.2.2 开发人员可以改变的bug状态 1-6 4.2.3 项目经理可以改变的bug状态 1-7 1.3 BUG处理原则 1-8 4.3.1 测试人员处理原则 1-8 4.3.2 开发人员处理原则 1-8 1.4 无效BUG（invalid）定义 1-8 1.5 BUG产生原因定义 1-9 1.6 测试退出（code freeze）准则 1-9 1.7 冒烟测试用例选择标准 1-10 1.8 测试执行期间版本发布原则 1-11 4.8.1 新功能版本发布 1-11 4.8.2 新功能版本+BUG Fixed版本发布 1-11 4.8.3 BUG Fixed版本发布 1-11 4.8.4 版本发布推进原则 1-12 测试管理规范 BUG优先级与严重级别定义 1.1.1BUG优先级 (Priority)P5-urgent? 最此优先级别的Bug，如果不进行修改会影响到系统主要功能的，优先级别最高操作中断测试不能继续进行程序崩溃原则上处理周期控制在BUG发布当天P4-Very High ?较此优先级别的Bug，如果不进行修改，会影响到其他功能的优先级别较高原则上处理周期控制在BUG发布后的一天内P3-High ? 一般此优先级别的Bug，如果不进行修改，说明功能没有实现有错误，优先级别一般原则上处理周期控制在BUG发布后的一天内P2-Medium ? 较低优先级 设定原则：此优先级别的Bug，如果不进行修改，不影响主要功能，属于页面美观和易用性的问题原则上处理周期控制在BUG发布后的两天内P1-Low ? 最低优先级 设定原则：此优先级别的Bug，不影响主要功能，只是页面上的文字错误或者需要改进的建议原则上处理周期控制在BUG发布后的两天内 优先级=问题出现的可能性+问题的严重性 问题出现的可能性划分： K1为随机出现，且出现几率比较低，暂且约定一个测试周期出现一两次。 K2为随机出现，且出现几率加大，10次操作出现3次以上。 K3为毕现，但仅在极端使用条件下出现，例如打开文档数量超过30个，新建500个白板等；或复杂的操作步骤、复杂的使用场景、某个操作时点才出现（如状态同步问题）等。 K4为毕现，但操作步骤较复杂，实际应用环境存在但不多。 K5为毕现，操作步骤简单，均属于正常操作范围。 严重等级=3时，可能性权值要进行换算，换算公式为Kn*3/5，按照向上取整的原则计算。 1.1.2BUG严重级别(Severity)S5-urgent类严重错误由于程序所引起的死机,非法退出死循环导致数据库发生死锁数据通讯错误严重的数值计算错误S4-Very High类较严重错误功能不符数据流错误程序接口错误轻微的数值计算错误S3-High类一般性错误界面错误(详细文档)打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示S2-Medium类较小错误辅助说明描述不清楚显示格式不规范长时间操作未给用户进度提示提示窗口文字未采用行业术语可输入区域和只读区域没有明显的区分标志系统处理未优化S1-Low类测试过程中站在用户角度提出一些易用性，人性化等更利于系统优化的建议（非系统缺陷） BUG处理原则当变更BUG状态时，开发、测试人员需要报告BUG后测试人员主动与开发人员沟通他们是否需要以邮件通知的模式通知BUGBUG描述需要尽量做到清晰、易懂，对于可以重现的BUG开发人员能够按照描述步骤重现BUG测试执行中发现BUG直接，报告BUG时除将BUG发现步骤描述清楚外，还需要提供测试数据、系统日志、截图等有助于开发人员分析、解决BUG的相关文件填报BUG或者转给他人BUG是否需要Email通知根据不同项目决定，但是所有转给产品人员的BUG均需要同时发送Email通知必须首先和测试人员沟通并获得同意对于标识为可重现的BUG开发人员必须按BUG描述步骤自己重现BUG，如果描述不清楚才可以要求测试人员配合重现开发、测试人员将一个bug转给他人之前，必须进行沟通并获得同意Bug的优先级别测试人员任何bug都不应该被删除，但是可以被置为 产品原有BUG，如某个项目的升级版本出现BUG，经查是原版本已知的BUG则可以选择