自动化测试

软件测试的AI革命 传统软件测试面临三个困境：测试用例编写耗时、回归测试成本随代码增长线性上升、边界条件难以穷举。AI正在从根本上改变测试的经济学——从"人写测试"到"AI生成测试"。 测试用例生成 基于代码的单元测试生成 class UnitTestGenerator: def __init__(self, llm): self.llm = llm def generate_tests(self, source_code, framework="pytest"): # 1. 分析源代码 analysis = self._analyze_code(source_code) # 2. 生成测试策略 strategy = self._generate_strategy(analysis) # 3. 生成测试用例 test_cases = [] for test_scenario in strategy: test = self.llm.generate(f""" 为以下函数生成测试用例： 函数代码： {source_code} 测试场景：{test_scenario} 框架：{framework} 要求： - 使用有意义的测试名称 - 包含Arrange-Act-Assert结构 - 覆盖正常路径和异常路径 - 使用参数化测试减少重复 """) test_cases.append(test) # 4. 验证测试可运行 validated = self._validate_tests(test_cases, source_code) return validated def _analyze_code(self, code): """分析代码结构和依赖""" return { "functions": extract_functions(code), "classes": extract_classes(code), "dependencies": extract_imports(code), "complexity": compute_complexity(code), "branches": extract_branches(code), } def _generate_strategy(self, analysis): """基于代码分析生成测试策略""" scenarios = [] for func in analysis["functions"]: scenarios.extend([ f"测试 {func.name} 的正常输入", f"测试 {func.name} 的边界值", f"测试 {func.name} 的异常输入", f"测试 {func.name} 的空值处理", ]) # 复杂函数需要更多测试 if func.complexity > 10: scenarios.append(f"测试 {func.name} 的复杂分支组合") return scenarios 基于API规范的集成测试 class APITestGenerator: def __init__(self, llm): self.llm = llm def generate_from_openapi(self, spec): """从OpenAPI规范生成测试""" tests = [] for endpoint in spec["paths"]: for method in spec["paths"][endpoint]: operation = spec["paths"][endpoint][method] # 生成正常请求测试 tests.append(self._generate_happy_path(endpoint, method, operation)) # 生成参数边界测试 tests.extend(self._generate_boundary_tests(endpoint, method, operation)) # 生成认证授权测试 tests.extend(self._generate_auth_tests(endpoint, method, operation)) # 生成并发测试 if method in ["POST", "PUT", "DELETE"]: tests.append(self._generate_concurrency_test(endpoint, method)) return tests def _generate_boundary_tests(self, endpoint, method, operation): """生成边界值测试""" tests = [] for param in operation.get("parameters", []): if param["in"] == "query": schema = param.get("schema", {}) if schema.get("type") == "integer": tests.append({ "name": f"测试 {param['name']} 最小值", "request": {param["name"]: schema.get("minimum", 0)} }) tests.append({ "name": f"测试 {param['name']} 最大值", "request": {param["name"]: schema.get("maximum", 999999)} }) tests.append({ "name": f"测试 {param['name']} 超范围", "request": {param["name"]: schema.get("maximum", 999999) + 1}, "expected_status": 400 }) return tests 智能回归测试 测试选择 代码变更后不需要运行所有测试，AI可以预测哪些测试可能受影响： ...

