用 tmux 对 Qwen Code TUI 做真实用户 E2E 测试capture-pane 可读日志工作流【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本指南讲解如何像真实用户一样在 tmux 中驱动 Qwen Code 的 TUI终端用户界面完成/auth、/model、/rewind、MCP 配置等交互流程并以tmux capture-pane -p逐步抓取可读快照生成维护者可以直接复查的叙事型测试报告tmux-readable-full.log。读完本文你将掌握一套从场景设计、按键驱动、状态轮询到日志归档的完整 tmux 真实用户测试方法论并理解为什么pipe-pane原始 ANSI 流不能作为主要交付物。该技能的完整定义位于仓库的 .qwen/skills/tmux-real-user-testing/SKILL.md。为什么用 tmux 而不是原始管道日志核心原则capture-pane 记录的是渲染后的画面Qwen Code 的 TUI 基于 React Ink 构建其输出在终端中通过 ANSI 控制序列实时重绘。如果直接用tmux pipe-pane把终端输出重定向到文件得到的往往是一大段夹杂转义序列的乱码文本无法直接阅读。因此本技能的核心原则是把 tmux 当作真实使用 harness用贴近真实用户的键盘操作驱动 TUI在每次有意义的界面状态变化后用tmux capture-pane -p抓取当前渲染帧将tmux-readable-full.log逐步可读快照作为主交付物pipe-pane仅作为可选的取证forensic工件不承担主要报告职责。这一判断也符合仓库中既有 E2E 实践例如 scripts/test-rewind-e2e.sh 中所有断言都基于tmux capture-pane -p的可见 pane 内容如等待Type your message提示符出现而非解析原始字节流scripts/tmux-compare.sh 也是用capture-pane -p分别抓取两个 pane 的渲染输出做 diff 对比。何时使用、何时不用场景推荐方案TUI 行为、渲染、对话框、键盘导航、slash 命令、auth 流程tmux 真实用户测试维护者事后想阅读完整交互旅程tmux 真实用户测试最终状态不足以判定、中间屏幕很关键的回归测试tmux 真实用户测试用户可见流程/auth、/model、/manage-models、MCP 配置、权限、onboarding、交互式错误恢复tmux 真实用户测试只需对工具执行或模型 API 行为做结构化断言无头 JSON E2E标准产物目录结构每次运行在项目tmp/下创建带时间戳的目录且不覆盖历史运行tmp/scenario-tmux-YYYYMMDD-HHMMSS/ ├── tmux-readable-full.log # 主报告逐步可读快照 ├── tmux-final-capture.log # 仅最终画面 ├── current-pane.txt # 最新轮询/快照临时文件 └── report.md # 简短摘要结果与产物指针除非用户明确要求脱敏或裁剪否则保留完整日志。这一布局与 helper 脚本的start命令自动生成的outdir$workdir/tmp/${scenario}-tmux-${ts}完全一致见 .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh。推荐助手脚本tmux-real-user-log.sh为避免重复编写 shell 胶水技能提供了scripts/tmux-real-user-log.sh支持 start / snapshot / send / type-submit / wait-for / finish / help 七个子命令。建议先查看完整用法bash .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh helpstart命令会输出export语句用eval直接注入当前 shelleval $(bash .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh \ start scenario . npm run dev -- --approval-mode yolo) # → $SESSION, $OUTDIR, $LOG 现在可直接使用各子命令的作用与参数对应脚本源码 .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh子命令参数行为startscenario workdir command...以 200x50 视口创建后台 tmux 会话并启动命令会先检查会话名是否已存在has-session避免误覆盖输出export SESSION/OUTDIR/LOGsnapshotsession outdir label [scrollback]向tmux-readable-full.log追加 label 标题与capture-pane -p -S scrollback快照默认 -300sendsession keys...逐个发送按键每个按键间隔 0.15stype-submitsession text先发送文本间隔 0.5s 后发送 Enterwait-forsession outdir regex [attempts] [sleep_seconds] [scrollback]轮询 pane 文本直到匹配正则默认 60 次 x 2sscrollback -400成功输出最终 pane 内容并退出 0超时输出内容并退出 1finishsession outdir抓取最终画面写入tmux-final-capture.log追加到主日志后 kill 会话并打印两个日志的行数wc -l注意wait-for的超时以退出码表达grep -Eq匹配则exit 0否则循环结束后exit 1见 脚本源码调用方可以据此判定 PASS/FAIL。手工工作流五步走如果不想依赖助手脚本也可以按以下手工流程操作。1. 启动 TUI使用大视口如-x 200 -y 50确保对话框完整渲染启动后不要盲目 sleep而是轮询已知的启动字符串TS$(date %Y%m%d-%H%M%S) PROJECT_ROOT$(pwd) OUT$PROJECT_ROOT/tmp/scenario-$TS SESSIONscenario-$TS mkdir -p $OUT tmux new-session -d -s $SESSION -x 200 -y 50 \ -c $PROJECT_ROOT \ npm run dev -- --approval-mode yolo # 轮询直到 TUI 就绪按你的应用启动行调整正则 for i in $(seq 1 30); do sleep 1 if tmux capture-pane -t $SESSION -p -S -100 | grep -q Ready\|; then break fi done启动命令的选择原则默认使用npm run dev源码调试态仅在验证构建产物时使用node dist/cli.js构建方式参考 scripts/test-rewind-e2e.sh 中的npm run build npm run bundle产物位于 dist/cli.js包定义见 packages/cli/package.json仅在复现用户报告的已安装版本 bug 时使用全局安装的qwen命令。--approval-mode yolo是 CLI 的免审批模式选项可避免测试过程中弹出权限确认阻塞流程仓库中大量 E2E 脚本均以此启动如 scripts/test-rewind-e2e.sh。2. 追加带标签的可读快照每次有意义的动作之后向主日志追加小节标题与capture-pane -pLOG$OUT/tmux-readable-full.log { printf \n 01 /auth dialog \n tmux capture-pane -t $SESSION -p -S -240 } $LOG随着会话增长逐步增大-S每个小节大约增加 100 行。关键点每个小节都是渲染后的帧而不是原始 ANSI 输出。3. 像用户一样发送按键将打字与回车分开避免提交被吞掉tmux send-keys -t $SESSION /auth sleep 0.5 tmux send-keys -t $SESSION Enter sleep 2导航类按键直接发送按键名tmux send-keys -t $SESSION Down tmux send-keys -t $SESSION Space tmux send-keys -t $SESSION Escape向 Ink 输入框填入文本时如果整段文本被忽略改为逐键发送tmux send-keys -t $SESSION e n a b l e d补充说明在需要精确控制回车与文本时可参考 scripts/test-rewind-e2e.sh 的做法——用tmux send-keys -l以字面模式发送文本、再单独发送Enter处理 ESC 相关交互时可先设置tmux set-option -sg escape-time 0避免 tmux 将 ESC 误判为转义序列前缀该脚本注释明确说明没有此设置时 tmux 会为 ESC 保留最多 500ms。4. 用屏幕文本轮询完成条件而非盲目 sleepfor i in $(seq 1 60); do sleep 2 tmux capture-pane -t $SESSION -p -S -400 $OUT/current-pane.txt if grep -q Successfully configured\|Error\|failed \ $OUT/current-pane.txt; then break fi done # 无论匹配还是超时都把最终轮询结果追加进日志 { printf \n 04 auth result \n cat $OUT/current-pane.txt } $LOG超时后也要 dump 当前 pane让日志如实记录等待超时那一刻屏幕上发生了什么。更进一步scripts/test-rewind-e2e.sh 展示了等待空闲的增强版同时要求提示符可见、无esc to cancel的旁路查询在跑、且连续 3 秒画面哈希不变才算真正 idle。5. 干净收尾tmux capture-pane -t $SESSION -p -S -10000 $OUT/tmux-final-capture.log { printf \n final capture before cleanup \n cat $OUT/tmux-final-capture.log } $LOG tmux kill-session -t $SESSION报告撰写规范每个场景必须生成report.md包含日期、tmux 会话名、启动命令、工作目录场景范围与被测的确切步骤PASS/FAIL 结果关键屏幕观察与重要状态迁移产物清单并标注tmux-readable-full.log为主日志已知副作用设置项更新、打开的浏览器窗口、API 调用等。断言必须与日志中的证据绑定。优先使用日志小节07 toggle model on显示16 enabled这类可定位表述而不是空泛总结。tmux-final-capture.log只含最后一屏它不是完整旅程完整旅程以tmux-readable-full.log为准。测试场景设计方法论一个良好场景是一条可观察状态迁移的线性序列每个步骤都应产生可捕获的可见 TUI 输出入口点Entry point——启动流程的 slash 命令或动作分支点Branch points——需要方向键Arrow / Space / Enter导航的对话框或选择器等待态Waiting states——加载屏、auth 回调、异步操作需要wait-for轮询确认Confirmation——屏幕上的成功/失败文本标记完成副作用Side effects——流程触发的外部动作打开浏览器、写文件、改配置可能影响后续运行。为每个步骤预先定义要发送的按键/auth、Down、Enter…、要等待的期望文本Successfully configured、Error、Saved…、何时截图每次交互前后各一次。实战示例测试 /auth → OAuthHELPER.qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh # 启动 eval $(bash $HELPER start auth-test . npm run dev -- --approval-mode yolo) # → 打印 SESSION... OUTDIR... # 触发 /auth导航到 OAuth provider bash $HELPER type-submit $SESSION /auth bash $HELPER snapshot $SESSION $OUTDIR 01 auth menu bash $HELPER send $SESSION Down Down Enter bash $HELPER snapshot $SESSION $OUTDIR 02 provider selected # 等待 OAuth 流程完成可能涉及浏览器交互 bash $HELPER wait-for $SESSION $OUTDIR Successfully configured|Error|failed bash $HELPER snapshot $SESSION $OUTDIR 03 auth result # 收尾 bash $HELPER finish $SESSION $OUTDIR对于涉及浏览器 OAuth 回调的流程wait-for轮询会在用户完成浏览器步骤后捕获结果如果流程需要 LLM 自己打开浏览器则要在场景设计中记录该副作用。安全与隐私删除日志或回滚设置前必须先征求用户同意用户明确要求完整日志时不要默认做脱敏日志若可能对外共享应提供一份独立脱敏副本而不是修改原件开始前说明可能的副作用OAuth 可能打开浏览器、写入 Qwen 设置、配置 API key、更新模型 provider 条目。常见陷阱清单macOS 上open file不产生终端输出是正常的——它会在关联应用中打开文件tmux-final-capture.log只含最后一屏不是完整旅程tmux-readable-full.log才是报告级产物tmux pipe-pane原始日志可能含 ANSI 控制序列看起来是乱码搜索框和输入框有时会忽略整段粘贴文本应逐字符发送capture-pane记录的是当前渲染状态不记录瞬时闪烁每次运行都要使用带时间戳的输出目录避免覆盖证据。这套方法论的价值在于把TUI 是否正常从断言通过/失败升级为维护者能读懂的叙事型旅程记录每个交互步骤都有对应渲染帧、每次轮询都有屏幕证据、每个断言都能定位到日志小节。对于/auth、/model、/manage-models、MCP 配置、权限授予、onboarding 等用户可见流程的回归测试这正是仓库所倡导的验证方式。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 tmux 对 Qwen Code TUI 做真实用户 E2E 测试：capture-pane 可读日志工作流
用 tmux 对 Qwen Code TUI 做真实用户 E2E 测试capture-pane 可读日志工作流【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本指南讲解如何像真实用户一样在 tmux 中驱动 Qwen Code 的 TUI终端用户界面完成/auth、/model、/rewind、MCP 配置等交互流程并以tmux capture-pane -p逐步抓取可读快照生成维护者可以直接复查的叙事型测试报告tmux-readable-full.log。读完本文你将掌握一套从场景设计、按键驱动、状态轮询到日志归档的完整 tmux 真实用户测试方法论并理解为什么pipe-pane原始 ANSI 流不能作为主要交付物。该技能的完整定义位于仓库的 .qwen/skills/tmux-real-user-testing/SKILL.md。为什么用 tmux 而不是原始管道日志核心原则capture-pane 记录的是渲染后的画面Qwen Code 的 TUI 基于 React Ink 构建其输出在终端中通过 ANSI 控制序列实时重绘。如果直接用tmux pipe-pane把终端输出重定向到文件得到的往往是一大段夹杂转义序列的乱码文本无法直接阅读。因此本技能的核心原则是把 tmux 当作真实使用 harness用贴近真实用户的键盘操作驱动 TUI在每次有意义的界面状态变化后用tmux capture-pane -p抓取当前渲染帧将tmux-readable-full.log逐步可读快照作为主交付物pipe-pane仅作为可选的取证forensic工件不承担主要报告职责。这一判断也符合仓库中既有 E2E 实践例如 scripts/test-rewind-e2e.sh 中所有断言都基于tmux capture-pane -p的可见 pane 内容如等待Type your message提示符出现而非解析原始字节流scripts/tmux-compare.sh 也是用capture-pane -p分别抓取两个 pane 的渲染输出做 diff 对比。何时使用、何时不用场景推荐方案TUI 行为、渲染、对话框、键盘导航、slash 命令、auth 流程tmux 真实用户测试维护者事后想阅读完整交互旅程tmux 真实用户测试最终状态不足以判定、中间屏幕很关键的回归测试tmux 真实用户测试用户可见流程/auth、/model、/manage-models、MCP 配置、权限、onboarding、交互式错误恢复tmux 真实用户测试只需对工具执行或模型 API 行为做结构化断言无头 JSON E2E标准产物目录结构每次运行在项目tmp/下创建带时间戳的目录且不覆盖历史运行tmp/scenario-tmux-YYYYMMDD-HHMMSS/ ├── tmux-readable-full.log # 主报告逐步可读快照 ├── tmux-final-capture.log # 仅最终画面 ├── current-pane.txt # 最新轮询/快照临时文件 └── report.md # 简短摘要结果与产物指针除非用户明确要求脱敏或裁剪否则保留完整日志。这一布局与 helper 脚本的start命令自动生成的outdir$workdir/tmp/${scenario}-tmux-${ts}完全一致见 .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh。推荐助手脚本tmux-real-user-log.sh为避免重复编写 shell 胶水技能提供了scripts/tmux-real-user-log.sh支持 start / snapshot / send / type-submit / wait-for / finish / help 七个子命令。建议先查看完整用法bash .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh helpstart命令会输出export语句用eval直接注入当前 shelleval $(bash .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh \ start scenario . npm run dev -- --approval-mode yolo) # → $SESSION, $OUTDIR, $LOG 现在可直接使用各子命令的作用与参数对应脚本源码 .qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh子命令参数行为startscenario workdir command...以 200x50 视口创建后台 tmux 会话并启动命令会先检查会话名是否已存在has-session避免误覆盖输出export SESSION/OUTDIR/LOGsnapshotsession outdir label [scrollback]向tmux-readable-full.log追加 label 标题与capture-pane -p -S scrollback快照默认 -300sendsession keys...逐个发送按键每个按键间隔 0.15stype-submitsession text先发送文本间隔 0.5s 后发送 Enterwait-forsession outdir regex [attempts] [sleep_seconds] [scrollback]轮询 pane 文本直到匹配正则默认 60 次 x 2sscrollback -400成功输出最终 pane 内容并退出 0超时输出内容并退出 1finishsession outdir抓取最终画面写入tmux-final-capture.log追加到主日志后 kill 会话并打印两个日志的行数wc -l注意wait-for的超时以退出码表达grep -Eq匹配则exit 0否则循环结束后exit 1见 脚本源码调用方可以据此判定 PASS/FAIL。手工工作流五步走如果不想依赖助手脚本也可以按以下手工流程操作。1. 启动 TUI使用大视口如-x 200 -y 50确保对话框完整渲染启动后不要盲目 sleep而是轮询已知的启动字符串TS$(date %Y%m%d-%H%M%S) PROJECT_ROOT$(pwd) OUT$PROJECT_ROOT/tmp/scenario-$TS SESSIONscenario-$TS mkdir -p $OUT tmux new-session -d -s $SESSION -x 200 -y 50 \ -c $PROJECT_ROOT \ npm run dev -- --approval-mode yolo # 轮询直到 TUI 就绪按你的应用启动行调整正则 for i in $(seq 1 30); do sleep 1 if tmux capture-pane -t $SESSION -p -S -100 | grep -q Ready\|; then break fi done启动命令的选择原则默认使用npm run dev源码调试态仅在验证构建产物时使用node dist/cli.js构建方式参考 scripts/test-rewind-e2e.sh 中的npm run build npm run bundle产物位于 dist/cli.js包定义见 packages/cli/package.json仅在复现用户报告的已安装版本 bug 时使用全局安装的qwen命令。--approval-mode yolo是 CLI 的免审批模式选项可避免测试过程中弹出权限确认阻塞流程仓库中大量 E2E 脚本均以此启动如 scripts/test-rewind-e2e.sh。2. 追加带标签的可读快照每次有意义的动作之后向主日志追加小节标题与capture-pane -pLOG$OUT/tmux-readable-full.log { printf \n 01 /auth dialog \n tmux capture-pane -t $SESSION -p -S -240 } $LOG随着会话增长逐步增大-S每个小节大约增加 100 行。关键点每个小节都是渲染后的帧而不是原始 ANSI 输出。3. 像用户一样发送按键将打字与回车分开避免提交被吞掉tmux send-keys -t $SESSION /auth sleep 0.5 tmux send-keys -t $SESSION Enter sleep 2导航类按键直接发送按键名tmux send-keys -t $SESSION Down tmux send-keys -t $SESSION Space tmux send-keys -t $SESSION Escape向 Ink 输入框填入文本时如果整段文本被忽略改为逐键发送tmux send-keys -t $SESSION e n a b l e d补充说明在需要精确控制回车与文本时可参考 scripts/test-rewind-e2e.sh 的做法——用tmux send-keys -l以字面模式发送文本、再单独发送Enter处理 ESC 相关交互时可先设置tmux set-option -sg escape-time 0避免 tmux 将 ESC 误判为转义序列前缀该脚本注释明确说明没有此设置时 tmux 会为 ESC 保留最多 500ms。4. 用屏幕文本轮询完成条件而非盲目 sleepfor i in $(seq 1 60); do sleep 2 tmux capture-pane -t $SESSION -p -S -400 $OUT/current-pane.txt if grep -q Successfully configured\|Error\|failed \ $OUT/current-pane.txt; then break fi done # 无论匹配还是超时都把最终轮询结果追加进日志 { printf \n 04 auth result \n cat $OUT/current-pane.txt } $LOG超时后也要 dump 当前 pane让日志如实记录等待超时那一刻屏幕上发生了什么。更进一步scripts/test-rewind-e2e.sh 展示了等待空闲的增强版同时要求提示符可见、无esc to cancel的旁路查询在跑、且连续 3 秒画面哈希不变才算真正 idle。5. 干净收尾tmux capture-pane -t $SESSION -p -S -10000 $OUT/tmux-final-capture.log { printf \n final capture before cleanup \n cat $OUT/tmux-final-capture.log } $LOG tmux kill-session -t $SESSION报告撰写规范每个场景必须生成report.md包含日期、tmux 会话名、启动命令、工作目录场景范围与被测的确切步骤PASS/FAIL 结果关键屏幕观察与重要状态迁移产物清单并标注tmux-readable-full.log为主日志已知副作用设置项更新、打开的浏览器窗口、API 调用等。断言必须与日志中的证据绑定。优先使用日志小节07 toggle model on显示16 enabled这类可定位表述而不是空泛总结。tmux-final-capture.log只含最后一屏它不是完整旅程完整旅程以tmux-readable-full.log为准。测试场景设计方法论一个良好场景是一条可观察状态迁移的线性序列每个步骤都应产生可捕获的可见 TUI 输出入口点Entry point——启动流程的 slash 命令或动作分支点Branch points——需要方向键Arrow / Space / Enter导航的对话框或选择器等待态Waiting states——加载屏、auth 回调、异步操作需要wait-for轮询确认Confirmation——屏幕上的成功/失败文本标记完成副作用Side effects——流程触发的外部动作打开浏览器、写文件、改配置可能影响后续运行。为每个步骤预先定义要发送的按键/auth、Down、Enter…、要等待的期望文本Successfully configured、Error、Saved…、何时截图每次交互前后各一次。实战示例测试 /auth → OAuthHELPER.qwen/skills/tmux-real-user-testing/scripts/tmux-real-user-log.sh # 启动 eval $(bash $HELPER start auth-test . npm run dev -- --approval-mode yolo) # → 打印 SESSION... OUTDIR... # 触发 /auth导航到 OAuth provider bash $HELPER type-submit $SESSION /auth bash $HELPER snapshot $SESSION $OUTDIR 01 auth menu bash $HELPER send $SESSION Down Down Enter bash $HELPER snapshot $SESSION $OUTDIR 02 provider selected # 等待 OAuth 流程完成可能涉及浏览器交互 bash $HELPER wait-for $SESSION $OUTDIR Successfully configured|Error|failed bash $HELPER snapshot $SESSION $OUTDIR 03 auth result # 收尾 bash $HELPER finish $SESSION $OUTDIR对于涉及浏览器 OAuth 回调的流程wait-for轮询会在用户完成浏览器步骤后捕获结果如果流程需要 LLM 自己打开浏览器则要在场景设计中记录该副作用。安全与隐私删除日志或回滚设置前必须先征求用户同意用户明确要求完整日志时不要默认做脱敏日志若可能对外共享应提供一份独立脱敏副本而不是修改原件开始前说明可能的副作用OAuth 可能打开浏览器、写入 Qwen 设置、配置 API key、更新模型 provider 条目。常见陷阱清单macOS 上open file不产生终端输出是正常的——它会在关联应用中打开文件tmux-final-capture.log只含最后一屏不是完整旅程tmux-readable-full.log才是报告级产物tmux pipe-pane原始日志可能含 ANSI 控制序列看起来是乱码搜索框和输入框有时会忽略整段粘贴文本应逐字符发送capture-pane记录的是当前渲染状态不记录瞬时闪烁每次运行都要使用带时间戳的输出目录避免覆盖证据。这套方法论的价值在于把TUI 是否正常从断言通过/失败升级为维护者能读懂的叙事型旅程记录每个交互步骤都有对应渲染帧、每次轮询都有屏幕证据、每个断言都能定位到日志小节。对于/auth、/model、/manage-models、MCP 配置、权限授予、onboarding 等用户可见流程的回归测试这正是仓库所倡导的验证方式。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考