缺陷不可重现的情况有很多种，按照我个人的工作经验和理解可以分为一下几类。

　　1. 自动化工具执行回归测试发现缺陷，之后单跑一个测试用例不会无法重现

　　2. 自动化工具执行测试用例发现缺陷，之后手动无法重现问题

　　3. 手动执行测试用例发现缺陷，之后无法重现

　　4. Free Testing发现缺陷，之后无法重现

　　5. QA的环境发现BUG，DEV无法重现

　　对于第一类情况：

　　我会先把这单个测试用例用自动化工具跑上3-5遍，这样能够帮助我基本确定这个缺陷是随机发生的还是（暂时）不能重现。

　　对于前者，我会它当作一个正常的缺陷来处理。

　　对于后者（暂时不能重现的），我会用自动化工具把这个测试用例以及其前几个相关的测试用例一起重新跑一遍，这样我也许能够找到这些测试用例间隐藏的关联性而造成的缺陷.

　　如果这样还不能够重现的话就比较麻烦了，按照项目的进度，我会选择先把它放在一边或者做以下尝试和分析

　　a. 分析自动化工具运行时生成的log文件（可能第一次脚本在运行时进入了一个奇怪的分支）

　　b. 把回归测试从头到底再跑一次（工作中确实还碰到一次只有从头运行回归测试才能重现的情况）

　　c. 搭建全新环境，用自动化工具执行测试用例（有些缺陷只有在第一次才会发生）

　　d. 自动化工具与被测软件之间有冲突（可能性相当之小...）

　　本文出自51Testing软件测试网，感谢会员wangjingying在每周一问（09-03-16）中的精彩回答。http://bbs.51testing.com/forum-157-1.html

　　对于第二种情况：

　　我会先降低自动化工具执行测试用例时的速率或修改一些相关参数（毕竟人点的速度赶不上自动化工具吗）。如果没有进展，我会通过分析自动化工具运行时生成的脚本，或者肉眼看自动化工具执行用例的过程来检查自动化过程与手动测试用例有无区别。如果仍没有收获，我可能会做以下尝试

　　a. 找出一些能够获取或者阅读dump file的工具，从接近DEV的角度尝试去分析自动测试与手动测试的不同之处

　　b. 自动化工具与被测试软件之间有冲突（我永远相信自动化工具是有问题的....^_^）

　　对于第三类情况：

　　一定要严格执行测试用例！！！否则还不如去做free testing！！！

　　回忆一下发现缺陷时与无法重现时在操作上有啥区别。如果没有的话，那么继续严格执行测试用例多次，以防缺陷为随机发生。若还没有进展，把情况如实记录下来，以备日后分析用

　　对于第四类情况：

　　这就比较复杂了，也许是重现步骤不对，也许是随机缺陷的原因，个人想不出太好的办法.....不过对于经常能够在free testing当中发现问题但无法重现的人，可以考虑在做free testing的时候用录像工具进行记录！！！

　　对于第五类情况：

　　俺熟悉的DEV，基本都是神一般的人。他们的桌面上总是放满了

　　形形色色的工具图标，任务栏上永远是20+个对话框.......所以俺心中对于DEV的DEBUG环境总是怀着一个大大的问号与感叹号.....

　　如果DEV不能重现问题，我一般会做下面这些事情

　　a. 确认DEV重现步骤是否正确（DEV好像经常会弄错步骤的说-_-|||）

　　b. 如果步骤正确，查看软件版本号（DEV好像比较喜欢用最新codeline进行DEBUG）并请DEV使用与QA相同的版本进行DEBUG。如果这个缺陷在老版本中能重现在新版本中不能，那么需要DEV分析这一段时间内codeline里面的changelist，把可能与此缺陷相关修改及信息记录在缺陷管理工具中。

　　c. 如果DEV使用QA测试的版本还不能重现，那么查看DEV用的是DEBUG build还是RELEASE build并请DEV使用后者重现缺陷。

　　d. 如果还不行，我会考虑新建一个标准测试环境来为DEV重现缺陷，或者直接让DEV在测试机上重现缺陷跟踪及定位。

　　个人看法，轻拍……

本文出自51Testing软件测试网，感谢会员wangjingying在每周一问（09-03-16）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

版权声明：51Testing软件测试网原创作品，转载请保留链接，标明本文原始出处、作者信息和本声明，否则将追究法律责任。