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

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

Vaycent发布于 今天 02:39

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​ 当然也不是...

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

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

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

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

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

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

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

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

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

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

单测和覆盖率该怎么用

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

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

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

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

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

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

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

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

质量完成与质量达成

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

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

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

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

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

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

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

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

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

从单测中帮助人持续学习

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

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

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


作者联系方式:

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

iosandroid测试

阅读 9更新于 55 分钟前

本作品系原创,采用《署名-非商业性使用-禁止演绎 4.0 国际》许可协议

avatar

Vaycent

1 声望

0 粉丝

0 条评论

得票时间

avatar

Vaycent

1 声望

0 粉丝

宣传栏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​ 当然也不是...

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

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

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

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

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

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

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

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

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

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

单测和覆盖率该怎么用

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

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

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

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

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

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

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

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

质量完成与质量达成

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

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

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

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

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

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

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

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

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

从单测中帮助人持续学习

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

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

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


作者联系方式:

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

以上是 【安卓】为什么你的单元测试IT管理总是失效 的全部内容, 来源链接: utcz.com/a/109477.html

回到顶部