【软件测试】测试人的懊恼，你要揭开的秘密复现bug......

---

前言

我们测试人常常会懊恼
你是否在为忘记前面怎么执行测试而出现bug苦苦冥思，因为现在你需要说明怎么复现它？
你是否在为开发人员不能根据你提交的bug描述而复现问题无奈？
你是否在开发人员的机器上不能复现bug而百思不得其解？

你是否在为忘记前面怎么执行测试而出现bug苦苦冥思，因为现在你需要说明怎么复现它？

碰到这样的情况，往往是缺乏对应的测试用例，且执行流程过于复杂导致的。而往往出现在探索性测试阶段，因为我们可能灵机一动就会想到一个可能会出现bug的测试场景。

如果经验不足的测试人员，可能会立即去执行自己的假设，但如果这个场景过于复杂，在执行过程中出现bug后，会突然蒙掉（如果一直专心做这件事还好，但往往中间可能会穿插着其它一些事情），忘记了前面的执行步骤。

我带过很多测试新人，普遍都存在这样的问题。这时我会告诫他们，以后再想到一个新的测试场景，或者在没有用例的情况下执行复杂的流程前，都应该用笔在纸上简单作下步骤描述。

这样避免了因为种种原因遗忘既定的测试流程，在出现bug时无法复现。而往往他们都采纳了我的建议，并在后面的测试中避免了这种情况。

你是否在为开发人员不能根据你提交的bug描述而复现问题无奈？

这也是我经常听到测试人员抱怨的，当然开发人员也在抱怨测试人员提交的bug不足复现bug。这种情况，往往由测试人员的bug描述的不够简洁、详尽；当然也可能有其它的原因…

针对这种情况，描述不够简洁、详尽。可能原因是测试人员口水话过多，但并没有把bug复现的信息表述清楚。描述一个bug，不一定需要让我们严格的把所有的执行步骤，测试结果，期望结果都按教科书经典案例一般详细的描述出来。反而这样做的话，在时间较紧的情况下会导致我们测试执行效率较低。

不管如何，一定要保证你的bug描述简洁明了，这里有几个妙招：

1.在bug摘要最前面，标明测试的功能点。这样会让开发人员快速知道是哪里出现了问题。
2.bug摘要应该简洁明了，并突出重点，即能让开发人员从摘要中就能大致了解怎么出现的这个bug。比如，【注册】输入5位长度密码也成功注册；密码长度应在6~15个字符之间
3.在bug描述中，应该标明测试环境，出现bug模块路径，测试数据，以及浏览器等信息。我们知道浏览器的兼容性，android和ios等手机系统的差异，都可能导致测试的结果完全不同。
4.复杂的测试，应该简单明了的说明bug出现的步骤。如，复现bug步骤：1、执行……；2，执行……
5.附上bug的重要截图。千言万语，抵不过一张截图；有图有真相。

你是否在开发人员的机器上不能复现bug而百思不得其解？

这样的问题也是测试人员容易碰到的。出现这种情况，往往存在如下几个原因：

1.开发人员复现bug，可能只是在自己的工作环境上。环境不一样，可能就会导致执行结果不一样。比如发布的测试版，打的包并不完整。或者开发人员并没有在发版之前把所做的修改全部提交到版本库等。

所以我们应该明确告诉开发人员，复现bug一定要去测试环境复现，确认问题后再到个人工作环境上对问题进行原因分析并修复。

2.版本管理混乱，开发人员随时修改测试环境，或者干脆测试环境和开发环境没有做区分。

测试环境和开发环境一定要分开，并且做好测试环境版本发布管理。否则开发人员为了避免一些责任，比如bug关乎于绩效考核，那么就可能在发布测试版本后发现bug而偷偷的去测试环境做更改。这样后面自然复现不了bug，反而指责测试人员不够仔细。

3.复现的环境情况不完全相同导致。

可能看起来复现的环境都是一样，但实际情况是这样吗？
比如复现一个WEB应用界面上的bug，可能看起来复现的环境都是一样的（比如都使用的chrome浏览器），但在自己和开发人员的环境并不一样。

这样的情况往往是因为一些配置，所使用的浏览器版本等因素不一致导致的。这时可以把开发人员拉倒你的面前一起复现bug，分析原因。

下面是我整理的2022年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

既异想天开，又实事求是，这是科学工作者特有的风格，让咱们在无穷的宇宙长河中探求无穷的真理吧。

以前以为坚持就是永不动摇，现在才明白坚持是犹豫着，退缩着，心猿意马着，但还在继续往前走。

伟人所达到并保持着的高处，并不是一飞就到的，而是他们在同伴们都睡着的时候，一步步艰辛地向上攀爬的。