（二）缺陷报告

转载

mob604757037cf3 2018-05-09 16:30:00

当测试人员发现一个缺陷，需要填写一份“缺陷报告”来记录这个缺陷，并通过这个缺陷报告告知开发人员所发生的问题–缺陷报告是测试人员和开发人员交流沟通的重要工具。
案例1：张三在测试案例1-2-1程序时，发现除数为0时程序异常退出，向开发组提交一份缺陷报告。
（二）缺陷报告_开发人员
（二）缺陷报告_sed_02
一、缺陷报告的组成：
①缺陷编号（Defect ID）:提交缺陷的顺序
②缺陷标题（summary）：简明扼要的描述缺陷
③缺陷的发现者（Defected By）:测试人员
④缺陷发现日期（date）：一般为当天
⑤缺陷所属的模块（subject）：在测试哪个功能模块时发现的bug.
开发组可以据此决定由谁负责修改该bug
⑥发现缺陷的版本（Defected in release）:
⑦指派给谁处理（Assigned to）:测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员。
⑧缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告、把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug,把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug,把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态改为fixed（已经修复的bug，可以返测的bug）
（4）测试人员对修复的bug进行返测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）
缺陷报告的处理流程
（二）缺陷报告_开发人员_03
用图表示↓：
（二）缺陷报告_优先级_04
说明：
（1）以上过程就是缺陷的处理流程
（2）一个缺陷的生命周期：new->open->fixed->closed
返测：针对程序员修复的缺陷进行测试，验证该缺陷是否真正解决。
⑨缺陷的严重程度（severity）：bug对软件的影响有多大
urgent：造成系统死机、重启、崩溃的缺陷
very high：非常严重的缺陷
high：大的缺陷
medium：中等程度的缺陷
low：小的缺陷

bug level（等级、级别）每一个等级到底包括哪些缺陷，最好在专门的文档中进行详细说明，这样可以使开发人员和测试人员达成共识
性能：performance
功能：function
⑩缺陷的优先级（priority）
测试人员希望该缺陷程序员在什么时间或者在哪个版本中解决
urgent：立刻修改（影响开发或测试的进度）
veryhigh：本版本修改（一个软件开发过程可能就含有多个版本，比如一个星期就是一个版本）
high：下版本修改
medium：产品发布前修改
low：允许在产品发布后存在的软件缺陷
十一：缺陷描述（description）
把发现bug的步骤、使用的数据等记录下来，使程序员通过该描述就能清楚所发生的的事情。
二、加深理解
1.缺陷的严重程度和优先级是不是成正比关系？
界面问题的严重程度一般比较低，但优先级可能很高—-立即修复
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低—在发布之前修复
2.缺陷的严重程度和优先级确定好后，还能改吗？
严重程度不允许改，优先级可能修改。
测试人员确定一个缺陷为“立即修复”，但开发组认为这个缺陷不好解决，而这个缺陷又不影响其他功能，这时可能要求在“下一个版本修改”或“发布之前修改”
3.是不是所有已发现的缺陷都会被修复？
有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户造成重大的影响及法律纠纷。后面再通过升级软件或者打补丁的方式修复缺陷或弥补漏洞
三、缺陷报告的用途
①记录bug
②对bug进行分类（模块、bug状态、严重程度、版本）
③跟踪bug
④对bug进行分析、统计
四、如何识别bug
①通过测试用例的预期结果判断—实际结果与预期结果不一致，就是bug
②看需求（通过缺陷的5点定义识别）
③沟通（开发、需求、用户）
五、写缺陷报告时注意的问题
①一个报告只提交一个缺陷
②缺陷描述清晰、准确、易读，使用最少、必须的步骤，保证缺陷可以再现
③对缺陷的严重性、优先级的划分准确、客观
④在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确造成的“假缺陷”
⑤不要为了引起开发人员的重视而夸大缺陷
⑥小的缺陷也要报告
⑦及时报告缺陷
⑧对于不可重现的缺陷也要报告
⑨不做任何评价