这篇不先堆名词。我们把《别急着换赛道：测试经验在 AI 项目里到底值多少？》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

摘要：很多测试同学转AI项目，简历上写着"会用Claude Code写脚本"，但真到团队里，连最基本的权限边界和调用日志都理不清楚。本文结合一个真实的项目复盘，聊聊测试工程师在AI质量工程中的真正价值——不是写Prompt，而是把Demo变成能上生产的东西。

---

目录

• 测试岗位的边界正在被重新定义
• AI辅助测试：别只把它当代码补全工具
• 自动化用例生成：从"能跑"到"敢跑"
• Agent测试框架：权限和日志才是第一优先级
• 质量评估：用测试思维补齐AI项目的短板
• 总结

---

测试岗位的边界正在被重新定义

去年我们团队接了一个内部知识库问答系统，技术上用RAG链路，Demo阶段回答准确率能到85%以上。业务方很满意，说要上线。

结果上线前一周，审计提了三个问题：

1. 用户能不能通过构造prompt拿到其他部门的敏感文档？
2. 所有问答调用有没有完整日志，包括用户输入、模型输出、检索结果？
3. 如果模型返回了错误内容，能不能追溯到是哪一步出了问题？

这三个问题，Demo阶段没人认真考虑过。

我当时愣了一下，但很快意识到：这恰恰是测试工程师该站出来的地方。

传统测试关注的是功能对不对、性能够不够、边界条件有没有覆盖。AI项目的这些新问题，本质上是"系统行为是否可控、可追溯、可审计"——这是质量工程的底层逻辑，只是换了个场景。

很多测试同学转AI时，第一反应是学LangChain、学Prompt工程、学Agent框架。这些当然有用，但真正拉开差距的，是你能不能快速理解一个新系统的权限边界和日志链路。

---

AI辅助测试：别只把它当代码补全工具

Claude Code、Codex这些工具确实能提效，但我见过太多同学把它们当成"写代码的替代品"。

真实场景是这样的：

你们要测试一个AI客服系统，需要生成边界测试用例。用AI辅助生成用例本身没问题，但关键问题是——你生成的用例，能不能覆盖权限越界的场景？

比如，普通用户和VIP用户的问答权限有什么区别？系统有没有做用户身份校验？这些不是AI能自动想到的，是测试工程师需要主动设计的。

我之前用过一段Claude Code辅助写测试脚本，效果确实好，但踩过一个坑：

它帮我写了一个自动化测试脚本，跑起来全绿。结果上线后才发现，这个脚本没有校验API调用时的用户身份参数，权限漏洞完全没覆盖到。

教训：AI辅助测试提效是真实的，但测试工程师的核心价值在于"知道该测什么"，而不是"让AI帮你写测试"。

---

自动化用例生成：从"能跑"到"敢跑"

Demo阶段的自动化测试，往往追求的是"能跑通"。生产环境要求的是"敢跑"。

区别在哪里？

我以之前做的一个AI文档问答项目为例。Demo阶段我们有一套Selenium+pytest的自动化套件，覆盖了核心功能路径。但上线前，QA团队要求补充以下几类测试：

• 权限回归测试：不同角色用户的访问边界
• 异常场景测试：模型超时、返回空结果、返回敏感内容
• 可观测性验证：每次调用的日志是否完整、trace_id是否正确传递

这三类测试，传统自动化框架覆盖得不好，需要结合AI系统的特性做适配。

比如权限测试，不能只测"正常路径能不能访问"，还要测"越权路径能不能拦截"。这需要你对系统权限模型有清晰理解，不是靠AI生成的用例能自动覆盖的。

---

Agent测试框架：权限和日志才是第一优先级

这是我最想展开的部分。

最近很多Agent项目能跑Demo，但团队不敢接手上线。我复盘了几个项目，发现卡住的关键不是代码能力，而是权限和日志这两个基础问题没解决。

我们当时设计了一套Agent测试框架，核心思路是：先保证可观测，再保证功能正确。

代码层面，我们做了这些事：

# 权限校验中间件示例
class PermissionMiddleware:
    def __init__(self, user_context, resource_acl):
        self.user_context = user_context
        self.resource_acl = resource_acl

    def check(self, action, resource):
        """检查当前用户是否有权限执行该操作"""
        if not self.user_context.is_authenticated():
            raise PermissionError("用户未认证")

        required_role = self.resource_acl.get_permission(resource, action)
        if not self.user_context.has_role(required_role):
            raise PermissionError(
                f"用户角色{self.user_context.role}无权限执行{action}"
            )
        return True

# 日志追踪中间件示例
class TraceMiddleware:
    def __init__(self):
        self.tracer = None  # 实际项目用OpenTelemetry

    def before_request(self, request_id, user_id, action):
        self.tracer.start_span(
            name=f"agent.{action}",
            attributes={
                "request_id": request_id,
                "user_id": user_id,
                "timestamp": time.time()
            }
        )

    def after_response(self, response, status_code):
        self.tracer.end_span(attributes={
            "status_code": status_code,
            "duration_ms": self.tracer.get_duration()
        })

这两段代码看起来简单，但背后是一个重要的判断标准：

Agent项目上线前，必须回答三个问题：
1. 每个操作有没有权限校验？越权能不能被拦截？
2. 每次调用有没有完整日志？能不能追溯到具体请求？
3. 异常返回有没有明确的错误码和错误信息？

如果这三个问题的答案都是"不确定"，那这个项目就不应该上线。

---

质量评估：用测试思维补齐AI项目的短板

很多AI项目质量评估只关注"准确率"，但这远远不够。

我们当时建立了一套质量评估体系，分三个层次：

第一层：功能正确性

• 核心场景的问答准确率
• 边界场景的拦截率
• 异常场景的降级表现

第二层：权限安全性

• 越权访问拦截率（应该是100%）
• 敏感信息泄露率（应该是0%）
• 权限变更后的回归通过率

第三层：可观测性

• 日志完整率（每个请求是否都有完整日志）
• Trace追踪覆盖率
• 错误告警的及时性和准确性

这个评估体系的好处是：把AI项目的质量要求从"黑盒"变成"白盒"。

之前有个项目，Demo阶段准确率90%，业务方很满意。但做了权限和安全测试后，发现越权漏洞有3个，敏感信息泄露风险2个。最终这个版本被打了回去。

这就是测试工程师的价值——你不是在找Bug，你是在帮团队判断"这个系统能不能上生产"。

---

总结

测试转AI，最大的优势不是会写代码，而是对系统行为边界的敏感度，以及对"什么才算质量达标"的判断力。

Demo能跑通，只是入场券。真正决定你能不能接手生产项目的，是你能不能回答这三个问题：

1. 权限边界清不清楚——不同用户能做什么、不能做什么，有没有被正确拦截
2. 日志链路完不完整——每次调用能不能追溯到具体请求，出了问题能不能定位
3. 异常处理到不到位——模型返回异常时，系统有没有降级和告警

这些能力，传统测试经验完全可以迁移过来。你不需要成为Prompt工程师，你只需要成为那个"知道系统哪里可能出问题"的人。

一句话总结：测试工程师转AI，别急着学新框架，先把权限和日志这两关过了。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。