软件测试中7个令人匪夷所思的真理

这是最近看到的一篇比较有意思的文章，原文在这里：https://medium.com/geekculture/seven-unspoken-truths-about-software-tests-4bcf0f720a04，简单的加工翻译了一下，其中（）里的内容是我为了帮助大家理解夹带的私货，希望这篇文章会对大家有所启示。

 

1，当你是一个项目的的测试负责人的时候，你有没有过质问过项目成员为什么没测试出某个具体的bug，或者因为某人没有测出bug而直接责备他？

2，当你提升了测试覆盖率的时候你有没有发现产品的bug数量其实没有发生变化？

3，你有没有在发布之前花费了大量的时间去进行测试却最终发现一无所获，而发布之后bug却不期而至？

4，开发可以测试他们自己的代码吗？

5，bug真的是发现的越晚修复成本就越高吗？

6，你有没有过以不按套路出牌的方式来进行软件的测试，并称之为“探索性测试”？

7，你是否需要通过QA活动来提升产品质量？

真相1：测试并不能找出所有的bug

 

很不幸这是真的，没有任何一种测试方式可以保证找出所有的bug。

一些测试活动跟直接上手点点点相比确实效率要低一些，所以我们可以不用那么关注测试的类型，相反我们要做的是选择合适的测试类型并综合使用，从而以最少的工作量打到较好的效果。（比如ui的自动化测试如果要做到非常复杂那么将花费相当大的开发和维护成本，但没有ui的自动化，每轮测试都靠人肉点来点去也不现实，所以比较合适的做法是一些稳定的核心路径可以用ui自动化去实现，平衡投入产出比，用较少的工作量达到效率最大化）

当有人抱怨为什么测试没有发现某些问题的时候麻烦提醒他们：测试确实没有办法保证一定会发现某些特定的缺陷。

我们会经常复盘测试的漏测情况，很不幸，这是落后的想法，这就像是在魔术揭秘了之后再马后炮的说其实这个戏法很简单，很容易被识破一样。事后做漏测复盘并不是一个有效的分析手段。

永远不要责备测试工程师，他们并没有写出bug，相反，他们一直在努力找出开发过程中引入的缺陷。没有什么是完美的，测试同学在接受现实的同时也需要记住千万别立flag，因为测试不可能发现所有的bug。

真相2：测试覆盖率与测试的效果几乎没有相关性

 

是的，你没有看错。我们已经有足够的科学证据表明，增加单元测试覆盖率不一定会提高我们测试套件发现bug的效率！也许是时候关注与测试相关的内容而不是正在测试的代码量了。（这里作者的原话是We already have enough scientific evidence to say that increasing unit test coverage may not necessar