缺陷报告书写注意

1.测试用例:缺陷比10：1或20:1。
2.实际工作中没有缺陷报告评审的活动。
3.缺陷有没有发现有价值。
有价值的缺陷是指和业务相关性比较强的缺陷。输入的合法性检查产生的bug一般就不是有价值的缺陷。
4.缺陷报告的格式：缺陷ID、缺陷标题、测试环境、重现步骤（包含预期结果和实际结果）、附图／附件、提交人、提交时间、严重级别（对用户影响有多大）、优先级（开发优先处理的顺序）、重现频度、缺陷状态。
5.缺陷标题的写法是：在什么什么界面／环境下？做什么操作？出现什么异常？
6.严重程度：致命、严重、一般、提示或者非常高、高、中、低，或者1,2,3,4/ABCD。实际工作中会对严重程度做定义，尽量让大家的设置一致，可以在测试方案中定义。
7.优先级
8.重现步骤如果细化，可以包含：预置条件、操作步骤、预期结果、实际结果。
9.缺陷无论大小，尽量都要有截图。
10.缺陷标题一般不超过20个字。
11.缺陷编号一般就是数字。
12.测试环境一定要标明具体的型号/版本。

Bug的严重程度。
1系统崩溃
2.某个功能失效
3一般子功能出现故障。

用例通过是pass，有bug是fail，用例问题是N/A
评审或执行用例不能修改用例
Bug的浏览器选择全部的浏览器

通过两次bug缺陷报告的编写，发现自己的诸多不足。
当然不同的是，第1次是直接执行测试用例在Excel里面编写的用例报告，第2个是在禅道里面编写导出的css文档。后期更偏向于实际工作一点。
不住足原因有以下几点
①测试用例本身覆盖的不全及不准确，对bug执行有诸多限制。
②同一模块同样功能类型的bug属于一个bug。
③用例执行bug应严格出现在bug缺陷报告文档中，执行结果应标注准确。
怎么处理偶发性的bug？（找到规律，排除环境问题）
发动更多的人去找复现bug的步骤，做更大范围的交互测试，争取找到规律。

实际工作执行测试效率比较严格，严肃进行，不要漏测。
用例是生命线，明码标价。