从零开始构建AI Agent评估管线 “没有度量就没有改进”——这句话对AI Agent尤其成立。一个没有评估管线的Agent项目，就像在没有仪表盘的飞机上飞行。本文是一份从零开始构建Agent评估管线的实操指南。 评估管线的整体架构 一个完整的Agent评估管线包含五个核心模块： 指标体系：定义"什么算好" 数据集：定义"在什么上评估" 评估器：执行评估的逻辑 报告系统：可视化评估结果 持续集成：将评估嵌入开发流程 模块一：指标体系设计 指标分类框架 我们将Agent评估指标分为四层： 任务完成层（最基础）： 成功率：任务是否完成 完成时间：从开始到完成的时间 步数效率：完成任务用的对话轮次/工具调用次数 质量层： 正确性：输出是否准确 完整性：是否覆盖了所有要求 相关性：输出是否切题 交互层： 理解准确度：是否正确理解了用户意图 澄清频率：需要多少次澄清才能理解 错误恢复率：出错后能否恢复 安全层： 安全通过率：安全测试集的通过率 过度拒绝率：安全请求被误拒的比例 越狱成功率：攻击测试的成功率 指标定义的SMART原则 每个指标必须满足： Specific：明确定义计算方法 Measurable：可量化计算 Actionable：指标变化能指导行动 Relevant：和产品质量相关 Trackable：可追踪趋势 反例：“用户满意度”——太模糊，无法计算。 正例：“用户在Agent完成任务后点击’满意’按钮的比例”——可计算、可追踪。 模块二：评估数据集构建 数据集类型 Golden Set：人工标注的标准问答对，有唯一正确答案。用于回归测试。 Evaluation Set：人工标注的开放性任务，可能有多种正确答案。用LLM-as-Judge评分。 Adversarial Set：红队设计的攻击性输入。用于安全测试。 Real-world Set：从真实用户对话中抽样（脱敏后）。用于反映实际使用场景。 数据集构建流程 需求分析：确定需要评估哪些能力和场景 种子设计：为每个场景设计3-5个种子案例 扩增：用LLM基于种子生成更多变体 人工审核：过滤质量不高的扩增案例 标注：为每个案例标注期望结果或评分标准 版本管理：数据集版本化，支持增量更新 数据集规模建议 类型 最小规模 推荐规模 更新频率 Golden Set 100 500+ 季度 Evaluation Set 50 200+ 月度 Adversarial Set 30 100+ 月度 Real-world Set 200 1000+ 周度 模块三：评估器实现 精确匹配评估器 适用于有唯一正确答案的任务： ...

AI生成代码的质量评估方法 AI生成代码的质量评估是一个看似简单实则复杂的问题。“代码能跑"只是最低标准，真正的质量评估需要从功能正确性、安全性、可读性、可维护性等多个维度进行。 评估的维度 功能正确性 最基础的维度——代码是否实现了预期功能。评估方法包括： 单元测试通过率：为生成代码编写单元测试，统计通过率。HumanEval和MBPP等基准数据集采用的就是这种方法。但单元测试的覆盖率决定了评估的可靠性——高通过率不代表代码正确，可能是测试不够全面。 差分测试：将AI生成的代码与已知正确的实现进行输入输出对比。这种方法不需要手写测试用例，但需要参考实现，且只能发现行为差异，不能判断哪个实现更正确。 变异测试：对AI生成的代码进行随机变异（改变操作符、删除语句等），然后检查测试是否能检测到变异。变异测试评估的是测试质量，间接评估了代码的正确性边界。 代码安全性 AI生成代码可能包含安全漏洞——SQL注入、缓冲区溢出、不安全的加密使用等。我们使用静态分析工具（如Semgrep、CodeQL）扫描生成代码中的安全模式。 在一项针对500段AI生成代码的分析中，我们发现约12%的代码包含至少一个安全问题。最常见的是硬编码凭证（28%）、不安全的反序列化（22%）和缺失的输入验证（19%）。 代码可读性 可读性是主观的，但可以通过一些客观指标近似：命名规范性、函数长度、嵌套深度、注释覆盖率等。我们定义了一个可读性评分公式，综合这些指标给出0-100的分数。 有趣的是，不同模型在可读性上的差异显著。一些模型倾向于生成紧凑但难以理解的代码，另一些则生成冗长但清晰的代码。这反映了训练数据中代码风格分布的差异。 代码可维护性 可维护性关注代码是否易于修改和扩展。评估指标包括：模块化程度、耦合度、单一职责原则遵循度等。这些指标难以自动计算，我们采用LLM-as-Judge的方法——用一个强大的模型对生成代码的可维护性进行评分。 评估框架 我们构建了一个多维代码评估框架： CodeQuality = w1 * Correctness + w2 * Security + w3 * Readability + w4 * Maintainability + w5 * Efficiency 权重根据应用场景调整。对于原型开发，Correctness权重最高；对于生产代码，Security和Maintainability权重更高；对于性能敏感场景，Efficiency权重最大。 效率维度 效率维度评估代码的时间和空间复杂度。我们采用实际运行benchmark而非理论分析——在标准输入集上测量运行时间和内存使用，与基线实现对比。 AI生成代码的效率往往低于人类专家代码。原因是AI倾向于使用更直接但效率较低的实现方式，而非经过优化的算法。在排序、搜索等经典算法上，AI代码平均比最优实现慢1.5-3倍。 评估的挑战 测试Oracle问题 功能正确性评估需要一个"正确答案"作为参考。但很多编程任务没有唯一的正确输出——实现同一个功能有多种合理方式。如何判断AI生成的不同实现是否等价，是一个根本性难题。 上下文依赖 代码质量高度依赖上下文。一段在Web应用中完全合格的代码，在嵌入式系统中可能完全不可接受。评估框架需要根据目标环境调整评判标准。 长尾问题 AI生成代码的失败模式呈现长尾分布——大部分问题集中在少数几个类别，但还有大量罕见的、意想不到的问题。评估框架需要持续更新，纳入新发现的失败模式。 自动化评估的局限 完全自动化的评估是不可能的——至少在可预见的未来。原因在于代码质量的某些维度（如架构合理性、业务逻辑正确性）需要人类的专业判断。 我们推荐"自动化+人工"的混合评估流程：自动化工具覆盖80%的常规检查，人工审查聚焦在20%的高风险区域——架构设计、安全关键逻辑、复杂业务规则。 结语 AI生成代码的质量评估不仅是一个测量问题，更是一个改进工具。通过系统化的评估，我们可以识别AI编程模型的薄弱环节，指导模型改进方向。随着AI编程能力的提升，评估框架也需要同步进化——今天的严格标准可能是明天的最低门槛。 本文同步发布于 硅基AGI论坛

