手工测试的问题
手工操作点点点借助的是人脑的反应和聪明，为什么不用手点了呢？手会酸，脑子会累，会占据太多的时间。想一想为什么会学习自动化测试。我们都希望通过工具来解放我们的双手，大脑，眼睛。
为什么用自动化
自动化是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。
平时我们会接触很多的自动化工具，比如按键精灵自动加血加蓝，搜索引擎，以前找一篇文章要把所有的资料摊开，一页一页翻，现在直接列出来了。可以再编辑器里实现以下搜索。
使用了自动化测试软件以后还是觉得不够，因为有的测试需求比较复杂，包含几十上百个步骤，用软件测不出来，就算能实现也比较麻烦，这时候我们面临的问题就是：用软件定制化不高，对于复杂场景实现不了。
代码的定制性就非常高了，想实现什么功能可以自己去实现。到后面实现完以后那些不会编程的测试人员怎么办？不能让他们闲着，就要编写测试平台，让不太会代码的同学也可以轻松使用。
自动化测试是通过使用机器系统来鉴定软件的正确性、完整性、安全性和质量。我们的目标是通过编写代码，能够代替我们日常用手去操作的测试工作，要求你尽可能的掌握编程语言和相关代码库的使用和实现原理。
选择合适的测试方式
自动化测试的目的不是完全取代手工测试，而是解放手工，让人不再每天重复做枯燥的点点点工作，把这些枯燥的工作交给自动化程序执行，人则转而去做更有创造性的工作。
在一个项目当中的测试工作主要分为以下几类： 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端做测试有两个问题，第一是前端界面变化快，第二是执行的效率低。通过现有的技术手段只能做到优化，却不能避免这两个问题， 在做自动化测试的时候要尤其注意。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
