软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13294 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

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

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

什么是单元测试?

在正式开始今天的话题之前,我先给你分享一个工厂生产电视机的例子。
工厂首先会将各种电子元器件按照图纸组装在一起构成各个功能电路板,比如供电板、音视频解码板、射频接收板等,然后再将这些电路板组装起来构成一个完整的电视机。
如果一切顺利,接通电源后,你就可以开始观看电视节目了。但是很不幸,大多数情况下组装完成的电视机根本无法开机,这时你就需要把电视机拆开,然后逐个模块排查问题。
假设你发现是供电板的供电电压不足,那你就要继续逐级排查组成供电板的各个电子元器件,最终你可能发现罪魁祸首是一个电容的故障。这时,为了定位到这个问题,你已经花费了大量的时间和精力。
那在后续的生产中,如何才能避免类似的问题呢?
你可能立即就会想到,为什么不在组装前,就先测试每个要用到的电子元器件呢?这样你就可以先排除有问题的元器件,最大程度地防止组装完成后逐级排查问题的事情发生。
实践也证明,这的确是一个行之有效的好办法。
如果把电视机的生产、测试和软件的开发、测试进行类比,你可以发现:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(54)

  • 小志
    我待过一些中国的互联网公司,也问过一些创业公司,进行单测的不多。我也一直在想没有单测,但是整体的质量也还能“说的过去”的原因是什么。首先没有单测的主要原因还是和中国互联网的现状有关,中国的互联网本质是商业公司,在中国激烈的竞争环境下,业务的快速发展导致需求的快速上线是一个常态。这也导致了无论是产品还是开发经理,都是以支撑业务为kpi,其次才是质量。所以单测是一件不能直接体现到kpi上的隐形需求,项目排期一般也没有单测的时间。那整体质量还过的去的原因其实也是因为互联网对质量的容忍度,允许出现一些非严重的问题,需要测试人员或qa通过checklist、集成测试工具或方法的提升能发现核心问题就够了,甚至通过监控和用户反馈紧急召回就够了。从这个方面也能说明中国的功能测试短期内不会像google一样完全被代替掉,还是会存在,根本是研发底层对质量的要求没有变化。不过不可否认的是,测试的一个趋势是写以提高质量的代码为目标,或许研发测试完全一体化之后,测试来写单测也不是一件不可能的事
    2018-07-04
    1
    43
  • 口水窝
    同在小的创业公司,根本不用问,没做单元测试,最近在学茹老师的课程,java基础知识,有研发看到,竟然说我一个测试干嘛去学开发的东西,我无语,我只能按照自己内心的想法去学习,知道自己想要什么,然后去努力,坚持打卡,加油!
    2019-02-26
    15
  • Cynthia🌸
    之前的一家公司曾经比较重视单元测试,当时具体单元测试代码是开发写的,对于测试部门的我而言,只是在CI这块,负责跑出各项目的单元测试结果后汇总成报告查看。具体单元测试的质量是由开发进行把控和审核。
    再后来组织有些变动,不再重视单元测试,便流于形式,开发可能就写个假的代码保证跑出的报告好看,实际的单元测试本身则被忽视了……
    目前就职的公司则是没有整体规划过单元测试这块,所以也是困惑怎么推动这件事情。
    2018-07-04
    14
  • Jump
    我现在的公司是比较重视单元测试的,也有专门也单测的人,我就是其中一个,我们单侧内容主要分两部分,一是基于mock的真正意义上的单元测试,这部分主要验证业务逻辑,二是与数据库的集成,应该算是集成测试,主要验证数据方面的一致性。另外,看评论有一位说在推行c#的单元测试,我们这边就是用的c#,框架之前用的Nunit,由于数据隔离性不是特别好,后来又换成了Xunit框架,Mock框架是moq,或许可以和那位哥们讨论一下,共同提高😊
    2018-08-17
    8
  • 黑米
    我们开发了个单元测试框架,测试人员写用例只要修改yaml配置文件即可完成单元测试,比以前方便多了。
    2018-11-05
    6
  • 海罗沃德
    在Accenture时候单元测试行覆盖率要达到99%,分支覆盖率要达到90%,仅一些exception分支可以不用覆盖,并且每个测试用例前面要注释好这个case测的是什么方法,输入什么输出什么,预计结果是什么等以便code review时可以快速的知道这段代码是做什么的,甚至一些大功能还要带上use case的id方便追溯原始需求,在测数据持久化层测试要通过内存数据库把CRUD流程都测出来

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

    2018-07-05
    6
  • BADBOY
    老师,我的学习方向是Python接口自动化,JMeTer,LR,是不是在学做性能之前就得先去学Java呢,在这学习方向中有什么建议么!谢谢
    2018-07-04
    6
  • sylan215
    十分赞同茹老师的这个观点「并不是所有的代码都要进行单元测试,通常只有底层模块或者核心模块的测试中才会采用单元测试。」,这一定是首要前提,不然在落实的时候会发现,被测函数可能会完全被 Mock 代码取代了。

    如果要做单元测试,那么对开发代码的要求也会更高,至少开发在代码分层上一定要做好,不然光去甄别哪些可以做单元测试哪些不能做,都需要花费很多的时间。

    单元测试和接口函数测试要区分开,我们有个项目,本来是以单元测试的名义开展的,结果搞出来的却是接口函数测试,比如 windows 端的文件导出函数的测试,这样就不需要 Mock 代码了,而相对导出函数,又增加了内部函数的覆盖,但是不管怎样,这个只能算是接口测试了,也就是说,并不是所有针对代码级别的测试,都叫做单元测试。

    最后,如果不是开发自己做单元测试的话,一定要考虑投入产出比的了。

    以上,望沟通交流,公众号「sylan215」
    2018-08-16
    5
  • Geek_84a77e
    不太理解老师说的输入数据那部分
    只知道被测函数的参数进行设计
    不知道如何针对函数的成员变量等进行设计用例?

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

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

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

    2019-01-21
    3
  • Xhavit🍭
    倒是定义一下mock代码啊?都不定义然后就对比,一脸懵逼。。。。
    2018-12-19
    2
  • 自动化测试集应该是一把可信的、灵活的尺子。所以测试集不宜过大,应能支持在几个小时内给出稳定可信结果。测试集的大小应考虑以下几个方面:以时间窗口为首要敏感因素,然后考虑覆盖功能的重要程度,测试执行的稳定性。

    作者回复: 很棒的总结

    2019-05-09
    1
  • 谭鹏
    公司的测试 都是靠开发人员自测和测试人员测试,测试方法也是手动点击的这种笨方法,想写打哪元测试,同事们都说 代价太大,最后也没执行起来。感觉测试集成也是一套系统,光靠单个方法和技术点没有完整的系统 感觉就像是增加了工作量
    2019-02-27
    1
  • zhangbitao
    我在开发过程中会写单测,但是耦合性一直是个大问题,有时候想到很多测试用例,但是模拟起来很麻烦就放弃了
    2018-08-31
    1
  • coco
    测试review ut也许不能提出很多意见,而且要开发来讲解一下,但是有两个好处1.防止假测试用例,也就是不做验证的用例,2.在进行上层用例的设计时可以知道哪些已经在ut层覆盖了,避免重复劳动
    2018-07-12
    1
  • Elsa
    我所在的是敏捷开发团队,QA需要review UT,那么我想知道QA 怎样review UT才更有价值呢?现在基本是根据业务需求去review UT的case是否有遗漏

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

    2018-07-12
    1
  • o0oi1i
    感觉小公司项目开发的同时写测试代码工作量不比写项目小,而且时间人员也不够用,老师请问怎么破这种情况?

    作者回复: 要真正做好单元测试,UT的代码工作量是不低,所以还是要看项目的性质来决定要不要UT,要的话需要做到什么程度,往往前端的代码做ut的相对比较少,后端代码尤其是比较核心和底层的,都会有ut的要求。

    2018-07-06
    1
  • 卫宣安
    今年刚在团队推行单元测试,阅读过《单元测试的艺术2》,觉得非常受益,也强烈推荐其他同学阅读。我认为单元测试不仅仅是为了测试,也能让你写出结构更好,质量更佳的逻辑代码。在推行的这几个月中,也只能以新代码进行试水,遗留代码完全没有勇气进行。而且目前团队成员在接受程度上还远没有达到得心应手,也比较容易出现抵触情绪,我也正在思考如何才能更有效的推广。
    另外,我们使用的C#语言,NUnit测试框架+JustMock Mock框架,从技术选型上我觉得还是比较好用的。
    非常期待后续的课程,也非常想认识更多的在单元测试上想尝试亦或是有所心得的同学共同交流
    2018-07-04
    1
  • 产品助理
    项目中推行单元测试中,您提及的问题如何解决,后面会有介绍吗?

    如单元函数中大部分都是对数据的CURD操作,如何获取有效数据,又如何防止脏数据。都很让人头痛。

    期待后续文章,多谢!
    2018-07-04
    1
  • 永不放弃
    老师,后面会有实战部分吗?

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

    2018-07-04
    1
收起评论
54
返回
顶部