ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Stack-chan 发布前实机测试清单:从候选提交到 main 合并的完整验证流程

2026/10/5 1:53:07 拓冰建站 浏览量
Stack-chan 发布前实机测试清单:从候选提交到 main 合并的完整验证流程 嵌入式物联网智能硬件机器人硬件开发前端AI 应用【免费下载链接】stack-chanA JavaScript-driven M5Stack-embedded super-kawaii robot.项目地址https://gitcode.com/gh_mirrors/sta/stack-chan点击查看免费下载导读本文档对应仓库 docs/operations/release-device-test_ja.md是一份用于 Stack-chan 稳定版发布前的实机验证操作清单。它规定了在稳定版合并到main分支之前必须在真实硬件上逐项确认的测试步骤、判定规则与记录规范并以 M5StackChan CoreS3 为必须验证的目标机型。读完本文后你将掌握发布候选提交release candidate commit的固定方法、PASS / FAIL / N/A 三级判定与记录表格式、CoreS3 共通项目G-01G-28、按变更功能挑选的追加案例C-01C-10以及失败候选提交的处理流程并理解这些人工验证步骤如何与仓库内的自动化验证脚本设备冒烟测试、发布元数据校验衔接配合。一、测试体系的定位与适用范围实机测试是 Stack-chan 发布流程的最后一个质量关卡。仓库的发布流程文档 docs/operations/release-flow_ja.md 描述了main - release/* - develop - feat/* | fix/*的分支模型其中第 4 步明确为自动验证与实机验证之后合并发布 PR并直接引用本清单作为实机验证依据実機検証ではリリース前実機テストを使用し、候補コミットと結果をリリース pull request に記録します。本清单的核心约束有三条必须项目以 M5StackChan CoreS3 为对象G-01G-28全部基于 CoreS3 编写是每次发布都不可跳过的底线。只选与本次发布相关的追加案例C-01C-10不是每次都执行而是根据发布中变更的功能挑选执行。候选提交candidate commit贯穿始终所有测试都必须锚定同一个 40 位 commit SHA证迹照片、视频、串口日志、浏览器 console也要与项目 ID 和候选提交一一对应。这一固定提交 → 固定产物 → 固定测试 → 留存证迹的思路与仓库中从同一候选提交生成 firmware bundle 与 Pages 预览的构建约定见 docs/operations/cloudflare-pr-preview_ja.md互相印证PR 预览站点的产物来自候选提交而不是复用gh-pages上已经生成的旧产物。二、判定与记录PASS / FAIL / N/A 三级规范每个测试项最终只能记录为PASS、FAIL、N/A三者之一规则如下PASS实测结果符合该项描述。FAIL任何一项不达标该候选提交即视为不可发布详见不合格时的处理。N/A必须项目G 系列不允许使用N/A只有追加项目C 系列可以且必须写明理由例如变更对象外或无对应实机。测试结果需要粘贴到发布 PR 中表格格式如下项目记录发布版本vX.Y.Z候选提交40 位 commit SHACI 执行URLPages 预览URL实施日期时间日期时间与时区实施者GitHub ID本体产品名、revision、是否有电池驱动部伺服类型、电源、pan 与 tilt 的构成操作终端OS、浏览器与版本追加设备Android 终端、相机、Dock 相手机器peer device等结果PASS或指向未解决项目的链接表格中本体 / 驱动部 / 操作终端 / 追加设备四行要求把实机环境描述清楚这对应了追加设备行中提及的 Android 终端、相机、Dock 相手机器等外设——它们是 C-01MediaPipe BLE、C-03Codex Voice Stackchan Dock等案例的必备硬件。证迹保存规则照片、视频、串口日志、浏览器 console 等材料一律按项目 ID 候选提交 SHA的方式归档便于日后回溯某条日志属于哪次提交的哪个测试项。三、事前准备P-01P-05编号内容P-01固定发布对象的 40 位 commit SHA此后只使用基于该 SHA 生成的成果物P-02确认发布 PR 的必须 CI 成功且 firmware bundle 成果物与 Pages 预览的生成源 SHA 与P-01一致P-03使用专用验证机确认没有残留删除会带来麻烦的设置与 MODP-04从伺服可动范围内移走物品并向本体与伺服供给稳定电源P-05准备支持数据通信的 USB 线、Wi-Fi、支持 Web Bluetooth 的浏览器其中P-02中提到的 firmware bundle 与 Pages 预览产物均来自 CI 对候选提交的构建P-03对应后续G-25中重写 host 固件会清空设置与 MOD的警告因此专用验证机应当是可以随意清空的机器。P-05中的 Web Bluetooth 浏览器是G-23设置画面 BLE 读写与G-24MOD Gallery BLE 连接的前置条件。四、CoreS3 共通项目G-01G-28共通项目是每次发布的必测项按六个主题分组。4.1 写入与启动G-01G-03G-01固件写入在 Pages 预览的固件写入画面选择M5StackChan CoreS3阅读警告后写入候选固件。确认写入以成功提示结束且不会被当作对象外板卡或空成果物而拒绝。仓库 web/flash/manifest_esp32_m5stackchan_cores3.json 中chipFamily: ESP32-S3与 bootloader、partition-table、xs_esp32.bin三个 partition 的定义正是该写入画面所消费的清单version字段当前仓库中为1.1.0会被发布验证脚本用来核对与发布版本的一致性。G-02断电重启 × 3拔掉 USB 重新上电从启动画面到达 Face 的操作重复 3 次确认不出现启动循环、panic、brownout 或画面冻结。G-03触摸启动设置上电过程中触摸屏幕打开启动设置同时尝试返回与正常启动两条路径确认触摸位置无偏移、画面切换后仍可输入。4.2 启动设置与保存G-04G-09G-04语言切换依次切换到日语、英语、简体中文确认标签无缺漏且当场刷新显示。仓库 firmware/host/app/strings/ 下存在en.json、ja.json、zh-CN.json三个语言资源与这一测试项一一对应。G-05时区将时区改为与当前位置不同的城市再改回当前位置确认 AppBar 时刻随之变化。G-06音量按低、中、高的顺序调节音量每次松手后确认音大小变化且本体不重启。G-07Wi-Fi 连接扫描 Wi-Fi输入 SSID 与密码连接确认连接中、时间同步中、已连接三种状态在画面上正确反映。G-08设置持久化正常启动后重新上电确认语言、时区、音量、Wi-Fi 均已保存并自动重连。G-09离线启动与清除在启动设置中选择离线启动确认画面后先取消一次再确认清除确认 Wi-Fi 信息被清除后仍可到达 Face且下次设置可重新登记。4.3 Face、输入与显示G-10G-15G-10Drawer 交互点按 Face 打开 Drawer尝试纵向滚动、项目选择、返回、点按 overlay 外部关闭确认无误动作、绘制残留或操作不能。G-11Face 切换将 Face 依次切换为简单simple、小狗いぬ、图片image并依次选择全部表情与黑白配色确认脸部部件与气泡speech balloon不缺、表情切换不停滞。G-12手势切换将手部动画切换为无 / 石头剪刀布 / 拍手 / 思考中确认 Drawer 关闭后所选动画在 Face 上正常播放。G-13抚摸pat在 Face 上做抚摸操作确认出现开心表情与摇头一段时间后恢复原表情与姿态并释放伺服扭矩。G-14IMU 姿态安全持握本体并施加倾斜与轻微振动确认 Face 切换为对应 IMU 的表情随后恢复原表情。G-15电池与 AppBar分别在接电池与外部供电状态下打开 AppBar确认时刻更新对应机型在 0100 范围内显示电池余量。4.4 运动、LED、相机与音频G-16G-22G-16伺服Servo从 Drawer 执行伺服确认 pan 与 tilt 向各方向运动并回到正面结束后无保持音或持续振动残留。G-17环视見回す / look around开启环视等待两次以上姿态更新再关闭确认开启期间视线与脖子运动关闭后释放扭矩。G-18LED开启 LED 确认虹彩显示关闭后确认完全熄灭。G-19相机 × 2连续执行两次相机每次显示并关闭预览确认第二次也能获取图像结束后回到 Face 并可再次操作 Drawer。G-20播放音执行播放音确认确认音不间断地完整结束。G-21录音与播放 × 2连续执行两次录音与播放确认每次都能回放录音第二次不出现无声、停止或操作不能。G-22TTSSpeak设置所用 TTS 后执行Speak确认语音、口型、气泡完整结束无论成功还是通信失败都能回到 Face 操作。仓库的 TTS 实现分布在 firmware/host/modules/audio/ 下的tts-local.ts、tts-openai.ts、tts-elevenlabs.ts、tts-voicevox.ts等模块对应的远程与本地引擎都通过统一生命周期管理这正是本项要验证的成功/失败都能收尾行为。4.5 Web 工具与 MODG-23G-26G-23设置画面 BLE 读写将 CoreS3 切到启动设置从 Pages 预览的设置画面通过 BLE 连接并读写设置确认本体侧值被更新重新连接后仍能读出相同值。G-24MOD Gallery 连接从 Pages 预览的 MOD Gallery 连接 CoreS3确认能读出固件标识符、XS 版本、host capability并且只有兼容的 MOD 其写入操作才可用。G-25MOD 写入与重置从 Gallery 写入一个基础 MOD重启后确认 MOD 动作随后重写 host 固件确认按照事前警告清空本体设置与 MOD再为后续测试重新登记设置。G-26块编辑器端到端在块编辑器Block Editor中打开示例先在模拟器Simulator中运行再写入实机确认生成、模拟器、实机三个阶段均无错误实机呈现对应动作。4.6 持续运行G-27G-28G-2730 分钟长跑保持 Wi-Fi 连接与 Face 动画开启 30 分钟以上期间打开/关闭 Drawer 至少 10 次确认无重启、操作不能、显示停滞或伺服的意外持续保持。G-28资源复检长跑后再次执行相机、录音与播放、伺服确认结果与刚启动时一致无资源枯竭导致的失败。五、按变更功能挑选的追加案例C-01C-10以下案例仅在本次发布改动到对应功能时执行每项同样记录 PASS / FAIL / N/A。C-01MediaPipe BLE MOD从 Gallery 写入 MediaPipe BLE MOD并从发布 PR 的 Pages 预览 MediaPipe 画面建立 BLE 连接确认脸朝向、笑容、左右眨眼、嘴部开合、手的位置与手指数都跟随实机断开后约 1 秒显示恢复且伺服扭矩释放。相关实现见 web/mediapipe/ 与 firmware/mods/examples/mediapipe_ble/。C-02MCP Server MOD导入 MCP Server MOD设置 Wi-Fi 与mcp.token让 Drawer 显示 endpoint确认/health有响应、无 token 与错误 token 的POST /mcp返回401正确的 Bearer token 下初始化与工具执行成功。实现见 firmware/host/modules/connectivity/mcp-server/。C-03Codex Voice Stackchan Dock连接 Codex Voice MOD 与对应 Dock 相手机器依次执行断开、重连、会话开始、会话停止确认 CoreS3 的麦克风输入与扬声器输出、字幕、口型、会话状态、批准的许可/拒绝都一致仅在后台任务执行期间 Face 显示蓝色指示器断开与重连后无旧状态或指示器残留。C-04Stack-chan JUMP从 Gallery 导入 Stack-chan JUMP启动同一归档archive中的 MOD 与 mini app 的 entrypoint确认使用其中一个 entrypoint 不会丢失另一个退出 mini app 后回到 Face。C-05USB Dock 音量在启动设置中改变音量后的启动处理过程中启用 USB Dock从相手机器播放音频确认保存的音量当场反映到 USB 播放且显式指定无音的诊断配置下不发声。相关模块见 firmware/host/app/docks/android-usb-audio/ 与 firmware/docs/android-usb-audio.md。C-06WebRadio / 音频流改动过 WebRadio 或音频流时尝试播放开始、停止、重连、长时间播放确认能恢复中断停止后可继续使用其他音频操作。C-07平台固有实现改动电源、伺服驱动、按键、显示屏、相机等平台固有实现时在受影响的全机型重跑对应操作并按机型分行记录结果。平台定义见 firmware/host/platforms/伺服驱动见 firmware/host/modules/motion/ 下的sg90-driver.ts、rs30x-driver.ts、scservo-driver.ts、dynamixel-driver.ts。C-08stack-chan-ai Realtime 语音适配器经wss://或可信本地网络的ws://连接服务器端 Realtime 语音适配器确认 Bearer token 不暴露在 URL 中连接、麦克风输入、文字转录、语音响应、tool call 与结果返回完成一个完整往返。C-09认证码与激活链接显示用 Codex Voice 等显示含英文大写的认证码与 activation link确认字符不缺漏QR 码在标准 host 与 WASM host 两种环境都能绘制扫出的 URL 与显示内容一致。C-10XiaoZhi v1 兼容服务器ChatService通过ChatService连接 XiaoZhi v1 兼容服务器确认 CoreS3 的 Opus 麦克风输入与语音应答text event 与 MCP 初始化、tool call、结果返回完成一个往返后断开再重连成功。六、追加机型的确认除 CoreS3 外分发 ZIP 中包含以下三个产品标识firmware identifier有对应实机时同样要执行写入、启动、输入、画面、音频的确认com.m5stackcom.m5stack.core2com.m5stack.cores3源代码构建对象机型方面Stack-chan RT 与高尾版タカオ版Core2 SG90 在有对应实机时需要确认伺服方向、可动范围与按键操作。相关固件 manifest 位于 firmware/host/app/manifest_stackchan_rt.json 与 firmware/host/app/manifest_takao_core2_sg90.json。若标准项目之外的实机测试无法实施需在发布 PR 中保留 CI 构建结果并写明N/A的理由——这与必须项目禁用 N/A形成对照标准外的机型允许用 CI 结果加理由替代实机而 CoreS3 的共通项目则不允许任何替代。七、不合格时的处理只要残留一个FAIL该候选提交就不得公开。将复现步骤、实机构成、日志、照片或视频记录为 GitHub issue修正后生成新的候选提交在新的提交上重新执行影响项目与全部共通项目。即使实机测试全部通过只要在测试后改动过发布成果物也必须更新候选提交并按同一套流程全部重跑。这一FAIL 即冻结 证据完整化 换提交重跑的闭环与仓库发布流程中自动验证与实机验证通过后才合并发布 PR、打vX.Y.Z标签的步骤一一对应见 docs/operations/release-flow_ja.md。八、与自动化验证脚本的衔接本清单是人工实机验证仓库同时提供了两层自动化校验与之配合建议在实机测试前后各跑一遍发布元数据校验firmware/scripts/lib/release-validation.mjs的validateRelease(rootDirectory, tag)会在打稳定版标签时强制校验标签必须形如vX.Y.Zfirmware/package.json、firmware/package-lock.json、web/package.json、web/package-lock.json的 version 必须一致web/flash/ 下全部manifest_esp32_*.json的 version 必须与标签一致docs/release-notes/vX.Y.Z.md必须存在且非空.changeset下不得残留未消费的 Changeset。入口脚本为 firmware/scripts/validate-release.mjs对应 npm scriptcheck:release见 firmware/package.json。测试用例见 firmware/scripts/lib/release-validation.test.mjs。设备冒烟测试firmware/scripts/run-device-smoke.js提供npm run test:device向 USB 连接的设备部署 smoke MOD并从设备日志判定 PASS/FAIL。它支持两条通道xsbug默认通过mcrun -dn -x桥接 trace 到本地日志服务器检测到完成标记即通过且已知 CoreS3 的 xsbug 串口桥偶发不稳定、会自动重试serial通道只监听原始串口的崩溃标记Guru Meditation、abort()、Brownout、panic属于启动稳定性冒烟而非完成性检查需要UPLOAD_PORT。注意固件文档 firmware/docs/flashing-firmware.md 配套说明写入流程而脚本注释特别提醒CoreS3 上 debug/instrument 构建会为 xsbug 保留 USB Serial/JTAG导致 Codex Voice 的 USB 通信不可用见 firmware/scripts/firmware.mjs 的对应警告。建议的执行顺序是候选提交固定P-01→ CI 与产物校验P-02→ 元数据校验check:release→ 设备冒烟test:device→ 人工实机清单本文全部项目→ 全部 PASS 后合并发布 PR、推送vX.Y.Z标签触发 firmware bundle 重构建与 GitHub Release 发布。结语发布前实机测试是 Stack-chan可复现发布的最后一道人工防线它用固定的候选提交、明确的判定记录表和分层的测试范围共通项 按功能挑选的追加项 追加机型把能不能发布这个问题从主观判断变成可审查的记录。配合仓库内check:release元数据校验与test:device设备冒烟脚本人工实机验证与自动化校验互为补充共同保证发布到main的每个版本都经过真实硬件确认、可追溯、可复现。赞分享嵌入式物联网智能硬件机器人硬件开发前端AI 应用【免费下载链接】stack-chanA JavaScript-driven M5Stack-embedded super-kawaii robot.项目地址https://gitcode.com/gh_mirrors/sta/stack-chan点击查看免费下载相关推荐Stack-chan 分支与发布流程全解从 develop 集成到 main 稳定版发布Stack chan 分支与发布流程全解从 develop 集成到 main 稳定版发布 本篇指南系统讲解开源机器人项目 Stack chan 的分支Bra嵌入式物联网智能硬件机器人硬件开发前端AI 应用ISO3166 PHP库常见问题解答解决90%开发者遇到的集成难题ISO3166 PHP库常见问题解答解决90%开发者遇到的集成难题 ISO3166 PHP库是一个提供ISO 3166 1数据的PHP工具包帮助开发者轻松处react-color版本发布清单从测试到生产完整流程react color版本发布清单从测试到生产完整流程 你还在为开源项目发布版本时手忙脚乱本文将带你了解react color项目从测试到生产的完整发布流程前端UI组件上一篇open62541加密通信全面支持从Basic128Rsa15到Aes256Sha256RsaPss下一篇Docker 一条命令部署 XiaoMusic小爱音箱 5 分钟免费播放本地音乐创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考