Bug的处理
问题定位:
Calculate_error | 计算错误,指计算过程中、计算结果错误。 |
Data_error | 数据错误,指非计算结果类的数据错误。 |
Graphics_error | 图形错误,指绘图、图形显示、图形编辑时发生的错误。 |
Interface_error | 界面错误 |
Requirement_error | 需求错误 |
Function_error | 功能错误 |
Unknown_error | 未知错误 |
缺陷来源(Source):指引起缺陷的起因。
Requirement | 由于需求的问题引起的缺陷 |
Architecture | 由于构架的问题引起的缺陷 |
Design | 由于设计的问题引起的缺陷 |
Code | 由于编码的问题引起的缺陷 |
Test | 由于测试的问题引起的缺陷 |
Integration | 由于集成的问题引起的缺陷 |
类型(Type):是根据缺陷的自然属性划分的缺陷种类。
F- Function | 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑,指针,循环,递归,功能等缺陷 |
A- Assignment | 需要修改少量代码,如初始化或控制块。如声明、重复命名,范围、限定等缺陷 |
I- Interface | 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。 |
C- Checking | 提示的错误信息,不适当的数据验证等缺陷。 |
B- Build/package/merge | 由于配置库、变更管理或版本控制引起的错误 |
D- Documentation | 影响发布和维护,包括注释。 |
G- Algorithm | 算法错误。 |
U- User Interface | 人机交互特性:屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷 |
P- Performance | 不满足系统可测量的属性值,如:执行时间,事务处理速率等。 |
N- Norms | 不符合各种标准的要求,如编码标准、设计符号等。 |
(以上依各组实际情况可以作适当调整)
项目组各角色在Bug库中的权限
管理员:全部权限
测试组长/经理:全部权限
测试人员:可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整:Bug概要(题目,Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人
开发人员/需求人员:不能删除Bug、可添加注释评论(R&D Comments)、可调整:注释评论(R&D Comments)、是否复现、Bug状态(不过无法直接标为closed)、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。
开发组长/经理/需求经理:除了开发人员的权限,还可调整:优先级别、责任人、Bug概要(题目,Summary) 、附件附图(Attachments)
项目经理:可添加Bug、可添加注释评论(R&D Comments)、可修改字段:Bug概要(题目,Summary) 、问题描述、附件附图(Attachments) 、Bug状态(不过无法直接标为closed)、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。也可删除Bug,但要与测试组长/经理协商。
不属于项目组成员的其他人如研发中心经理组成员等,有必要查看TD库的话,可分配给其帐号及查看的权限。
Bug描述要求
Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查(截图或其它形式的附件)。测试组长/经理把关,以开发人员的角度来审查Bug描述,看其是否描述清楚了Bug,不好描述的把工程文件或截图作为附件提交。具体要求为:
- 问题描述一般格式:问题描述时,建议分几步描述:模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息,可依实际情况调整;
- 单一:尽量一个报告只针对一个软件缺陷,报告形式应方便阅读。在主报告之后应注明不同的条件;
- 简洁:每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节,不要写无关信息;
- 再现:问题必须在自己机器上能复现方可入库(个别严重问题复现不了也可入库,但需标明);
- 复杂的问题应附截图补充说明或直接通知指定的修改人;考虑到网络数据传输效率,截图的文件格式建议用JPG或GIF,不建议用BMP;抓图可用TestDirector自带的功能,亦可用HyperSnap之类的专用抓图工具。
- 报告中不允许使用抽象词句:比如“有错误”之类;
- 有关操作系统特征问题:应在不同操作系统上进行操作,看是否能重现,并在Bug报告中标识;
- Bug描述示例:
例一 | 例二(模块或功能点也可在‘功能模块’字段中规定,则Bug描述中就不必写了) | 例三(程序员知道期望结果的情况下) | 例四(建议、需求类) |
注:所有项目采用TestDirector进行Bug管理,该工具能从测试步骤自动生成Bug报告,因此对于Bug描述要求在测试方案用例设计(在Test Plan页中)阶段就可以进行控制。
附:好的Bug报告应满足以下几方面的要求:
- 结构清晰
- 复现故障再写报告
- 隔离Bug:更改条件复测
- 归纳:是否其他模块也有相同的Bug
- 比较:其他测试用例是否使用到此Bug
- 总结:报告的开头有Bug的总结
- 精简:不要有多余的步骤和语言
- 无歧义:语言明确
- 中立:无批评性语言
- 讨论:将要发出的报告送其他测试人员讨论
小结
- 通过专业的技术测试出精确的Bug;
- 通过准确的文档报告Bug;
- 通过良好的沟通使Bug尽快解决。