一、自动化测试概述

大家好，我是这次课程的主讲人。在正式开始之前，我想先聊聊一个基础但关键的问题——什么是自动化测试？

说白了，自动化测试就是让机器代替人，去执行那些重复性的测试工作。你写一段脚本，告诉电脑「点这里、输入这个、检查那个」，然后它就能一遍又一遍地跑，不喊累、不偷懒。

我记得刚入行那会儿，带我的老大哥说过一句话，我一直记到现在：「自动化测试不是银弹，但它是一把好用的瑞士军刀。」 这句话怎么理解？我们往下看。

1.1 什么是自动化测试

从技术角度讲，自动化测试是指使用专门的工具或框架，将人工测试的行为转化为可重复执行的脚本或程序。它对比的是手工测试——也就是人坐在电脑前，手动点击、输入、观察结果。

举个例子：

# 手工测试的步骤
1. 打开浏览器
2. 输入网址 http://example.com/login
3. 在用户名框输入 "admin"
4. 在密码框输入 "123456"
5. 点击登录按钮
6. 检查页面是否跳转到首页

# 自动化测试的脚本（Python + Selenium）
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("http://example.com/login")
driver.find_element_by_id("username").send_keys("admin")
driver.find_element_by_id("password").send_keys("123456")
driver.find_element_by_id("loginBtn").click()
assert "首页" in driver.title
driver.quit()

你看，手工测试做一遍可能花30秒，但自动化脚本写好后，跑一次只要3秒。而且它可以跑100次、1000次，每次结果都一样。

1.2 自动化测试的优缺点

任何技术都有两面性。我在项目中踩过不少坑，这里把优缺点掰开揉碎了讲清楚。

优点

• 效率高：脚本跑一次几秒钟，手工测可能要几分钟。尤其是回归测试，几百个用例手工跑一遍，人得疯。
• 可重复性强：同样的脚本，今天跑和明天跑，结果完全一致。手工测试就不一定了——你困了、饿了、走神了，都可能漏掉bug。
• 覆盖面广：可以同时跑多台机器、多种浏览器、多种数据组合。手工测试很难做到这一点。
• 7×24小时运行：下班前把脚本挂上，第二天早上看报告。我经常这么干，省出来的时间用来分析问题。
• 减少人为错误：手工测试容易犯低级错误，比如点错按钮、看错数据。自动化脚本不会。

缺点

• 开发成本高：写脚本需要时间，维护脚本也需要时间。我见过一个项目，自动化用例的维护成本比手工测试还高，最后不得不砍掉。
• 不能发现所有问题：自动化只能验证你写好的检查点。界面布局好不好看？用户体验顺不顺畅？这些它管不了。
• 对变化敏感：UI稍微改一下，脚本可能就废了。我曾经因为一个按钮的class名从"btn-primary"改成"btn-blue"，导致50多个用例全部报错。
• 初期投入大：需要搭建框架、选工具、培训人员。小团队或者短期项目，可能划不来。

1.3 适用场景分析

不是所有场景都适合自动化。我总结了一个简单的判断标准：「三多一少」——重复多、数据多、回归多、变化少。

场景	是否适合自动化	说明
回归测试	✅ 非常适合	每次发版都要跑，重复性极高
冒烟测试	✅ 适合	核心功能验证，脚本稳定后收益很大
数据驱动测试	✅ 非常适合	同样的操作，换不同的数据，脚本改数据文件就行
性能测试	✅ 必须自动化	手工根本模拟不了高并发
探索性测试	❌ 不适合	需要人的创造力和直觉
一次性测试	❌ 不适合	写脚本的时间比手工测还长，何必呢？
UI频繁变动的项目	⚠️ 谨慎	维护成本可能超过收益

嗯，这里要注意一点：自动化测试不是要取代手工测试。它们应该是互补的关系。手工测试负责「找新问题」，自动化测试负责「确保老问题不再出现」。

1.4 自动化测试的知识体系

为了让大家对自动化测试有个整体认知，我画了一张图。这张图涵盖了自动化测试的核心要素和它们之间的关系。

这张图把自动化测试的常见分类和核心目标串起来了。你想想看，不管你是做UI自动化还是接口自动化，最终都是为了那三个目标：提升效率、保证质量、降低成本。

好了，这一章的内容就到这里。自动化测试的概念说复杂也复杂，说简单也简单。关键是要理解它的本质——用机器的高效和稳定，弥补人工的不足。下一章我们会深入聊聊自动化测试框架的选择和搭建，到时候再细聊。

---

可可精品资料库