为什么用Selenium做自动化测试

1,750 阅读9分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第1天,点击查看活动详情>>

手工测试的问题

手工操作点点点借助的是人脑的反应和聪明,为什么不用手点了呢?手会酸,脑子会累,会占据太多的时间。想一想为什么会学习自动化测试。我们都希望通过工具来解放我们的双手,大脑,眼睛。

为什么用自动化

自动化是指机器设备、系统或过程(生产、管理过程)在没有人或较少人的直接参与下,按照人的要求,经过自动检测、信息处理、分析判断、操纵控制,实现预期的目标的过程。

平时我们会接触很多的自动化工具,比如按键精灵自动加血加蓝,搜索引擎,以前找一篇文章要把所有的资料摊开,一页一页翻,现在直接列出来了。可以再编辑器里实现以下搜索。

使用了自动化测试软件以后还是觉得不够,因为有的测试需求比较复杂,包含几十上百个步骤,用软件测不出来,就算能实现也比较麻烦,这时候我们面临的问题就是:用软件定制化不高,对于复杂场景实现不了。

代码的定制性就非常高了,想实现什么功能可以自己去实现。到后面实现完以后那些不会编程的测试人员怎么办?不能让他们闲着,就要编写测试平台,让不太会代码的同学也可以轻松使用。

自动化测试是通过使用机器系统来鉴定软件的正确性、完整性、安全性和质量。我们的目标是通过编写代码,能够代替我们日常用手去操作的测试工作,要求你尽可能的掌握编程语言和相关代码库的使用和实现原理。

这些都非常容易成为面试中的常考问题。这些高频问题我平时也比较喜欢收集,有一线大厂一些大佬的面试心得,也有一些刚入行时候的面试题,特意整理了一下,有需要的评论区回复 【面试必过】或者关注我微信公众号【九柄】,我发给你。 在这里插入图片描述

选择合适的测试方式

自动化测试的目的不是完全取代手工测试,而是解放手工,让人不再每天重复做枯燥的点点点工作,把这些枯燥的工作交给自动化程序执行,人则转而去做更有创造性的工作。

在一个项目当中的测试工作主要分为以下几类: 1、探索式的手工测试 2、依赖脚本的手工测试 3、生成脚本的测试工具 4、代码方式 大多数情况下,都是这四种方式的组合,但是我们如何分配这 4 种方式呢?有没有一种模式让我们合理的安排这四种方式?

什么时候引入自动化测试

自动化测试不是凭空来的,它需要建立在手工测试的基础上。通常来说,在引入自动化测试之前,测试团队已经实施过几轮手工测试。

这种手工测试可以用探索式的方式,更多的是依赖脚本的手工测试。我们会根据用例设计方法设计每一个用例的操作脚本,然后按照脚本执行每个用例。

当用例越来越多,而产品迭代周期不变的情况下,总有一天,现有团队无法在上线之前把所有的用例执行完,我们需要更有效率的用例执行方式。 同时,测试人员总是需要重复执行同样的用例,时间长了会产生疲惫感,我们也会想办法把一些枯燥的工作交给自动化程序去执行。

那么,什么时候引入自动化测试呢?其实就是当测试团队已经很难应付这么多用例的情况下,通过挑选一些适合交给自动化程序执行的用例出来,从而过渡到自动化测试阶段。

以Jmeter为代表的测试工具

jmeter 在测试界有很高的地位,他的表现稳定,扩展能力强,可以支持接口测试、网页测试,性能测试等多方位的测试,而且操作也不是很复杂。

因此,很多测试团队在用代码去搭建测试框架前,一般都会先尝试用 Jmeter 来做自动化测试。具体的操作方式在这里我不展开讲了,感兴趣的私聊吧。

如果是很小型的测试团队,没有太多技术储备去做代码维护,用测试框架或者现有平台是比较合适的方式。

但是这种方式对于测试从业人员不太友好,比如换了一家公司,这家公司不在用之前的工具了,那在找工作的时候会遇到比较大的麻烦。在技术领域,每天都有新的工具冒出来,挑战现有工具的市场地位,每家公司倾向的技术选型都不一样,要找到一种通用的方式来应对面试和招聘,是测试人员面临的难题。

