软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6701 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

29 | 自动化测试:如何把Bug杀死在摇篮里?

宝玉 2019-05-04
你好,我是宝玉。前不久我所在项目组完成了一个大项目,把一个网站前端的 jQuery 代码全部换成 React 代码,涉及改动的项目源代码文件有一百多个,变动的代码有几千行,最终上线后出乎意料的稳定,只有几个不算太严重的 Bug。
能做到重构还这么稳定,是因为我们技术水平特别高吗?当然不是。还是同样一组人,一年前做一个比这还简单的项目,上线后却跟噩梦一样,频繁出各种问题,导致上线后不停打补丁,一段时间才逐步稳定下来。
这其中的差别,只是因为在那次失败的上线后,我们总结经验,逐步增加了自动化测试代码的覆盖率。等我们再做大的重构时,这些自动化测试代码就能帮助我们发现很多问题。
当我们确保每一个以前写好的测试用例能正常通过后,就相当于把 Bug 杀死在摇篮里,再配合少量的人工手动测试,就可以保证上线后的系统是稳定的。
其实对于自动化测试,我们专栏已经多次提及,它是敏捷开发能快速迭代很重要的质量保障,是持续交付的基础前提。
所以今天我将带你一起了解什么是自动化测试,以及如何在项目中应用自动化测试。

为什么自动化测试能保障质量?

