为什么你的单元测试IT管理总是失效

为什么你的单元测试IT管理总是失效

《从Kotlin双锁单例中学习到...》

《为你的Android实现测试覆盖率》

《为你的Android添加第一个单元测试》

​ 续上之前单元测试系列，此篇将从单元测试发散开来，讨论有关于单测上IT管理的思考点，此篇会尽量少用技术语言来讲述技术问题并按以下主题叙述：

• “我们不需要单测”是一种迷思
• 你的覆盖率指标质量管理总是失效
• 单测和覆盖率该怎么用
• 质量完成与质量达成
• 从单测中帮助人持续学习

我们不需要单测”是一种迷思

相信大多数人都会或多或少碰到，甚至在说以下言论：

• “我们没有足够的成本做单元测试”
• “我们开发已经很忙没时间做单元测试”
• “我们的项目是一次性交付的，不需要反复的测试”
• “我们不需要单元测试，它没有用”
• “我们已经有自动化测试，不需要它”

那么这些团队通常是在怎么做测试的呢？通常是如下：

• 开发完成后，告诉测试人员改了什么，测试人员手工测试点点点。
• 测试人员根据需求文档出用例，开发完成后，测试人员手工测试点点点。
• 一次性开发完成，找测试人员手工测试点点点，通过完成交货。
• 采购UI自动化工具，做了一些用例，然后这些自动化测试总是跑失败，或者跟构建完版本耦合，每次都要重新录制，慢慢就没人管实际情况只管对外说我们已经实现自动化。

以上这些处理方式的假设前提到底是什么呢？

​ 我们认为的开发和测试范围占比是左边这样，而实际上它应该是右边这样，随着开发完成的内容增多，每次测试的范围都在扩大，如果不加入自动化测试，很快就会因为交付速度过慢导致项目失控。

​ 但是为什么所有项目都没有失控呢？

​ 因为所有人都在假设....

​ 假设只要有人（开发/需求）负责框出本次增量，清晰“已知影响范围“，那么根据这个范围就能准确地验证结果。然而它只是解决“已知影响范围”下的验证结果，无法针对“未知影响范围”，所以这样假设是矛盾的。

​ 正因为人无法清晰所有“影响范围”，所以质量出现问题。

​ 那么，一次性项目是否就没有测试必要呢？

​ 当然也不是...

​ 即使一次性交付项目，我们继续细化来看。程序猿们每一次点击Run按钮构建项目都是一次反馈机会，如果无法对本次Run进行测试，亦无法确保本次新增的“影响范围”，更何况是经过无数次增量和运行的项目版本交付。

​ （P.S.如果你非要说，我们的开发都很牛掰，只管写代码不构建，几个月之后才构建一次项目并顺利交付。好吧，那么我输了）

你的覆盖率指标质量管理总是失效

​ 经常看到管理人员要求项目的测试覆盖率指标，作为管理项目质量的标准，那么到底需要多少的覆盖百分比，才是质量的保证呢？答案是：

​ 作为管理指标，覆盖率没有任何作用。

​ 作为一名程序猿追求更高的覆盖率可能是他对追求技术卓越的结果，而作为一名管理者要求覆盖率指标，那更大可能是他对团队的量化/考核/衡量。“当管理用怎样的指标来要求，就会得到怎样的结果”，而程序猿又是一群小机灵鬼，他们有一百种方法让你的指标待不下去。举两个简单例子：

例子一：增加实际无用的方法和测试以提高覆盖率

例子二：不做断言使得测试通过

单测和覆盖率该怎么用

​ 上面举的两个小机灵鬼的例子，当然也有方法去检测，可当我们引入怀疑论之后，又应如何检测这个检测的质量呢？此时会陷入一个套娃模式。

​ 增加一层监管，永远无法解决怀疑的问题

​ 这样的话，单元测试和覆盖率又应怎么使用呢？

​ 答案是：把它当成是反馈手段，而不是考核的手段。

​ 这也是为什么管理人员把它作为考核指标就会失效，若程序猿把它当作反馈手段才能生效。程序猿可以通过这些反馈来学习和改进，从而拉升项目质量，这才是一个持续改进的过程。如上图例子我们就可以学习到：

• 黄色钻石行原来没有被测试覆盖到
• 既然没有被覆盖到的代码是否是冗余呢
• 如非冗余，那么我们就可知道不是所有覆盖率都可到100%(这里是双锁)
• 有了单测建立过滤网，我们可以安全地进行重构
• 我们更可以尝试修改它，研究单测结果仍通过的原因是什么

质量完成与质量达成

​ 当我们看完覆盖率质量指标为何失效以及该怎么使用之后，我们补充下在上篇《为你的Android实现测试覆盖率》里提到的那个管理提覆盖率要求的可怕案例，现在该轮到更可怕的场景出场囖：

• 管理人员不知道覆盖率是个啥却提出要求，我们项目要达到70%以上代码覆盖率！
• 更可怕的是，团队最后竟然神奇地完成目标！
• 更更可怕的是，管理人员转身就对外报告，我们出色地满足标准，还有量化数据支撑，极大地拉升和保证项目质量！

​ 最后结果如何可想而知，质量问题当然还是如约而至。既然IT技术也不只是事情而已，若我们仅盯着事情表面，而不关注人本身，这种问题就层出不穷。更重要的是，我们会总感觉到某些员工的不对劲！

• 他们为啥总有想法，不听命令
• 他们为啥总提出反对
• 他们为啥总亲力亲为不能同时处理好多件任务
• 他们为啥总承担过多责任，做事超出边界
• 他们为啥好像经常犯错

​ 相比之下另外的员工就好得太多！他们能顺利地完成目标，报告里的他们像超人般同时负责几十个任务，更重要的是他们从来不犯错且善于发现别人的问题，这真是太棒了！

​ 可是不知道为什么，团队里效率越来越低，质量问题频出，需要规模越来越大，却不提建议不积极，不对劲的员工慢慢都不在了。

​ 单元测试也好，覆盖率也好，仅仅是这些状况的一种展现。这些状况一旦发生，劣币驱逐良币，就是个难以自察且不可逆转的过程，只能祝君武运昌隆了～

​ 关注事表面，仅是实现完成

​ 关注人本身，才能实现达成

从单测中帮助人持续学习

​ 上述这么多，回到我们的单元测试本身上。既然知道它应该为人的持续改进而被使用，那我们就可遵循以下原则来帮助人持续学习：

• 以终为始：先知道正确验证结果长怎样，并以此为测试目标
• 确认边界：知道结果的边界在哪里，如><=+-！这种符号边界
• 代码变异：通过变异测试修改代码，将变异杀死，体现测试质量
• 频繁验证：每次变动/每日去重新验证，尽快发现问题

（不要问我为什么这节这么短，想偷懒而已，以后补充）(坏笑...)

---

作者联系方式：