软件测试 52 讲
茹炳晟
腾讯 TEG 基础架构部 T4 级专家
71691 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
结束语 (1讲)
软件测试 52 讲
15
15
1.0x
00:00/00:00
登录|注册

03 | 什么是单元测试?如何做好单元测试?

思考题
总结
实际项目中如何开展单元测试?
如何做好单元测试?
什么是单元测试?
单元测试

该思维导图由 AI 生成,仅供参考

今天我要跟你分享的主题是单元测试,如果你没有开发背景,感觉这篇文章理解起来有难度,那你可以在学完后续的“代码级测试”系列的文章后,再回过头来看一遍这篇文章,相信你会有醍醐灌顶的感觉。

什么是单元测试?

在正式开始今天的话题之前,我先给你分享一个工厂生产电视机的例子。
工厂首先会将各种电子元器件按照图纸组装在一起构成各个功能电路板,比如供电板、音视频解码板、射频接收板等,然后再将这些电路板组装起来构成一个完整的电视机。
如果一切顺利,接通电源后,你就可以开始观看电视节目了。但是很不幸,大多数情况下组装完成的电视机根本无法开机,这时你就需要把电视机拆开,然后逐个模块排查问题。
假设你发现是供电板的供电电压不足,那你就要继续逐级排查组成供电板的各个电子元器件,最终你可能发现罪魁祸首是一个电容的故障。这时,为了定位到这个问题,你已经花费了大量的时间和精力。
那在后续的生产中,如何才能避免类似的问题呢?
你可能立即就会想到,为什么不在组装前,就先测试每个要用到的电子元器件呢?这样你就可以先排除有问题的元器件,最大程度地防止组装完成后逐级排查问题的事情发生。
实践也证明,这的确是一个行之有效的好办法。
如果把电视机的生产、测试和软件的开发、测试进行类比,你可以发现:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

