什么是自动化测试？
- 以程序测试程序
- 以代码代替思维
- 以运行脚本代替手工测试
- 将自动化工具和技术应用到软件测试中
- 自动化测试包括一切通过工具（程序）的方式来代替或辅助手工测试的行为，比如接口测试（postman），性能测试（LR、Jmeter），Python 脚本
- 总结：通过工具或编写脚本模拟手工测试的过程，然后通过重复运行脚本来执行测试用例，从而替代人工功能测试
自动化测试的目的？作用？优势？
宗旨
为了更高的质量+更高的效率
降低成本
节省了人力、物力、时间、硬件资源
提早发现问题
- 自动化测试可以让测试左移，更早介入介入
- 有助于在软件开发生命周期的早期就发现问题，降低交付问题软件的风险
减少测试工作量，提升测试效率
- 花费一次编写脚本的时间，可以多次运行，减少测试时间同时还能提升测试速度
- 对于烦琐又要重复执行的测试用例（回归测试），可以使测试人员更专注于其他有意义的事情
- 可以 7*24 小时不间断进行自动化测试（无人值守）
一致性、重复性
- 每次自动化测试执行的步骤是一致的，不用担心手工测试时出现的误操作，若出现问题还可以迅速定位问题根源【一致性】
- 同一个脚本可以重复运行多次【重复性】
完成人工难以实现的测试手段
如性能测试，自动化测试可以模拟数百万级别的用户，若人工测试基本不可能
增加产品快速迭代发布的能力
- 现在大部分互联网企业都是敏捷开发，经常会1~2周就一个版本迭代，这个时候对测试的工作效率要求将非常高
- 如果一直纯手工测试的话，不仅要做新功能测试还得回归测试，时间成本将会非常大
- 假如将回归测试的部分做成自动化测试，每次迭代都将会节省大量的测试时间
推动 CI 和 DevOps
- 自动化测试是构建 CI（持续集成）或 DevOps 的基础
- 代码库每次新提交都将自动进行测试，开发可以优先修复导致构建失败或测试失败的错误，确保送测后主流程是没问题的
衡量质量指标
提供了测量产品代码质量指标的功能，比如代码覆盖率、技术债、代码语义检查
自动化测试的劣势？
- 适用范围较窄，一般只会在回归测试中使用
- 编写功能测试用例时间会远小于自动化测试用例
- 手工测试可以凭借人的想象力发现更多意想不到的缺陷，而工具是死的，无法自由发挥
- 对测试工程师的技术水平有较高要求，水平不足反而会增加测试时间成本
- 前期投入成本高、风险大
自动化测试可以完全代替手工测试吗？
- 不可以
- 自动化测试是对手工测试的一种补充，不可能完全替代
- 因为很多数据的正确性、界面是否美观、业务逻辑是否正确、体验是否流畅都离不开人工判断
自动化测试和手工测试的区别
回答上面三个问题的答案就差不多了，或从几个维度去回答
接口自动化测试有什么常见的自动化测试框架/工具？
postman、jmeter、Python+Request 编写脚本等等
UI 自动化测试
selenium、appium、cypress、airtest 等等
什么项目（功能）适合自动化测试？
项目改动小
- 测试脚本的稳定性决定了自动化测试的维护成本
- 如果项目改动频繁，测试人员也要根据改动的需求去修改测试脚本、测试用例，甚至需要修改底层的自动化测试测试框架
- 项目中某些模块比较稳定的，就可以针对这些模块进行自动化测试（如：登录、注册等等）
项目生命周期长
- 自动化测试从 0 到 1 的搭建需要相当长的时间来完成
- 包含了确定需求范围、自动化测试框架设计、编写自动化测试用例、调试、运行等工作
- 已经可以理解为这是一个测试软件的开发过程
- 唯有项目生命周期长才能支持这样一个过程
项目资源充足
- 自动化测试需要一个 team 来搭配完成，需要一帮人长期维护才能发挥自动化测试的价值
- 还得考虑公司的人力、物力（基础设施）能否支撑自动化测试长期运转
需要回归测试的产品项目
- 项目一般迭代版本时，都需要过一遍全流程的回归测试，这将占用大量的人力时间
- 若将回归测试转换为自动化测试，可以发挥自动化测试的最大优势
- 为的就是：验证新增的功能是否引入新的问题，而旧的缺陷是否修复成功
重复、机械性的动作
将繁琐又要重复执行的任务转换为自动化测试，可以节省大量人力成本，也是自动化测试的优势
需要频繁的进行测试
需要每天都进行测试的模块，可以将它们转换为自动化测试，7*24 小时都能不间断的运行
什么项目（功能）不适合自动化测试？
项目改动太大
- 项目三天一小改，半月一大改
- 有可能自动化测试用例/脚本刚写完，产品功能又发生变动了
- 这样维护成本将会极高而且没有任何收益
项目生命周期短
- 一个项目的生命周期只有一个月
- 而这一个月的时间中相当长的时间都要用来看需求文档、改需求文档、编写测试用例等
- 真正测试的时间并不多，此时还做自动化测试的话，可能用例都还没写完，项目就要 over 了
定制型项目（一次性）
为客户定制的项目
开发、运行环境、后期维护都是客户说了算，这样很明显也不适合做自动化测试
易用性测试
上面也说到了，比如：界面美观性、体验友好程度、产品的易用性，只能人为感官，自动化测试无法完成
业务逻辑复杂
业务很复杂的对象，开发实现都很头疼的那种业务，一堆逻辑关系、运算关系，手工测试已经很难了，就没必要自动化测试了
不常用的功能模块
很少用到的功能（低优先级），回归测试都不需要测的，做自动化测试就显得多余了
软件不稳定
软件本身不稳定的话，比如：偶发崩溃、卡死，这样会很影响自动化测试的执行
硬件（物理）交互
和物理设备交互的自动化测试很难完成，比如刷卡、刷脸、插拔等操作
插播一个知识点
- 影响自动化测试的投入产出比的最关键因素就是：变化
- 因为变化会导致需要修改自动化测试用例、脚本、框架，增加了维护成本
- 如何控制失败、降低维护成本是自动化测试能否可持续性运转下去的关键
- 当然，如果一个自动化测试用例永远都运行成功而没有失败也是没有意义的
你觉得做好自动化测试需要具备哪些能力？
- 编程开发能力
- 熟悉被测系统
- 掌握一套自动化测试框架/工具（原理、设计思路、基础使用、高级使用）
- 培养技术能力，锻炼自动化测试的思维
什么情况下可以开始自动化测试？
- 通常项目只有经历了完整的系统测试之后才算具备了引入自动化测试的条件
- 在敏捷开发中，某个核心模块已经开发完成后，就可以针对该模块开始自动化测试了
自动化测试的常见使用场景
- 回归测试：通过自动化测试快速验证是否引入新的缺陷，以及旧的缺陷是否修复成功
- 冒烟测试：在手工测试之前先跑一轮自动化测试，保证项目主流程没有问题
- 在需要生成大数据量的时候也可以用自动化测试
- 线上巡检：构建自动化测试每日巡检，用于每日实时监测线上产品主流程的稳定性和可用性
- 固化资产：通过自动化测试可固化测试资产（流程、工具、代码、文档）
- 建立测试与代码的覆盖联系：通过自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖
前四个比较重要
自动化测试的研究领域（知识点非面试题）
- 目前，自动化测试的研究领域主要集中在软件测试流程的自动化管理及动态测试的自动化（如单元测试、功能测试及性能测试方面）
- 在这两个领域，与手工测试相比，测试自动化的优势是明显的
- 首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模式的建立和开发，从而提高测试覆盖率（上述使用场景前四个）
- 其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其有意义（上述使用场景最后两个）
如果让你来从零主导，如何开展自动化测试？
前期准备
- 评估被测项目是否适合做自动化测试（什么样的项目、团队适合开展自动化测试？）
- 评估被测项目适合在哪些功能模块做自动化测试（什么样的功能模块适合开展自动化测试？）
- 确定使用何种测试工具、测试框架
- 评估开展自动化测试需要哪些资源，包括：人员、机器、时间；
- 当前可用或是可以申请到的资源
- 如何在不影响日常测试工作的前提下，开展自动化测试工作
启动自动化测试工作
- 确定自动化测试框架的开发原则
- 搭建自动化测试框架
- 确定自动化测试用例的编写原则
- 根据功能测试用例，筛选可转换为自动化测试用例的用例集，评审
- 编写自动化测试用例
- 评审自动化测试用例
- 编写自动化测试脚本
- 调试自动化测试脚本
- 运行自动化测试脚本
- 输出测试结果，将报告发送至同事邮箱
后期工作
- 完善自动化测试用例
- 定期根据实际情况，调优自动化测试脚本、框架
- 集成 CI，定时执行自动化测试脚本，自动发送测试结果到同事邮箱
如何挑选自动化测试框架/工具？
根据测试类型进行初步区分
- 接口自动化测试
- UI自动化测试
- 性能测试
接口自动化测试
工具：postman（入门）、jmeter（高级）
若需要结合代码更加推荐用 jmeter
代码：Python + Requests + 单元测试框架（Unittest、Pytest）、Cypress、HttpRunner、RobotFramework
UI自动化测试
- app 端：Appium、Airtest、RobotFramework
- 小程序：MiniProgram
- Web 端：Selenium、Cypress、RobotFramework
- Window 端：Cypress（electron框架的应用）、Airtest
性能测试
- Jmeter（开源，可二次开发）
- Loadrunner（付费）
自动化测试用例覆盖度到什么程度？
- 回归测试一般都是选取主流程或优先级最高的功能模块进行回归
- 而自动化测试又是解决人工回归测试的绝佳方案
- 所以一般都会将主流程和优先级最高（使用频率最高）的功能模块的功能测试用例转换为自动化测试用例
