1、回忆操作步骤、尝试重现
-
尽量回忆当时的操作步骤,并且最大可能的复原当时的操作环境。
-
确认当时的操作步骤是否有误。如果确认无误,可以多次尝试重现;
-
即使发现有操作错误的情况,也不要认为没问题了,要思量为什么会操作错误是否用户也会有这种操作?然后和产品讨论自己的想法,很可能这是用户体验上的问题。
-
可以把整个操作流程进行分解,逐个步骤进行考虑影响因素,然后进行验证
-
视测试时间、严重程度、重要程度而定,要花多久进行重现,既不能一两次就草草了事,也不能无休止的在这一个问题上无限制消耗时间
-
如果是崩溃问题,一定要尽可能的抓取log并分析原因,然后提供给开发
2、提交bug与开发沟通
-
即使不能重现,也一定要提交bug备忘:
1)有的测试人员经常会因为不能重现,就不提交或忽略提交了,这是错误的
2)用户那边可能会出现,至少我们测试出现过,所以出于测试责任考虑,也要提交;
3)当前不能重现,不代表以后不能重现,既然出现问题了,那肯定是有问题,只不过当前无法解释而已。
4)要把当时出现问题时的环境、步骤,尽可能的在bug上写全,并且附上自己的分析和看法,哪怕是猜测也行,以便后续尝试重现
-
开发对自己的程序了解深刻,看到bug后,有可能很容易就能知道问题所在立马就能修改,或者根据现象给测试人员重现上的提示
-
对于这类bug,有些开发可能不太乐意让提交,因为没有重现步骤没法改,所以一定要和开发明确说明,这首先是备忘一下,后续可能会重现或想到修改方法;就算最后一直无法解决,也可以置为不可重现关闭。(在搜狗项目中,开发的bug数是不计入绩效统计的,所以开bug对于开发没有什么阻力)
-
切忌测试人员把单次发现的bug直接给开发,而不进行多次验证、尝试重现,因为这是不专业的表现,发现问题、多次多角度尝试重现、帮助分析问题原因都是测试人员应该做的。
-
虽然重现bug是测试的职责,但初步定位bug也是测试人员需要提高的能力,因为这样可以和开发一起找原因,提高开发对你能力的认可。但一定要注意,测试人员认为的原因,需要用一种建议的形式和开发沟通,否则会让开发认为你太自负,并且一旦你说的原因是错的,更会被认为是自不量力。
-
如果直到最后上线前都没有重现,那么就要把这个问题计入上线风险。
3、后续回归测试时着重关注
-
一轮测试时发现的不可重现问题,在后续回归测试或随机测试时,可以把这类问题重新拿出来分析并尝试重现(所以当即提交bug并详细说明步骤与分析内容的重要性就体现出来了,如果没有这些内容,后续想尝试复现难度都很大)。
-
重现问题时,不要仅局限在当前的环境下,换换思路、逆向思维、多发散、甚至带点创造性的做法往往会有较大的惊喜。
-
一旦再次重现,一定要保留现场,叫开发人员一起查看
-
如果发现了必现步骤,那么就要好好进行分析,为什么测试用例没有覆盖或者常规测试没有发现,及时总结。