自动化测试(Automated Testing)，是指把以人为驱动的测试行为转化为机器执行的过程。往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试过程

大体思路

1. 明确测试目标 & 选择适当工具：
   • 定义清晰的测试目标，例如功能测试、性能测试、可访问性测试等。
   • 确定关键路径和核心功能，确保它们被充分覆盖。
   • Jest、Mocha、Chai等用于单元测试
   • Selenium、Cypress、Puppeteer等用于端到端测试
   • 考虑使用辅助工具，如Mock服务、测试数据生成器等
2. 制定测试计划：
   • 制定测试计划，包括测试用例的编写、执行计划、测试数据准备等。
   • 考虑测试的覆盖范围，包括正面测试、边界测试、异常测试等。
3. 测试用例种类覆盖
   • 单元测试（Unit Testing）：
     • 针对小的代码单元，如函数、组件等进行测试。
     • 使用合适的断言库来验证代码的正确性。
     • 通过模拟（mock）或替代外部依赖，确保测试独立性。
   • 组件测试：
     • 验证组件的行为和渲染是否符合预期。
     • 测试组件的交互、状态管理等方面。
   • 集成测试：
     • 测试多个组件、模块或服务之间的协作和交互。
     • 确保系统各部分协同工作的正确性。
   • 端到端测试（E2E Testing）：
     • 模拟用户在真实环境中的操作，验证整个应用的流程和功能。
     • 确保不同页面和组件之间的集成正常工作。
   • 性能测试：
     • 测试应用的性能和响应时间。
     • 使用工具模拟并发用户、大规模数据等场景。
   • 可访问性测试：
     • 确保应用对残障用户友好，符合无障碍标准。
     • 使用工具或手动检查页面的可访问性。
4. 持续集成和部署（CI/CD）：
   • 集成测试到持续集成和部署流程，确保每次提交都能触发自动化测试。
   • 定期执行冒烟测试，保证主要功能不受破坏。
5. 测试报告和监控 & 持续改进：
   • 生成详细的测试报告，包括通过和失败的测试用例。
   • 配置监控系统，实时跟踪应用性能和稳定性。
   • 定期回顾测试结果和反馈，根据测试覆盖和质量指标进行调整。
   • 更新测试用例，以适应应用变更。

自动化流程解决的问题

• 测试时间紧张，手工测试可能覆盖不全，容易错过某些边界情况；
• 模块间强耦合时，单纯从页面进行测试时，比较难深入的发现问题；
• 回归测试时，需要投入较大的人力/工时；
• 实现手工测试无法达成的测试任务；
• 通过编写测试用例，加深对业务/数据的认知，有助于下阶段迭代中发现隐藏的问题；

引入自动化测试的前提条件

• 项目周期长，需求变动不频繁
• 自动化测试脚本可重复使用
• 测试任务手工测试难以实现

自动化用例一般在哪个阶段完成

一般落后于新功能的手工测试阶段，可以在手工用例执行完成或功能上线后，再去补充自动化的用例。
自动化不是跟着新需求走，而是测变化的东西对不变东西的影响，一定不要做为了自动化而自动化的工作。

分层自动化测试

• UI层
  适当的界面自动化测试是有必要的，但是没有必要在UI层投入太多(价值最小，它最接近用户真实场景，也容易发现问题)
• Service层
  接口自动化测试, 要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景(价值居中)
• Unit层
  单元测试。最有价值的测试，但是对测试人员要求比较高，一般由开发人员完成

通常来说，手工测试是最基本的，可以做到接近100%,而对于自动化测试来说，它更像是一件”防弹衣”，用来防护身体的主要部位。有人认为自动化率提高了，就可以节省人力，这实际是非常片面的，因为提高自动化率，意味着需要投入更大的人力在维护的成本上。因为系统的需求是在不断变化的，每一个变化都会导致自动化测试用例需要更新调整。

所以，自动化测试做到什么样才算好，也要结合上面的测试金字塔来分析。对于UI层面的自动化测试，保证少量必要的主流程即可，切勿在这一层面将自动化测试的”防弹衣”变成臃肿的”宇航服”；Service层面的接口自动化测试，可以考虑覆盖大部分的流程；Unit层面的单测，做到100%是最好的，即使有需求变化，一般也很少影响到已有的用例。一般来说，单元测试可以发现80%的缺陷。

参考:
https://developer.aliyun.com/article/334946

https://juejin.cn/post/6896890664726822920