我个人的想法是,熟练掌握一两种市场占有率非常高的测试工具,以后遇到了新工具,可以简单学一下,除非是现有公司需要,否则不用花太多心思在市场占有率很低的新奇工具上,他们可能会提供很多看起来很厉害的功能,可以学习他们的思路,但是很有可能在公司里用不到。

编程能力既重要又不重要

编程,可以说是解决自动化测试的万金油方式。编程提供的灵活性,是所有现有工具都无法比拟的,只要技术允许,你几乎可以通过编程实现任何的测试工具,覆盖任何的测试场景。

那为什么又说编程又不重要呢?因为无论通过什么方式,自动化的目的都是为了解放人力,如果一个测试团队花了很多精力编程,覆盖多种测试场景,投入大量的人力物力和金钱,但是效果和之前没什么两样,那反而是对人才的束缚,而不是解放人力。

在编程领域,你可以使用已有的框架,站在巨人的肩膀上,实现自动化测试,比如可以用 selenium 实现网页自动化测试。 如果有一天 Selenium 不再流行,你可以把它的实现思路快速的转移到其他的框架中,只要有编程能力,一般都不要慌。

为什么是Selenium

目前,在web自动化测试中,用得较多的主要有以下框架:

  • Selenium
  • Cypress
  • Playwright
  • Puppeter 这些框架或者工具我都接触过,机会合适,我都会去编写具体的操作笔记。 虽然有很多的挑战者,但是Selenium还是用得最多的,他的技术架构也在不停的演化。有的人说selenium过时了,他们说的都是对的,它确实有点老,不过如果让我选型,我还是会优先选择 selenium。

在学它之前,只需要问几个问题:

  • Selenium 能解决 web 自动化测试问题吗?
  • Selenium 容易学吗?
  • Selenium 资料丰富吗?
  • Selenium 方便迁移和扩展吗?
  • Selenium 方便团队协作吗?

我都能得到肯定的答案。当然它也有些缺点,但这些缺点现在都无伤大雅,Selenium 目前的缺点:

  • 截图、录制、回溯不方便
  • 没有流量拦截
  • 没有 mock
  • 在反爬中会被识别,当然其他工具也是。

无论如何,Selenium 只是一个自动化辅助工具,需要对他有清晰的认识: selenium只是一个浏览器自动化工具需要结合测试工具使用。 selenium 无法提高你的测试水平 帮助你快速定位bug

没有最好的技术,只有合适的技术

我大概列举了一下平时技术选型时需要考虑的问题,一个技术,是不是新,是不是好看当然可以做为参考指标,不过也可以看点更实际的: 是否能解决你的问题

  • 跑 Demo
  • 环境搭建
  • 学习成本低
  • 友好的文档
  • 丰富的教程
  • 完善的解决方案
  • 大量的案例
  • 完善的生态
  • 社区活跃
  • 更新活跃
  • API成熟
  • 企业很愿意用,大量招聘岗位
  • 方便迁移和扩展
  • 支持多平台
  • 支持多语言
  • 是否开源
  • 方便团队协作
  • 手工测试团队
  • 开发团队
  • 你能接受他的缺点吗
  • 没有十全十美的技术
  • 没有最好的测试工具,没有最好的测试语言
  • 只有适合的场景

web自动化测试效率不高

对整个web端进行自动化测试主要的目的是更贴近用户使用场景,因为界面是用户直接和软件接触的载体。用户几乎所有的操作都是通过 ui 实现的,因此 ui 测试最能模拟实际的用户使用情况,进行 ui 测试需要站在用户的立场,考虑用户的痛点,模拟用户的行为进行操作。 用户使用产品的功能,是想获得某种能力,因此应该通过功用设计测试用例,而不是单纯的从产品特性和说明来考虑。

web端做测试有两个问题,第一是前端界面变化快,第二是执行的效率低。通过现有的技术手段只能做到优化,却不能避免这两个问题, 在做自动化测试的时候要尤其注意。