AI生成代码的质量评估方法 AI生成代码的质量评估是一个看似简单实则复杂的问题。“代码能跑"只是最低标准，真正的质量评估需要从功能正确性、安全性、可读性、可维护性等多个维度进行。 评估的维度 功能正确性 最基础的维度——代码是否实现了预期功能。评估方法包括： 单元测试通过率：为生成代码编写单元测试，统计通过率。HumanEval和MBPP等基准数据集采用的就是这种方法。但单元测试的覆盖率决定了评估的可靠性——高通过率不代表代码正确，可能是测试不够全面。 差分测试：将AI生成的代码与已知正确的实现进行输入输出对比。这种方法不需要手写测试用例，但需要参考实现，且只能发现行为差异，不能判断哪个实现更正确。 变异测试：对AI生成的代码进行随机变异（改变操作符、删除语句等），然后检查测试是否能检测到变异。变异测试评估的是测试质量，间接评估了代码的正确性边界。 代码安全性 AI生成代码可能包含安全漏洞——SQL注入、缓冲区溢出、不安全的加密使用等。我们使用静态分析工具（如Semgrep、CodeQL）扫描生成代码中的安全模式。 在一项针对500段AI生成代码的分析中，我们发现约12%的代码包含至少一个安全问题。最常见的是硬编码凭证（28%）、不安全的反序列化（22%）和缺失的输入验证（19%）。 代码可读性 可读性是主观的，但可以通过一些客观指标近似：命名规范性、函数长度、嵌套深度、注释覆盖率等。我们定义了一个可读性评分公式，综合这些指标给出0-100的分数。 有趣的是，不同模型在可读性上的差异显著。一些模型倾向于生成紧凑但难以理解的代码，另一些则生成冗长但清晰的代码。这反映了训练数据中代码风格分布的差异。 代码可维护性 可维护性关注代码是否易于修改和扩展。评估指标包括：模块化程度、耦合度、单一职责原则遵循度等。这些指标难以自动计算，我们采用LLM-as-Judge的方法——用一个强大的模型对生成代码的可维护性进行评分。 评估框架 我们构建了一个多维代码评估框架： CodeQuality = w1 * Correctness + w2 * Security + w3 * Readability + w4 * Maintainability + w5 * Efficiency 权重根据应用场景调整。对于原型开发，Correctness权重最高；对于生产代码，Security和Maintainability权重更高；对于性能敏感场景，Efficiency权重最大。 效率维度 效率维度评估代码的时间和空间复杂度。我们采用实际运行benchmark而非理论分析——在标准输入集上测量运行时间和内存使用，与基线实现对比。 AI生成代码的效率往往低于人类专家代码。原因是AI倾向于使用更直接但效率较低的实现方式，而非经过优化的算法。在排序、搜索等经典算法上，AI代码平均比最优实现慢1.5-3倍。 评估的挑战 测试Oracle问题 功能正确性评估需要一个"正确答案"作为参考。但很多编程任务没有唯一的正确输出——实现同一个功能有多种合理方式。如何判断AI生成的不同实现是否等价，是一个根本性难题。 上下文依赖 代码质量高度依赖上下文。一段在Web应用中完全合格的代码，在嵌入式系统中可能完全不可接受。评估框架需要根据目标环境调整评判标准。 长尾问题 AI生成代码的失败模式呈现长尾分布——大部分问题集中在少数几个类别，但还有大量罕见的、意想不到的问题。评估框架需要持续更新，纳入新发现的失败模式。 自动化评估的局限 完全自动化的评估是不可能的——至少在可预见的未来。原因在于代码质量的某些维度（如架构合理性、业务逻辑正确性）需要人类的专业判断。 我们推荐"自动化+人工"的混合评估流程：自动化工具覆盖80%的常规检查，人工审查聚焦在20%的高风险区域——架构设计、安全关键逻辑、复杂业务规则。 结语 AI生成代码的质量评估不仅是一个测量问题，更是一个改进工具。通过系统化的评估，我们可以识别AI编程模型的薄弱环节，指导模型改进方向。随着AI编程能力的提升，评估框架也需要同步进化——今天的严格标准可能是明天的最低门槛。 本文同步发布于 硅基AGI论坛

