程序员的测试课
郑晔
开源项目 Moco 作者
18911 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 23 讲
加餐 (1讲)
结束语 (1讲)
程序员的测试课
15
15
1.0x
00:00/00:00
登录|注册

15 | 测试应该怎么配比?

你好,我是郑晔!
经过前面内容的讲解,相信你对在实际项目中如何编写单元测试和集成测试已经有了一个基本的认识。无论你是经验丰富的老程序员还是初入职场的新程序员,如果只是单独写几个测试,相信你都可以手到擒来。但真实的项目中我们不是要编写几个测试,而是要大批量地编写测试。
一旦编写的测试增多,你脑海里必然会出现一个疑问:有一些内容用单元测试覆盖可以,用集成测试覆盖也可以,如果只写单元测试总有些不放心,如果同时用单元测试和集成测试去覆盖,工作量似乎又会增大,不同的测试应该怎样配比呢?这就是我们这一讲要讨论的内容。

测试的特点

在讨论如何配比测试之前,我们需要先了解各种类型测试的特点,毕竟正是因为它们有着不同的特点,我们才需要对不同的测试按照不同的比例进行配比。
首先来看单元测试。单元测试是针对一个单元的测试,因为涉及面很小,所以单元测试要进行的设置会比较少。单元测试不牵扯到外部组件,一般而言只在内存中执行,执行速度很快。所以谈及单元测试的特点我们一般会说,它成本低、速度快、单个测试的覆盖面小,但整体覆盖面大。
再来看集成测试。相比于单元测试来说,集成测试的涉及面要广一些,设置起来就比较麻烦。有的集成测试还会集成外部组件,这也就意味着设置起来要更麻烦,比如你在上一讲见识过的数据库测试,就要准备各种配置信息。同时,无论是组件多还是集成外部组件,这都意味着执行速度要比单元测试慢。所以相比于单元测试,集成测试成本要高一些、速度要慢一点;单个测试的覆盖面要大一些,但整体覆盖面要小一些。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文讨论了软件开发中的测试配比模型,重点介绍了冰淇淋蛋卷模型和测试金字塔模型。冰淇淋蛋卷模型侧重于多写系统测试,而测试金字塔模型以单元测试为基础,逐层递减。作者强调了测试金字塔模型作为行业最佳实践的重要性,尤其适用于新项目的测试策略。对于遗留项目的测试补充,冰淇淋蛋卷模型也具有一定的适用性。建议在遗留系统上补充测试后,仍需向测试金字塔模型方向前进,以单元测试为整体基础。文章通过对两种模型的比较和应用场景的讨论,为读者提供了在实际项目中如何选择合适的测试配比模型的指导建议。文章强调了在新项目中采用测试金字塔模型,在遗留项目中则从冰淇淋蛋卷模型出发,为读者提供了实用的技术建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《程序员的测试课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • byemoto
    开发不愿意写单元测试, 说单元测试没用的, 大部分是不会写. 这变向地给QA增加了很多不必要的工作负担, 本应通过单元测试发现的Bug会逃逸到更高层次的测试中, 导致的现象就是: 研发改一行, QA测一天.

    作者回复: 哪有什么岁月静好,不过是有人替你负重前行

    2021-09-06
    4
    13
  • Geek_3b1096
    谢谢老师解答了我的疑惑测试金字塔不是唯一标准

    作者回复: 工具虽好,用好需要知道它的来龙去脉。

    2021-09-12
    4
  • 大碗
    单测比集测多,那么单测和集成测试的比例是多少? 集成是否只测happyPath就可以呢?

    作者回复: 这个是每个团队对自己的要求,不同的团队要求不同。如果你前面已经用单元测试进行了 100%的测试覆盖,其它类型的测试就比较灵活了。我自己就曾经在项目中,只有一个系统测试,用来覆盖启动的场景。

    2021-09-06
    3
  • chon
    现在流行微服务,服务间调用通过dubbo和feign来调用。这种情况单元测试是用mock吗?集成测试和端到端测试呢?怎么处理?

    作者回复: 微服务与单元测试是两个独立维度,该怎么测就怎么测。至于把所有的系统都连起来的测试,那就是系统测试了,做好这种测试的关键是要把基础设施的自动化做好,否则,手工启动这些服务就是无尽的痛苦。

    2021-09-08
    2
  • sylan215
    从单元测试到系统测试的区别,就是逻辑关联越来越多,好处是覆盖面越来越全(越是系统级越靠近用户场景),不足是问题定位也更麻烦(现在的多人合作开发更增加了这个麻烦,如果是单人对系统很了解的话,其实也并没那么难)。 都知道金字塔好,但现实情况是开发同学都不愿做(没时间没动力)单元测试,最终都是冰淇淋了。 现在还有一个提法,叫菱形,UT 和 UI 的测试都少做,中间的集成(接口)多做,这样降低了 UI 测试的复杂度,也保证了单元测试接口的覆盖度,不足的还是场景化测试覆盖不够。 这些都是理论层面,实际落地还是需要和实际情况相结合,适合的才是最好的。
    2021-09-16
    4
  • ifelse
    前几天和公司里一个技术还行的同事聊天,谈到了写测试和重构,结果他说这样做会让代码变成屎山代码,又说敏捷开发不行,自己以前在日企呆过。"日式"开发模式很好,我问他是什么模式,他就说是"日式",后来在我一再追问下,他说就是传统模式。说敏捷开发会不停改需求重构。说自己以前也看过敏捷开发,传统开发的书,自己都了解。我当时听了有点激动,就和他争了起来。😂
    2022-06-12
    3
    1
  • 我是李椭超他哥李方超 🐕
    写的真踏马好
    2023-03-28归属地:上海
  • ifelse
    新项目采用测试金字塔,遗留项目从冰淇淋蛋卷出发--记下来
    2022-06-12
  • 花花大脸猫
    目前在兼顾基本功能的基础上开始补充单元测试,基本满足所说的金字塔模型,但是由于qc的整体测试质量不行,导致开发不得不写很全的功能测试,在打包前全量验证单元与功能测试!
    2022-04-13
  • aoe
    现在的系统使用冰淇淋蛋卷进行测试,因为随便一个接口SkyWalking显示的调用链几十到上千不等
    2021-11-13
    2
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部