Files

2.3 KiB
Raw Permalink Blame History

name, description
name description
tests 测试任务统一入口与调度器。当用户说"测试、开始测试、测一下、验证一下、跑一遍测试"等模糊测试指令时使用——自动判断被测对象属于哪一端(后端/管理端 UI/小程序),路由到对应专项测试技能执行。触发关键词:测试、开始测试、测一下、验证一下、帮我测、跑测试。

测试调度器(fly-home 全端)

接住模糊的"测试"请求,三步走:定对象 → 选技能 → 执行。

Step 1:定对象(从上下文推断,推断不出就问)

按优先级取信号:

  1. 本轮对话改了什么(git status/diff 哪个仓库有改动)
  2. 用户点名的功能/页面/接口
  3. 完全无信号 → 只问一句:"测哪端?后端服务 / 管理端 UI / 小程序(C 端)"

Step 2:路由表

被测对象 信号特征 路由技能
后端 Java(fly-home-server) 改了 *.java、接口、Service/Mapper spring-boot-test-patterns(JUnit5/Mockito/Testcontainers;跑既有测试用 mvn test -pl <模块>)
管理端 UI(fly-home-ui,Vue3) 改了 fly-home-ui/src 页面/组件 playwright-cli(Playwright 录制/生成/执行)
小程序 C 端(customer-app,uni-app→mp-weixin) 改了 customer-app/src、C 端页面/接口 mp-weixin-verify(本机 automator 配方:构建→cli auto→登录态注入→观测三件套)

多端同时改动:按依赖序执行——后端编译/单测 → 管理端 UI → 小程序走查。

Step 3:执行门槛(用户规矩,勿违反)

  • 用户说"开始测试"才执行测试动作;只说"怎么测/要测吗"时给方案不动手
  • 后端起服务只用 local profile(nacos namespace=gqb)
  • 正式库(cynos 只读)禁止任何写操作;dev 库可写但 update_by 留痕
  • 小程序/服务端口等人工前置条件(微信开发者工具服务端口)提前列出,不卡半路

质量要求(各端通用)

  • 测试结论必须有证据:截图(管理端/小程序)、接口响应体、mvn 测试输出,存 materials/ 留档
  • 失败即报,不粉饰:哪个断言红了、哪步起不来,原样呈现
  • 测完口头总结:覆盖了什么、没覆盖什么、遗留风险