软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13425 人已学习
课程目录
已完结 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讲
登录|注册

04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?

茹炳晟 2018-07-06
在上一篇文章中,我为你介绍了什么是单元测试,以及如何做好单元测试,今天我来跟你聊聊什么是自动化测试,为什么要做自动化测试,以及什么样的项目适合做自动化测试。

什么是自动化测试?

不管你是刚入行的小白,还是已经在做软件测试的工作,相信你一定听说过或者接触过自动化测试。那么,自动化测试到底是什么意思呢?
顾名思义,自动化测试是,把人对软件的测试行为转化为由机器执行测试行为的一种实践,对于最常见的 GUI 自动化测试来讲,就是由自动化测试工具模拟之前需要人工在软件界面上的各种操作,并且自动验证其结果是否符合预期。
你是不是有点小激动?这似乎开启了用机器代替重复手工劳动的自动化时代,你可以从简单重复劳动中解放出来了。但现实呢?
自动化测试的本质是先写一段代码,然后去测试另一段代码,所以实现自动化测试用例本身属于开发工作,需要投入大量的时间和精力,并且已经开发完成的用例还必须随着被测对象的改变而不断更新,你还需要为此付出维护测试用例的成本。
当你发现自动化测试用例的维护成本高于其节省的测试成本时,自动化测试就失去了价值与意义,你也就需要在是否使用自动化测试上权衡取舍了。

为什么需要自动化测试?

