从狂热到理性大模型在测试内部落地的实战复盘

twc829

165人浏览 · 2026-03-22 11:54:38

twc829 · 2026-03-22 11:54:38 发布

从狂热到理性：大模型在测试内部落地的实战复盘

一、理想与现实的差距

推动大模型技术在组织内部落地，从来不是一帆风顺的浪漫之旅。最初以为这只是"水到渠成的小工程"，毕竟开源工具和云服务触手可及。然而真正推进时才发现，这是一场旷日持久的"拉锯战"，其艰难程度远超传统的 DevOps 转型。

两类根深蒂固的阻力

第一类：害怕而拒绝

AI 技术带来的效率跃升，也伴随着岗位重组的焦虑。许多资深工程师担心大模型的"黑箱"性质会削弱测试过程的可控性，本能地筑起防线，表面点头称是，私下却"阳奉阴违"。

第二类：不相信

不相信大模型的能力，也不相信它能真正帮助工作。这种不信任源于对技术的未知和误解。

二、第一阶段：消除疑惑，拥抱智能化

策略：从 RAG 开始，化繁为简

第一次大规模推广时，选择了基于 Dify 平台的测试用例生成智能体作为切入点。

反直觉的策略设计：

故意打乱传统知识点讲解顺序，避免入门级劝退
直接从 RAG 内容讲起，展示如何快速搭建 RAG 应用
简化配置步骤，省略潜在调试坑点
让现场观众产生"原来这么简单"的错觉

成果：意外的繁荣

一周内，测试团队对大模型的"芥蒂"烟消云散
跨团队的用例生成采纳率稳定在 60% 左右
各团队开始主动构建自己的专属智能体
需求完善智能体、测试分析智能体、多智能体协同系统如雨后春笋

三、第二阶段：乐极生悲，进入绝望之谷

大胆尝试：自研接口测试生成系统

在 Dify 智能体繁荣的鼓舞下，测试开发团队决定从零搭建完整的大模型生成接口测试功能体系：

API 规格文档解析
大模型提示工程优化
输出测试脚本的自动化校验
无缝集成到现有测试管理平台

现实打击：从热捧到冷场

平台正式开放后，从零星试用到迅速冷却至无人问津，整个过程不超过两周。

用户吐槽点总结

问题类别	具体表现
流程刚性	缺乏灵活干预机制（暂停、参数调整、临时调试）
等待时间长	LLM 处理复杂任务耗时久，尤其高负载下
产出不稳定	受模型性能、输入数据、算力影响，质量不一致
缺乏个性化	流程与配置过于通用，无法适配不同项目需求
反馈循环不足	问题反馈机制迟缓，长期痛点未解

根本原因

禀赋效应的影响：Dify 智能体的繁荣影响了团队的正确思考。大家对大模型生成接口测试功能的要求和测试管理平台一样，容忍度一点也没有变化。

禀赋效应：人们一旦拥有某样东西，就会不由自主地高估它的价值。谁都想让别人知道"我的想法有多优秀"，因此一直推销自己设计的智能体，满足成就感。

步子迈大了，太着急了——没有真正将"大模型能够帮助我们提升效率"的理念植入每个人心里。

四、第三阶段：重整出发，开悟之坡

MCP 的启示

MCP（Model Context Protocol）的横空出世提供了新的思路。开始打造自己的 MCP Servers，但吸取了前面的教训：

提供已经封装好的 MCP Server
分享使用例子
但不分享如何开发——避免重蹈 Dify 的覆辙

MCP Server 封装的最佳实践

1. 控制加载数量，整合相关 API

# 不好的做法：为每个 API 单独创建 MCP Server
# mcp-server-login, mcp-server-logout, mcp-server-get-user...

# 好的做法：将相关 API 整合到一个 MCP Server
@mcp.tool()
async def user_login(credentials: dict) -> str:
    """用户登录"""
    pass

@mcp.tool()
async def user_logout(user_id: str) -> str:
    """用户登出"""
    pass

@mcp.tool()
async def get_user_info(user_id: str) -> str:
    """获取用户信息"""
    pass

2. 命名要有具体含义

不好的命名	好的命名
`tool1`, `api_call`	`jira_search`, `browser_navigate`
`get_data`	`shell_execute_command`

命名也是工具提示词的一部分，要做到见名知意。参考 Claude 的做法：

浏览器相关工具以 browser_ 开头
命令行相关工具以 shell_ 开头

3. 返回有价值的信息

# 不好的做法：返回原始平台 API 的完整响应
{
    "id": "10001",
    "di": "xyz123",  # 无语义内容，占 Tokens
    "name": "test_case_001",
    "created_at": "2024-01-01T00:00:00Z",
    # ... 大量无关字段
}

# 好的做法：二次加工，只返回最有用的内容
{
    "test_case_name": "用户登录成功场景",
    "test_steps": [
        "输入有效用户名和密码",
        "点击登录按钮",
        "验证跳转至首页"
    ],
    "expected_result": "登录成功，进入系统首页"
}

4. 错误返回要有意义

# 不好的做法：返回错误码
{
    "errorCode": "90001"
}

# 好的做法：返回语义信息
{
    "errorMessage": "数据库访问超时，请检查网络连接或稍后重试",
    "suggestion": "可尝试：1) 检查数据库服务状态 2) 查看网络连接 3) 联系 DBA"
}

五、关键教训总结

推广策略

阶段	策略	结果
第一阶段	从简单入手（Dify 智能体），化繁为简	成功，用户接受度高
第二阶段	自研复杂系统，期望一步到位	失败，用户弃用
第三阶段	提供封装好的 MCP Server，控制开放程度	成功，避免重蹈覆辙