同样是做测试这两年的工作对象已经换了。以前主要盯页面、接口、数据库、日志。现在一个需求上线背后可能串着浏览器调试、代码仓库、工单系统、设计产物、模型服务、语音接口、外部工具调用甚至跨数据中心的推理链路。Chrome DevTools MCP 已经能让 MCP 客户端驱动浏览器并记录 performance traceBolt Connectors 明确基于 MCP把 Notion、GitHub、Jira、Sentry 这类工程上下文接进工作流Claude Design 也已经支持导出到 Canva、PDF、PPTX、HTML并把 handoff bundle 直接交给 Claude Code。再往底层看变化还在继续下沉。DeepSeek 的 DeepGEMM 已经把大模型核心计算库做成统一的 CUDA 代码库并通过轻量 JIT 在运行时编译Moonshot/Kimi 的新论文开始讨论跨数据中心的 Prefill-as-a-Service把长上下文 prefill 和 decode 拆开并把 KV Cache 传到本地解码集群xAI 新发布的语音接口把 STT 价格继续压低OpenClaw 相关部署风险则已经被监管和安全圈持续提醒。这对测试岗位的影响很直接被测对象已经从“一个应用”扩展成“多上下文、多工具、多执行环境、多算力层”的长链路系统。测试边界先变岗位考核后变。能跑通脚本已经不够能解释失败原因才开始有区分度。Agent 项目最难上线的地方往往不是演示效果而是权限与审计。一、被测对象已经从“应用”变成“链路”现在很多测试同学会觉得工作越来越碎问题越来越难复现定位越来越慢。 这不是个人感觉出了偏差而是系统形态真的变了。Chrome DevTools MCP 让浏览器不再只是被点开的页面而是变成一个可以被 MCP 客户端直接观察和分析的运行环境。Bolt Connectors 把文档、工单、仓库、监控等工具直接接进上下文。Claude Design 则把设计稿、可编辑产物和代码交接继续往同一条链路上拉。原来分散在设计、研发、调试、执行、回归、交付中的能力正在被同一条工作流重新编排。这会带来一个非常实际的变化 缺陷不再只出现在“某个页面按钮点不了”这种单点问题上而会出现在链路之间。需求文档理解偏了后面的生成逻辑就会偏。 工单上下文拿错了自动化用例就会测偏。 页面能打开但控制台报错、网络抖动、trace 异常用户照样会卡。 模型本身没换但缓存策略、算子实现、资源调度一变性能和成本就可能完全改观。所以现在再谈“测试对象”已经不能只盯某一个功能点。 真正的测试对象是这条链从输入、上下文、执行、调用到回写的整体行为。二、系统一旦长链路化测试入口就必须前移以前很多团队的测试入口在研发后面。 页面出来了接口联通了再开始补功能、兼容、回归、性能。链路一旦拉长这个顺序就会越来越吃亏。因为真正影响结果的东西很多出现在代码执行之前。 比如需求文档怎么写工单字段怎么规范知识库内容是不是可检索日志和埋点能不能支撑诊断工具调用有没有权限分层设计交付是否能被后续代码和测试系统直接利用。Bolt Connectors 的价值就在这里它不是多接了几个插件而是把上下文直接从源头拿进来减少“人手复制上下文”这类高噪声动作。Claude Design 往 Canva、PPTX、HTML 和 Claude Code 的导出与 handoff也说明设计到实现之间的交接正在被进一步压缩。这意味着测试必须往前站。 不是为了抢研发的活而是因为很多后置问题本质上是前置约束没有建好。后面的测试能力差距很多不会出在“谁脚本写得更快”。 而会出在“谁更早把上下文、权限、埋点、可观测性和回归入口铺好”。三、自动化测试正在从执行脚本演进为诊断脚本这一层变化Chrome DevTools MCP 给得最直接。它不只是让 MCP 客户端把浏览器打开。官方示例里已经明确写到客户端可以驱动浏览器并记录 performance trace在连接运行中的 Chrome 时MCP server 还会访问所选 profile 下的所有打开窗口。这个能力边界已经不是传统意义上“帮你自动点页面”那么简单了。([GitHub][1])这对测试开发的影响很大。过去写 UI 自动化很多脚本价值主要体现在“执行步骤”和“断言结果”。 脚本挂了常见报错是元素没找到、页面超时、断言不通过。后面真正有价值的自动化会越来越像这样先执行操作再自动抓浏览器现场再结合 network、console、trace、页面状态做定位最后把诊断结果回写给缺陷系统或流水线这才是“长链路系统里的自动化”。因为问题越来越不是“有没有执行到第 7 步”而是“为什么执行到第 7 步时系统抖了”。 能不能把失败解释清楚会比“脚本有没有跑完”更重要。同样的变化也出现在上下文侧。Bolt 的 Connectors 可以直接连 Notion、Linear、GitHub、Miro、Sentry、Jira 等工具官方还明确写到Bolt 可以读取页面、拉取任务、创建 issue能做什么取决于 Connector 支持什么动作而且这些动作默认全部开启可按工具逐项控制。([bolt.new][3])这意味着自动化的输入也在变化。 以前自动化主要吃页面结构、接口协议和测试数据。 后面自动化还会直接吃需求文档工单状态仓库变更日志异常浏览器现场设计交接产物这已经不是传统脚本维护问题。 这是上下文治理问题。四、AI 性能测试正在下沉到算子、缓存和调度层很多团队现在谈 AI 性能测试思路还停在传统接口压测。 看 RT、TPS、错误率。 这当然有用但只够看表层。真正往下看性能问题已经在往基础设施层转移。DeepGEMM 的官方描述非常明确它是一个统一的高性能 tensor core kernel library把现代大模型里的 GEMMs、MoE、MQA scoring、HyperConnection 等关键计算原语收进同一套 CUDA 代码库而且通过轻量 JIT 在运行时编译不需要安装阶段就做 CUDA 编译。([GitHub][2])这说明什么说明模型服务的性能不再只是“请求到了模型就算完事”。 很多差异会来自算子实现精度策略kernel 调度硬件利用率通信与计算的重叠方式再看 Kimi 新论文给出的方向更直接。论文提出 Prefill-as-a-Service把长上下文 prefill 卸载到独立的高计算密度集群再把 KV Cache 通过普通以太网传给本地 PD 集群做 decode作者同时提到这个方案不是简单把 KV Cache 变小就结束而是还要配合 selective offloading、bandwidth-aware scheduling、cache-aware request placement 等系统设计。论文案例里相比基线方案拿到了更高吞吐。这一层变化对测试的启发很明确AI 性能测试不能只测接口快不快还要测系统为什么这样快为什么突然变慢。后面更该盯住的指标至少包括这些首 token 延迟长上下文吞吐尾延迟batch 策略波动KV Cache 命中与迁移成本不同精度 / 不同硬件下的结果与性能双回归谁还把 AI 性能测试只理解成“压接口”后面一定会遇到解释不了的问题。五、多模态一旦进入常规交付语音测试会快速补课很多团队以前不怎么碰语音不是因为不需要而是因为成本、接入复杂度和交互链路都偏高。xAI 最新公布的语音接口价格里STT 批处理是每小时 0.10 美元流式是每小时 0.20 美元。官方同时把电话、会议、视频/播客、电话场景等作为评估维度列了出来。([xAI][5])价格往下走企业把语音接进客服、助手、办公、教育、车载这些场景的意愿就会上来。 一旦进入常规交付测试就不能继续停在 demo 级验证。后面语音测试会很快补这些能力ASR 准确率与领域词识别TTS 一致性与自然度打断、插话、重试弱网、噪声、回声流式返回时延多轮上下文保持语音链路里的权限与数据合规这也是为什么很多看上去“和测试没关系”的接口降价实际会直接改写测试工作量结构。 成本一降试验品就容易变成正式需求。 正式需求一上生产测试方法就必须跟上。六、Agent 能不能上线卡点通常落在权限边界Agent 项目最容易被低估的不是效果评估而是安全测试。OpenClaw 的例子已经很典型。Reuters 报道里提到中国工信部曾警告 OpenClaw 在配置不当时可能带来网络攻击和数据泄露风险并要求部署组织审计公网暴露、加强身份认证和访问控制。同一篇报道还提到Moltbook 暴露出的安全缺陷让数千人的私有数据受到影响。([Reuters][6])这件事对测试团队的提醒非常直接Agent 一旦获得工具权限风险就不再只是“答错一句话”。它可能会越权读取内容误删文件误发消息错改任务状态调用不该调用的外部能力在多工具链路里把一次错误放大成系统性事故所以后面的智能体测试基础项至少应该包括最小权限高风险操作确认插件与工具白名单审计日志凭证隔离回滚与熔断异常行为告警很多团队现在把这些当成上线前补充检查。 这个顺序后面会越来越危险。 权限边界本身就应该是测试范围的一部分。七、岗位不会先消失考核方式会先改写很多人最关心的问题还是那个 测试岗位会不会被替代我更倾向于先看另一个变化。 岗位名称未必先变考核方式会先变。以前很多团队看的是用例写了多少回归跑完没有bug 提了多少自动化覆盖率到了没有后面越来越多的团队会看这些能不能把问题定位到链路中的具体一层能不能把自动化从执行扩展到诊断能不能建立 AI 服务的性能基线能不能把权限、审计、可观测性纳入测试设计能不能把文档、工单、日志、浏览器、模型服务串成可回归的闭环这对三类人影响都很大。对在校生来说最重要的不是把所有新词背下来而是知道行业现在到底在测什么。 对初级工程师来说最关键的是别停在“会跑工具”。 对中级工程师来说真正拉开差距的是能不能把测试方法从短链路系统升级到长链路系统。可以把这两类工作方式放在一起看维度传统自动化测试链路型测试关注对象页面、接口、数据库上下文、工具调用、模型服务、权限边界自动化目标执行步骤、断言结果执行、诊断、回写、解释失败性能视角RT、TPS、错误率首 token、吞吐、缓存、调度、尾延迟风险重点功能正确性权限、审计、工具边界、数据暴露方法难点脚本维护上下文治理、可观测性、系统级定位这不是为了制造焦虑。 它只是把岗位变化说得更准确一点。测试这行后面不会只剩一种能力。 但只会页面点点点、接口压一压、脚本跑一跑这条路会越来越窄。系统已经从单体应用走到了长链路协同。 测试方法要不要跟着升级已经不是一个学习态度问题而是交付能力问题。你现在手里的项目测试关注点还停在页面和接口还是已经开始覆盖上下文、浏览器诊断、模型性能、工具权限和审计闭环了霍格沃兹测试开发学社是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区