小王刚跳槽进一家做 SaaS 系统的创业公司，每天站会都听产品喊“这个需求下周上线”，开发改完代码直接提测，测试同学手忙脚乱点半天，结果上线当天发现登录页多了一个空格导致按钮错位——这种场景，在没上自动化测试的敏捷团队里太常见了。
敏捷不是“快就行”，而是“快且稳”
敏捷开发强调短周期迭代（比如每两周一个 Sprint），但人工测试跟不上节奏：回归一遍核心流程要 3 小时，而留给 QA 的测试时间可能只剩半天。这时候，自动化测试不是锦上添花，而是卡点上线的“安全带”。它不替代手工探索，但能把重复验证的事儿交给机器干——比如每次提交代码后，自动跑一遍登录、下单、支付这三条主路径。
从哪几块先动起来？
别一上来就想覆盖全部功能。建议盯住三个“高频+高风险”环节下手：
- 核心业务流：比如电商的“加购→结算→支付成功”，写成端到端脚本，用 Cypress 或 Playwright 跑；
- 关键接口逻辑：用户注册时邮箱格式校验、密码强度判断，用 pytest + requests 写几行断言就搞定；
- UI 基础元素稳定性：比如首页 banner 图是否加载、购物车图标数字是否实时更新，用 Selenium 检查 DOM 存在性即可。
一个真实的小例子
团队把“用户修改手机号”这个接口加了自动化检查。以前靠人手动输 11 位、10 位、带字母的号码去试，现在 CI 流水线里自动跑 5 种边界值：
def test_update_phone_number():
assert api.update("13812345678").status == 200
assert api.update("138").status == 400 # 太短
assert api.update("abc").status == 400 # 非数字
提交代码后，流水线 22 秒出结果。某次开发误删了长度校验逻辑，测试直接红了，立马回滚，没等测试同学点开页面就拦住了问题。
别踩这些坑
自动化测试在敏捷里容易“半途而废”，常见原因是：
- 脚本写得像说明书：一行代码对应一个点击动作，UI 一改全挂。建议封装常用操作，比如
login_with(username, password)，而不是写十遍find_element(...).click()； - 只写不维护：Sprint 里没人分配时间修脚本，三个月后 70% 用例失效。建议每个迭代留 1 小时专门清理和优化；
- 当成测试全部：自动化跑得再快，也发现不了“这个弹窗文案读着别扭”或者“支付成功页少了震动反馈”这类体验问题——这些还得靠人来试。
自动化测试真正的价值，不是让测试人数变少，而是把人从机械劳动里解放出来，去深挖用户真实使用时的异常路径。就像你家扫地机器人不会替你擦窗户，但它确实让你有空坐下来喝杯茶，顺便想想怎么把产品做得更顺手。