前提概要

AI时代发展太快了，现在接口自动化不接入AI的，真的跟不上了。我在原有框架上加入了skill能力，项目命名为k6auto，定位是全栈自动化测试框架。

目前该项目完成度也有80%，其中接口自动化部分完成度100%，已拿实际项目做出了实际效果。项目目前代码中涉密比较多，性能方面完成度还不够，所以还没开源。预计年底会开源到社区，这阶段还需要再打磨打磨。

为啥做这个k6auto？有什么优势？

以下摘抄自项目的readme：

传统的测试工具往往只能覆盖单一测试类型，而 k6auto 打破了这个限制。我们基于 k6 核心引擎，通过自研扩展和工程化封装，打造了一个真正的一体化测试框架。

核心优势

特性 |
说明 |
价值 |

自研 k6 扩展生态 |
自研 xk6-zap 高性能日志等扩展 |
突破原生 k6 功能边界，满足复杂业务场景 |

全测试类型覆盖 |
API 自动化 + 接口性能 + 前端性能 + WebSocket + 数据库 + 中间件 |
一套框架，全链路质量保障 |

Allure 企业级报告 |
美观的 HTML 报告，支持步骤追踪、失败分析、历史趋势 |
让测试结果一目了然，提升团队协作效率 |

云原生架构 |
完整的 Dockerfile + K8s Deployment 配置 |
轻松实现容器化部署和弹性扩缩容 |

高性能日志引擎 |
基于 Uber Zap 的高性能日志扩展 |
海量并发下依然保持稳定的日志记录 |

WebSocket 实战 |
支持多人协同文档、实时通信场景测试 |
覆盖现代 Web 应用的核心交互场景 |

场景化编排 |
支持 setup/teardown、数据驱动、复杂业务流程 |
灵活应对各种业务测试需求 |

AI 驱动开发 |
集成 k6skill，覆盖接口封装、场景编排、性能压测与调试 |
提升测试脚本开发效率，降低人工编写成本 |

技术架构```
┌──────────────────────────────────────────────────────────────────────────┐
│ k6auto 自动化测试框架 │
├──────────────────────────────────────────────────────────────────────────┤
│ API 自动化层 │ 性能测试层 │ 前端性能层 │ WebSocket 层 │
│ ├─ apiTest │ ├─ performance │ ├─ browser │ ├─ scen │
│ ├─ 场景编排 │ ├─ 高并发压测 │ ├─ Core Web │ ├─ 协同文档 │
│ ├─ 数据驱动 │ ├─ 统一断言 │ ├─ 页面交互 │ ├─ 实时通信 │
│ └─ 通用日志 │ └─ 数据采集 │ └─ 可视化指标 │ └─ 场景定义 │
├──────────────────────────────────────────────────────────────────────────┤
│ k6 扩展层 │
│ ├─ xk6-zap: 高性能结构化日志 ├─ xk6-sql: 数据库操作 │
│ ├─ xk6-file: 文件读写支持 └─ 更多扩展 │
├──────────────────────────────────────────────────────────────────────────┤
│ 基础设施层 │
│ ├─ Allure 报告 ├─ Docker 容器化 ├─ Kubernetes 编排 │
│ ├─ Chai 断言库 ├─ PostgreSQL ├─ Redis 缓存 │
│ └─ 消息/协同能力 └─ 其他中间件 │
├──────────────────────────────────────────────────────────────────────────┤
│ AI 辅助层 (k6skill) │
│ ├─ curl 转接口 ├─ 业务流程转场景 │
│ ├─ 性能压测场景 └─ 场景调试执行 │
└──────────────────────────────────────────────────────────────────────────┘

- k6auto 演示视频

视频中没任何声音，所以请参考我这里的解说：

视频开头就是我的提示词：请帮我完成一个xx场景，然后后面就是场景的步骤：先帮我找到下拉字段；然后帮我加入xx值，【此处贴了一段页面上复制过来的curl】；然后创建测试设计；然后干嘛干嘛，贴curl。

整个做法就是手写场景，直接贴curl，k6skill会自动帮你完成接口自动化编写，并且能帮你自动调试修正问题。AI会复用已有的接口，比如`创建测试设计`，我这里没贴curl的，不需要，因为已经有这个接口了，AI会自己找到并复用。有的curl贴多了也没事，AI也会先复用已有接口，如果是新接口，AI会自己判断要写入哪个文件，并询问你意见。

这个贴curl让AI写，其实提速已经非常可怕了，平常这个复杂的场景，给普通测试得写一天半天的。附个演示视频的最终效果图：

![图片](https://cdn3.ldstatic.com/optimized/4X/4/9/9/4991586c1c36b785fb10b2fe1308becdbb813756_2_530x500.png)

为什么是curl？其实想改成其他都行，什么接口文档，swagger之类的。只是这类东西基本没人维护，不是很靠谱。我综合实际情况，认为直接从页面上复制curl粘贴过来，最靠谱，也很简单。所以就做成这个。

智能特性

能力 |
说明 |

**统一 Skill 入口** |
`k6skill` 统一承接 curl 转接口、场景编写、性能压测和调试执行 |

**自动对齐项目风格** |
生成或修改代码时优先适配现有 `apiTest/`、`scenarios/` 和通用请求封装 |

**重复接口识别** |
新增接口前会搜索已有方法、路由和描述，避免重复封装 |

**敏感信息规避** |
不把 curl 中的 Cookie、token、租户或固定业务数据直接写死到代码 |

**场景化编排** |
支持将多步骤业务流程沉淀为可复用的场景方法 |

**调试闭环** |
可更新 `scenario_debug.js` 并执行指定场景，结合日志定位问题 |

Skill 配置

统一配置位于 `skills/k6skill/SKILL.md`，按任务类型拆分引用文档：

- `references/curl-to-api.md`：curl 转接口

- `references/scenario-authoring.md`：业务场景编写

- `references/performance-scene.md`：性能压测场景

- `references/scenario-debug.md`：场景调试执行

全栈能力？

除了核心的接口自动化，前端性能，后端压测，后端各种协议测试，socket、RPC、MQ，谷歌的protobuf，均可以一套框架完成。目前项目中已经实战了协同文档压测。RPC和protobuf也有demo例子。这不知道算不算全栈能力。以往那些框架感觉总是覆盖单一类型，做好多套，很麻烦。k6auto目前只在UI自动化上我没有太好方式，其他我都是做过实践的，代码也是写了demo样例。接口自动化是优先主打了，所以已经写了比较多的场景。

意见咨询

佬们可以看看演示视频，如果这套给你们用，觉得方式如何？手写场景，贴curl，这种可还行？

有什么意见都可以说说，我也好借鉴借鉴。