1. 自动化测试概述：什么是自动化测试、自动化测试的优势与挑战、自动化测试的适用场景

大家好，欢迎来到这门课的第一讲。

说实话，我见过太多测试新手，一上来就问我：「老师，自动化测试到底是个啥？是不是就是写代码点点点？」

嗯，这个问题问得挺好。但答案远不止这么简单。

今天，我就用我这些年踩过的坑、流过的泪，跟你好好聊聊自动化测试的本质。

1.1 什么是自动化测试？

先给个最直白的定义：自动化测试，就是用代码代替人工，去执行测试用例并验证结果的过程。

你想想看，手工测试是什么？是测试人员打开浏览器，输入账号密码，点击登录按钮，然后看页面是不是跳转到了首页。这个过程重复一百遍，谁都会烦。

自动化测试就是把这些重复劳动，写成脚本。让机器替你跑。

我个人习惯把自动化测试分成三个层次：

• 单元测试：测函数、测方法。比如你写了一个计算器加法函数，自动化测试就验证 1+1 是不是等于 2。
• 接口测试：测 API。比如登录接口，传正确的参数返回 token，传错误的参数返回 401。
• UI 自动化测试：测界面。模拟用户点击、输入、滑动，看页面反应对不对。

我在项目中遇到过不少新人，一上来就搞 UI 自动化，结果维护成本高得吓人。其实，自动化测试的投入产出比，往往是从接口测试开始见效的。这个后面我们会详细讲。

1.2 自动化测试的优势与挑战

说到优势，我直接给你列个表，一目了然。

优势	说明
速度快	机器执行比人快得多。一套回归测试，手工跑可能要半天，自动化 10 分钟搞定。
可重复	同样的用例，跑一万次结果都一样。人可能会疲劳、会漏点，机器不会。
覆盖面广	可以同时跑多台设备、多种浏览器、多种数据组合。
反馈及时	代码一提交，自动化测试立刻跑。有问题马上知道，不用等到第二天。
节省人力	把测试人员从重复劳动中解放出来，去做更有创造性的工作。

但是，别高兴太早。自动化测试不是银弹。它也有不少挑战。

挑战一：前期投入大。 写脚本、搭框架、维护用例，都需要时间。我见过一个团队，花了三个月搭了一套 UI 自动化框架，结果业务需求一变，80% 的用例全废了。你说心疼不心疼？

挑战二：维护成本高。 尤其是 UI 自动化。前端稍微改个 class 名、调个布局，你的定位器就失效了。我曾经维护过一个项目，每周光修定位器就要花半天时间。

挑战三：不能发现所有 bug。 自动化测试只能验证你写好的用例。那些你没写到的边界情况、用户体验问题、视觉问题，它发现不了。说白了，自动化测试只能证明「代码没坏」，不能证明「软件好用」。

1.3 自动化测试的适用场景

那到底哪些场景适合做自动化？我总结了几条经验，你直接拿去用。

适合做自动化的场景

• 回归测试：每次发版都要跑一遍的核心功能。比如登录、支付、下单流程。
• 重复性高的测试：比如同一个接口，要测几十组不同的参数组合。
• 跨平台测试：同一个功能要在 Chrome、Firefox、Safari 上各测一遍。手工测太累，自动化一次搞定。
• 数据驱动测试：用不同的数据跑同一个用例。比如注册功能，测不同格式的邮箱、不同长度的密码。
• 性能测试：模拟大量用户并发访问。这个手工根本做不了。

不适合做自动化的场景

• 一次性测试：比如某个功能只测一次就下线了。写脚本的成本比手工测还高。
• 探索性测试：需要测试人员动脑子、凭经验去发现问题的场景。自动化脚本太死板，发现不了意外情况。
• 频繁变更的功能：业务逻辑一周改三次，你脚本改得过来吗？
• 用户体验测试：页面好不好看、操作顺不顺手，机器判断不了。

小结

这一章我们聊了自动化测试的本质、好处和坑，以及什么时候该用、什么时候不该用。

说白了，自动化测试就是个工具。工具好不好，关键看你会不会用。我见过有人用自动化测试把团队效率翻了三倍，也见过有人把团队拖进维护的泥潭。

区别在哪？就在「选对场景」这四个字上。

下一章，我会带你看看主流的自动化测试框架，以及怎么选一个适合你项目的。到时候我会分享一些我踩过的框架选型坑，保证让你少走弯路。

咱们下章见。