测试开发

UI自动化测试长期面临元素定位困难、脚本脆弱、维护成本高等痛点。本文提出用AI技能链（ui-page-parser等）实现全流程自动化，核心思路是"AI解析+人工校验"。

写在开头 2026 年，国内外AI大模型已经「卷」到了一个新高度。 GPT、Claude、Gemini、GLM、DeepSeek、KIMI、Qwen……各家厂商每隔一两个月就发布新模型，声称在各项基准

前一个系列，我们用 AI + Agent Skill 把接口测试脚本"造"了出来。但脚本生成只是起点——真正让接口自动化测试产生价值的，是让脚本跑起来、修得好、清得净、出报告

Appium自2013年出现以来一直主导移动端自动化测试，但因其编写脚本繁琐、易受UI变更影响等问题，近年来受到挑战。最近出现的开源项目agent-device，通过让AIAgent

前面几篇，我们分别分享了 api-test-executor（执行）、api-failure-diagnoser（诊断修复）、api-testdata-cleaner（数据清理）、api-report

api-report-generator是一款AI驱动的接口测试报告生成工具，一句指令即可将执行数据自动转化为含11大专业分区、风险分级、优化建议及Allure联动的决策型HTML报告，告别“数字

api-testdata-cleaner 是接口自动化测试的数据清理专家，你可以把它理解成测试环境的"智能清洁工"。

写在开头 先问大家一个问题：接口测试跑完之后，你最头疼的是什么？ 大概率是这样的—— 几十条失败用例堆在面前，不知道从哪条看起； 翻日志，错误堆栈一大堆，看不出所以然； 判断是环境问题、数据问题、脚本

测试行业有句老话：“自动化测试的难点不在写脚本，而在跑脚本、看结果、修失败。” api-test-executor 解决的就是这三个难点中最关键的一环——让脚本能"听话地跑起来"。

大家好，我是狂师。 时间过得真快。一转眼，2026 年已经走过了一半，「狂师・AI 进化社」已正式成立了 4 个月。 回头看一下，今年 2 月份我宣布要做这件事的时候，写了一篇近万字的官宣文，把"AI

事情是这样的。 最近这一两年，我日常的活基本都交给 Claude Code 了。 让它帮我整理文件、写代码、查资料、做总结，凡是能交给它的我绝不动手。我自己一个很深的感受是，Agent 这种东西，你用

在 AI 全面赋能测试的今天，测试工程师的竞争力，早已不再是"会用多少工具"，而是"能否合理运用AI赋能提效到自己的工作中"。 作为测试工程师，日常工作中最耗时的不是分析问题、定位根因，而是那些重复的

一、AI 生成的脚本，真的可以直接跑吗？ 如果你跟着本系列前三篇实操过，应该已经体验到了 AI 生成脚本的"爽感"：输入一份接口文档，几分钟内就能拿到一套完整的接口自动化项目，几百条测试数据、几十个脚

在接口自动化测试的全流程中，脚本开发曾是最耗时、最考验技术功底的环节。人工编写脚本不仅要至少掌握一门编程语言，而且还要面对版本迭代快、用例量大的压力，还极易出现语法错误、场景覆盖不全、规范不统一等问题

在上一篇中，我们介绍了 api-schema-parser —— 它是接口自动化测试的"入口技能"，它能将各种格式的接口文档统一解析为标准化的 api_definitions.json。 但解析完接口

在测试领域，接口自动化测试是企业落地范围最广、投入性价比最高的自动化测试类型。 但传统开发模式下，需要人工梳理接口文档、请求参数、入参出参规则、异常参数、业务关联关系，构造测试数据、编写脚本、后续维护

做软件测试的朋友都清楚，测试用例设计有多么重要。它直接决定了测试覆盖是否全面，也直接影响了后续整体测试流程的质量。 传统模式下，大家手动一条一条编写用例，不仅耗时费力，还经常因为考虑不周，漏掉异常场景

前两天刷知乎的时候，看到一个很有意思的帖子，标题叫：《面试官问：你用 AI 编程半年了，那怎么保证 Claude Code 写出来的代码是对的？》 翻完评论区，我没有找到特别满意的答案，反而越发有感触

从本篇教程开始，我们将沿着软件测试全流程，逐环节、逐步骤深度拆解，系统学习如何借助 AI + Agent Skill，为测试工作的每个核心节点赋能提效。 我们的第一站，便是软件开发全流程的起点 ——需