1. 自动化测试概述

大家好，我是这门课的主讲人。今天咱们聊聊自动化测试最基础的东西——它到底是什么，能干什么，不能干什么。

我记得刚入行那会儿，带我的老大哥跟我说过一句话：「测试不是点来点去，而是设计出来的。」当时我不太理解，后来做了几年项目，踩了不少坑，才慢慢品出这句话的滋味。

什么是自动化测试

说白了，自动化测试就是让机器替你执行测试用例。你写一段代码，告诉机器：「打开这个页面，输入这些数据，点这个按钮，然后检查结果对不对。」机器会乖乖照做，而且比你手动点快得多。

举个例子，你有个登录功能，手动测试要输入用户名、密码、点登录、看结果。如果每天回归测试十次，你可能会疯掉。但自动化脚本可以一分钟跑完，还能跑十遍。

自动化测试的优缺点

任何技术都有两面性，自动化测试也不例外。我在项目中见过不少团队，一上来就搞自动化，结果搞了半年发现维护成本比手动测试还高。

优点

• 速度快：机器执行比人快得多，尤其是回归测试。我有个项目，手动回归要两天，自动化跑完只要40分钟。
• 可重复：同样的用例，跑一百次结果都一样。人可能会疲劳、走神，机器不会。
• 覆盖面广：可以同时跑多个浏览器、多个设备、多种数据组合。手动测试很难做到。
• 节省人力：把重复劳动交给机器，测试人员可以去做更有价值的事，比如探索性测试。

缺点

• 初期投入大：写脚本、搭框架、配环境，这些都需要时间和人力。我见过一个团队，花三个月搭框架，结果项目黄了。
• 维护成本高：UI变了、接口改了、数据换了，脚本就得跟着改。我曾经维护过一个老项目，每次改版都要花两天修脚本。
• 不能发现所有问题：自动化只能验证你写好的断言。界面布局歪了、颜色不对、用户体验差，这些它发现不了。
• 误报率高：环境不稳定、网络延迟、数据问题，都可能导致脚本失败。你想想看，半夜收到报警，爬起来一看是环境问题，多崩溃。

自动化测试的适用场景

不是所有场景都适合自动化。我建议你记住一句话：自动化测试解决的是「重复」和「回归」的问题，不是「探索」和「一次性」的问题。

适合自动化的场景：

• 回归测试：每次发版都要跑一遍的核心功能。比如登录、支付、搜索这些。
• 数据驱动测试：同样的操作，换不同的数据。比如注册功能，要测几十种用户名格式。
• 跨平台测试：同一个功能要在多个浏览器、多个设备上验证。手动测一遍就累死了。
• 性能测试：模拟大量用户并发访问，这个手动根本做不了。

不适合自动化的场景：

• 一次性测试：比如某个功能只测一次就下线了，写脚本的成本比手动测还高。
• 探索性测试：你想看看系统有没有隐藏的bug，这种需要人的直觉和创造力。
• UI频繁变动的功能：如果页面每周都在改，你写脚本的速度可能跟不上改版的速度。

自动化测试金字塔模型

这个模型是自动化测试领域的经典理论，由Mike Cohn提出。它把测试分为三层，像个金字塔。

层级	名称	特点	占比建议
顶层	UI测试	模拟用户操作，速度慢，维护成本高	10% - 20%
中间层	服务层测试	测试API、接口，速度快，稳定性好	20% - 30%
底层	单元测试	测试代码逻辑，速度最快，成本最低	50% - 70%

金字塔告诉我们一个道理：底层测试要多写，顶层测试要少写。

为什么会这样？你想想看，单元测试跑一次只要几毫秒，而且出了问题能精确定位到哪一行代码。UI测试跑一次可能要几分钟，而且失败了你还得去排查是代码问题还是环境问题。

我在项目中见过不少团队，把大部分精力花在UI自动化上，结果维护成本高得吓人。后来我建议他们调整策略，把重心放到接口测试和单元测试上，UI测试只覆盖核心流程。效果立竿见影，测试效率提升了至少一倍。

嗯，这里要注意一点：金字塔模型不是绝对的。如果你的项目是纯前端应用，没有后端接口，那服务层测试可能就不适用。要根据实际情况灵活调整。

好了，这一章的内容就到这里。自动化测试不是银弹，它有自己的适用范围和局限性。但如果你用对了地方，它绝对能帮你省下大量时间，让你从重复劳动中解放出来。

下一章，咱们聊聊自动化测试框架的设计思路，包括怎么选型、怎么搭架子。到时候我会分享一些我在实际项目中的踩坑经验，保证对你有用。