【安卓】为什么你的单元测试IT管理总是失效
为什么你的单元测试IT管理总是失效
Vaycent发布于 今天 02:39
为什么你的单元测试IT管理总是失效
《从Kotlin双锁单例中学习到...》
《为你的Android实现测试覆盖率》
《为你的Android添加第一个单元测试》
续上之前单元测试系列，此篇将从单元测试发散开来，讨论有关于单测上IT管理的思考点，此篇会尽量少用技术语言来讲述技术问题并按以下主题叙述：
- “我们不需要单测”是一种迷思
- 你的覆盖率指标质量管理总是失效
- 单测和覆盖率该怎么用
- 质量完成与质量达成
- 从单测中帮助人持续学习
我们不需要单测”是一种迷思
相信大多数人都会或多或少碰到，甚至在说以下言论：
- “我们没有足够的成本做单元测试”
- “我们开发已经很忙没时间做单元测试”
- “我们的项目是一次性交付的，不需要反复的测试”
- “我们不需要单元测试，它没有用”
- “我们已经有自动化测试，不需要它”
那么这些团队通常是在怎么做测试的呢？通常是如下：
- 开发完成后，告诉测试人员改了什么，测试人员手工测试点点点。
- 测试人员根据需求文档出用例，开发完成后，测试人员手工测试点点点。
- 一次性开发完成，找测试人员手工测试点点点，通过完成交货。
- 采购UI自动化工具，做了一些用例，然后这些自动化测试总是跑失败，或者跟构建完版本耦合，每次都要重新录制，慢慢就没人管实际情况只管对外说我们已经实现自动化。
以上这些处理方式的假设前提到底是什么呢？
我们认为的开发和测试范围占比是左边这样，而实际上它应该是右边这样，随着开发完成的内容增多，每次测试的范围都在扩大，如果不加入自动化测试，很快就会因为交付速度过慢导致项目失控。
但是为什么所有项目都没有失控呢？
因为所有人都在假设....
假设只要有人（开发/需求）负责框出本次增量，清晰“已知影响范围“，那么根据这个范围就能准确地验证结果。然而它只是解决“已知影响范围”下的验证结果，无法针对“未知影响范围”，所以这样假设是矛盾的。
正因为人无法清晰所有“影响范围”，所以质量出现问题。
那么，一次性项目是否就没有测试必要呢？
当然也不是...
即使一次性交付项目，我们继续细化来看。程序猿们每一次点击Run按钮构建项目都是一次反馈机会，如果无法对本次Run进行测试，亦无法确保本次新增的“影响范围”，更何况是经过无数次增量和运行的项目版本交付。
（P.S.如果你非要说，我们的开发都很牛掰，只管写代码不构建，几个月之后才构建一次项目并顺利交付。好吧，那么我输了）
你的覆盖率指标质量管理总是失效
经常看到管理人员要求项目的测试覆盖率指标，作为管理项目质量的标准，那么到底需要多少的覆盖百分比，才是质量的保证呢？答案是：
作为管理指标，覆盖率没有任何作用。
作为一名程序猿追求更高的覆盖率可能是他对追求技术卓越的结果，而作为一名管理者要求覆盖率指标，那更大可能是他对团队的量化/考核/衡量。“当管理用怎样的指标来要求，就会得到怎样的结果”，而程序猿又是一群小机灵鬼，他们有一百种方法让你的指标待不下去。举两个简单例子：
例子一：增加实际无用的方法和测试以提高覆盖率
例子二：不做断言使得测试通过
单测和覆盖率该怎么用
上面举的两个小机灵鬼的例子，当然也有方法去检测，可当我们引入怀疑论之后，又应如何检测这个检测的质量呢？此时会陷入一个套娃模式。
增加一层监管，永远无法解决怀疑的问题
这样的话，单元测试和覆盖率又应怎么使用呢？
答案是：把它当成是反馈手段，而不是考核的手段。
这也是为什么管理人员把它作为考核指标就会失效，若程序猿把它当作反馈手段才能生效。程序猿可以通过这些反馈来学习和改进，从而拉升项目质量，这才是一个持续改进的过程。如上图例子我们就可以学习到：
- 黄色钻石行原来没有被测试覆盖到
- 既然没有被覆盖到的代码是否是冗余呢
- 如非冗余，那么我们就可知道不是所有覆盖率都可到100%(这里是双锁)
- 有了单测建立过滤网，我们可以安全地进行重构
- 我们更可以尝试修改它，研究单测结果仍通过的原因是什么
质量完成与质量达成
当我们看完覆盖率质量指标为何失效以及该怎么使用之后，我们补充下在上篇《为你的Android实现测试覆盖率》里提到的那个管理提覆盖率要求的可怕案例，现在该轮到更可怕的场景出场囖：
- 管理人员不知道覆盖率是个啥却提出要求，我们项目要达到70%以上代码覆盖率！
- 更可怕的是，团队最后竟然神奇地完成目标！
- 更更可怕的是，管理人员转身就对外报告，我们出色地满足标准，还有量化数据支撑，极大地拉升和保证项目质量！
最后结果如何可想而知，质量问题当然还是如约而至。既然IT技术也不只是事情而已，若我们仅盯着事情表面，而不关注人本身，这种问题就层出不穷。更重要的是，我们会总感觉到某些员工的不对劲！
- 他们为啥总有想法，不听命令
- 他们为啥总提出反对
- 他们为啥总亲力亲为不能同时处理好多件任务
- 他们为啥总承担过多责任，做事超出边界
- 他们为啥好像经常犯错
相比之下另外的员工就好得太多！他们能顺利地完成目标，报告里的他们像超人般同时负责几十个任务，更重要的是他们从来不犯错且善于发现别人的问题，这真是太棒了！
可是不知道为什么，团队里效率越来越低，质量问题频出，需要规模越来越大，却不提建议不积极，不对劲的员工慢慢都不在了。
单元测试也好，覆盖率也好，仅仅是这些状况的一种展现。这些状况一旦发生，劣币驱逐良币，就是个难以自察且不可逆转的过程，只能祝君武运昌隆了～
关注事表面，仅是实现完成
关注人本身，才能实现达成
从单测中帮助人持续学习
上述这么多，回到我们的单元测试本身上。既然知道它应该为人的持续改进而被使用，那我们就可遵循以下原则来帮助人持续学习：
- 以终为始：先知道正确验证结果长怎样，并以此为测试目标
- 确认边界：知道结果的边界在哪里，如><=+-！这种符号边界
- 代码变异：通过变异测试修改代码，将变异杀死，体现测试质量
- 频繁验证：每次变动/每日去重新验证，尽快发现问题
（不要问我为什么这节这么短，想偷懒而已，以后补充）(坏笑...)
作者联系方式：
iosandroid测试
阅读 9更新于 55 分钟前
本作品系原创，采用《署名-非商业性使用-禁止演绎 4.0 国际》许可协议
Vaycent
1 声望
0 粉丝
Vaycent
1 声望
0 粉丝
宣传栏
为什么你的单元测试IT管理总是失效
《从Kotlin双锁单例中学习到...》
《为你的Android实现测试覆盖率》
《为你的Android添加第一个单元测试》
续上之前单元测试系列，此篇将从单元测试发散开来，讨论有关于单测上IT管理的思考点，此篇会尽量少用技术语言来讲述技术问题并按以下主题叙述：
- “我们不需要单测”是一种迷思
- 你的覆盖率指标质量管理总是失效
- 单测和覆盖率该怎么用
- 质量完成与质量达成
- 从单测中帮助人持续学习
我们不需要单测”是一种迷思
相信大多数人都会或多或少碰到，甚至在说以下言论：
- “我们没有足够的成本做单元测试”
- “我们开发已经很忙没时间做单元测试”
- “我们的项目是一次性交付的，不需要反复的测试”
- “我们不需要单元测试，它没有用”
- “我们已经有自动化测试，不需要它”
那么这些团队通常是在怎么做测试的呢？通常是如下：
- 开发完成后，告诉测试人员改了什么，测试人员手工测试点点点。
- 测试人员根据需求文档出用例，开发完成后，测试人员手工测试点点点。
- 一次性开发完成，找测试人员手工测试点点点，通过完成交货。
- 采购UI自动化工具，做了一些用例，然后这些自动化测试总是跑失败，或者跟构建完版本耦合，每次都要重新录制，慢慢就没人管实际情况只管对外说我们已经实现自动化。
以上这些处理方式的假设前提到底是什么呢？
我们认为的开发和测试范围占比是左边这样，而实际上它应该是右边这样，随着开发完成的内容增多，每次测试的范围都在扩大，如果不加入自动化测试，很快就会因为交付速度过慢导致项目失控。
但是为什么所有项目都没有失控呢？
因为所有人都在假设....
假设只要有人（开发/需求）负责框出本次增量，清晰“已知影响范围“，那么根据这个范围就能准确地验证结果。然而它只是解决“已知影响范围”下的验证结果，无法针对“未知影响范围”，所以这样假设是矛盾的。
正因为人无法清晰所有“影响范围”，所以质量出现问题。
那么，一次性项目是否就没有测试必要呢？
当然也不是...
即使一次性交付项目，我们继续细化来看。程序猿们每一次点击Run按钮构建项目都是一次反馈机会，如果无法对本次Run进行测试，亦无法确保本次新增的“影响范围”，更何况是经过无数次增量和运行的项目版本交付。
（P.S.如果你非要说，我们的开发都很牛掰，只管写代码不构建，几个月之后才构建一次项目并顺利交付。好吧，那么我输了）
你的覆盖率指标质量管理总是失效
经常看到管理人员要求项目的测试覆盖率指标，作为管理项目质量的标准，那么到底需要多少的覆盖百分比，才是质量的保证呢？答案是：
作为管理指标，覆盖率没有任何作用。
作为一名程序猿追求更高的覆盖率可能是他对追求技术卓越的结果，而作为一名管理者要求覆盖率指标，那更大可能是他对团队的量化/考核/衡量。“当管理用怎样的指标来要求，就会得到怎样的结果”，而程序猿又是一群小机灵鬼，他们有一百种方法让你的指标待不下去。举两个简单例子：
例子一：增加实际无用的方法和测试以提高覆盖率
例子二：不做断言使得测试通过
单测和覆盖率该怎么用
上面举的两个小机灵鬼的例子，当然也有方法去检测，可当我们引入怀疑论之后，又应如何检测这个检测的质量呢？此时会陷入一个套娃模式。
增加一层监管，永远无法解决怀疑的问题
这样的话，单元测试和覆盖率又应怎么使用呢？
答案是：把它当成是反馈手段，而不是考核的手段。
这也是为什么管理人员把它作为考核指标就会失效，若程序猿把它当作反馈手段才能生效。程序猿可以通过这些反馈来学习和改进，从而拉升项目质量，这才是一个持续改进的过程。如上图例子我们就可以学习到：
- 黄色钻石行原来没有被测试覆盖到
- 既然没有被覆盖到的代码是否是冗余呢
- 如非冗余，那么我们就可知道不是所有覆盖率都可到100%(这里是双锁)
- 有了单测建立过滤网，我们可以安全地进行重构
- 我们更可以尝试修改它，研究单测结果仍通过的原因是什么
质量完成与质量达成
当我们看完覆盖率质量指标为何失效以及该怎么使用之后，我们补充下在上篇《为你的Android实现测试覆盖率》里提到的那个管理提覆盖率要求的可怕案例，现在该轮到更可怕的场景出场囖：
- 管理人员不知道覆盖率是个啥却提出要求，我们项目要达到70%以上代码覆盖率！
- 更可怕的是，团队最后竟然神奇地完成目标！
- 更更可怕的是，管理人员转身就对外报告，我们出色地满足标准，还有量化数据支撑，极大地拉升和保证项目质量！
最后结果如何可想而知，质量问题当然还是如约而至。既然IT技术也不只是事情而已，若我们仅盯着事情表面，而不关注人本身，这种问题就层出不穷。更重要的是，我们会总感觉到某些员工的不对劲！
- 他们为啥总有想法，不听命令
- 他们为啥总提出反对
- 他们为啥总亲力亲为不能同时处理好多件任务
- 他们为啥总承担过多责任，做事超出边界
- 他们为啥好像经常犯错
相比之下另外的员工就好得太多！他们能顺利地完成目标，报告里的他们像超人般同时负责几十个任务，更重要的是他们从来不犯错且善于发现别人的问题，这真是太棒了！
可是不知道为什么，团队里效率越来越低，质量问题频出，需要规模越来越大，却不提建议不积极，不对劲的员工慢慢都不在了。
单元测试也好，覆盖率也好，仅仅是这些状况的一种展现。这些状况一旦发生，劣币驱逐良币，就是个难以自察且不可逆转的过程，只能祝君武运昌隆了～
关注事表面，仅是实现完成
关注人本身，才能实现达成
从单测中帮助人持续学习
上述这么多，回到我们的单元测试本身上。既然知道它应该为人的持续改进而被使用，那我们就可遵循以下原则来帮助人持续学习：
- 以终为始：先知道正确验证结果长怎样，并以此为测试目标
- 确认边界：知道结果的边界在哪里，如><=+-！这种符号边界
- 代码变异：通过变异测试修改代码，将变异杀死，体现测试质量
- 频繁验证：每次变动/每日去重新验证，尽快发现问题
（不要问我为什么这节这么短，想偷懒而已，以后补充）(坏笑...)
作者联系方式：
以上是 【安卓】为什么你的单元测试IT管理总是失效 的全部内容， 来源链接： utcz.com/a/109477.html
得票时间