本报告介绍 AutoTest-Orchestrator StandardFlow，一套基于 CoStrict 平台构建的、面向任意开源项目的端到端自动化测试工作流。
通过严格的阶段化流程和统一输出规范，用户仅需提供最基本的仓库路径和环境信息，即可实现项目扫描、环境检查、服务部署、接口与前端验证、复现脚本生成以及最终测试报告输出的全流程自动化验证。
本报告将展示在 HRMS、RuoYi-Vue 和 sist2 三个项目上的应用示例及执行效果。
【作者信息】
姓名：IveGotMagicBean
联系方式：542058929@qq.com
更新日期：2026.01.05
【文档目录】
一、设计背景
二、总体思路
三、各阶段设计说明
四、测试示例
五、总结
附录
3.1 Mode 设计说明
3.2 斜杠工具设计说明
4.1 示例输入指令
4.2 hrms 开源库自动调试流程
4.3 更多调试示例
- 说明文档在线链接
- CoStrict 使用建议
随着 AI Coding 与自动编程技术的普及，越来越多的代码由大语言模型直接生成或大幅修改。然而在实际工程中，这类代码往往存在以下风险：
- 缺乏系统化测试，功能是否可运行不可知
- 不同项目技术栈差异大，测试方案难以复用
- 测试流程高度依赖人工经验，难以标准化
- 前后端项目结构复杂，端到端验证成本高
CoStrict 是一个面向开源和企业级项目的自动化测试与代码质量管理平台，旨在通过流程化、标准化的方式提升 AI 或人类开发的代码可信度。它提供开源仓库分析、测试工作流编排、结果可复现、报告统一输出等功能，使复杂的端到端测试可以自动化、规范化地进行。
基于 CoStrict 平台，AutoTest-Orchestrator StandardFlow 能够在面对陌生项目时，模拟真实测试工程师的工作思路，自主完成从项目扫描到测试报告生成的全流程自动化验证。
让 AI 能够像一名自动化测试工程师一样，面对一个完全陌生的代码仓库，自主完成从识别 → 运行 → 测试 → 汇总报告的完整流程。
AutoTest-Orchestrator 采用流程驱动而非工具驱动的设计方式，不依赖某一种固定的测试框架，而是按照真实工程中的测试思路组织整体流程：
先识别项目类型与技术栈，再评估当前环境是否具备运行条件，随后选择合适的测试方式，最终输出可复现的测试结果。
为保证流程稳定性与可控性，整个自动化测试过程被拆分为多个职责清晰的阶段，每个阶段都有明确的输入与输出，即使某一环节执行失败，也可以给出可解释的结果并安全降级。
各阶段通过斜杠命令串联执行，从而在保证自动化程度的同时，避免流程混乱和上下文失控。
【项目串联的斜杠命令】
Step 1 项目扫描与技术栈识别（/autotestscan）
Step 2 执行环境与平台可用性检测（/autotestenvcheck）
Step 3 项目部署与启动验证（/autotestdeploycheck）
Step 4 后端接口自动化测试（/autotestapitest）
Step 5 前端页面可访问性测试（/autotestfrontendtest）
Step 6 生成并验证项目检查脚本 run_test.sh （/autotestgenerateruntest）
Step 7 统一汇总测试报告（/autotestgeneratereport）
所有阶段的产出统一写入项目根目录下：test_{YYYYMMDD_HHMMSS}/
同时输出命名统一的分阶段测试报告及测试复现文档 run_test.sh ，确保：
- 测试结果不污染源码
- 多次执行互不覆盖
- 方便打包、复现与验收
Fig.1 示例输出目录
AutoTest-Orchestrator 使用 Custom Mode 作为自动化测试流程的统一控制中枢，用于固化测试执行顺序、角色定位和输出规范。
该 Mode 的核心目标是：
在面对未知代码仓库时，模拟真实测试工程师的工作思路，自动完成从项目识别到测试报告生成的完整流程。
Mode 主要承担以下职责：
- 统一自动化测试的阶段划分与执行顺序
- 约束 AI 始终以“测试工作流编排器”的角色进行分析
- 规范所有阶段的输出路径与报告结构
- 在出现风险或失败时，提供可解释的降级结果
在此基础上，各测试阶段通过独立的斜杠命令实现，Mode 负责全局控制，命令负责阶段执行，从而保证流程清晰、结果稳定、可重复运行。
目标：回答三个最基本的问题
- 这是个什么项目？
- 用了什么技术栈？
- 理论上能不能跑？
核心思路：
- 通过目录结构、配置文件、依赖描述推断项目类型
- 不执行任何代码，仅做静态分析
- 给出“是否值得继续自动化”的初步判断
目标：判断当前运行环境是否支持该项目
重点关注：
- 操作系统类型（Linux / Windows / macOS / WSL）
- 语言运行时是否存在
- 基础工具是否可用（bash / curl 等）
此阶段不尝试启动项目，只检测测试环境是否满足项目要求。
目标：验证项目是否真的能跑起来
设计原则：
- 优先选择最小侵入的启动方式
- 对可能的危险命令（如构建、启动服务）进行提示
- 关注启动失败的常见原因，而非强行成功
此阶段输出：
- 启动是否成功
- 监听端口冲突检查
- 是否对外提供服务
目标：验证后端服务是否可用
测试策略：
- 自动发现接口或使用最小可验证接口集合
- 覆盖成功 / 异常 / 鉴权相关场景
- 避免依赖复杂业务数据
目标：验证是否存在可访问的前端页面
关注点包括：
- 是否存在前端资源
- 页面是否返回 HTML
- 是否出现明显错误页
- 是否被登录 / token 拦截
目标：生成并验证可独立复现的自动化测试脚本 run_test.sh。
设计思路：
- 将已验证成功的 API 测试步骤转化为标准 bash 脚本
- 明确服务地址、端口、请求顺序与必要参数
- 避免依赖 AI 交互状态或隐式上下文
生成完成后，工作流会对 run_test.sh 进行基本校验，确保脚本逻辑完整、可直接执行。
目标：将零散的阶段结果转化为一份自然语言测试报告，便于用户检查项目调试情况。
最终报告包含：
- 各阶段执行状态汇总
- 常见失败模式归因
- 是否具备部署价值的结论判断
- 针对项目的改进建议
在本测试示例中，用户仅需提供最基本的执行指令，即可启动完整的端到端自动化测试流程，无需逐步执行各阶段命令。
整个流程几乎零人工干预，用户只需提供目标仓库和基础环境信息，即可获得完整、可复现的自动化测试结果。
请使用 AutoTest-Orchestrator 模式，在 WSL 环境下，对代码仓库 /home/linshiyi/Studying/2025.12_SXFCompetition/20260102_test02/hrms
执行完整自动化测试工作流
备注：
- Go 路径：/home/linshiyi/Studying/software/go1.25.5/go/bin/go
- MySQL 路径：/usr/bin/mysql
- 请使用“mysql -u root -p”登录 MySQL，账号为 root，密码为 123
- WSL 下可能已有 mysqld 进程
- 若需要，优先通过调用登录接口（使用测试账号）获取有效 Cookie / Token
- 输出的 run_test.sh 要求能够让第一次接触该项目的用户实现一键部署，并输出前端访问链接和后端验证命令
请使用 AutoTest-Orchestrator 模式，在 WSL 环境下，对代码仓库/home/linshiyi/Studying/2025.12_SXFCompetition/20260102_test01/RuoYi-Vue 执行完整自动化测试工作流。
备注:
- 数据库已存在数据库名为 ry，可能和脚本中有冲突，请予以注意。请注意脚本中前后端分别的端口号
- mysql 的登陆用户为 root，密码为 123
- 输出的 run_test.sh 要求能够让第一次接触该项目的用户实现一键部署，并输出前端访问链接和后端验证命令
请使用 AutoTest-Orchestrator 模式，在 WSL 环境下，对代码仓库 /home/linshiyi/Studying/2025.12_SXFCompetition/20260102_test01/sist2
执行完整自动化测试工作流。
备注：
- 请按照项目要求的用 docker 环境启动，注意可能存在的端口冲突问题。
- mysql 的登陆用户为 root，密码为 123（如果不需要用到 mysql，则忽略该信息）
- 输出的 run_test.sh 要求能够让第一次接触该项目的用户实现一键部署，并输出前端访问链接和后端验证命令
以 HRMS 开源库为例，AutoTest-Orchestrator 在 WSL 环境下能够自动完成整个端到端调试与测试流程。
流程特点如下：
A. 项目扫描与技术栈识别
- 自动分析仓库结构，判断主要语言、框架及可执行入口
Fig.2 项目扫描与技术栈识别
B. 环境与依赖检查
- 检测 Go 和 MySQL 路径是否可用
- 识别已有服务进程，避免端口或数据库冲突
Fig.3 环境与依赖检查
C. 服务部署与可用性验证
- 自动启动后端服务
- 检查关键接口和端口是否可访问
Fig.4 服务部署与可用性验证
D. 后端功能验证
- 自动执行最小接口集合测试（包括登录、查询等）
Fig.5 后端功能验证
E. 前端功能验证
- 检查前端页面访问和资源加载状态
Fig.6 前端功能验证
F. 测试结果复现脚本 (run_test.sh)
- 生成
run_test.sh脚本，实现可重复执行
Fig.7 测试结果复现脚本
G. 测试报告生成
- 输出完整 Markdown 测试报告，包括成功用例、失败用例和改进建议，便于用户快速检查。
Fig.8 测试报告生成
H. 规范可控的输出格式
- 所有阶段的产出统一写入项目根目录下：
test_{YYYYMMDD_HHMMSS}/ - 输出命名统一规范的分步执行报告和总体报告，便于阅读
- 多次执行互不覆盖
Fig.9 hrms 调试报告输出目录
除了 HRMS 项目外，AutoTest-Orchestrator 对 RuoYi-Vue 和 sist2 两个仓库也进行了完整的自动化测试。
- RuoYi-Vue：自动处理数据库可能存在的冲突，成功启动前后端服务，顺利完成接口与前端验证。
- sist2：通过 Docker 环境启动，自动检测并解决端口占用问题，测试流程顺利完成。
三个项目的执行结果均高度稳定，测试报告结构统一，复现脚本可直接运行，几乎无需人工干预。 这一结果充分验证了 AutoTest-Orchestrator 在不同类型项目和运行环境下的高通用性、强复现性和端到端自动化能力。
完整流程及自动化执行效果的演示，请参见附录视频，展示了从项目扫描到测试报告生成的全流程可复现过程。
Fig.10 RuoYi-Vue（左）与 sist2（右）调试报告输出目录
AutoTest-Orchestrator StandardFlow 是一个面向任意开源项目的端到端自动化测试工作流编排系统，其核心优势在于流程驱动、阶段可控、输出规范化。
通过严格的阶段划分与斜杠命令串联，它能够在几乎零人工干预的情况下，完成从项目扫描、环境检测、部署验证、接口与前端测试，到测试报告与复现脚本生成的全流程操作。
从 HRMS、RuoYi-Vue 到 sist2 的多项目测试示例表明，该工作流具有以下特点：
- 高通用性：适应不同语言、框架和项目类型，跨平台支持 WSL、Linux、Docker 等环境；
- 强复现性：生成的 run_test.sh 脚本可重复执行，输出路径与报告命名统一，结果稳定可靠；
- 端到端自动化：无需用户手动操作每个阶段，输入最少即可完成完整测试；
- 结果可解释：各阶段失败可降级输出原因，方便问题定位和改进建议生成。
综上，AutoTest-Orchestrator 不仅是一个自动化测试工具，更是一套模拟真实测试工程师思路的智能测试工作流，能够在面对陌生或复杂开源仓库时，快速、稳定地产出可复现、结构化的测试结论，为开发者和评测人员提供可靠、高效的端到端质量验证方案。
说明文档：https://ai.feishu.cn/docx/Phhnd2Jm2onGmmxlnRFcby54nxe?from=from_copylink
完整prompt：https://ai.feishu.cn/docx/R0wjdaAqsoMd8BxFQSSc2QMKnsf?from=from_copylink
欢迎评论交流~
VSCode 中使用 Remote WSL 连接 Ubuntu 时无法使用 CoStrict（已排除 WSL 联网问题）
message: {"apiProtocol":"openai","originModelId":"Auto"}
provider: zgsm
Model: Auto
BaseUrl: https://zgsm.sangfor.com
vscodeVersion: 1.107.1
pluginVersion: 2.1.3
editorType: Remote (wsl)
httpProxy: undefined
httpsProxy: undefinedupdate：已得到回复