单元测试在软件开发中扮演着至关重要的角色,类似于工厂对每个电子元器件进行测试以确保最终产品质量。它是对最小可测试单元进行隔离验证的工作,能以最小成本保证代码质量,并以自动化方式执行,适用于大量回归测试的场景。单元测试的实施过程能帮助改善代码设计与实现,并提供函数的使用示例,构成了函数的使用说明。文章深入探讨了如何做好单元测试,包括对代码基本特征与产生错误的原因的理解、单元测试用例的设计、以及驱动代码、桩代码和Mock代码的应用。作者详细解释了单元测试用例的“输入数据”和“预计输出”的复杂性,以及驱动代码、桩代码和Mock代码的逻辑关系。此外,还强调了编写桩代码的原则和Mock代码与桩代码的本质区别。这篇文章对于想要深入了解单元测试的读者来说,提供了全面而深入的技术指导。 在实际项目中,开展单元测试需要注意以下三个问题:首先,代码要做到功能逻辑正确,必须做到分类正确并且完备无遗漏,同时每个分类的处理逻辑必须正确;其次,单元测试是对软件中的最小可测试单元在与软件其他部分相隔离的情况下进行的代码级测试;最后,桩代码起到了隔离和补齐的作用,使被测代码能够独立编译、链接,并运行。 在实际软件项目中,开展单元测试需要确定单元测试框架的选型,选择适合开发语言的桩代码框架和Mock代码框架,并引入计算代码覆盖率的工具。最后,将单元测试执行、代码覆盖率统计和持续集成流水线做集成,以确保每次代码递交都会自动触发单元测试,并在单元测试执行过程中自动统计代码覆盖率,最终以“单元测试通过率”和“代码覆盖率”为标准来决定本次代码递交是否能够被接受。 总的来说,本文详细介绍了单元测试的概念和实际项目中开展单元测试的方法,为读者提供了全面而深入的技术指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件测试 52 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(78)

  • 最新
  • 精选
  • 海罗沃德
    在Accenture时候单元测试行覆盖率要达到99%,分支覆盖率要达到90%,仅一些exception分支可以不用覆盖,并且每个测试用例前面要注释好这个case测的是什么方法,输入什么输出什么,预计结果是什么等以便code review时可以快速的知道这段代码是做什么的,甚至一些大功能还要带上use case的id方便追溯原始需求,在测数据持久化层测试要通过内存数据库把CRUD流程都测出来

    作者回复: 埃森哲的所有项目都有这么高的单元测试需求吗?我的理解是一些和人的生命安全息息相关的软件才会有几近苛刻的代码覆盖率要求,比如航空航天,汽车电子,轨道交通,部分医疗器械软件等,如果所有项目都这样做成本还是很高的

    2018-07-05
    19
  • happychap
    单元测试本身并不复杂,但在实践中又经常需要十填许多坑,如:事务的传递可能导致单元测试结束后事务回滚失败(若用内存数据库又存在解决sql兼容性的烦恼),多线程执行单元测试导致测试结果不正确,对第三方接口做mock困难,实现逻辑中会周期性计划任务的功能也不好做单元测试。

    作者回复: 涉及数据库的单元测试建议不要操作真实的数据库,而是使用dbmock。你说的非常对,单元测试是入门容易,工程实践比较难

    2019-01-21
    12
  • 自动化测试集应该是一把可信的、灵活的尺子。所以测试集不宜过大,应能支持在几个小时内给出稳定可信结果。测试集的大小应考虑以下几个方面:以时间窗口为首要敏感因素,然后考虑覆盖功能的重要程度,测试执行的稳定性。

    作者回复: 很棒的总结

    2019-05-09
    8
  • Geek_84a77e
    不太理解老师说的输入数据那部分 只知道被测函数的参数进行设计 不知道如何针对函数的成员变量等进行设计用例?

    作者回复: 能问这个问题,说明你已经很好地理解了文章的关键内容。这里的成员变量指的是类的成员变量,逻辑上你也可以把它想象成是全局变量。因为函数内部会去读取类的成员变量,然后根据类的成员变量来决定后续逻辑等。

    2018-07-04
    2
    8
  • 刘炜
    单元测试开展最佳时机是从项目初级就开始,结合TDD的方式。现实中的困难就是当代码已经烂成一坨翔的时候才意识到要做单元测试,而这个时候的成本和收益已经不允许了。

    作者回复: 哈哈,你说得太对了,但是现实都是先实现再补单元测试

    2018-07-10
    6
  • Elsa
    我所在的是敏捷开发团队,QA需要review UT,那么我想知道QA 怎样review UT才更有价值呢?现在基本是根据业务需求去review UT的case是否有遗漏

    作者回复: 我建议qa从接口层面review效率更高,qa直接review ut可能并不是太合适

    2018-07-12
    2
    4
  • 捷后愚生
    这篇文章,不仅是测试人员要看,开发人员也要看!

    作者回复: 是的,可能开发看会更有感觉,因为单元测试一般都是开发自己在做

    2018-07-11
    3
    3
  • 永不放弃
    老师,后面会有实战部分吗?

    作者回复: 专栏后期会有专门的篇幅讲代码级测试,那里会提供更多实际的例子

    2018-07-04
    1
  • Walter
    请问一下,现在如果要做plc这种单元级别的测试,该如何做呢?

    作者回复: PLC的单元测试用例的设计思想方法是类似的,但是具体实施起来的差别会比较大,PLC一般都有自己专用的ide环境,我不确定是否存在类似Xunit的工具。

    2018-10-11
  • 小老鼠
    单元测试是否应该也分为黑盒与白盒测试两种。不考虑内部实现的API属于黑盒单元测试、考虑语句、分支、条件等程序内部覆盖率的测试属于白盒单元测试。

    作者回复: 严格来讲,单元测试基本都是属于白盒的范畴,而api本身更多属于灰盒的范畴。但是,我们其实并没有很大的必要去纠结到底是黑盒还是白盒,我们应该通过这样的分类来看到背后想要表达的测试思想。

    2018-10-04
收起评论
显示
设置
留言
78
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部