一、自动化测试概述

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

我刚开始带团队的时候，经常有人问我：「老师，我们是不是所有测试都应该自动化？」每次听到这个问题，我都想笑。你想想看，要是所有测试都能自动化，那测试工程师岂不是要失业了？

其实，自动化测试没那么神秘。说白了，就是用代码代替手工去执行测试用例。我习惯把它理解成「让机器替你干活」。

什么是自动化测试

自动化测试，就是用脚本或工具，自动执行被测软件的功能、性能、接口等测试。它不需要人工一步步点击，而是通过代码模拟用户操作，然后自动比对结果。

举个例子。你手工测试一个登录功能，得打开浏览器、输入账号密码、点击登录、看页面跳转。自动化测试呢？写一段脚本，跑一下，几秒钟就完事。

我记得刚入行那会儿，公司有个项目要回归测试200多个用例。手工跑一遍要两天，我连续加了两周班。后来我写了个简单的Selenium脚本，把重复操作全自动化了。从那以后，我彻底爱上了自动化测试。

自动化测试的优缺点

先说说优点，这个大家可能都听过一些。

优点

• 效率高——机器跑测试比人快得多。我做过对比，同样的回归测试，手工要3小时，自动化只要15分钟。
• 可重复性强——脚本写好了，想跑多少次都行。不会因为人累了就漏掉步骤。
• 覆盖面广——可以同时跑多个环境、多种数据组合。手工测试很难做到这一点。
• 节省人力——把重复劳动交给机器，测试人员可以去做更有价值的事，比如探索性测试。
• 持续集成友好——代码一提交，自动触发测试，问题早发现早修复。

缺点

嗯，这里要注意，自动化测试不是万能的。我踩过的坑不少，跟大家说说。

• 前期投入大——写脚本、搭框架、维护用例，都需要时间和人力。我见过一个团队花了3个月搭自动化框架，结果项目黄了，全白干。
• 维护成本高——UI变了、需求改了，脚本就得跟着改。我曾经维护过一个老项目的自动化脚本，改一个按钮位置，要改20多个用例。
• 不能发现所有问题——自动化只能验证你写好的断言。界面布局好不好看、用户体验顺不顺，它管不了。
• 误报率高——环境不稳定、网络延迟，都可能导致脚本失败。我遇到过最夸张的一次，一个用例因为页面加载慢了0.5秒，连续报了3天假失败。

适用场景与不适用场景

这个部分我觉得特别重要。很多团队一上来就搞自动化，结果搞到一半发现根本不适合。为什么会这样？因为没搞清楚什么场景该用，什么场景不该用。

适用场景

场景	说明	我的经验
回归测试	每次发版都要跑的老用例	这是自动化最值得投入的地方，我一般优先做这个
冒烟测试	验证核心功能是否可用	建议放在CI流程里，每次构建自动触发
数据驱动测试	同样的操作，不同的输入数据	比如登录测试，准备100组账号密码，脚本跑一遍就行
性能测试	模拟大量用户并发访问	手工根本做不了，必须靠工具
接口测试	验证后端API的正确性	稳定、高效，我建议团队优先从接口自动化开始

不适用场景

说白了，有些场景你硬上自动化，就是给自己找麻烦。

• 一次性测试——就测一次的项目，写脚本的时间比手工测还长，图啥？
• UI频繁变动的项目——前端三天两头改，你改脚本都改不过来。我有个朋友就是，项目还在原型阶段就搞UI自动化，结果每周都要重写脚本，最后放弃了。
• 探索性测试——需要靠人的直觉和经验去发现问题的测试，机器做不了。
• 用户体验测试——界面好不好看、操作顺不顺手，这些主观感受，脚本判断不了。
• 短期项目——项目周期就两周，自动化框架还没搭完就结束了，何必呢？

好了，这一章的内容就到这里。自动化测试说到底是个工具，用好了能帮你省不少事，用不好反而添乱。下一章咱们聊聊自动化测试的工具选型，我会分享一些我实际用过的工具和踩过的坑。