全栈工程师修炼指南
熊燚(四火)
Oracle 首席软件工程师
32206 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
全栈回顾 (1讲)
加餐 (1讲)
全栈工程师修炼指南
15
15
1.0x
00:00/00:00
登录|注册

30 | Ops三部曲之三:测试和发布

用例简洁程度和核心功能覆盖的不平衡
独立性和幂等性
问题三:对达到“单元测试覆盖率”机械而生硬地执行
问题二:无法消除依赖
问题一:执行缓慢
部署
测试
构建
编译
代码开发
规则自定义和重用能力
基于监控信息的自动化操作
多维度、分级别、可视化的数据统计和监控
不同环境的不同依赖配置
版本冲突的选择
工具为程序员服务
冒烟测试
集成测试
单元测试
Pipeline
环境监控
依赖管理
代码静态分析
不同测试的集成
CI/CD 和 Pipeline
选修课堂:持续集成和持续发布的更多挑战
持续集成和持续发布
Ops三部曲之三:测试和发布

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

你好,我是四火。
今天,我们继续 Ops 三部曲。今天我要讲一讲持续集成和持续发布,以及 Web 全栈项目中一些常见的测试维度。

CI/CD 和 Pipeline

CI 指的是 Continuous Integration,持续集成,而 CD 指的是 Continuous Delivery,持续交付。它们二者结合起来,通过将工程师的代码变更反复、多次、快速地集成到代码主线,执行多种自动化的测试和验证,从而给出快速反馈,并最终达到将变更持续、迅速发布到线上的目的。
为了达到持续集成和持续交付,我们几乎一定会使用一个叫做 pipeline 的工具来将流程自动化。Ops 中我们总在谈论的 Pipeline,指的就是它。Pipeline 是一个将代码开发、编译、构建、测试、部署等等 Ops 活动集成起来并自动化的基础设施。把 Pipeline 放在最先讲,是因为它是集成 Ops 各种自动化工具的核心,而这一系列工具,往往从编译过程就开始,到部署后的验证执行结束。
Pipeline 确定和统一了从开发、测试到部署的主要流程,但最大的作用是对劳动力的解放。程序来控制代码从版本库到线上的行进流程,而非人。因此,如果一个 pipeline 上面设置太多个需要人工审批的暂停点,这样的自动化就会失去一大部分意义。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

持续集成和持续发布是现代软件开发中至关重要的环节,本文深入探讨了Ops三部曲之三:测试和发布。首先介绍了持续集成(CI)和持续交付(CD)的概念,以及通过pipeline工具实现自动化流程的重要性。文章强调了pipeline的核心作用,即统一和自动化开发、测试到部署的流程,并解放人力。随后,文章讨论了不同测试的集成,包括单元测试和集成测试。在单元测试方面,作者指出了执行缓慢、无法消除依赖和机械执行覆盖率的问题。而在集成测试方面,作者强调了测试独立性和幂等性的重要性,并介绍了在某些团队中通过不同环境完成集成测试的做法。此外,文章还提到了冒烟测试在Web项目中的实用性,强调了对重要功能或核心功能的保障。除此之外,还介绍了代码静态分析、依赖管理和环境监控等持续集成和持续发布中的更多挑战和技术要点。整体而言,本文通过实例和问题分析,深入探讨了持续集成和持续交付中的测试维度,为读者提供了有益的技术指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《全栈工程师修炼指南》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(3)

  • 最新
  • 精选
  • Geek_74d3ac
    前端测试确实不容易 在我的实践中 unit test 可以对部分小的函数功能进行测试,这依赖前端对功能抽象的做得足够好。 甚至一些基于框架的 unit test 还支持到 react vue 这一类框架的组件级别的交互功能的测试。 但是对于交互后界面动画样式变化是否等一些可观测性的东西,就很无能为力,逃不开让人去确认。 当然,也有一些测试方案是通过网页快照,或者将这些界面上内容是否正确抽象为 dom 节点结构是否正确的方法。但在我们的项目中搭建成本过高,一直无法有效推动。

    作者回复: 👍🏻

    2020-08-13
    1
  • 小寞子。(≥3≤)
    对于一些很难做测试的前端怎么办? unit test在angular里面花费的时间比写代码本身还要花时间 而且需要大量维护。最后每次都是测试代码有bug而不是本身有bug。。 。 还有自动化测试安全性问题。 搭建一个自动化平台里面 很多时候都因为安全性导致很难落地。比如账号登录, 必须要在固定ip地址里。。 企业本身IT的成熟程度很重要。

    作者回复: 这个问题很大,不过我有这样几点看法: 1. unit test时间成本高,识别问题的原因是第一步,也就是说需要分析一下为什么?是重复劳动吗?是因为容易出各种各样的错吗?是因为测试本身的机制不合理,把问题复杂化了?还是写了过多且冗长代码,就为了源码和case的覆盖呢? 2. 如果时间成本高是因为代码的逻辑复杂,或者说业务复杂,那么这样的时间成本高就很可能是值得的,因为从开发测试到发布的一系列流程中,为了保证质量,你总有一个环节需要花时间下力气去做。 3. 如果是其它原因,那确实需要改进,否则开发人员就会很快丢掉积极性。 4. 另外,在我接触的前端项目中,我个人认为比较具备性价比的做法是核心代码和复杂逻辑代码写一定的unit test,凡是追求覆盖率的测试最后写着写着都失败了。

    2020-04-04
    1
  • Geeker
    👍
    2020-03-10
收起评论
显示
设置
留言
3
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部