回归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关闭阶段，积极完善测试案例。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
