第1章自动化测试概述

一、自动化测试概述

大家好，我是你们这门课的主讲。今天咱们聊聊自动化测试最基础的东西——它到底是什么，为什么非用不可，以及怎么衡量它值不值得做。

说实话，我刚开始做Android开发那会儿，对自动化测试也是嗤之以鼻的。觉得「手动点两下不就完了？写测试代码的时间都够我测三遍了」。直到有一次，我负责的一个支付模块上线后出了严重bug，用户反馈说「支付成功但余额没扣」——嗯，那场面，至今难忘。

自动化测试，说白了就是让机器代替人去执行测试用例。你写一段脚本，告诉机器：「打开App，点击这个按钮，输入这些数据，检查那个结果」。机器就会一遍又一遍地执行，不会累，不会烦，也不会因为半夜加班而手抖点错。

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

你想想看，这三个层次覆盖了从代码到用户的全链路。少了哪一层，都可能漏掉问题。

这个问题我经常被问到。很多团队觉得「我们人测就够了啊」。但实际情况是——

第一，回归测试太痛苦了。 我经历过一个项目，每次发版前要手动测试200多个用例。一个版本迭代两周，光测试就要花掉3天。而且经常出现「修了一个bug，引出三个新bug」的情况。手动测试根本来不及覆盖所有场景。

第二，人总会犯错。 我记得有一次，测试同事连续加班三天，凌晨两点测完最后一个用例，结果漏掉了一个边界条件——输入框长度限制没测。上线后用户输入了超长文本，直接导致App崩溃。你说这是人的问题吗？是，但更是流程的问题。

第三，速度就是竞争力。 现在的互联网产品，恨不得一天发三个版本。手动测试根本跟不上节奏。自动化测试可以在你提交代码后几分钟内就跑完所有用例，告诉你「这次提交有没有搞坏东西」。

核心观点： 自动化测试不是用来替代手工测试的，而是用来解放手工测试的。让机器做重复的事，让人做创造的事。

说到ROI（投入产出比），很多老板会问：「写自动化测试要花多少时间？能省多少时间？」

我给大家算一笔账：

看到了吗？自动化测试的投入是一次性的，但收益是持续的。一般来说，一个用例如果会被执行超过5次，写自动化脚本就是划算的。

我的经验： 别一上来就想把所有用例都自动化。先挑那些「高频、稳定、核心」的用例。比如登录、支付、注册这些核心流程。我曾经见过一个团队，花了两周时间自动化了一个「用户协议页面」的测试——那个页面一年都没改过一次。你说这ROI能高吗？

另外，ROI还要考虑隐性收益：

说到测试策略，就不得不提测试金字塔。这个模型是Mike Cohn提出来的，在Android领域同样适用。

金字塔从下到上分为三层：

底层：单元测试（占比约70%）
测试单个方法、单个类。速度快，毫秒级就能跑完。我建议每个工具类、每个数据模型都要有单元测试。比如你写了个日期格式化工具，就测它能不能正确处理各种格式。
中层：集成测试（占比约20%）
测试多个组件之间的交互。比如ViewModel和Repository配合是否正常，Room数据库的查询是否返回正确结果。这一层比单元测试慢一些，但比UI测试快得多。
顶层：UI测试（占比约10%）
模拟用户操作，测试整个App的界面和交互。比如用Espresso或Compose Test框架。这一层最慢，也最脆弱——UI稍微改一下，测试可能就挂了。所以只覆盖核心用户流程就好。

避坑指南： 我曾经见过一个团队，把80%的精力都花在了UI测试上。结果每次UI改版，测试代码就要重写一大半。测试变成了负担，而不是保障。记住金字塔的原则：底层要多，顶层要少。单元测试才是性价比最高的。

你想想看，如果单元测试覆盖得好，很多bug在代码编译阶段就被发现了。根本不需要跑到UI层去验证。这就好比盖房子——地基打牢了，上面怎么折腾都不怕。

好了，这一章的内容就到这里。下一章咱们聊聊「如何搭建Android自动化测试环境」，包括JUnit、Mockito、Espresso这些工具的配置和使用。到时候我会分享一些我在项目中踩过的坑，保证让你少走弯路。