可以把“Skill”理解为一套可复用的 AI 测试能力包它不仅生成测试用例还要能读取项目资料、启动环境、调用接口、操作页面、校验数据库、收集证据并输出报告。对于一个完全没有测试体系的 ToB 项目不建议直接让 Skill“把所有页面点一遍”。正确方式是先建立业务模型和风险基线再逐层补齐接口、UI、数据、权限和非功能测试。一、先定义测试范围ToB 项目通常要重点覆盖核心业务流程创建、审批、执行、撤回、作废、归档多租户隔离租户之间数据、配置、文件、缓存是否隔离权限体系用户、角色、部门、数据权限、字段权限状态机不同状态允许执行哪些操作数据一致性页面、接口、数据库、报表数据是否一致集成能力ERP、CRM、支付、消息、SSO、Webhook批量操作导入、导出、批量审批、批量修改审计合规操作日志、登录日志、敏感信息脱敏稳定性并发、超时、重试、幂等、重复提交升级兼容历史数据和旧配置能否正常使用测试优先级建议按以下方式计算风险分 业务影响 × 发生概率 × 使用频率 × 变更频率先覆盖高风险主流程不追求一开始就达到很高的用例数量。二、Skill 应包含哪些能力建议将一个大 Skill 拆成多个职责清晰的子 Skilltesting-skills/ ├── requirement-analysis/ ├── test-plan/ ├── api-testing/ ├── ui-testing/ ├── database-validation/ ├── permission-testing/ ├── tenant-isolation/ ├── integration-testing/ ├── performance-testing/ ├── security-baseline/ ├── defect-analysis/ └── test-report/每个 Skill 至少包含输入格式执行步骤可调用工具判断规则输出格式失败处理证据要求禁止事项例如 UI 测试 Skill 的输出不能只有“执行成功”而应包含测试用例编号操作步骤预期结果实际结果截图或录像控制台错误网络请求异常Trace ID是否通过三、完整落地流程1. 项目侦察让 Skill 读取并分析PRD、原型、流程图API 文档或 OpenAPI数据库表结构权限模型前后端代码结构部署说明第三方集成文档历史线上问题客户定制配置产出项目测试地图 ├── 业务模块 ├── 用户角色 ├── 核心实体 ├── 状态流转 ├── 外部依赖 ├── 数据边界 └── 高风险区域如果项目没有完整文档Skill 可以根据路由、菜单、接口和数据库反向生成系统功能清单但必须由产品或业务负责人确认。2. 建立可测试环境测试环境至少要具备可重复部署固定测试账号多个租户不同权限角色可重置的测试数据数据库只读查询权限日志和链路追踪第三方系统 Mock邮件、短信等测试通道建议至少准备这些身份平台管理员 租户 A 管理员 租户 A 普通用户 租户 A 只读用户 租户 B 管理员 无权限用户 已禁用用户测试数据不要依赖人工长期维护。使用 API 或数据库脚本生成并为每次执行增加唯一标识例如AUTO_20250308_订单_0013. 建立业务模型AI 最容易生成大量低价值用例因此需要先定义业务规则。每个核心实体整理为entity:订单states:-草稿-待审批-已通过-已驳回-已取消transitions:-from:草稿action:提交to:待审批roles:[创建人]-from:待审批action:通过to:已通过roles:[审批人]invariants:-已取消订单不可再次审批-非本租户用户不可查询-金额必须大于零-重复提交不得生成两条业务记录Skill 根据状态机生成正常、异常、越权和并发用例比单纯根据页面生成用例可靠得多。4. 先做 API 测试推荐顺序健康检查和鉴权核心业务接口参数校验状态流转权限与租户隔离幂等和并发第三方集成异常恢复接口测试至少校验HTTP 状态码业务错误码响应 Schema字段值数据库落库状态变化审计日志消息或异步任务租户归属重复请求结果工具可采用pytest requests/httpxPlaywright APIPostman/NewmanREST AssuredPact做契约测试不要只断言status_code 200。5. 再做 UI 核心流程UI 自动化主要覆盖登录和退出核心业务 Happy Path权限可见性关键表单校验审批和状态流转搜索、筛选、分页导入和导出用户可见的错误提示推荐使用 Playwright定位优先级为data-testid role/name label 稳定业务属性 CSS避免依赖绝对 XPath动态 class固定等待时间用例间共享前置状态UI 用例失败时Skill 应自动保存截图、视频、DOM、控制台日志和网络请求。6. 专项验证权限与多租户权限测试需要形成“角色 × 资源 × 动作 × 数据范围”矩阵角色资源查看创建修改删除审批管理员订单是是是是是普通用户订单本人是本人否否只读用户订单授权范围否否否否每个权限点同时验证菜单是否隐藏按钮是否禁用或隐藏直接调用接口是否被拒绝修改请求参数能否越权直接访问 URL 是否被拒绝数据库是否出现越租户数据仅检查“按钮看不见”不能证明权限安全。7. 非功能测试ToB 项目至少增加以下基线性能核心查询、批量导入、报表、审批并发安全鉴权绕过、越权、注入、文件上传、敏感数据泄漏可靠性重复提交、超时重试、消息重复消费兼容性企业常用浏览器和目标分辨率可恢复性服务重启、任务失败、第三方超时可观测性错误能否通过日志和 Trace ID 定位性能工具可用k6或JMeter安全基线可接入 OWASP ZAP但扫描结果必须人工复核。四、CI/CD 分层执行不要在每次提交中运行全部测试。建议分层提交阶段510 分钟 - 静态检查 - 单元测试 - API 冒烟 - 核心权限检查 合并请求阶段2040 分钟 - 核心接口回归 - 核心 UI 流程 - 数据库一致性 - 契约测试 每日夜间 - 全量 API - 全量 UI - 多租户和权限矩阵 - 集成测试 版本发布前 - 性能基线 - 安全基线 - 数据升级验证 - 关键客户配置回归失败用例应自动分类为产品缺陷自动化脚本问题环境问题测试数据问题第三方依赖问题疑似不稳定用例不应通过无限重试掩盖失败。五、Skill 的执行约束为了避免 AI 误操作建议加入硬性规则1. 默认禁止连接生产环境。 2. 禁止执行 DROP、TRUNCATE 和无条件 DELETE/UPDATE。 3. 不得输出密码、Token、身份证号等敏感数据。 4. 不得把需求文档当作唯一正确来源。 5. 每个结论必须附带请求、响应、截图或数据库证据。 6. 环境异常不得直接登记为产品缺陷。 7. 不确定的业务规则必须标记待确认不得自行推断。 8. 自动生成的测试用例必须经过风险去重和人工评审。六、第一阶段建议交付物从零开始时第一阶段不需要追求“全自动化”建议先完成系统功能地图核心业务流程图风险清单角色权限矩阵多租户隔离用例Top 20 核心 API 自动化Top 5 UI 冒烟流程自动测试数据生成CI 测试流水线缺陷报告模板测试结果看板可设定一个务实目标核心业务流程覆盖率 90% 高风险接口覆盖率 80% 核心权限规则覆盖率 100% 核心多租户隔离场景覆盖率 100% UI 自动化只覆盖稳定且高价值的流程七、推荐技术组合如果没有既有技术约束可以采用用例与执行框架pytest 接口测试httpx / Playwright API Web UIPlaywright 数据库验证SQLAlchemy 或数据库只读客户端 契约测试OpenAPI 校验 / Pact 性能测试k6 安全基线OWASP ZAP 报告Allure 流水线GitLab CI / GitHub Actions / Jenkins 环境Docker Compose 或 Kubernetes真正有效的 Skill 不是“自动生成测试用例的提示词”而是带有明确输入、工具权限、业务规则、校验机制、证据链和 CI 门禁的一套测试执行系统。实施顺序应是项目侦察 → 风险建模 → 环境与数据 → API 测试 → 权限与租户 → UI 冒烟 → 非功能测试 → CI 持续回归。
无专职测试人员如何利用skill完成测试
可以把“Skill”理解为一套可复用的 AI 测试能力包它不仅生成测试用例还要能读取项目资料、启动环境、调用接口、操作页面、校验数据库、收集证据并输出报告。对于一个完全没有测试体系的 ToB 项目不建议直接让 Skill“把所有页面点一遍”。正确方式是先建立业务模型和风险基线再逐层补齐接口、UI、数据、权限和非功能测试。一、先定义测试范围ToB 项目通常要重点覆盖核心业务流程创建、审批、执行、撤回、作废、归档多租户隔离租户之间数据、配置、文件、缓存是否隔离权限体系用户、角色、部门、数据权限、字段权限状态机不同状态允许执行哪些操作数据一致性页面、接口、数据库、报表数据是否一致集成能力ERP、CRM、支付、消息、SSO、Webhook批量操作导入、导出、批量审批、批量修改审计合规操作日志、登录日志、敏感信息脱敏稳定性并发、超时、重试、幂等、重复提交升级兼容历史数据和旧配置能否正常使用测试优先级建议按以下方式计算风险分 业务影响 × 发生概率 × 使用频率 × 变更频率先覆盖高风险主流程不追求一开始就达到很高的用例数量。二、Skill 应包含哪些能力建议将一个大 Skill 拆成多个职责清晰的子 Skilltesting-skills/ ├── requirement-analysis/ ├── test-plan/ ├── api-testing/ ├── ui-testing/ ├── database-validation/ ├── permission-testing/ ├── tenant-isolation/ ├── integration-testing/ ├── performance-testing/ ├── security-baseline/ ├── defect-analysis/ └── test-report/每个 Skill 至少包含输入格式执行步骤可调用工具判断规则输出格式失败处理证据要求禁止事项例如 UI 测试 Skill 的输出不能只有“执行成功”而应包含测试用例编号操作步骤预期结果实际结果截图或录像控制台错误网络请求异常Trace ID是否通过三、完整落地流程1. 项目侦察让 Skill 读取并分析PRD、原型、流程图API 文档或 OpenAPI数据库表结构权限模型前后端代码结构部署说明第三方集成文档历史线上问题客户定制配置产出项目测试地图 ├── 业务模块 ├── 用户角色 ├── 核心实体 ├── 状态流转 ├── 外部依赖 ├── 数据边界 └── 高风险区域如果项目没有完整文档Skill 可以根据路由、菜单、接口和数据库反向生成系统功能清单但必须由产品或业务负责人确认。2. 建立可测试环境测试环境至少要具备可重复部署固定测试账号多个租户不同权限角色可重置的测试数据数据库只读查询权限日志和链路追踪第三方系统 Mock邮件、短信等测试通道建议至少准备这些身份平台管理员 租户 A 管理员 租户 A 普通用户 租户 A 只读用户 租户 B 管理员 无权限用户 已禁用用户测试数据不要依赖人工长期维护。使用 API 或数据库脚本生成并为每次执行增加唯一标识例如AUTO_20250308_订单_0013. 建立业务模型AI 最容易生成大量低价值用例因此需要先定义业务规则。每个核心实体整理为entity:订单states:-草稿-待审批-已通过-已驳回-已取消transitions:-from:草稿action:提交to:待审批roles:[创建人]-from:待审批action:通过to:已通过roles:[审批人]invariants:-已取消订单不可再次审批-非本租户用户不可查询-金额必须大于零-重复提交不得生成两条业务记录Skill 根据状态机生成正常、异常、越权和并发用例比单纯根据页面生成用例可靠得多。4. 先做 API 测试推荐顺序健康检查和鉴权核心业务接口参数校验状态流转权限与租户隔离幂等和并发第三方集成异常恢复接口测试至少校验HTTP 状态码业务错误码响应 Schema字段值数据库落库状态变化审计日志消息或异步任务租户归属重复请求结果工具可采用pytest requests/httpxPlaywright APIPostman/NewmanREST AssuredPact做契约测试不要只断言status_code 200。5. 再做 UI 核心流程UI 自动化主要覆盖登录和退出核心业务 Happy Path权限可见性关键表单校验审批和状态流转搜索、筛选、分页导入和导出用户可见的错误提示推荐使用 Playwright定位优先级为data-testid role/name label 稳定业务属性 CSS避免依赖绝对 XPath动态 class固定等待时间用例间共享前置状态UI 用例失败时Skill 应自动保存截图、视频、DOM、控制台日志和网络请求。6. 专项验证权限与多租户权限测试需要形成“角色 × 资源 × 动作 × 数据范围”矩阵角色资源查看创建修改删除审批管理员订单是是是是是普通用户订单本人是本人否否只读用户订单授权范围否否否否每个权限点同时验证菜单是否隐藏按钮是否禁用或隐藏直接调用接口是否被拒绝修改请求参数能否越权直接访问 URL 是否被拒绝数据库是否出现越租户数据仅检查“按钮看不见”不能证明权限安全。7. 非功能测试ToB 项目至少增加以下基线性能核心查询、批量导入、报表、审批并发安全鉴权绕过、越权、注入、文件上传、敏感数据泄漏可靠性重复提交、超时重试、消息重复消费兼容性企业常用浏览器和目标分辨率可恢复性服务重启、任务失败、第三方超时可观测性错误能否通过日志和 Trace ID 定位性能工具可用k6或JMeter安全基线可接入 OWASP ZAP但扫描结果必须人工复核。四、CI/CD 分层执行不要在每次提交中运行全部测试。建议分层提交阶段510 分钟 - 静态检查 - 单元测试 - API 冒烟 - 核心权限检查 合并请求阶段2040 分钟 - 核心接口回归 - 核心 UI 流程 - 数据库一致性 - 契约测试 每日夜间 - 全量 API - 全量 UI - 多租户和权限矩阵 - 集成测试 版本发布前 - 性能基线 - 安全基线 - 数据升级验证 - 关键客户配置回归失败用例应自动分类为产品缺陷自动化脚本问题环境问题测试数据问题第三方依赖问题疑似不稳定用例不应通过无限重试掩盖失败。五、Skill 的执行约束为了避免 AI 误操作建议加入硬性规则1. 默认禁止连接生产环境。 2. 禁止执行 DROP、TRUNCATE 和无条件 DELETE/UPDATE。 3. 不得输出密码、Token、身份证号等敏感数据。 4. 不得把需求文档当作唯一正确来源。 5. 每个结论必须附带请求、响应、截图或数据库证据。 6. 环境异常不得直接登记为产品缺陷。 7. 不确定的业务规则必须标记待确认不得自行推断。 8. 自动生成的测试用例必须经过风险去重和人工评审。六、第一阶段建议交付物从零开始时第一阶段不需要追求“全自动化”建议先完成系统功能地图核心业务流程图风险清单角色权限矩阵多租户隔离用例Top 20 核心 API 自动化Top 5 UI 冒烟流程自动测试数据生成CI 测试流水线缺陷报告模板测试结果看板可设定一个务实目标核心业务流程覆盖率 90% 高风险接口覆盖率 80% 核心权限规则覆盖率 100% 核心多租户隔离场景覆盖率 100% UI 自动化只覆盖稳定且高价值的流程七、推荐技术组合如果没有既有技术约束可以采用用例与执行框架pytest 接口测试httpx / Playwright API Web UIPlaywright 数据库验证SQLAlchemy 或数据库只读客户端 契约测试OpenAPI 校验 / Pact 性能测试k6 安全基线OWASP ZAP 报告Allure 流水线GitLab CI / GitHub Actions / Jenkins 环境Docker Compose 或 Kubernetes真正有效的 Skill 不是“自动生成测试用例的提示词”而是带有明确输入、工具权限、业务规则、校验机制、证据链和 CI 门禁的一套测试执行系统。实施顺序应是项目侦察 → 风险建模 → 环境与数据 → API 测试 → 权限与租户 → UI 冒烟 → 非功能测试 → CI 持续回归。