自动化测试并不难理解,你可以想想人是怎么做测试的:首先根据需求写成测试用例,设计好输入值和期望的输出,然后按照测试用例一个个操作,输入一些内容,做一些操作,观察是不是和期望的结果一致,一致就通过,不一致就不通过。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • yasuoyuhao
    .net core 的同學,我們項目使用 NUint 進行單元測試,集成測試可以使用 WebApplicationFactory,模擬工具可以使用 Moq

    作者回复: 赞,感谢回复!🙏

    2019-05-06
    5
  • kirogiyi
    请教宝玉老师:团队成员的能力和素质参差不齐,如何有效的去组织和管理项目的自动化测试,自动化集成?

    作者回复: 首先,你要先搭建好自动化测试环境,让自动化测试代码能跑起来,最好最好要和CI(持续集成工具)整合在一起,每次提交代码CI都会跑自动测试,然后能看到运行结果。

    然后,把自动化测试作为开发流程的一部分,比如说要代码审查和自动化测试通过后才能合并代码。这部分工作如何和CI集成会容易很多。

    再有就是要培训,比如遇到不会写的,开始先带着他写几个,确保他学会了自己能写,然后下次代码审查的时候,看到缺了就要求补上,还不会就继续教,来不及写的就创建个TIcket跟踪起来。

    简单来说,就是代码审查+CI+培训

    2019-05-04
    5
  • Joey
    请教宝玉老师:
    消息类接口应该通过哪种方式高效、有效维护?

    现状:
    系统A属于联机类系统(高并发、低延迟),其中接口B与多个应用相关,当接口B的定义发生变化时,往往忘记通知相关方或者漏通知,从而引发生产事件。

    尝试过的手段:
    1、通过流程约束,需求评审阶段,强制增加是否有接口变化的评审,但是落实结果不理想,主要因为增加流程,开发人员嫌浪费精力,最后流于形式。
    2、通过自动化手段约束,原则上要求接口必须在CI阶段有自动化用例守护,但是效果也不理想,自动化用例缺失或者开发人员懒的写自动化用例,最后流于形式。(我们部门研发和测试属于不同的团队,所以开发人员对于代码质量,都指望测试人员守好最后一道关卡。)

    作者回复: 我觉得对于API,应该要有版本的概念,也就是一个版本的API在确定前,多论证,多确认,确认后就不要做大的改动,大改动就用新版本,新版本上线时,旧API应该持续运行一段时间。

    然后对于API修改后,应该当作一个小项目来看待,也就是要确保通知所有相关方,确定API切换的时间点,帮助调用房升级迁移到新版本。

    最后再是自动化测试帮助检测。

    2019-06-26
    3
  • Liber
    宝玉老师你好,有个地方感觉有必要再展开谈谈:
    以本文注册用户为例,本文分别对这个case写了小、中、大型测试用例,但实际开发过程中,如何权衡对一个场景是该小、中、大都写,还是只写部分?

    作者回复: 实际开发中,理论上来说一个场景大中小测试都要写的。

    通常来说,开发写小型测试和中型测试,测试写大型测试,或者开发帮助写大型测试。

    小型测试:中型测试:大型测试比例大约为 7:2:1

    小型测试尽可能多覆盖,不要求100%,谷歌是85%

    中型测试覆盖大部分用户使用场景

    小型测试覆盖主要用户场景

    2019-05-13
    2
  • Zebin
    宝玉老师,请教下,我们现在LINUX环境下开发项目,主要编程需要是C/C++。
    现在想搭建持续集成开发环境,有什么合适的工具可以推荐下吗

    作者回复: 单元测试你可以用gtest,集成测试工具你可以参考我之前 那篇集成测试的文章,比如说试试Jenkins或者Gitlab CI。

    具体怎么搭你可以参考网上的教程,应该已经有很多了

    2019-05-08
    1
    2
  • 小小
    老师你好,请问下有没有介绍开发如何写好测试不错的书?

    作者回复: 推荐:《how we test software at microsoft》中文版《微软的软件测试之道》

    不过没有书其实你也可以找到很多资料的。比如我平时写前端程序,那么我会去GitHub或者Google,通过关键字、语言找跟我项目类似的开源项目,然后看其中有没有自动化测试写得好的,找到了(例如:reactstrap、electron-react-boilerplate、kitematic)就照葫芦画瓢好了,因为都是真实项目,所以特别简单有效,建议你也可以试试。

    另外耐心一点,你也可以看到很多关于测试知识分享的技术文章,多看一看也有收获。

    2019-05-07
    2
  • 阿陆
    请教老师,我现在做的是嵌入式设备,要跟很多硬件外设打交道,这块的自动化测试和持续集成有什么好的建议吗?我看到文章中大多提到的都是互联网相关的方法和工具

    作者回复: 我对嵌入式和硬件不懂,没有这方面的经验。不过软件和硬件的开发,都属于工程开发,这里面其实有很多道理是相通的。

    吴军老师写过一篇很好的文章:《把事情做好的三条边》,里面举了莱特兄弟发明飞机的例子,莱特兄弟在试飞之前,打造了一个风洞,进行了上千次的风洞试验,这样可以不需要上天就可以对飞机进行测试。而同时期的很多飞行发明家,自己打造了一个飞机就上天,很多都摔死了。

    自动化测试其实有些类似于风洞试验,相对于手工测试,可以“低成本”、“高效率”的对产品进行反复的测试和验证,每次提交代码就可以自动运行测试,马上收到反馈。

    从软件的自动化测试和飞机的风洞试验,可以找到一些可以借鉴的点:

    1. 找到了一条低成本测试的方式
    风洞试验,可以降低飞行测试的成本,不必付出生命代价就可以测试结果;
    软件的自动化测试,刚开始写的时候是要付出一些成本的,但磨刀不误砍柴工,运行次数越多成本越低。

    嵌入式系统是不是也可以找到一条低成本、模拟的、反复测试的方式?

    2. 可以模块化的测试
    软件的自动化测试,主要有单元测试、集成测试、端对端测试这三种自动化测试类型。单元测试成本是最低效率最高的,而集成测试和端对端测试成本要高很多,所以通常单元测试最多,集成测试次之,端对端测试最少。

    我想莱特兄弟发明飞机飞机之前,在组装成整个飞机之前,对各个模块也是有单独的测试,而且测试的应该和自动化测试的比例也是类似。

    那么嵌入式系统的自动化测试,是否也可以分模块化的进行测试?让模块的测试占更大比例?

    3. 可以即时得到反馈
    软件的自动化测试,尤其是结合CI(持续集成),可以即时得到反馈。每次提交代码修改,就会出发自动化测试任务,这样一旦有导致自动化测试失败的代码,能即时发现。
    风洞试验也是类似的,飞机不用上天,通过风洞的测试,马上就能得到反馈。

    嵌入式系统的自动化测试,是否也可以做到即时反馈?在作出修改后,能否马上得到测试结果的反馈?

    以上三点是我认为可以从软件自动化测试借鉴的地方,希望有所帮助!

    2019-10-14
    1
  • 小老鼠
    1,小型、中型、大型自动化测试是不是对应单元、集成、系统测试。2、现在测试金字塔模型已经被防锤模型替代了,GUI自动化减少,Interface自动化测试增多。3、有没有必要小、中、大型自动化测试覆盖率均达到100%?4、开头你们前端改造项目自动化测试釆用GUI还是Interface?若是GUI,有多少个测试用例,每个测试用例执行时间有多长,所有测试用例执行有多长。若是Interface ,如何测试前端?5、前端有没有自动化测试框架?

    作者回复: 1. 一般来说是这么对应的
    3. 没有必要达到100%,这样做成本太高,需要有一个平衡和取舍
    4. 我们项目集成测试和单元测试都有。
    我们前端项目基于React开发的,所以接口的测试基于React的单元测试接口。
    各有几百个测试用例。
    整个测试单元测试很快,一分钟不到,集成测试要长一点,5-10分钟。
    5. 前端框架都有测试框架,比如React/Vue都有单元测试框架,可以查阅其文档

    2019-09-24
    1
  • 探索无止境
    老师你好,各种类型的测试覆盖率你们一般采用什么指标?个人感觉在理想的情况下最好是做到百分百覆盖率

    作者回复: 100%覆盖这个我觉得可以作为一种理想追求,但是没必要追求极致,还是要在进度和质量之间有个平衡比较好,毕竟进度也很重要。

    另外对于前端业务,我更重视集成测试的覆盖,对于主要业务场景集成测试覆盖到位后,单元测试也就有比较多的覆盖,相对性价比更高,然后再逐步补充单元测试的覆盖率。

    2019-05-06
    1
  • yellowcloud
    宝玉老师,我们现在使用的框架是.net core,语言是C#,用其进行后端开发。能否推荐一下好的自动化测试框架。我根据您的检索方法语言+自动化测试框架找到的是RedwoodHQ,不知道它在实际使用中是否可行。

    作者回复: 如果是单元测试,.Net Core应该自带了,例如:《.NET Core 和 .NET Standard 单元测试最佳做法》https://docs.microsoft.com/zh-cn/dotnet/core/testing/unit-testing-best-practices

    你可以换一下关键字:".Net core unit testing", ".Net core integration tests"。

    这一篇《Integration tests in ASP.NET Core》https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests 写的很详细,还有实例。

    另外不知道你的具体是什么类型项目,Web还是Winform?

    2019-05-05
    1
  • hua168
    看到bug我又想起了网站安全,宝哥,像我们中小公司网站安全也是运维负责的
    一般网站安全怎做呀?如果服务器linux(centos)被入侵一般怎么查别人是怎么入侵的?
    宝哥您了解这方面的吗?小公司运维真是什么都做,打杂的~~

    作者回复: 网站安全会在后面一篇有详细讲。如果你现在遇到了入侵,你可以查一下操作的日志看看,看登录的IP、账号,看是不是有什么线索。

    2019-05-05
    1
  • 丿淡忘
    宝玉老师,我想问一下,针对桌面开发的界面自动化测试一般是怎么进行的

    作者回复: 可以试试 Appnium或者Ranorex。不过我没直接用过,不好评价是不是适合你,建议你先试试看。

    2019-05-04
    1
  • 起而行
    老师,持续集成怎么理解呢,我看知乎上说就是团队成员在一天内多次进行编译,发布或自动化测试

    作者回复: 狭义的持续集成不包括发布,主要指集成,持续的(每次提交代码变更都触发,频繁的提交)对代码进行集成(合并到主干),但集成前要确保自动化测试通过。

    广义的持续集成还包括部署,也就是集成后自动部署测试环境(持续交付)或者生产环境(持续部署)。

    在《26 | 持续交付:如何做到随时发布新版本到生产环境?》这一篇里面有详细介绍。

    2019-05-04
    1
  • hua168
    宝哥,我想问一下:
    1.开发哪些测试需要自己写的呀, “测试驱动开发”的概念,开发应该要会写测试吧?
      到底要求会写哪些测试?
    2.现中小公司都没有自动化测试工程师,写好测试手工检查的多,怎搞?
      开发学一点selenium3自动化测试之类会不会好点?
    3.单元测试是不是数据越简单越好,最好不使用数据库,在dao层组或map
    4.集成测试和大型测试用数据库则比较好,对吗?

    作者回复: 1. 文章中的小型测试和中型测试都应该是开发来写的。大型测试一般是测试开发工程师来写,也可以开发写。
    2. 这个必须要去学习的,
    3. 单元测试不能使用真实数据库,必须要模拟数据访问的,否则速度太慢也不稳定
    4. 集成测试一般用本机的数据库,或者也可以模拟数据。大型测试肯定用真实数据库的。

    2019-05-04
    1
  • miketan
    我们项目中主要是通过单元测试和集成测试来做自动化测试。单元测试主要做最外层的代码覆盖率要求。

    作者回复: 👍感谢分享

    2019-05-05
收起评论
15
返回
顶部