BUG贯穿研发体系、测试质量衡定的始终,做好BUG回归,即能保证质量,又能提高个人测试能力。做好BUG回归,能够很大程度的避免漏测。
BUG的处理流程
回归BUG的思路
从回归BUG的思路来看,首先验证原BUG现象是否仍然复现。然后需要进行BUG扩展回归,主要从哪几方面扩展呢?
首先是开发原理。
根据开发原理评估问题的原因、改动的方法、以及可能产生的影响。
然后BUG扩展。
针对BUG本身的扩展,建议从BUG描述进行断句,分析每个涉及到的模块,是否有扩展测试的必要。
另外是一些常规的扩展测试比如:
- 是否需要覆盖多个平台?
- 是否需要覆盖手机和平板?
- 是否需要考虑横竖屏?
- 是否要考虑分辨率?
- 是否要考虑多语言?
举几个之前回归过bug作为示例:
BUG1:文件列表中文件的创建日期显示不正确,应该显示今天、昨天、两天前的需要显示具体日期。
回归方法:
首先确保显示上没问题,无文案错误。
从开发原理上讲,要考虑:
1、今天、昨天和三天前是以什么时间为节点判断。以当前系统时间24个小时往前推算,还是服务器时间以0点为准?
2、显示具体日期时,日期的格式具体是怎样的,是否显示年月日?年月日的顺序是怎样的?中间是用-隔开,还是\隔开呢?
3、是否存在中文和英文的差异,甚至是多语言?因为不同语言表达日期的惯用格式是不一样的。
3、文件的日期是怎么获取来的?如果是服务端,那万一服务端返回回来为空或者异常,列表会怎么显示?
4、假设修改手机系统的日期了 ,今天、昨天、三天前是否会改变?
针对BUG本身的扩展:
1、文件列表:文件列表是否存在多个地方?改动是一处,还是多处?是否存在其他的列表也显示日期的?
2、创建日期:创建日期和修改日期是有差别的,是否显示的和需求相符是创建日期,而非修改日期。
其他常规的扩展:
1、因为涉及到Android和iOS两个平台,因此需要覆盖两个平台测试。
2、仅支持手机,因此仅测试手机即可。
3、不支持横竖屏,因此不必扩展。
4、低分辨率或者大字体下有没有可能超出一行,超出一行时如何处理,显示是否美观。
5、存在英文,英文的习惯是年份在后面,是否有符合英文的阅读习惯?
当然,涉及到需求不明确的时候,预期结果要以需求为准。
BUG2:文件名称过长换行时,发现右侧的编辑按钮换行且和第二行标题重叠了。
从开发原理上讲,还要考虑:
1、为何之前会换行,是因为之前没对文案的长度做限制。那么修改后是以字符数作为限制,还是以相对布局的宽度来做长度限制的?
2、右侧编辑按钮为什么会换行?因为原来标题和编辑按钮是相对布局,相对于标题的右侧进行显示。需要修改为线性布局,固定在右侧给编辑按钮一个位置。
3、超出一行的内容如何显示,省略号还是其他?
针对BUG本身的扩展:
1、文件名称:中文、英文、标题、符号是否都能正常换行显示?换行的效果看起来都是美观的?英文单词中间是否会出现换行?
2、改动布局之后的编辑按钮位置是否明显,点击触控区域是否合理?
如何提高回归bug的准确性?
- 测试用例设计和评审阶段,输出一份完整明确的案例。
- 案例设计的越完整,回归BUG时可参考的案例越明确。
- Bug提交阶段,给出明确的描述和步骤
一方面开发重现问题时可以参考,快速分析。另一方面,大幅度提高他人熟悉和回归的效率。尤其在提交BUG时附上的截图和日志,是非常有价值的。
- Bug修复阶段,开发和测试要积极沟通修复方案。
一般来说,会要求在缺陷管理平台上开发处理bug时提交修改说明,第二,在测试回归前积极跟开发沟通问题原因、修复的方案和影响。
- BUG关闭阶段,积极完善测试案例。