花了幾個月，終於搭建好測試全流程 Skill

2026-11-02 10

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 从年初开始，我断断续续一直在搭建测试相关的提效 Skill。最初只是想解决几个具体问题：需求文档太长，怎么更快梳理测试点；接口文档不完整，怎么辅助生成用例；重复的页面操作，能不能交给自动化工具执行。但随着使用场景越来越多，我逐渐发现，单独解决某一个环节还不够。测试工作是一条连续的链路：从理解需求、分析风险，到设计用例、准备数据、执行测试，再到提交缺陷、回归验证和结果分析。任何一个环节没有衔接好，后面的效率都会受到影响。于是，这件事从“做几个实用skill”，慢慢变成了“搭一套测试全流程 Skill”。前后花了几个月，目前这套体系终于基本成形：共整理了 70+ 个 Skill，覆盖用例

从年初开始，我断断续续一直在搭建测试相关的提效 Skill。

最初只是想解决几个具体问题：需求文档太长，怎么更快梳理测试点；接口文档不完整，怎么辅助生成用例；重复的页面操作，能不能交给自动化工具执行。

但随着使用场景越来越多，我逐渐发现，单独解决某一个环节还不够。

测试工作是一条连续的链路：从理解需求、分析风险，到设计用例、准备数据、执行测试，再到提交缺陷、回归验证和结果分析。任何一个环节没有衔接好，后面的效率都会受到影响。

于是，这件事从“做几个实用skill”，慢慢变成了“搭一套测试全流程 Skill”。

前后花了几个月，目前这套体系终于基本成形：共整理了 70+ 个 Skill，覆盖用例设计、接口测试、接口自动化、性能测试、UI 自动化和测试执行流程等方向。

不是把 AI 塞进测试，而是重新梳理测试流程

开发这些 Skill 的过程中，我一直在考虑一个问题：AI 到底适合放在测试流程的哪个位置？

如果只是让 AI “帮我写一份用例”，确实可以节省一点时间，但很容易停留在一次性使用的层面。输入方式不统一、输出结构不稳定，也很难和后续执行衔接。

所以这套体系没有围绕某个模型或某个工具来设计，而是围绕测试人员每天真正要完成的任务来拆分。

整体上可以分为三层：

1. 信息读取与需求分析：把需求文档、原型、接口文档和项目代码转换成可分析的结构化信息；

2. 测试设计与资产生成：输出需求分析、测试点、测试计划以及 XMind、Excel、API 等不同形式的测试用例；

3. 执行、诊断与结果沉淀：完成接口、性能和 UI 自动化执行，并辅助定位失败原因、提交缺陷和汇总结果。

这样的拆分有一个直接好处：每个 Skill 只负责解决一类明确的问题，同时又能和上下游 Skill 组合起来。

从需求输入到测试用例生成

测试工作的第一步通常不是写用例，而是准确理解需求。

但实际项目里的需求输入并不统一。有时是 PDF、Word 或 PPT，有时是 Figma、Axure、蓝湖、墨刀等原型，也可能来自飞书文档，甚至只有一部分前端或后端代码。

因此，用例生成这部分首先解决的是“如何读取需求”：

读取常见格式的需求文档；

读取不同平台的产品原型；

从项目代码中提取已有业务逻辑；

在原始材料不完整时，对需求内容进行整理和补充。

信息读取之后，再进入需求分析、测试视角评审和测试点拆分。确认范围后，才生成 XMind、Excel 或 API 测试用例，并增加对应的用例评审环节。

这条链路的重点不是追求“一键生成”，而是尽量减少前期的机械整理，让测试人员把时间放在业务规则、风险判断和覆盖完整性上。

因为需求里的隐含规则、历史问题和真实优先级，仍然需要测试人员结合项目背景做判断。

接口测试：先建立信息，再生成脚本

接口测试部分也采用了类似思路。

在不少项目中，真正影响接口测试效率的并不是脚本怎么写，而是前置信息不完整：接口文档没有及时更新、字段依赖不清楚、上下游关系分散在多个系统里。

针对这些问题，目前的 Skill 覆盖了几类工作：

读取 Swagger、YApi 等接口文档；

根据项目代码生成接口说明；

通过抓包信息还原接口；

分析接口之间的依赖关系；

生成接口测试计划、测试用例和 Pytest 自动化代码；

执行用例并汇总 Allure 报告；

分析失败原因，辅助修复脚本。

这套流程并不要求所有项目都从头走到尾。文档齐全时可以直接生成测试计划和用例；缺少接口说明时，可以先通过代码或抓包补齐信息；已有测试代码时，也可以只使用执行、报告和失败诊断相关能力。

性能测试也是同样的逻辑：从澄清压测需求、生成测试计划开始，到准备数据、校验环境、生成 JMeter 脚本、分析结果，再到根据性能指标定位瓶颈，形成一条相对完整的流程。

