为什么用Selenium做自动化测试

为什么用Selenium做自动化测试

​

活动地址：​​天学习挑战赛​​

手工测试的问题

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

为什么用自动化

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

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

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

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

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

选择合适的测试方式

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

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

什么时候引入自动化测试

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

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

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

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

以Jmeter为代表的测试工具

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

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

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

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

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

编程能力既重要又不重要

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

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

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

为什么是Selenium

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

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

在学它之前，只需要问几个问题：

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

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

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

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

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

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

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

web自动化测试效率不高

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。