为了让你更好地理解自动化测试的价值,即为什么需要自动化测试,我先来跟你聊聊自动化测试通常有哪些优势:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(61)

  • 龍蝦
    手工测试还涉及到一个人性的问题。
    某些手工测试团队考核的标准就是找到的bug个数,个数越多绩效越好。而开发人员开发的代码,在一些问题上算不算bug有不同的见解。然后就开始扯皮了。

    作者回复: 以缺陷数量来衡量测试的绩效是不可取的,而且还会激化测试和开发之间的矛盾。

    2018-07-06
    1
    24
  • Cynthia🌸
    实际项目中使用自动化的部分,接触过gui自动化测试,接口测试,性能测试。
    执行次数肯定是远大于5次的,毕竟开发和维护成本都要算进去,收益远超手工测试时才会考虑去做。除非是“面子工程”,用来应付某些场合。
    不过还是很好奇作者的“5次”这样一个分水岭是怎么来的,是否依据经验总结得来。

    作者回复: 5次完全完全是经验值,因为这个主要取决于自动化测试的开发成本,如果你有很好的框架,自动化用例开发的成本比较低,那么这个值就会偏小,如果有你的测试框架很低效,那么开发自动化用例的代价就很大,那么这个值自然就好大

    2018-07-06
    16
  • 麦西尼
    在我之前参与的一个敏捷团队中,对自动化测试理解可能有些不一样,自动化测试更多的是被认为是保护已有软件功能的一张安全网,由QA和dev共同开发,和软件系统本身的功能代码一起成长,每当有新功能代码commit进主线的时候就会触发,以检测新代码是否会破坏原有功能。

    作者回复: 你说的是正确的,commit之后通常会自动触发静态代码扫描和单元测试,如果两周都通过后、通常会执行自动部署,然后还会自动执行smoke和e2e测试,这些都是自动化的范畴,后面的一篇文章会专门来讨论这个

    2018-07-06
    15
  • Mr.Z
    现在好多公司完全把业务测试和测试开发分离开来,导致开发自动化的人不理解业务,业务用自动化工具的觉得工具不够符合业务,这样往往就是自动化成效不高,所以我一直建议测试开发要去做业务,业务要去理解怎么利用代码和工具提高效率.

    作者回复: 是的,你说的这个是很多公司都有的典型问题,懂自动化的不懂业务,懂业务的不懂自动化,必须要让两者能够有机的结合,否则效率很难提高,之前有提BDD其实就是为了解决这个问题,但实际落地过程中大量的mapping又引入了很多新问题

    2018-07-06
    9
  • 木主人
    自动化测试如果由自动化测试架构工程师来牵头实现,辅以业务功能的开发或测试人员构成核心团队,这样的企业级自动化测试的成本和收益应该是线性回归的:1.测试架构师负责企业级核心代码的复用设计及实现,2.项目团队内负责功能共用模块的抽取,3.两者结合建立自动化测试数据池仓库的建立,4.结合项目具体情况做自动化代码实现的二次设计。

    作者回复: 非常棒的分享,我们以前也尝试过这种模式,效果还是不错的

    2018-07-11
    7
  • 浮生凉
    我们产品迭代很快(一周一个版本)连测试用例都没办法写全,只能写写测试点,更不要提自动化了,每次刚开个头就没有然后了

    作者回复: 这种短期项目就不太适合自动化测试,对于这类项目的测试重点可以放在如何设计有针对性的测试用例上面,建议可以开展手工探索式测试

    2018-07-06
    7
  • Tomandy
    自动化的出发点是提高效率和质量监控。盲目追求所谓的“全自动化”往往得不偿失,应根据项目实际情况做出选择。可退而求其次选择“半自动化”测试,辅助手工测试来提升效率,比如开发小工具来做资源的整合(脚本执行结果自动同步案例管理系统及缺陷系统、批量执行案例生成可视化报告、表断言检查、依赖开源框架搭建性能测试平台等)。

    作者回复: 说得非常对,👍

    2018-07-06
    6
  • 棉花糖family
    老师,您好!我是一名刚毕业的学生,从事软件测试有快两个月,在公司做的是功能测试,最近看第四讲到第六讲都很懵,不知道老师能否给我些建议,如何更好的去了解消化这些知识!

    作者回复: 这应该不是你一个人会有这种感觉,因为第4-6讲不是基于黑盒来谈测试的,而是从软件实现的内部,即从白盒的视角来谈测试,所以需要你具有一定的代码能力,至少能够明白一门高级语言。但是你也不用太担心,因为基于代码的测试我们后面还会有专门的篇幅,那边我会以更多的实例来讲解,希望能够对你有帮助

    2018-07-11
    5
  • 王征
    目前项目中落地的重点还是接口测试的自动化,单元测试推不动,UI自动化耗时耗力效果也不好,项目更新太快,前端页面频繁变更,不适合做UI的自动化测试

    作者回复: 你说的是很典型的案例,但是还是建议有最基本的GUI测试当作smoke来用,保证产品基本功能的可用性

    2018-07-06
    5
  • 秋荣
    我觉得比较难的部分在于如何使数据准备自动化,尤其当需要的业务场景比较多的时候

    作者回复: 是的,非常对,尤其是数据参数又很多的时候,这个问题会更突出,后面文章我会专门来讲这块

    2018-07-09
    3
  • gevin
    我们这里现在是要求做api开发的后台,都要对自己的功能写测试用例,实现自动化测试,主要是出于对自己的开发功能的保护和负责,并未把自动化测试划给测试的同事来做

    作者回复: 这个就是目前比较流行的做法,最理想的情况是工程效能团队可以提供更好的工具去支持开发自己做测试,比如提供方便的测试数据准备工具,测试执行服务等等

    2018-07-06
    3
  • ThUG
    我做自动化测试有8年了,从通信到传感器到现在的车联网。通信领域就非常适合做自动化,无非就是造包解包,各种场景都是可以模拟的,可以说自动化覆盖率基本达到百分百
    2018-07-29
    2
  • ll
    测试数据的自动化在自动化测试的维护成本中有着举足轻重的作用,我认为测试数据的多样化和自动化也会给自动化测试带来了探索性和智能化的契机……

    作者回复: 非常正确👍,所以我们后续会专门来讲测试数据

    2018-07-12
    2
  • 郭婷
    我想说尽管是软件产品,它在不断发展过程中,也有项目迭代非常忙的时候,比如测试时间只有不到5天,质量的方针仍然定为接口测试为主,导致最终线上bug率很高,但是至今TL仍意识不到这个问题,规定一个月要写20个接口的自动化测试用例(补齐老用例),并把此列入绩效考评,可这是按量来的事么,测试人员不去看代码实现逻辑,简单的通过入参返回值去写用例,覆盖率难以提升,最终只能收效甚微,变成面子工程。

    作者回复: 一定不是为了测试而去测试,测试的根本在于寻求最高效的方法去发现尽可能多的问题,如果单单以用例数量做为衡量标准一定会本末倒置,用例不在于多,而在于针对性和全面性

    2018-07-06
    2
  • hyeebeen
    同意自动化测试是安全网的概念,自动化测试的价值点主要会是在回归效率,还有一些复杂场景模拟上,自动化测试脚本的架构设计也会影响维护效率。CI和CD里面,自动化测试、性能自动化和安全自动化(扫描为主)都是重要应用,单元测试也是自动化测试的一种,还有契约测试等。
    结合用例和脚本自动生成计划,GUI和API都可以减少编写成本,不过个人对于智能技术在这里会是一个很重要的应用场景,具体怎么落地还没想明白,但大家可以多沟通研究下。

    作者回复: 你说的很在点子上,后面的一篇文章就会专门讨论这个话题,后续我也还会在适当的时候来谈“如何自动化你的自动化测试”

    2018-07-06
    2
  • Dehom
    赞同您的说法,软件测试的目的是发现问题,如果自动化测试维护成本高于它带来的测试效率和价值,就失去了本身的意义。测试工程师热衷于自动化测试学习很重要的一个原因也是适应新的工作竞争吧

    作者回复: 所以有些时候就需要去平衡两者之间的关系

    2018-07-06
    2
  • Cynthia🌸
    对了,个人理解,CI/CD应该也算自动化测试的范畴吧,也是应用了自动化技术,提高手工效率的,而且非常实用。

    作者回复: CI/CD应该属于devops的范畴,CI/CD往往是自动化测试的发起者,关于广义的我自动化测试,在下一篇文章中我会详细来展开

    2018-07-06
    2
  • 口水窝
    现在想来也就是待得第一家公司做过稳定性测试,属于一点自动化测试的范畴。后面的基本就是接口测试比较多了,且执行次数都没超过5次的,得不偿失,最后腰斩的很多,且流于形式。
        现在互联网迭代中周期短,研发测试配比高,很多小的创业公司对于测试人员可有可无的思想阶段。但是从长远看,大的公司,必定把质量放在第一位的,所以,做一个全栈性的测试人员,懂代码、懂沟通,能够全面把控质量关,是我们每一个测试人员努力的方向!
    2019-02-28
    1
  • CY_suncheng
    测试工程师通常会非常热衷于学习使用自动化测试技术,以至于他们...
    这点有体会
    2019-02-23
    1
  • sylan215
    点点到位,拳拳到肉。

    非常赞同茹老师的分析,说说我们项目的现状:
    1.一直有推进自动化用例覆盖率,但是经常改动的部分需要自动化用例频繁同步更新,不经常改动的部分,自动化的必要性又不大;
    2.GUI 改动多,但是实施难度大,就好比茹老师提到的图形验证码的例子;
    3.测试开发和业务测试是分开的,导致懂业务的不懂实现,懂实现的不懂业务;

    目前我们的解决办法:
    1.优先考虑 P1 优先级的用例覆盖,以及需要经常回归的功能点的自动化用例覆盖;
    2.开发提供必要的支持,提供特殊版本文件辅助自动化实现;
    3.测试开发负责架构实现,并设计好必要的分层,业务测试负责自动化函数需求的提出和调用;

    以上,欢迎沟通交流。
    2019-02-12
    1
收起评论
61
返回
顶部