自动化测试不只是一种方案

UI 自动化是目前 Skill 数量最多的一部分，也是实际差异比较大的一个领域。

不同团队的技术栈、测试对象和维护成本差别很大，很难用一种工具覆盖所有场景。因此，我没有把 UI 自动化限定为单一方案，而是按照测试端和项目条件进行了拆分。

Web 端包含 Playwright Test、Playwright CLI、Browser Use、Midscene.js 等不同实践；移动端覆盖 Appium 和 Maestro；此外还包括小程序端、桌面端以及鸿蒙应用相关方案。

有些方案适合沉淀长期维护的自动化项目，有些更适合快速生成和执行一次性任务，还有一些更强调自然语言描述和视觉识别。选择时不能只看“能不能跑起来”，还要考虑：

团队是否熟悉对应技术栈；

脚本是否需要长期维护；

页面结构是否稳定；

是否涉及多端、多设备或复杂交互；

失败后是否容易定位原因；

现有项目能否方便接入。

所以，这部分 Skill 的目标不是给出一个统一答案，而是为不同场景提供可以落地的路径。

把测试执行之后的工作也接起来

很多提效方案会停在“生成用例”或“生成脚本”，但在实际工作中，测试执行之后还有大量工作：

根据代码改动判断回归范围；

结合代码和用例提前识别风险；

扫描源码中的并发等潜在问题；

根据接口文档或表结构构造测试数据；

梳理业务流程和编写操作手册；

将缺陷提交到 TAPD、禅道或 Jira；

汇总并分析缺陷数据。

这些任务单独看都不复杂，但频繁切换工具、整理格式和重复录入会消耗不少时间。

因此，我把它们也纳入了测试全流程 Skill。只有把需求、设计、执行、缺陷和结果分析连接起来，这套体系才真正接近测试人员日常工作的完整链路。

我的设计思路

1. 先解决真实问题

这套体系里的很多 Skill，都来自测试小伙伴反馈的实际需求。

哪些工作最耗时间，哪些环节最容易遗漏，哪些工具在真实环境里不好接入，我会先确认场景，再考虑如何实现。相比功能数量，我更看重它是否能在具体项目里完成任务。

2. 保留人工确认环节

AI 可以帮助读取资料、整理结构、生成初稿和执行重复操作，但不能替代测试人员对业务风险的判断。

例如，AI 可以从需求文档中生成测试点，却不知道某个看似普通的字段曾经引发过线上故障；可以根据页面生成自动化脚本，却无法自行决定这段脚本是否值得长期维护。

因此，需求评审、用例评审、风险确认和结果判断仍然是整套流程中的必要环节。

3. 让 Skill 可以组合和复用

不同项目的流程并不完全相同。小需求可能只需要需求分析和用例生成；接口项目可能更关注文档、依赖关系和自动化执行；多端项目则需要组合 Web、APP 或小程序相关能力。

相比做一套固定且庞大的流程，我更希望每个 Skill 都有清晰的输入、输出和职责，使用者可以根据项目情况自由组合。

核心价值

现阶段，我认为这套 Skill 的价值主要体现在三个方面。

第一，减少重复整理。读取文档、转换格式、搭建用例框架、生成基础脚本、汇总执行结果，这些工作可以交给工具先完成。

第二，让流程更规范。即使不同测试人员负责不同项目，也可以通过统一的分析、设计、评审和执行步骤，减少因个人习惯造成的遗漏。

第三，降低尝试新方案的成本。面对接口自动化、性能测试或多端 UI 自动化时，可以先用对应 Skill 搭建可运行的基础版本，再结合项目实际情况继续完善。

但它不会让测试工作变成完全自动化。需求理解是否准确、风险判断是否合理、用例是否真正覆盖业务，最终仍然取决于使用者。

写在最后

从最初几个零散的 Skill，到现在覆盖测试全流程的70多个 Skill，这个过程比预想中花了更长时间。

中间做过不少调整，也反复验证过不同工具和方案。有些思路看起来很好，但放到真实项目里并不稳定；有些能力单独使用效果不错，却很难接入现有流程。只有经过实际使用和反馈，才能慢慢把边界梳理清楚。

期间也收到了不少测试小伙伴的认可和建议，这些反馈是我持续更新的重要动力。

目前这套体系已经完成了基础框架，但还不是终点。接下来仍会围绕真实测试场景继续补充和优化，包括输出质量、工具兼容性、执行稳定性以及不同 Skill 之间的衔接。

如果你也在尝试把 AI 引入测试工作，我的建议是：不必一开始就追求全自动化。先找到流程里最重复、最耗时、规则相对明确的一小段，把它真正跑通，再逐步向前后环节扩展。