1 背景
测试是开发的一个非常重要的方面,可以在很大程度上决定一个应用程序的命运。良好的测试可以在早期捕获导致应用程序崩溃的问题,但较差的测试往往总是导致故障和停机。
单元测试用于测试各个代码组件,并确保代码按照预期的方式工作。单元测试由开发人员编写和执行。大多数情况下,使用JUnit或TestNG之类的测试框架。测试用例通常是在方法级别写入并通过自动化执行。
单元测试不仅仅用来保证当前代码的正确性,更重要的是用来保证代码修复、改进或重构之后的正确性。
2.单元测试定义
单元测试又称模块测试,是针对程序模块(软件设计的最小单位)来进行正确性校验的测试工作,程序模块在面向对象编程中一般指方法。
3.为什么需要进行单元测试
编写单元测试代码并不是一件容易的事情,那为什么还需要去花费时间和精力来编写单元测试呢?原因如下:
· 减少Bug:如今的项目大多都是多人分模块协同开发,当各个模块集成时再去发现问题,定位和沟通成本是非常高的,通过单元测试来保证各个模块的正确性,可以尽早的发现问题,而不时等到集成时再发现问题。
· 放心重构:如今持续型的项目越来越多,代码不断的在变化和重构,通过单元测试,开发可以放心的修改重构代码,减少改代码时心理负担,提高重构的成功率。
· 改进设计:越是良好设计的代码,一般越容易编写单元测试,多个小的方法的单测一般比大方法(成百上千行代码)的单测代码要简单、要稳定,一个依赖接口的类一般比依赖具体实现的类容易测试,所以在编写单测的过程中,如果发现单测代码非常难写,一般表明被测试的代码包含了太多的依赖或职责,需要反思代码的合理性,进而推进代码设计的优化,形成正向循环。
就个人而言,感受最深的就是,有了单测后重构代码起来心里压力小多了,其次是通过单测减少了很多低级错误。
4.单元测试带来的一些问题
单元测试在解决了一些问题的同时也容易产生一些问题:
学习成本:单元测试框架的学习需要一定的成本
开发成本:项目初期,往往最重要的是快速上线,时间非常紧张,这时容易出现单测代码难以编写,代码经常变化导致单测代码也需要更着同步变化,一定程度上会拖慢项目的进度,可以在项目中后期再补上重要部分的单测代码
推广实行:项目中推广单测有一定成本,单纯为了覆盖率的单测是没什么意义的,所以在项目中推广单测时,要考虑到项目成员是否接受单测,能否编写出较好的单测代码,否则单测容易流于形式,达不到理想的效果。
个人经验,在项目中要施行单测,需要做到以下几点:
·说服领导,给出合理的考核指标(如单测覆盖率等要求,需要结合现状给出合理的指标)
· 提供单测指标统计的大盘,显示项目单测指标,督促大家完成指标
· 对项目结构配置等进行调整,提供单测工具类,基础类,让单测易编写,能运行,速度快
· 对项目组成员进行单测编写方法分享,使成员熟悉单测技术
· 提供单测代码示例,示例要够全面够清晰明了,方便成员参考
· 定时检查成员单测代码,提供改进意见,防止流于形式
5 单元测试用例相关概念
5.1正面测试(Positive Testing)
测试被测对象的正确功能实现无误,即正常流程功能。往往需要根据设计说明进行用例导出,严格按照设计说明编写即可,用例划分注意等价类区分等方法。
5.2负面测试(Negative Testing)
测试被测对象的异常功能实现无误,多在异常流程,异常数据中体现。该部分测试需要对被测对象进行错误发散,常依赖于边界值区分等方法。
5.3分支测试
使用流程图,明确可能出现的每条分支,制造响应的数据进行覆盖,实现对被测对象的测试。这个过程对于分支可以进行响应的简化,可以穿插等价类等方法去除同类分支。
5.4 边界值分析法
这种方法更偏向于黑盒测试用例设计中使用,对被测输入进行边界分析,从各个角度都会有边界值,例如程序内部依赖之间,已经有一些边界存在,在程序集成展示后,也会有新的边界出现,在设计的时候,需要注意这些细节。例如我们可输入范围是3-6,和输入类型为浮点数。那么边界值为7-8之间。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取