高级 QA 的宣言:我如何决定哪些不自动化
发布: (2026年1月7日 GMT+8 13:49)
5 min read
原文: Dev.to
Source: Dev.to
在 QA 工作了 6 年以上,我意识到高覆盖率往往只是虚荣指标。我合作过的一些最优秀的工程团队的 UI 覆盖率较低,因为他们更看重流水线速度,而不是脚本数量。
自动化并不是“免费”的时间——每当开发者必须等待构建完成,却因为不稳定的选择器导致构建失败时,你都要为维护和挫败感付出代价。一个不稳定的测试比根本没有测试更糟;它会产生噪音,最终导致团队开始忽视它。一旦开发者不再信任 CI 中的红灯,QA 流程实际上就宣告死亡。
当我跳过自动化时
- 振动特性 – 如果 UI 或需求每隔几天就会变化,你就在写一次性代码。我会等到该特性至少在两个冲刺中没有重大逻辑变更后再进行自动化。
- 噩梦式设置 – 如果测试一个“Submit”按钮需要填充 10 个数据库、绕过双因素认证并模拟 5 个外部 API,投资回报率不划算。我宁愿花 30 seconds 手动检查,也不愿花两天调试脆弱的脚本。
Test‑selection strategy
“Must‑Automate” List
- Complex calculations – Humans are prone to errors with tax logic, currency conversions, etc. Machines don’t get tired of math.
- Smoke test – The “happy path” that proves the app starts and a user can log in. This is the heartbeat of your pipeline.
- Data integrity – Verify that data entered in step 1 actually appears in the database in step 10.
“Do‑Not‑Touch” List
- Visual “feel” – A script can tell you a button is
is_visible(), but it won’t detect overlapping text or unreadable fonts on a 13‑inch laptop. - One‑and‑done features – Seasonal promotions that last two weeks don’t merit three days of scripting.
- Driving every test through the browser – This is slow, expensive, and fragile. For example, verifying that a user’s profile updated does not require clicking through the entire UI each time.
UI 密集 vs. 平衡方法
// UI‑heavy (fragile)
test('user updates profile - the slow way', async ({ page }) => {
await page.goto('/settings');
await page.fill('#bio-input', 'New Bio');
await page.click('.save-button-variant-2'); // This selector will break eventually
await expect(page.locator('.success-toast')).toBeVisible();
});
// Balanced (faster and stable)
// 1. Check the logic via API (milliseconds)
test('profile update data integrity', async ({ request }) => {
const response = await request.patch('/api/user/profile', {
data: { bio: 'New Bio' }
});
expect(response.ok()).toBeTruthy();
});
// 2. Check the UI once (does the button work?)
test('save button triggers action', async ({ page }) => {
await page.goto('/settings');
await page.click('button:has-text("Save")');
// No DB check needed; the API test already covered that.
});
电子商务结账示例
典型的结账流程包括:
- 将商品加入购物车。
- 输入收货地址。
- 输入信用卡信息。
- 验证订单确认。
仅通过 UI 自动化会产生 40–50 个可能失效的定位器。一次网络波动或轻微的 CSS 变动都可能导致整个构建中断。
我的做法:
- 自动化 “Add to Cart”(加入购物车)和 “Checkout”(结账)API 调用,以确保后端正常工作。
- 在不同浏览器分辨率下对 UI 进行快速的手动 “sanity check”(基本检查)。
这样可以保持流水线绿色运行,让开发者满意。
选择性自动化的好处
- 更快且更可靠的 CI 流水线
- 更少的误报失败和重新运行
- 开发者对测试结果的信任度更高
- 降低维护成本
- 更快的发布周期且风险更低
目标不是最大化覆盖率,而是最大化信心。如果一个测试减慢了交付速度,却没有显著降低风险,那么它就不应出现在流水线中。