接了大模型生成测试用例后，我们统计了一周数据，发现人工还得改掉 40%
大模型生成 Playwright 测试用例的实际可用率约 60%，但算上审查和重写成本，净节省开发时间仅 29%。40% 的用例需重写，主要失败在 selector 失效、时序问题、断言质量差和逻辑错误。复杂业务场景下模型表现断崖式下跌，prompt 优化效果有限。团队转而采用分层策略，将模型定位为辅助工具，最终实现稳定且可预期的效率提升。
分类: 全栈工程化
共 50 篇文章
你的 UI 测试脚本是不是也写了一堆 findElement 然后改版就全崩
UI 自动化测试失败的主因并非断言错误，而是定位器硬编码导致页面微调即崩溃。核心解决思路是建立分层防御：页面对象模型应暴露用户行为而非元素，定位器优先使用`data-testid`等稳定属性，等待逻辑需封装在框架层。测试数据必须自给自足，通过API准备以避免级联失败。还需引入组件化抽象复用交互逻辑，并完善失败诊断信息，记录URL、DOM快照等上下文。
写接口文档时，我把分页、排序、筛选参数声明复用了，结果每个接口都长得差不多，那差异化配置到底加在哪里
接口文档的复用困境源于混淆了参数声明与参数约束。解决之道在于将接口契约分为两层：结构层定义参数名称、类型等通用格式，实现复用；约束层则针对每个接口，明确具体的取值范围、白名单和业务规则，实现差异化。通过OpenAPI的`enum`、独立schema或文档中的专属约束表格，可清晰传达每个接口的独特限制，避免文档流于形式。
给接口文档生成流程加一道校验，没写文档的接口别想进测试环境
后端联调最烦接口文档缺字段，这本质是流程问题。解决方案是在CI/CD流水线中加入文档校验，与lint和单测同级，不合格则构建失败。具体通过ArchUnit在编译期扫描源码，检查Controller方法的@Operation注解及入参、返回值对象的@Schema注解是否完整，并可在集成测试阶段对生成的OpenAPI文档做二次校验。
接手屎山代码时，我让 AI 把接口逻辑和业务语义自动填进了文档
接手无文档老项目时，用AI按接口分析调用链并自动生成业务语义文档，效率极高。核心流程分四步：先让AI扫描项目结构建立全局认知；再逐接口追踪完整调用链，区分代码含义与业务含义；接着通过多轮对话补全业务场景和规则；最后格式化输出可直接交付的接口文档。该方法比人工编写更可靠、高效，37个接口仅需40分钟，但依赖清晰的代码结构和主流框架。
团队协作时接口文档老打架，试试这样合并和消解冲突
从单体 OpenAPI 文件迁移到多文件结构，是解决接口文档冲突的根本方法。通过按模块拆分规范文件，并利用构建命令拼装完整文档，可将冲突率降低 90% 以上。核心操作包括：将路径、模式等定义拆分为独立文件，用 `$ref` 在入口文件中组装，并借助 Redocly CLI 进行构建与校验。对于同一模块的并发修改，可进一步按 HTTP 方法拆分文件。若冲突发生，使用 Git 的 `union` 合并策略和编辑器插件能高效解决。
用 TypeScript 类型做接口文档，怎么让它跟后端返回保持同步
解决前后端接口类型不一致的核心方案：将 TypeScript 类型定义作为唯一真相来源，通过工具链实现自动化校验。具体做法是用 ts-json-schema-generator 将类型编译为 JSON Schema，再在 CI 中用 Ajv 校验实际响应数据。也可从后端代码直接生成前端类型，或用 OpenAPI 作为中间契约，配合 openapi-diff 检测破坏性变更。针对泛型、联合类型等复杂场景需注意工具版本和配置优化。
写了个插件让 Swagger 自动把后端下划线字段转成前端驼峰，顺便标清楚映射关系
Swagger 插件自动将文档中的蛇形字段名转为驼峰，并在描述里标注映射关系，解决前后端命名风格不一致的联调痛点。文章分析了现有手动维护或前端转换方案的不足，详细介绍了基于 SpringDoc 的实现原理，包括递归处理嵌套对象、参数和响应体，并讨论了边界情况与常见问题。
monorepo 接口文档别每次 commit 都全量生成，我们踩过的坑和现在的触发策略
从全量生成到按需触发，接口文档生成策略的核心在于声明式依赖图和文件指纹。通过 Turborepo 的依赖感知能力，结合 `turbo.json` 的任务声明和 `--filter` 差分计算，能将文档生成范围精确到受影响的服务，并利用远程缓存大幅减少重复计算，使 CI 耗时从 11 分钟降至 1 分 12 秒。
让工具读懂两种接口语言：GraphQL 与 OpenAPI 自动生成文档的落地难点
GraphQL 与 REST API 文档统一的根本挑战在于两种接口哲学差异：OpenAPI 是资源视图，GraphQL 是能力视图。强行用同一种生成逻辑会导致文档残缺。可行的统一路径包括以 GraphQL 为主封装 REST、用 OpenAPI 扩展承载 GraphQL 语义，或双 schema 并存通过中间层做字段映射统一渲染。落地时需注意工具选型、参数展示区分、统一错误格式，并做好手动维护映射与示例的准备。