测牛学堂:软件测试基础理论分享之缺陷报告理论知识总结

137 阅读5分钟

首先我们要理解什么是缺陷,缺陷的含义就是不符合需求,缺陷也可以理解为BUG

缺陷的定义

①软件未达到需求规格说明书表明的功能

②软件出现了需求规格说明书明确指定不能出现的错误

③软件功能超出了需求规格说明书指明的范围(多做的功能是画蛇添足)

④软件未达到需求规格说明书未明确指定却应该达到的功能(手机一重启App数据就丢失)

⑤测试人员认为软件难以理解、不易使用、速度慢或最终用户认为不好(甲方拿钱,乙方干工程)

缺陷的表现形式

①功能特性没有实现或部分实现

②设计不合理,功能不明确,逻辑不清楚,存在矛盾

③产品实际结果和预期结果不一致

④没有达到需求规格说明书所规定的性能指标

⑤运行出错,运行中断,系统崩溃,界面混乱

⑥数据不正确,精度不够,数据不完整或格式不统一

⑦用户不能接受的其他问题,比如存取时间过长,界面不美观

格式组成

1)缺陷ID:就是唯一的编号,ID具有唯一性,可以根据ID追踪到具体缺陷

2)缺陷状态:就是BUG修复过程的进展情况 ☆(不同公司定义不同)

提交(New):已提交完成的缺陷,开发没有确认

打开(Open):开发已经确认是缺陷

修复(Fixed):开发已经修复好缺陷,等待测试人员回归测试

打开(Reopen):修复完的BUG依然有问题,指定开发重新修改

关闭(Closed):通过回归测试,BUG被成功修复

拒绝(Rejected):开发认为不是缺陷,拒绝修改(可能无法重现,或步骤不明确)

延后(Delay):开发认为暂时不需要修复,或等待下个版本修复

3)缺陷标题:简洁描述缺陷的内容(总结性语言)

注意:

1标题要简短准确,提供缺陷的本质信息

2避免使用含糊不清的词语,比如功能中断、功能不正确、行为不起作用等不可以使用

4)缺陷严重等级:该缺陷对产品影响的程度

1级(Low):表面性错误,如错别字,显示格式不规范

2级(Medium):影响相对独立的功能,在特定条件下会发生,断断续续出现问题

3级(High):功能点没有实现,不符合用户需求,提交后数据丢失(大多数BUG)

4级(VeryHigh):频繁死机,系统大部分功能不可用

5级(Critical):系统瘫痪,异常退出,死循环,严重的计算错误

5)缺陷优先级:

优先级:指的是缺陷被修复的先后顺序(给开发人员的建议)

P0紧急:不能满足产品要求,核心功能明显未实现或完全不可用,阻塞测试流程与进度

P1高:产品的功能实现和需求不符合,没有达到预期的效果,但不阻塞测试进度

P2中:比较小的功能、UI或交互问题,可以绕过此类问题来进行测试

P3低:一些可修改或不可修改,或者是还不确定能否修改成功的BUG,均不影响用户体验使用

6)缺陷类型:

功能缺陷:无法实现,不符合需求(最常用)

兼容性缺陷:系统兼容、浏览器兼容、分辨率兼容(常用)

界面缺陷:删除操作未给出提示,界面不规范,文字图片位置(常用)

系统缺陷:死机、崩溃、异常退出、程序错误

数据缺陷:数据计算错误、输入输出错误

数据库缺陷:连接错误、表中有冗余、表中有过多空字段(设计)、约束错误

接口缺陷:接口返回异常,传参类型错误

安全性缺陷:超时限制(session)、访问权限、无加密

性能缺陷:未达到性能指标(并发量,负载量,压力指标)

7)缺陷重现步骤:简易描述缺陷是如何产生的

①操作步骤:用例

②预期结果:

③实际结果:

注意:步骤要完整,不要丢掉必要的操作,不要使用长句,不要拽文,应简明准确,确保缺陷可复现

注意:常见步骤合并为较少步骤(例如:双击打开文件夹:谁都知道文件夹需要双击)

8)缺陷所属模块:该BUG属于哪个功能模块

9)缺陷记录者:提交缺陷的人

10)缺陷提交时间:提交的时间点(需要知道处理时间)

11)缺陷处理人:处理缺陷的人(对接的程序员)

12)处理结果描述:对结果描述(程序员写)

13)缺陷处理时间:处理完毕的时间点

14)缺陷验证人:做回归测试的人

15)验证结果描述:回归测试通没通过

16)缺陷环境说明:在什么测试环境下出现的BUG

17)必要附件:截图、录屏(偶现Bug)

6.缺陷修改说明

说明:并不是所有的缺陷,都需要修改☆

①由于市场动态竞争,使得产品需要提前发布,没有充分的时间修复BUG(优先级)

②修改此BUG,会影响其他模块较多,会带来的风险较大,所以延迟到后续版本再修复

③修改性价比太低,也就是耗费时间长,浪费人力物力财力,效果还不明显

④缺陷难以重现,重现概率低,周期性很长

7.缺陷报告的注意事项

说明:缺陷报告是提交给开发人员用于BUG修复,如果报告含糊不清,会误导开发人员,影响缺陷修复速度,进而影响软件研发进度。同时也会影响测试人员本身的声誉,影响团队协作

注意事项:

①要保证缺陷可以重现

②文件简单明确、专业完整,确保开发迅速定位问题

③一个缺陷对应一个报告

④避免使用“似乎”、“可能”、“大概”、“差不多”等含义模糊的词语,需要写出确定的结果

⑤避免使用自己认为“很幽默”的词语,只需客观描述缺陷信息