# 测试金字塔作为 QA 中 AI 助手的架构约束
当语言模型成为测试设计者时，经典的测试金字塔不再只是一个建议——它变成了严格的技术要求。原因很简单：LLM 的上下文窗口物理上无法容纳复杂功能的完整描述，该功能包含数十个用户故事和任务。试图“一次性喂给它所有内容”会导致质量下降或完全生成失败。
为什么测试金字塔能解决上下文问题
测试金字塔提供了一种自然的任务分解方式。与其向模型加载整个 IT 解决方案的描述，不如按层级处理：
- 任务级别（组件） —— 仅限于一个微服务的 API 契约和业务规则。
- 用户故事级别（系统） —— 单个信息系统内的前端和后端集成。
- 功能级别（E2E） —— 系统间交互以及端到端业务流程。
每个级别都需要自己的上下文。而且每个级别单独提供时，都能符合 LLM 的限制。这不是理论——这是实际需求。
示例：“订单结账时的促销码”功能包含三个用户故事和九个任务。完整描述（包括原型图、API 规范和测试数据）需要约 15 万 token。Claude 3 Opus 拥有 20 万 token 的窗口，理论上能处理——但由于高层级“噪声”，低层级测试质量会下降。按层级分解后，每个请求负载降至 8000–1.5 万 token——质量大幅提升。
AI 助手如何使用金字塔层级
在 QA Assist 系统里，每个测试层级由专属代理处理。架构如下：
- 单元/API 代理 —— 接收单个端点或组件的规范。生成覆盖边界值、负面场景和向后兼容检查的单元测试和 API 测试。
- 系统代理 —— 接收用户故事描述及相关组件接口。生成验证集成和用户场景的系统测试。
- E2E 代理 —— 接收功能地图和用户故事状态。生成检查系统间数据一致性的端到端测试。
关键在于每个代理的上下文严格限定在其层级。单元代理不知道管理面板。系统代理看不到订单历史。这不是限制——这是针对 LLM 能力的优化。
具体示例：AI 在每个层级生成什么
拿一个任务：后端应用促销码的 API（POST /orders/apply-promo）。
单元/API 代理接收的内容：
- 端点规范（输入参数、输出字段、错误码）。
- 折扣计算业务规则（固定金额、百分比、组合折扣）。
- 约束条件（使用限制、到期日期、地理限制）。
代理生成的内容：
# Example sgenerirovannogo test
@pytest.mark.parametrize("promo_code, expected_discount", [
("SALE10", 10.0), # Protsentnaya skidka
("FIXED50", 50.0), # Fiksirovannaya sum
("COMBO", 60.0), # Kombinirovannaya (10% + 50 rubles)
])
def test_valid_promo_codes(api_client, promo_code, expected_discount):
response = api_client.post("/orders/apply-promo", json={"code": promo_code})
assert response.status_code == 200
assert response.json()["discount"] == expected_discount
@pytest.mark.parametrize("invalid_code", ["EXPIRED", "OVERUSED", "INVALID_FORMAT"])
def test_invalid_promo_codes(api_client, invalid_code):
response = api_client.post("/orders/apply-promo", json={"code": invalid_code})
assert response.status_code == 400
assert "error" in response.json()现在拿一个用户故事：“用户在订单结账时应用促销码”。
系统代理接收的内容：
- 场景描述（用户添加商品、输入促销码、看到折扣、完成订单）。
- 前端和后端接口（输入表单、API 调用、总额显示）。
- UX 要求（客户端验证、错误消息、加载状态）。
代理生成的内容：
// Example Playwright-test
test('User applies valid promo code during checkout', async ({ page }) => {
await page.goto('/cart');
await page.fill('#promo-code', 'SALE10');
await page.click('#apply-promo');
// Checking otobrazhenie skidki
await expect(page.locator('.discount-amount')).toHaveText('-10%');
// Checking pereschyot itogovoy summy
const originalTotal = await page.locator('.original-total').innerText();
const discountedTotal = await page.locator('.final-total').innerText();
expect(parseFloat(discountedTotal)).toBeLessThan(parseFloat(originalTotal));
// Oformlyaem zakaz
await page.click('#checkout-button');
await expect(page).toHaveURL('/order-confirmation');
});为什么 LLM 在高层级更吃力
语言模型在处理高层抽象时，质量可预测地下降：
- 功能/E2E 级别 —— 需要理解往往未明确形式化的业务逻辑。模型必须做出可能错误的假设。
- 系统/用户故事级别 —— 好一些，但仍需整合多源知识（前端、后端、UX）。
- 任务/单元级别 —— 最适合 LLM 优势：明确规范、正式规则、可预测输入/输出。
经验法则：金字塔层级越低，AI 助手生成测试的准确率越高。实际中，这意味着：
- 单元/API 测试——几乎完全信任 AI（90–95% 覆盖率）。
- 系统测试——进行审查，尤其是复杂集成（70–80% 覆盖率）。
- E2E 测试——仅用 AI 生成初稿，需要大量人工精炼（50–60% 覆盖率）。
AI 助手的架构要点
如果你在构建测试生成的 AI 系统，忽略测试金字塔就是失败之道。我们在 QA Assist 中内置的关键原则：
- 按层级分解 —— 强制要求。禁止一次性倾倒整个功能。
- 隔离上下文 —— 每个代理仅处理其层级。层级间信息通过结构化数据传递，而非文本上下文。
- 人工参与循环 —— 尤其高层级。AI 生成初稿；人工精炼并批准。
- 反馈循环 —— 测试执行结果用于微调代理。如果 AI 漏掉边界情况，就加入训练集。
没有这些原则，即使最强大的 LLM 也会生成看似合理却抓不住真实 bug 的测试。
关键要点
- 测试金字塔不只是方法论——它是有效 AI 助手的架构要求。
- LLM 上下文窗口物理上无法完整处理复杂功能而不损失质量。
- 按层级分解（任务 → 用户故事 → 功能）是生成全层级高质量测试的唯一途径。
- AI 在金字塔低层（单元/API）表现出色，在高层（E2E）更吃力。
- 人工仍不可或缺，尤其是审查和精炼系统及 E2E 测试。
— Editorial Team
暂无评论。