一、前言
本系列文章主要的目的是提高大家对代码的单测意识, 其中文章主要会分享单测过程中,常见的测试场景及这些场景的解决方案和处理思路。 为了能使大家更好地了解单元测试,作为程序员会从源码入手,分享JUnit的运行原理。在了解了JUnit的原理后, 再回顾我们的问题场景,那由于内容较多,小编会分篇进行分享,文章脉络大纲已列出如上图所示。各位客官请自行取用。
二、单测的意义
很多人说单测没有意义, 这是完全不正确的思想。相信随着码龄增加你会越发的认同这句话。据国外研究统计软件系统中最大的成本是 维护成本,所以你能看到凡是开源的框架单测一定是非常丰富的,因为它要去迭代升级,要去向下兼容版本。如果没有单测那就是完全的黑盒。 是好是坏听从天意,这是没有质量保证的。这点是软件系统都具有的所以说就这一点,就证明了单测的必须性。下面谈几个不写单元测试的说法。
2.1 压缩开发时间,任务延期
或许说中国的国情跟国外的不一样,中国的系统或者说是业务系统更新的快,单测用完就失效。写单测会压缩开发时间,导致任务延期。从眼下看是压缩了开发的时间,但是它提高了开发的质量,一定程度上减少了系统的维护成本。其次单测并不是说要对你所有的方法进行测试, 这个要针对业务系统情况,把系统的核心业务中使用到的核心方法进行详细的单测维护即可。系统的核心逻辑是不会经常变动的, 所以这部分的单测就是你整个单测的核心。
2.2 公司性质
像一般政府的项目基本都会给到外部的公司来竞争,部分的外包公司只注重交付,不注重质量。或者说这个项目就是一个xx工程, 没有实用价值。 只要上线就行。也不用维护。对于这种的确实现状是都不会写单元测试。(因为整个项目就是没有任何实用价值)
2.3 别人都不写,我为啥要写
代码是有温度的,养成好的习惯从自己做起。好习惯会传染,需要一个好的带头人。团队内部成员每个人都有自己负责的功能区域。 只要每个人针对自己的功能区域的核心计算逻辑写好单测,那么一定是好处大于坏处的。另外要写在平时,不要专门找时间来写代码。那样就容易把单测当做是任务去完成,就失去了写单测的意义。
相信你所认为虽然很正确,但是做起来很傻逼的事情,一定有人在默默的坚持着。努力做一个优秀的人。
2.4 代码都测完了,要测试干嘛
自己测完了,要测试干嘛。首先如果你有这样的想法,那么一定是因为你不了解测试的工作。测试是开发的补充,他一定不是开发的保姆。测试 是对应用或系统的整体场景或者说功能的验证, 他不能对你代码的最小单元进行验证。所谓代码的最小单元一定是开发同学最了解的,代码的最小单元 就是你定义的代码块,方法,技术框架。这部分测试同学是无法帮你验证的。我们这里举一个例子。
软件工程师好比是盖大楼的,具体每一堵墙砖头如何摆放,房间如何设计,是否关注采光这是你设计师要干的事情,而测试好比质量验收,会看你整栋 大楼是否有倾斜,水电煤气是否可以使用。测试同学并不了解所有的细节。
开发和测试看到的东西不是完全一样的,越往上测试的黑盒越大。
2.5 应付覆盖率指标
当然如果公司对这个有要求,一定会有应付的办法。最差的情况就是全部都是为了应付而写代码。从价值观上来看,这是不对的。从实用性上来看这是没有任何价值的。那么如何解决这个办法呢? 价值观来保证咯。那么就需要一个指标了(非硬性指标), 把数据量化展示出来,作为应用质量的一个参考的因素。 就算你全是应付而写,也一定有一定的价值。
另外要说一点的是单测行覆盖率高不代表应用的质量就一定高,但是单测行覆盖率低一定代表着这个应用出现质量问题的可能性就越大。 这无疑增加了业务风险和测试成本。为了减少业务风险和测试成本,希望大家提高对单测的意识。
那么我们在上升一点总结下如何提高应用的质量呢? 请看下文
三、应用质量
应用质量如何来衡量, 这是一个完全可以通过指标来进行衡量的。那么究竟如何指标化呢? 这里首先对应用质量进行一个拆分。
可以将应用质量分为两种:
代码编程质量(编程风格)
业务编程质量(业务是否清晰,异常场景的考虑)
3.1 代码编程质量
代码编程质量往往只的是开发人员的编程风格,基于团队成员风格的相似度。 也可以说是代码的可读性,可维护性,方法的复杂度,方法的执行效率。这个是最容易指标化处理的。 基于规则引擎,进行静态代码扫描就可以扫描出。Sonar 或者 阿里规约都可以完成。 他们都会把问题分为四个等级Blocker, Critical, Major, Minor/Trivial。
3.1.1 Blocker
即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
3.1.2 Critical
即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
3.1.3 Major
即界面、性能缺陷、兼容性。
3.1.4 Minor/Trivia
即易用性及建议性问题。
质量分计算
3.2 业务编程质量
3.2.1 UT测试
对软件设计的最小单位进行正确性检测，如函数或一个类的方法。
UT由开发同学保证,开发同学进行最小单元测试, 那么数据指标如何进行衡量呢?
基于Jenkins的 Jcoco 插件,会统计行覆盖率，类覆盖率，复杂方法覆盖率等。输出一个 可视化的图表
3.2.2 IT测试
IT场景测试，将后端接口,按照业务流程的顺序编排成自动化的场景用例。
四、讲在最后
当然能做到这些的一定是体量不小的公司,对于小公司而言,要的是敏捷开发快速迭代，出现问题,快速发现及时补偿即可。所以这篇文章可能不适用于小公司内进行运营。因为这些不仅对开发者的要求高，而且对测试也有不小的要求。但是相同的是, 有一点是一样的。就是不管是开发同学还是测试同学都应该提高对单元测试的认识。要知道: 单侧不是目的而是提高应用质量的手段。
对于管理者来说，应用质量的指标是完全可以可视化展示出来的。后面小编会一步一步来搭建这个应用质量可视化方案和单元测试的分享。
本文属于开篇只讲概念后面会讲到使用到的技术。和如何搭建一个可视化的平台。感谢阅读。
最后求关注,求订阅,感谢您的阅读，本文由西魏陶渊明 版权所有。如若转载，请注明出处：程序猿升级课（https://blog.springlearn.cn/）
