许式伟的架构课
许式伟
七牛云 CEO
84946 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

73 | 软件质量管理:单元测试、持续构建与发布

欢迎讨论与分享
软件工程的不确定性与确定性
A/B 测试
灰度发布
人工的代码互审
静态代码质量检查
单元测试覆盖率检查
自动化运行单元测试案例
极度高频交付的要求
交付频率对软件工程的影响
小发布与高频率发布
推广单元测试的挑战
单元测试成本与效益
模块级单元测试
自动化测试
维护期
开发期
结语
质量管理抓手
持续构建与持续发布
单元测试
预见性的重要性
软件工程生命周期
软件质量管理

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

你好,我是七牛云许式伟。
上一讲 “72 | 发布单元与版本管理” 我们聊了版本管理中,只读思想给软件工程带来的确定性价值,它在软件工程质量管理中也是很核心的一点。

软件质量管理

今天我们聊聊软件工程中,我们在质量管理上其他方面的一些思考。事实上,软件质量管理横跨了整个软件工程完整的生命周期。
软件工程与传统工程非常不同。它快速变化,充满不确定性。不仅如此,一个软件工程往往是生命周期以数年甚至数十年计的工程。对于传统工程,我们往往把一个工程同时也称之为项目,项目工程。但软件工程不同,虽然我们平常也有项目的概念,但软件工程并不是一个项目,而是无数个项目。每个项目只是软件工程中的一个里程碑(Milestone)。
这些都决定了软件工程质量管理的思想与传统工程截然不同。在传统工程中,设计的工作往往占比极少,重复性的工作占据其生命周期的绝大部分时间。所以传统工程有极大的确定性。检查清单(Check List)很可能就已经可以很好地实现其工程质量的管理。
但对于软件工程来说,设计工作在整个工程中持续发生。哪怕是非设计工作,比如编码实现,也仍然依赖个体的创造力,同样存在较强的不确定性。显然,检查清单(Check List)完全无法满足软件工程的质量管理需要。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件质量管理在软件工程中扮演着至关重要的角色。本文从软件工程的不确定性出发,探讨了软件质量管理的思考与方法。首先,强调了软件工程与传统工程在质量管理上的巨大差异,指出软件工程需要极强的预见性,而设计工作的质量至关重要。其次,文章提出了两个关键的质量管理方法:单元测试和持续构建、持续发布。单元测试被强调为软件工程中的重中之重,因为它具有低成本、高效率、可回归性的特点,能够缩短问题发现周期,降低Bug的修复成本。持续构建、持续发布则被认为是应对软件工程不确定性的最佳方式,通过更小、更短、更高频率的发布,降低了发布的负担,提高了交付效率。最后,文章强调了对于软件工程的系统化建设和质量管理抓手的重要性,如自动化运行单元测试案例、单元测试覆盖率检查、静态代码质量检查等。总的来说,本文深入探讨了软件工程的质量管理,强调了在高度不确定性中寻找确定性的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(14)

  • 最新
  • 精选
  • Geek007
    相比单元测试,似乎code review在我司更难推动。code review需要人的投入,而且往往需要有经验的工程师,有经验的工程师有他们自己的开发任务,他们会把code review当成是额外的工作,动力不够,责任心也不够,code review的质量因而也不能控制。有时候迫于发布的压力,code review做的很粗糙。code review 必要么?许老师对这个问题有何看法?谢谢。

    作者回复: code review 非常重要,我们不 code review 就没法合并 pull request。

    2020-01-16
    4
    16
  • 何磊
    不好意思,上条消息没法完整,补一条 关于单元测试请教一下许老师。对于业务系统,比如我写的一个对外的http系统,针对http系统如何做单元测试呢? 以经典的MVC架构为例,我的C层依赖M层,M层依赖存储层 1. 针对M层做单元测试时,我对每个结构体的每个方法写测试用例,由于它依赖存储层,只能去做mock吗? 2. 再对C层做单元测试时(这个时候不确定是测controller这个方法,还是直接测试http的接口),由于它又依赖了M层,M层又依赖了存储层。这种情况直接对依赖的M层做mock吗? 如果每一层都去做mock,实际上会代码很大的编码工作。工作这么多年也没有见过哪家公司完整的有实践。希望老师能够点拨一下

    作者回复: 从原则来说,测试一个模块什么东西应该直接依赖,什么需要mock,基本的判断逻辑是:所依赖的模块越稳定(至少接口稳定,实现也稳定就更好),越经过长期迭代,越可以直接依赖。反之如果所依赖模块也是新模块,在高速发展中,那么应该用mock。 通常而言,Model对存储层的依赖不会用mock,因为存储中间件是非常稳定的。而controller对model的依赖往往早期用mock,因为在同步迭代,但后期往往逐步改为基于真实的,因为可以有稳定的真实版本可以依赖。

    2020-07-24
    2
    6
  • leslie
    最近就碰到一个现状在“持续构建,持续发布“方面的问题:公司业务最近刚好进入了高速增长期,每次交付的功能很多且目前上传频率基本上已经是每天的业务的低谷-凌晨那一段时间;如何权衡这种现状?按照老师前面课程提及的方式只能是每次只上传核心/最重要的更新功能,不知道老师是否有更好的建议。谢谢老师的分享,期待老师后面章节的更新。,

    作者回复: 如果发布很频繁,需要在发布系统和架构上优化,保证发布出问题可以一键回滚,另外升级要做到不影响用户,这样发布随时都可以,而不是只能在业务低谷。

    2020-01-14
    4
  • Bachue Zhou
    大部分服务器项目或库项目一般都有单元测试,但涉及到图形化界面的项目可能就非常不乐观了,纯计算的代码太少也够简单不需要做测试,涉及到 UI 交互的代码量很大却不知道如何测试。最后还是要靠手测。

    作者回复: ui测试的确复杂很多,但也不是不可能

    2020-01-21
    3
  • 我在你的视线里
    持续构建和持续发布还有一种小步快跑的感觉。但是不是会影响客户体验。

    作者回复: 是的

    2020-01-14
    3
    1
  • Jeyrce.Lu
    想请教一下许老师,硬件、底层资源的自动化测试怎么做?如果是简单的基于数据库存储的中间件,我们通常只需要关注数据库的结果。但是对于硬件来说,产生的结果很可能是破坏性的,不可逆转的,比如说需要测试down库,删盘,执行某些shell命令等

    作者回复: 你是要测试软件在硬件故障下的行为 还是测试硬件本身?

    2022-04-06
  • Aaron Cheung
    我们不把推广单元测试看作是让大家去多做一件额外的事情,而是规范大家做单元测试的方法。 感觉知道的有单元测试的项目都没有四成……
    2020-01-14
    8
  • 程序员小跃
    自动化测试真的很重要,尤其是持续集成,持续构建。在前公司的时候,因为有每日构建,每日跑自动化,只要当天提交的代码出错,第二天就会在项目经理的邮件上体现出来,这样能一定程度上避免了因为个人疏忽导致在交付上出现差错,把错误在第一时间就扼杀掉。 现公司因为种种原因始终不能推进自动化,纯人工,所以会频繁遇到线上问题。看来不能太佛系地面对,还是需要向老师这样,通过绩效等管理规范来完善这个自动化,对自己,对项目,对公司的口碑都好
    2020-03-07
    1
  • ifelse
    学习打卡
    2023-10-16归属地:浙江
  • ifelse
    学习打卡
    2023-10-16归属地:浙江
收起评论
显示
设置
留言
14
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部