一个白盒测试菜鸟的心路历程

tg50

转发一个做了半年单元测试的同学分享的文章，虽然刚入行不久，但自称菜鸟也是过谦了。他还有另外一个分享是为了解决白盒测试找全代码路径麻烦的问题，创造性的应用搜索算法找全代码路径，如果大家感兴趣的话我也转过来~

（以下为分享正文）

人呐就都不知道，自己不可以预料。一个人的命运啊，当然要靠自己奋斗，但是也要考虑到历史的行程。我绝对不知道，我作为一个普通挨踢民工，怎么就上公众号发文章了呢。所以组委会负责的同学同我说“组委会都决定了，今天就你来发文章”，后来我念了两句诗，叫“苟利搜狗生死以，岂因祸福避趋之。” 所以今天我就发篇文章讲讲最近做白盒测试感受。

---

问题一：辛辛苦苦做完一个模块的单元测试没发现Bug，失落怎么破？

由于我们做单元测试的模块往往都是已经成熟稳定的模块，雷区之前黑盒测试同学已经帮我们踩的差不多了，所以才会出现上述情况。不过我们要认清单元测试的目的以及价值就不会有这么不成熟的想法了。

首先，单元测试的目的是什么？
找Bug？No，黑盒测试找Bug的效率比你要高得多。
那是什么？目前我们达成一致的观点是——保证模块的正确性。
相信大家更愿意听到你说这个模块我已经用单元测试保证过了没问题，而不是我在这个模块又发现了哪几个Bug。
当然，也不是说不用去找Bug了，只不过寻找Bug是我们用来保证这个模块正确性的一个方法而已，确定bug都踩完了，这个模块也就没问题了。

然后，都这么说了，那单元测试的价值在哪？
这个相信不论是黑盒还是白盒同学都应该能体会到，单元测试我们可以天天回归，而且不费人力物力，这点对于需要长期维护并且迭代更新的模块来说简直就是福音。所以说，单元测试的主要价值就在于便于回归，减少上层测试的工作量。

问题二：跟着项目走的白盒测试需要做怎么做？

有个现象，代码提测了，黑盒与白盒同时加入进行测试，最后往往大部分bug都是黑盒先发现的。

这也是很正常的，因为白盒测试本来需要花费的时间就多，那在项目中需要白盒测试怎么去发挥自己的作用呢？

其一就是我们可以提前介入，在开发写好一个接口时，我们就可以先直接去测这个接口；
其二就是做代码的静态检查，这个有好多辅助工具，做起来也简单，同时往往能够发现一些开发代码不规范的地方，而且这些在黑盒层次一般是很难发现的；
其三就是单元测试，这个主要用于后期回归，对于不需要长期维护或者不稳定的模块不建议做。

问题三：遇到和外界环境关系紧密的模块怎么去测？

我的答案是：不测。
因为你想在单元测试中模拟各个环境代价太大，个人认为不值得。
但不测并不代表不作为，我们可以把这个模块的功能写到一个小工具里，然后我们测试同学就可以拿着这个工具到各个环境下去看看结果。

---

以上仅是个人经验，有什么不对的地方，欢迎批评指正！

（正文完）

放任无奈

不错，就是太短了，意犹未尽的感觉

957924462

感觉写得蛮好的