父母邦测试bug规范

父母邦Bug等级划分及响应（更新中）

• 各角色职责划分

开发负责人 
每天对Bug 进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug 库分析，找出常出错的模块，进行代码审查

开发人员 
修复bug中提到的问题，修改完成后将bug状态置为“已解决”并添加修改备注（问题定位或者修复方案），同时指派给提交bug的测试人员。

产品人员 
解释需求，给出处理意见，将Bug 库中的建议整理成需求文档。评审确定后列入开发计划

测试人员 
提交bug，指派给负责该项目的开发人员，如果不明确指派对象或者提交的是建议性bug，可指派给开发负责人或者产品经理。提交的Bug要包括bug的严重程度、验证Bug 是否已被解决

测试负责人 
审核测试人员提交的Bug。定期对Bug 库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见

• 'Bug'状态，优先级，严重程度

'Bug '状态(Status) ：指缺陷通过一个跟踪修复过程的进展情况。
新建	为测试人员新问题提交所标志的状态。
认可	为任务分配人（开发组长/ 经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug 解决中的状态，由任务分配人改变。对没有进入此状态的Bug ，程序员不用管。
重开	为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。
已修复	为开发人员修改问题后所标志的状态，修改后还未测试。
关闭	为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
反馈	开发人员认为不是Bug 、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug 分配人或者开发人员来设置。
'Bug '严重级别(Severity ，Bug 级别) ：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。
致命错误	致命错误通常有如下情况：1、需求书中的重要功能未实现；2、造成系统崩溃、死机,并且不能通过其它方法实现功能；3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。
严重错误	严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如：1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；2、重要功能不能按正常操作实现，但可通过其它方法可实现；3、错误的波及面广，影响到其它重要功能正常实现；4、密码明文显示；5、C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。
中等错误	程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如：1、次要功能不能正常实现；2、操作界面错误（包括数据窗口内列名定义、含义不一致）；3、打印内容、格式错误；4、查询错误，数据错误显示；5、简单的输入限制未放在前台进行控制；6、删除操作未给出提示；7、数据库表中有过多的空字段；8、因错误操作迫使程序中断；9、找不到规律的时好时坏；10、数据库的表、业务规则、缺省值未加完整性等约束条件；11、经过一段时间运行后，系统性能或响应时间会变慢；12、重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；13、硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；14、系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。
细微错误	程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如：1、界面不规范；2、辅助说明描述不清楚；3、输入输出不规范；4、长操作未给用户提示（或长操作结束后提示没有消失）；5、提示窗口文字未采用行业术语；6、可输入区域和只读区域没有明显的区分标志；7、界面存在文字错误；8在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)
改进建议	进行合理化建议。不影响使用的瑕疵,更好的实现方式。
'Bug '优先级(Priority) ：指缺陷必须被修复的紧急程度。由Bug 分配者（开发组长/ 经理）指定。
紧急	阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试
非常高	必须修改，发版前必须修正
高	必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
中	如果时间允许应该修改
低	允许暂不修改

上线前优先级其他状态可设定为：重要且紧急;重要不紧急;紧急不重要;不紧急不重要，

处理意见: 开发组长/ 经理( 或具体Bug 分配人员) 在审核新Bug 时、将Bug 分配给开发人员解决前，需要给出该Bug 的处理意见。

重复	表示该Bug 已经被其它测试人员找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
延后	由于时间、进度、重要程度或者技术/ 需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug 。（注：因‘Bug 状态’字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/ 测试各有侧重地使用这两个Postponed ）
原始设计	因设计结构问题无法修改。测试人员认为是Bug ，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大
不可复现	不能重现（如因Bug 出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug 的时候把这个Bug 一并修复掉了）。
不是问题	测试人员提错了
不修复	这个Bug 是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计

 

说明：
1. 定为重复的Bug ，必须注明和XXX bug 重复。
2. 测试人员对标明为重复的Bug 复测，需要XXX Bug 修改后方可进行。
3. 定期回顾不可复现，延后。
4. 定期整理原始设计。

 

• 项目组各角色在Bug 库中的权限

管理员 ：全部权限

测试组长/ 经理 ：全部权限

测试人员 ：可添加Bug 、不能删除Bug 、可添加注释评论(R&D Comments) 、可修改他人所提Bug 、可调整：Bug 概要( 题目，Summary) 、问题描述、附件附图(Attachments) 、Bug 状态、Bug 级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments) 、复测人、复测日期、修改人

开发人员/ 需求人员 ：不能删除Bug ，不能关闭bug。可添加注释评论(R&D Comments) 、可调整：注释评论(R&D Comments) 、是否复现、Bug 状态（不过无法直接标为closed ）、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug 。

开发组长/ 经理/ 需求经理 ：除了开发人员的权限，还可调整：优先级别、责任人、Bug 概要( 题目，Summary) 、附件附图(Attachments),不能关闭bug.。

项目经理 ：可添加Bug 、可添加注释评论(R&D Comments) 、可修改字段：Bug 概要( 题目，Summary) 、问题描述、附件附图(Attachments) 、Bug 状态（不过无法直接标为closed ）、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。也可删除Bug ，但要与测试组长/ 经理协商。

不属于项目组成员的其他人 如研发中心经理组成员等，有必要查看Bug 库的话，可分配给其帐号及查看的权限。

 

• Bug 描述要求

[[|Bug]] 描述的要求 为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/ 经理把关，以开发人员的角度来审查Bug 描述，看其是否描述清楚了Bug ，不好描述的把工程文件或截图作为附件提交。具体要求为：

1)  问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=> 测试步骤=> 期望结果=> 实际结果=> 其它信息，可依实际情况调整；

2)  单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件；

3)  简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；

4)  再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；

5)  复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF ，不建议用BMP ；

6)  报告中不允许使用抽象词句：比如“有错误”之类；

7)  有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug 报告中标识；

 

• 改动：
• 增加预期结果，实际结果,预置前提项。
• 分类改为：模块。
• 出现频率（有时，随机，没有试验，无法重现，不适用）改为：100%,75%,50%,25%,一次，无法复现
• 严重性改为：严重级别，内容做调整
• 优先级别：内容做调整
• 产品版本指的是发现bug的版本，目标版本是计划何时修复，修正版本是已做修复的版本。
• 测试必选字段：模块，出现频率，严重性，产品版本，分派给，摘要，问题重现步骤，预期结果，实际结果。
• Error Manager必选字段：优先级，（目标版本）。
• 开发必选字段：修复版本，处理状况。
• 处理状况增加 新需求 字段

 

早上，中午，下班前检查各自名下的bug。

有异议的问题指派

文档，修复在svn，修改记录，代码评审