引言 LLM应用的测试与传统软件测试截然不同：输入空间无限大、输出不确定、质量主观。2026年，LLM自动化测试已经形成了一套完整的方法论和工具链。本文将系统介绍如何构建LLM自动化测试体系。 LLM测试的挑战 挑战一：输入空间无限 传统软件的输入是结构化的（如表单字段），而LLM的输入是自由文本，可能的组合无限多。 挑战二：输出不确定 同一个输入，LLM可能给出不同的输出（即使temperature=0，不同版本也可能不同）。 挑战三：质量主观 “好的回答"的定义因任务、用户、上下文而异。 挑战四：成本高 每次测试都需要调用LLM API，大规模测试成本可观。 测试分层架构 ┌─────────────────────────────────┐ │ 端到端测试 (E2E) │ ← 模拟真实用户场景 ├─────────────────────────────────┤ │ 集成测试 │ ← 测试模块间协作 ├─────────────────────────────────┤ │ 提示测试 │ ← 测试提示效果 ├─────────────────────────────────┤ │ 单元测试 │ ← 测试单个功能 └─────────────────────────────────┘ 第一层：单元测试 测试LLM的基本功能： class TestLLMUnit: def test_json_output(self): """测试JSON输出格式""" response = llm.generate("输出JSON格式：{\"name\": \"test\"}") assert is_valid_json(response) def test_language_detection(self): """测试语言识别""" response = llm.generate("用中文回复：Hello") assert is_chinese(response) def test_length_constraint(self): """测试长度约束""" response = llm.generate("用50字以内回答：什么是AI？") assert len(response) <= 100 # 中文字符数 第二层：提示测试 测试提示在不同输入上的表现： class TestPrompt: def test_sentiment_analysis(self): """测试情感分析提示""" test_cases = [ {"input": "太棒了！", "expected": "positive"}, {"input": "太差了！", "expected": "negative"}, {"input": "还行吧。", "expected": "neutral"}, ] for case in test_cases: response = llm.generate(prompt.format(input=case["input"])) assert case["expected"] in response.lower() def test_robustness(self): """测试提示鲁棒性""" # 测试不同表述方式 inputs = [ "这部电影怎么样？", "你觉得这部电影如何？", "评价一下这部电影", ] responses = [llm.generate(prompt.format(input=i)) for i in inputs] # 检查输出是否一致（语义相似度） for i in range(len(responses)-1): similarity = compute_similarity(responses[i], responses[i+1]) assert similarity > 0.7 第三层：集成测试 测试多个模块协作： ...

RAG评估的困境 大多数RAG系统在上线时面临一个尴尬的问题：你知道它在工作，但你不知道它工作得有多好。 没有系统化的评估框架，调参就像蒙眼开车——你不知道改chunk_size从512到1024到底是好了还是坏了。 RAGAS（Retrieval Augmented Generation Assessment）是目前最流行的RAG评估框架，它提供了一套无需人工标注的自动化评估指标。 RAGAS核心指标体系 指标全景图 RAGAS 指标体系 │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ 检索指标 生成指标 端到端指标 │ │ │ ┌─────┼─────┐ ┌────┼────┐ ┌────┼────┐ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ 上下文 上下文 ─ 忠实 答 答 语义 答案 精确率 召回率 度 案 案 相似 相关 相 完 关 整 性 性 四大核心指标详解 指标 评估什么 范围 理想值 Faithfulness（忠实度） 答案是否忠于检索到的上下文 0-1 >0.95 Answer Relevancy（答案相关性） 答案是否回答了用户问题 0-1 >0.85 Context Precision（上下文精确率） 检索到的上下文有多少是相关的 0-1 >0.80 Context Recall（上下文召回率） 回答问题所需的信息是否都检索到了 0-1 >0.85 指标计算原理 Faithfulness（忠实度） 衡量答案中的每个claim是否能从检索上下文中找到支撑。 ...

引言 传统软件测试的基石是确定性：相同输入产生相同输出。LLM Agent 打破了这个前提，让 CI/CD 测试面临根本性挑战。2026年，随着 Agent 评估框架的成熟，一套可落地的 CI/CD 测试方法论终于成型。本文将带你构建完整的 Agent 测试金字塔。 一、Agent 测试金字塔 ┌─────────┐ │ E2E │ ← 端到端场景测试（5-10个） ┌┴─────────┴┐ │ Integration │ ← 多 Agent 协作测试（20-50个） ┌┴──────────────┴┐ │ Evaluation │ ← LLM 评判测试（50-100个） ┌┴──────────────────┴┐ │ Component │ ← 工具/Prompt 测试（200+） ┌┴──────────────────────┴┐ │ Unit Test │ ← 纯函数测试（500+） └───────────────────────────┘ 二、第一层：单元测试（确定性层） 单元测试只测试不涉及 LLM 的部分：数据处理、工具执行的解析逻辑、Prompt 模板渲染。 import pytest class TestPromptTemplate: """Prompt 模板渲染测试""" def test_system_prompt_renders_correctly(self): template = SystemPromptTemplate( role="research_assistant", tools=["search", "calculator"], constraints=["cite sources", "be concise"] ) rendered = template.render() assert "research_assistant" in rendered assert "search" in rendered assert "calculator" in rendered assert "cite sources" in rendered def test_few_shot_template_with_examples(self): template = FewShotTemplate( system="You are a classifier", examples=[ {"input": "I love it", "output": "positive"}, {"input": "Terrible", "output": "negative"}, ], query="{user_input}" ) rendered = template.render(user_input="Amazing!") assert "positive" in rendered assert "negative" in rendered assert "Amazing!" in rendered class TestToolParsing: """工具调用解析测试""" @pytest.mark.parametrize("raw_output,expected_tool,expected_args", [ ('{"tool": "search", "args": {"q": "weather"}}', "search", {"q": "weather"}), ('```json\n{"tool": "calc", "args": {"expr": "1+1"}}\n```', "calc", {"expr": "1+1"}), ('I\'ll use the search tool: {"tool": "search", "args": {"q": "news"}}', "search", {"q": "news"}), ]) def test_parse_tool_call(self, raw_output, expected_tool, expected_args): result = parse_tool_call(raw_output) assert result.tool == expected_tool assert result.args == expected_args def test_parse_malformed_output(self): with pytest.raises(ToolParseError): parse_tool_call("This is not JSON at all") 三、第二层：组件测试（Mock LLM） 使用 Mock LLM 测试 Agent 的控制流，确保工作流逻辑正确。 ...