一、自动化测试概述
什么是自动化测试
自动化测试，说白了就是用代码代替人工去执行测试用例。
我刚开始带团队的时候，经常有人问我：“老师，自动化测试是不是就是录个脚本回放一下？”其实远不止这么简单。真正的自动化测试，是把测试步骤、数据验证、结果判断全部用程序化的方式表达出来。你写一段代码，让它自动打开浏览器、填表单、点按钮、检查结果——这就是自动化测试的雏形。
我个人习惯把自动化测试分成三个层次：
- 脚本层：写代码模拟用户操作
- 数据层：用不同的输入数据驱动同一个脚本
- 框架层：封装公共方法，让脚本更易维护
嗯，这里要注意：自动化测试不是把手工测试的步骤原封不动地翻译成代码。你得重新思考——哪些步骤可以合并？哪些检查点可以自动化？我在项目中遇到过有人把“等待3秒”这种硬编码写满整个脚本，结果每次跑都又慢又不稳定。
自动化测试的优缺点
先说说优点，这个大家应该都有体会：
优点
- 速度快：同样的回归测试，手工跑一天，自动化可能半小时搞定
- 可重复：脚本写好了，想跑多少次就跑多少次，不会累
- 覆盖面广：可以同时跑多台机器、多种浏览器、多组数据
- 减少人为失误：机器不会因为困了漏掉某个检查点
但缺点也很明显，我踩过的坑不少：
缺点
- 前期投入大：写脚本、搭框架、维护用例，都是时间成本
- 不能发现所有问题：自动化只能验证你写好的检查点，界面布局、用户体验这些很难覆盖
- 维护成本高：UI一改，脚本就得跟着改。我曾经维护过一个项目，每周花两天时间修脚本
- 误报率高：网络延迟、元素没加载出来，脚本就报红了。你得花时间排查是真bug还是环境问题
为什么会这样？说白了，自动化测试不是银弹。它解决的是“重复劳动”的问题，不是“测试质量”的问题。
自动化测试的适用场景
你想想看，什么样的场景最适合上自动化？我总结了几条经验：
| 场景 | 适合程度 | 我的建议 |
|---|---|---|
| 回归测试 | ★★★★★ | 每次发版都要跑，自动化收益最高 |
| 冒烟测试 | ★★★★☆ | 快速验证核心功能是否可用 |
| 数据驱动测试 | ★★★★★ | 同样的流程，换不同的输入数据 |
| 性能测试 | ★★★★☆ | 模拟高并发场景，手工做不到 |
| 探索性测试 | ★☆☆☆☆ | 这个还是交给人工吧 |
| 一次性测试 | ★☆☆☆☆ | 跑完就扔的脚本，不值得自动化 |
我曾经接手过一个项目，团队把所有的测试用例都自动化了，包括那些一个月才跑一次的边界值测试。结果呢？维护脚本的时间比手工测试还长。所以我的原则是：自动化只做高频、稳定、可重复的事情。
自动化测试金字塔模型
这个模型是Mike Cohn提出来的，我把它当作自动化测试的“宪法”。
金字塔分三层：
- 底层：单元测试 —— 测试函数、方法、类。跑得最快，成本最低
- 中间层：服务测试 —— 测试API、接口、服务。比UI稳定，比单元测试覆盖面广
- 顶层：UI测试 —— 测试用户界面。最接近用户行为，但也最脆弱、最慢
我见过很多团队一上来就写UI自动化，结果金字塔倒过来了——UI测试占了80%，单元测试几乎没有。这样做的问题在哪？你想想看，UI一改，顶层脚本全废。而底层单元测试改起来就轻松多了。
下面这张图是我自己画的，帮你理解这个金字塔的结构：
我的建议
按照金字塔的比例来分配自动化测试的投入：
- 单元测试占 60% 以上
- 服务测试占 30% 左右
- UI测试控制在 10% 以内
这样做的好处是：底层稳定了，上层即使出问题，排查范围也小很多。
我记得有一次，团队把UI测试写到了2000多个，每次跑都要4个多小时。后来我带着大家重构，把大部分业务逻辑的验证下沉到服务测试层，UI测试只保留核心流程。结果呢？UI测试从2000个降到了200个，跑一次只要20分钟，而且稳定性从70%提升到了95%。
所以，自动化测试不是越多越好，而是越合理越好。金字塔模型就是帮你找到这个“合理”的尺度。
公众号:蓝海资料掘金营，微信deep3321