BUG报告处理
在软件测试过程中，对于发现的每一个软件缺陷，都要记录其特征和复现步骤等信息，以便相关人员分析和复现软件缺陷。
一、软件缺陷报告包含的内容
1、报告编号：为了方便对缺陷进行管理，每个缺陷必须赋予一个唯一的编号，规则根据需要和需求进行制定；
2、标题：标题用简单的方式可以传达缺陷的基本信息，标题应该简短并尽量做到唯一，因为这个缺陷可能在以前的版本修改过；
3、报告人：缺陷报告的原始创造人，有时也应该包含报告的修订者；
4、报告的日期：首次报告的日期。让开发人员知道创建缺陷报告的日期是很重要的，因为这个缺陷有可能在以前的版本有改过；
5、程序或组件的民称：可分辨测试对象；
6、版本号：测试可能跨越多个版本的软件，提供版本信息可以方便对缺陷进行管理；
7、配置：发现缺陷的软件和硬件配置。如操做系统类型、是否用游览器、处理器的类型和速度；
8、缺陷的类型：如代码错误、设计你问题和文档不匹配；
9、严重性：描述报告的严重性；
10、优先级：由开发人员或管理人员确定；
11、关键词：使用关键词以便分类查找缺陷报告；
12、缺陷描述：对发现的问题进行详细描述
13、重现步骤：这些步骤必须是有限的，并且描述的信息足够读者知道正确的执行就可以重现报告的缺陷；
14、结果对比：在执行了重现步骤后，将期望结果与实际结果进行对比
下面是一个软件缺陷模板
|
模板名称
|
用户注册
|
||
|
版本号
|
v1.1
|
测试人
|
XXX
|
|
缺陷类型
|
功能错误
|
严重级别
|
B
|
|
可重复性
|
是
|
缺陷状态
|
New
|
|
测试平台
|
win XP Professional
|
游览器
|
ie8.0
|
|
简述
|
系统规定注册用户名长度为6-20字符，至少6个字符的用户名可成功注册
|
||
|
操做步骤
|
1、进入xxx购物网首页
2、单机“注册”按钮，进入用户注册协议页面
3、单机“同意”按钮，进入用户注册信息页面
4、按要求输入相关信息
5、点击“提交”按钮，提示注册成功
|
||
|
实际结果
|
提示用户名错误，不能注册成功
|
||
|
预期结果
|
注册成功
|
|
|
|
注释
|
建议修改
|
|
|
二、缺陷的严重性和优先等级
1、缺陷的严重性
0级（致命）：最严重等级，缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机等；
1级（严重）：系统的主要功能部分丧失、数据不能完全保存，系统的次要功能完全丧失，系统所提供的功能或服务收到明显影响；
2级（一般）：系统的次要功能没有完全实现，但不影响用户的正常使用。例如，提示信息不太准确；或用户界面差、操做时间稍长等问题；
3级（微小）：操作者不方便或遇到麻烦，但不影响功能的操做和执行，如字体不美观、按钮大小不很合适、字体排列不对齐等一些小问题。
2、缺陷的优先级
立即解决（p1级）：缺陷导致系统几乎不能完全运行、使用，或严重妨碍测试的执行，需立即修正、尽快修正；
高优先级（p2级）：缺陷严重，影响测试，需要优先考虑修正，如不超过24小时修正；
正常排队（p3级）：缺陷需要修正，但可以正常排队等待修正；
低优先级（p4级）：缺陷可以在开发人员有时间的时候被修正，如果没时间可以不修正。
三、软件缺陷的生命周期
缺陷的生命周期可以简单地表现为：打开（open）—修正(fixed或solved)—关闭（close）
软件缺陷状态的描述：
打开/激活：缺陷的起始状态，或重新打开的状态。问题存在或依旧没有解决，等待修正，如新报告的缺陷、补充完整信息后在打开；
已修正：已经被开发人员检查、修复过的缺陷，通过单元测试，认为及解决但还待测试人员验证；
关闭/非激活：测试人员验证后，确认缺陷不存在的状态；
无法解决：由于技术原因或者第三方软件的缺陷，开发人员目前不能解决的缺陷；
延迟：这个缺陷不严重，被推迟修正，可以在下一个版本解决；
功能增强：该问题符合 当前的设计规格说明书，但有一个待改进问题；
不是缺陷：开发人员认为不是问题，十年测试人员的误报缺陷；
不能再现：开发人员不能复现这个软件缺陷，需要测试人员检查缺陷复现步骤；
需要更多信息：开发不能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件、图片等。
缺陷质量
- 缺陷分级：一般四级分类法，
- 缺陷记录：bug管理系统，bug的生命周期理论
- 缺陷反思：bug评审，开发避免类似错误，测试在设计测试用例的时候考虑类似情景
《BUG严重性等级与优先级定义》
同时在测试过程中，发现了 bug 必须详细描述问题，不管是 jira,禅道或是其他的 bug 管理方式，一个 bug 要写清楚以下几点：Bug 问题描述，bug 重现步骤，是否有前置条件，预期结果，实际结果，以方便开发去进行修改。同时给 bug 准确分级，实时跟踪进度，保证项目按期完成。
上线回归与项目总结
一个需求上线完成后，要及时进行线上回归，如果有必须提醒相关的人员进行自动化线上回归或是监控工作。
在一个项目完成后，不管公司有没有要求，要对项目做相应的文字总结。总结整个项目过程中遇到的问题，最后的解决办法或是当时讨论的处理办法，有哪些需要注意的问题？有什么可以借鉴的方案或是改进策略？项目中有没有通用性的问题等等。
如冒烟测试是否一次通过，Bug 数及不同级别的 bug 数，参与开发人员对应的 Bug 数，提测试次数，上线次数等等。而后借助于第三方工具进行图表化相应的数据，然后相关问题的总结，改进方案都需要进行详细的总结。
好多也说会写缺陷报告，但总是提交信息不系统，漏掉某些关键业务处理链路上的必要信息。
缺陷报告的处理
1. 缺陷报告的简单处理流程/缺陷的生命周期
- 软件测试人员提交缺陷报告；
- 测试负责人审核后将缺陷报告分配给相关的开发人员修改；
- 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；
- 返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重新 修改，缺陷报告直到缺陷被修复以后才关闭；
- 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，这些报告一旦被再次打 开应该立即处理。
2. 缺陷报告的标准处理流程
- 正常缺陷
- 重复缺陷
- 无效缺陷
- 推迟修改
- 验证不通过
- 描述不清楚
3. 缺陷跟踪管理系统/缺陷管理工具
3.1 缺陷管理工具的功能
- 缺陷提交
- 缺陷跟踪
- 缺陷分析
- 有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评 估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程 进行改进。
- 缺陷分析还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指 定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。
3.2 常见缺陷管理工具
- Bugzilla
- Bugfree
- Mantis
- Jira
- ZenTao（禅道）
- Quality Center/Application Lifecycle Management
- 目前市场占用率最高的项目管理工具。
- 全球最大的测试工具提供商 Mercury Interactive 公司生产的企业级项目管理工 具。
