桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载本文以 docs/develop/testing/README.md 及其配套文档 fixture_controller.md 为主体结合主仓src/one_dragon/base/operation/下的操作框架源码operation.py、operation_edge.py与「随便观」示例应用源码讲解绝区零一条龙项目ZenlessZoneZero-OneDragon的自动化测试方法论。读者将掌握测试代码放在哪里、如何运行、测试基建长什么样、如何判断一个 app/op 该写哪些测试完整性判据、如何写单节点单元测试与多帧流程测试以及提交与代码规范。1. 测试在哪里、怎么跑测试代码不在主仓而在独立仓zzz-od-test主仓.gitignore忽略它clone 到主仓根目录使用。docs/develop/testing/目录的作用是记录怎么跑测试 测试基建 怎么判断写哪些 怎么写。1.1 仓库布局测试仓zzz-od-testclone 到主仓根目录IDE 中把zzz-od-test/设为Test Sources Root主仓不保留测试历史tests/已废弃新测试统一加到zzz-od-test/test/对应被测包的路径下环境变量把zzz-od-test/.env.sample复制到主仓根目录为.env部分测试需要如果本地只跑自己改动的部分可以不配全。1.2 运行测试uv run --env-file .env pytest zzz-od-test/该命令基于项目使用的 uv 工具链参见根目录 pyproject.toml 与 uv.lock以.env注入环境变量后对整个测试仓执行 pytest。2. 测试基建zzz-od-test/test/conftest.py所有依赖识别能力的测试共享同一套基础设施核心是三件套2.1test_contextfixturesession 级运行ctx.init()加载真 OCR与真 screen_info即 assets/game_data/screen_info/ 下的画面定义注入MockController全程只初始化一次session 内复用使用current_instance_idx99隔离测试配置写盘避免污染真实用户配置。2.2 mock 下一帧test_context.add_mock_screenshot(img)把任意一张图设为 controller 的下一帧test_context.mock_screen(screen_name, state)从测试仓截图存档screens/screen/state.webp读取一帧并设上存档说明见 screenshot_archive.md。2.3MockControllerscreenshot()返回 mock 帧click()返回 in-bounds 布尔值不真正点击用于断言点击动作是否落点在合法范围内。3. 完整性方法论拿到 app/op怎么判断写哪些测试这是文档的核心章节解决「一个 app/op 的测试怎样才算完整」的问题。方法论先给出一句话判据再展开为「动作一适用所有节点 动作二判定是否需要流程测试」两套动作。3.1 完整性判据一句话一个 app/op 的测试完整当且仅当每个节点的每个分支都有单测动作一适用所有节点且返回round_wait或用until_*的节点额外有流程测试动作二且status 契约在写测试时人工对照下游node_from动作一第 3 步——不写对账工具。注意边界拓扑合法性节点/边/start 唯一由框架加载时校验operation.py_analyse_node_annotationsL240-292 与_init_networkL294-342如「存在多个起始节点」「找不到节点 xx」等 ValueError不计入测试职责。3.2 动作一数全分支 完整覆盖 对照下游适用所有节点对每个operation_node节点先确定它的分支集合 可能返回的 status 集合。节点有四种写法分支来源各不相同1显式字面量body 里有round_success/wait/retry/fail(statusxxx)→ 这些xxx就是分支。2薄包装return self.round_by_X(...)body 无显式 status 字面量 → 分支 helper 返回契约。常见契约可在 operation.py 中确认源码实现helper返回契约round_by_ocr_and_click_by_priority(targets)round_success(status匹配的 target)/round_retry(未匹配到目标文本)L1227 起round_by_find_and_click_area(screen, area)无 until_点击成功round_success(area_name)/ 未找到·点击失败round_retry/ 区域未配置round_failL894 起round_by_find_and_click_area(screen, area)带 until_点击成功先round_wait(area_name)下一轮 until 满足后round_success(area_name)round_by_find_area(screen, area)round_success(statusarea_name)/ 未命中round_retryL993 起⚠️ area 类 helper 另有一个round_fail(区域未配置 area)分支配置错误通常不测但数分支时要知道它存在。表中为非完整列表round_by_ocr_and_click_with_action还能返回round_waitround_by_click_area、round_by_goto_screen等请以 operation.py 源码为准。3混合显式守卫 薄包装先if 守卫: return round_X(status显式字面量)再return self.round_by_Y(...)。此时分支 显式 statuses ∪ helper 契约不能只数 helper 那部分。源码示例click_squad_team节点先not self.claim→round_success(跳过收获)再走 ocr_and_click。4委托子 opround_by_op_result(op.execute())→0 自有分支进子 op 测。委托分支的路由正确性依赖子 op 的测试——其下游node_from(status具体)边的 status 来自子 op 返回对照时查子 op。每个分支一个单测mock 该分支输入先读节点/helper 检测什么——OCR 文本areaconfigstatus 名是线索→ 调节点 → 断言返回status 动作。要点断言类型按返回走不要照搬is_successround_success/round_by_find_area命中 Trueround_wait/round_retryFalse看 status薄包装节点mock 让 helper命中 / 不命中两种帧断言两种返回until_find_all/until_not_find_all多帧场景同一 op 实例连续调 2 次节点方法。完整覆盖 对照下游契约兜底关键完整覆盖上面数出的每个分支都要有单测断言 status一个不漏对照下游grep 本节点的所有node_from(from_name本节点, ...)把「下游声明的 status」与「本节点返回的 status」对比。⚠️只比round_success/round_fail的 status——round_wait/round_retry是节点内自循环/重试框架 WAIT/RETRY 直接 continue 同节点不经node_from不进下游边对应源码 operation.pyexecuteL412-512 中的if round_result.result OperationRoundResultEnum.WAIT: continue与 RETRY 分支下游statusX声明的 X本节点 success/fail 会返回吗没有 死边拼错或漏测分支本节点 success/fail 返回的 X有下游接吗没有statusX边不一定是死 status——可能被ignore_statusTrue兜底边接收框架无精确匹配时走兜底见 operation_edge.py L36-41 与_get_next_nodeL550-588 的final_next_node_id逻辑都没有才是死 status或 X 是终态——人工判失败路由边node_from(successFalse)带具体 status的status 来自子 op 失败/超时确认其在失败场景可达流程测试 mock 子 op 失败覆盖多数失败边用默认ignore_statusstatus 无关安全。⚠️ 动作一适用所有节点包括动作二判为「要画面变化」的。它们的每个分支也能单帧 mock 测mock 一帧 → 调节点 → 断言返回round_wait/success——单帧 mock 跑完整execute()会卡死但直接调节点方法不会。3.3 动作二这个节点要不要额外流程测试信号节点会返回round_wait 下一轮重跑自身期待画面演进或用了until_find_all/until_not_find_all。有→ 额外用FixtureController「会换帧的假游戏」跑execute()覆盖「点 → 等画面变 → 再识别」的推进/轮询动作一单测覆盖不到的运行时推进。注意五个坑运行态前置 / 看门狗 / 恢复 clickon_click_in/ OpenGame 排除 / 剪贴板规避详见 fixture_controller.md没有看一眼就返回或只round_retry同帧重试→ 动作一的单测够⚠️round_retry不是画面变化信号同帧重试点击失败 / 未找到。流程测试是动作一的补充不是替代被判为需要流程测试的节点仍要按动作一逐分支写单测。3.4 完整度自检 checklist每节点每分支含薄包装的 helper 契约分支都有单测返回round_wait/ 用until_*的节点额外跑了流程测试每节点写测试时对照了下游node_from死边 / 死 status3.5 status 契约方法论约束不写对账工具靠动作一「对照下游」写每个节点测试时 grep 其node_from对照返回 status死边/死 status 当场发现为什么不写对账工具静态猜 body 上游 status 不可靠——薄包装 status 来自 helper 的target_cn/area_nameround_by_op_result透传子 op status静态分析会误报漏报单测驱动版仍要约定断言写法 方法↔节点名映射 处理终态噪声成本/可靠性比不好。advisory code review 兜底足矣残余风险诚实无自动化持续保证靠人/AI 写测试时对照 review 二次兜底薄包装节点「数全分支」必须查 helper 返回契约动作一已述否则对照失效。3.6 示例随便观两动作走一遍以主仓 suibian_temple_app.py随便观 App为例完整走一遍两动作节点动作一分支动作二返回 round_wait/until_*?写什么测试check_initial_screenL50-582显式是入口 / 不在否2 单测handle_auto_manage/yum_cha_sin/good_goods/boo_box/pawnshop各 1config 显式未开启…否各 1 单测goto_suibian_templeL66-96~5wait(result.status)/success(current_screen)/success(开始托管)/wait(返回)/retry(未识别当前画面)是ocr_and_click → 手写 round_wait5 单测 流程测试goto_adventure子 op薄包装find_and_click_area until_not_find_all是单测until 连调 2 次 流程测试click_squad_team混合3跳过收获 ocr 命中/未命中否3 单测click_finish/click_claim/click_confirm纯薄包装2ocr 命中/未命中否各 2 单测handle_adventure_squad/adventure_squad_2/craft/sales_stall/goto_category/back_at_last纯委托0 自有分支—进子 op 测不单列结论随便观应写 单测app 层 config/入口/goto_suibian_temple各分支 子 op 薄包装/混合节点分支 流程测试goto_suibian_temple/Transport/BackToNormalWorld/goto_adventure要 FixtureController 凑帧因实拍成本搁置。4. 测什么归属与判据支撑第 3 节的「为什么」#测什么归属判据载体1拓扑合法性框架加载校验不用 app 测框架2单节点识别/决策含薄包装 helper 契约分支简单 mock 单测第 3 节动作一第 5 节3流转/轮询/重试/恢复返回 round_wait / until_*FixtureController第 3 节动作二第 6 节4status 契约单测断言上游 对照下游node_from第 3 节动作一「对照下游」第 3 节判据原则流转不能全交给底层框架只管拓扑不管 status 匹配与画面推进流程测试只给「返回 round_wait / until_*」的节点不是每个 app 端到端。5. 怎么写单节点测试5.1 简单 / 单节点测试常用范式mock 一帧 直接调 op 的节点方法 断言。示例对应test_suibian_temple_app.py::test_check_initial_screen_in_templedef test_xxx(test_context): test_context.mock_screen(打开游戏, ready) # 设一帧 op SomeOp(test_context) op.screenshot() # 取 mock 帧 → last_screenshot result op.check_screen() # 直接调节点 assert result.status 打开游戏覆盖识别 单节点决策/分支。5.2 断言看 node 返回类型别照搬 is_successnode 返回的OperationRoundResult类型决定is_success写断言前先读 node 代码确认返回类型node 返回is_success断言用round_success/round_by_find_area命中 /round_by_ocr_and_click命中Trueassert result.is_successround_wait点 area / click 后等下一轮Falseassert result.status 匹配词round_retry未识别重试Falseassert not result.is_success或status不同 app 同类 node 返回类型可能不同别照搬别的 app 的断言。源码上round_success/round_wait/round_retry/round_fail分别构造OperationRoundResultEnum.SUCCESS/WAIT/RETRY/FAIL结果operation.py L789-851。5.3 mock 哪帧先读 node 逻辑 status 名线索测哪个 node、mock 哪帧取决于该 node 在哪帧检测什么。读 node 代码确认 OCR/area 的检测目标画面 元素别臆测status 名是线索如round_success(status已在邻里街坊-进入好物铺)暗示检测的是邻里街坊菜单的「好物铺」选项进好物铺前置不是好物铺画面的标题 logo → mock 邻里街坊菜单OCR/area 检测目标node 的round_by_ocr(X)/round_by_find_and_click_area(screen, area)检测的是哪种画面的什么元素——决定 mock 哪帧失败别急着归因绕过测试失败先回 node 代码确认检测目标别直接「OCR 不到 → 换图绕过」。⚠️注意 LCS 误匹配mock 帧里若含与 target 部分相似的文字如入口「游历」tab vs target「游历小队」LCS 会误命中str_utils.find_by_lcs的匹配阈值默认 0.5见 operation.py L1210——换个不含干扰文字的帧。5.4 多分支用例参数化 vs 独立方法按逻辑同质性一个节点的多个分支按分支逻辑是否同质选写法pytest 行业惯例旧约定非教条逻辑同质同一套 mock → 调节点 → 断言只输入/期望不同→参数化pytest.mark.parametrize 数据表每行一个分支带ids让失败用例名可读。例某节点按标题 OCR 分多个子态识别逻辑一样、只是标题 期望标志不同 → 一张表搞定同质硬拆独立方法反而是反模式逻辑异质断言类型不同is_successvsstatus/ 搭建不同 / 改 config / mock 子 op→独立方法test_场景_分支每个方法断言自己的返回。「每个分支一个单测」参数化每行 / 独立方法每个都算一个单测两种都满足。下方「薄包装节点命中/不命中」是异质例子命中看is_success、不命中看status→ 拆独立方法同质多分支用参数化。5.5 薄包装节点mock 命中 / 不命中两帧薄包装节点return self.round_by_X(...)按 helper 契约第 3 节动作一mock 两种帧命中mock 含 target/area 的帧 →round_success(status匹配词)不命中mock 不含 target 的帧 →round_retry(未匹配到目标文本)。混合节点守卫 薄包装额外测守卫分支例如claimFalse→跳过收获。5.6 config 分支monkeypatch 改 config不写盘config 开关分支用monkeypatch.setattr(ConfigClass, 字段, 值)改 config不写盘、自动还原、实例 99 隔离。⚠️ 这些未开启/未开启自动托管等 status 串是下游node_from的匹配词断言它们 守 app 编排边契约。5.7until_find_all/until_not_find_all同一 op 实例连续调 2 次多帧 mockround_by_find_and_click_area(until_*...)这类「click 后等画面变化」的 node源码见 operation.py L934-966node_clicked为 True 时才做 until 校验否则先 click 并置node_clickedTrue、返回round_wait用last_screenshot验证 node_clicked标志需两轮第 1 轮node_clickedFalsemock click 前画面 → click →round_wait(statusarea)第 2 轮node_clickedTruemock click 后画面 → until 验证 area 消失/出现 →round_success。测试在同一 op 实例上连续调 node 2 次不经 runner——_reset_status_for_new_node只在 runner 进新 node 时重置node_clicked手动连调保持标志对应源码 operation.py L590-599。示例op SomeOp(test_context) test_context.mock_screen(随便观, 入口-手动态) # 第 1 帧click 前 op.screenshot() r1 op.goto_adventure() # click 按钮-游历 → round_wait assert r1.status 按钮-游历 test_context.mock_screen(随便观, 游历) # 第 2 帧click 后 op.screenshot() r2 op.goto_adventure() # until 验证 → round_success assert r2.is_success6. 怎么写流程测试FixtureController6.1 是什么FixtureControllerMockController子类位于zzz-od-test/test/harness/fixture_controller.py 一个「会反应的假游戏」screenshot()返回当前 phase 的固定截图click/input/press_key记录动作 按剧本推进到下一 phase配真 ctx真 OCR screen_infoop 的识别/流转/决策在固定帧上跑。何时用第 3 节动作二op 有返回round_wait或用until_*的节点流转/轮询/重试/恢复/多帧状态机才需要跑完整execute()对应源码 operation.pyexecuteL412-512 的多轮循环。线性派发每节点看一眼就返回不用——动作一的单测够。示例test_enter_game_flow.pyEnterGame 自动登录全流程ready → 点进入游戏 → 登录服务器中 → ... → 大世界。覆盖op 的流程逻辑节点图边、轮询、恢复分支——单节点测试覆盖不到的部分。6.2 剧本phase有序 phase 列表每 phase 一帧 退出条件on_click_in(region)click 落在 region查 screen_info 的 areapc_rect或剧本给坐标 rect才推进。对有恢复性 click 的节点强制用这个避免恢复 click 误推进on_action任何 click/input 推进。只用于「该 phase 唯一流程 click、无恢复 click」on_polls(n)screenshot()调 n 次后自动推进模拟游戏自动流转如登录服务器中 → 大世界无用户动作。最脆弱见 6.3 看门狗坑优先少用。末 phase 默认粘住多余 sense 一律返末帧抗轮询次数漂移。6.3 关键坑必读运行态前置op 的execute()首轮查is_context_stop_run_stateSTOP默认→ 直接退出源码见 application_run_context.py L309 与 operation.py L430。is_context_stop是只读属性无 setter。测试execute()前直接置ctx.run_context._run_state RUNNINGfinally复位STOPctx.run_context.event_bus.unlisten_all_event(op)——sessiontest_context复用不复位会污染后续测试。用 harness 的enter_running_state(ctx, op)/reset_running_state(ctx, op)。看门狗必须op 框架的 round 上限只管 RETRYWAIT 无上限源码 L474-485RETRY 受node_max_retry_times限制WAIT 直接continue——剧本对不齐会在 WAIT 段死循环。用WatchdogOperationMixin覆盖_execute_one_round不是execute()轮次上限 → 置_run_stateSTOPloop 下轮退出。恢复性 click on_click_inop 有些节点在 retry/recovery 时也 click如 EnterGamecheck_screen卡登录时点「国服-返回按钮」恢复。这些 click不能推进 phase——该 phase 用on_click_in(期望的流程 area)只认流程 click忽略恢复 click。OpenGame 排除OpenGame/OpenAndEnterGame会写 Windows 注册表HDRsubprocess.Popen拉 exeFixtureController 拦不住。只测画面驱动的 op如 EnterGameis_game_window_readyTrue绕过框架注入的 check-window 链否则会被路由到「打开并进入游戏」调 OpenGame。剪贴板规避op 输账号密码可能走PcClipboard.copy_and_paste不走 controller会写真实 OS 剪贴板。测试 pinctx.game_config.type_input_way INPUT走keyboard.type分支FixtureController 能 mock。fixture 用monkeypatch改 controller type_input_way避免污染 sessiontest_context。6.4 参考实现zzz-od-test/test/harness/fixture_controller.pyFixtureController WatchdogOperationMixin 运行态 helperzzz-od-test/test/zzz_od/operation/enter_game/test_enter_game_flow.pyEnterGame 自动登录流程测试 on_click_in 门控单测。7. 提交坑重要测试文件在zzz-od-test独立仓。主仓git add zzz-od-test/...会被.gitignore静默跳过不报错但未加入。必须在测试仓内提交协作边界说明见 AGENTS.md「提交流程与协作边界」git -C zzz-od-test add test/ git -C zzz-od-test commit -m ...8. 代码规范 / fixture 格式8.1 代码规范项目特有过自检筛文件路径测试文件放在被测文件的包路径 被测文件名的文件夹下如被测one_dragon/base/operation/one_dragon_context.py→zzz-od-test/test/one_dragon/base/operation/one_dragon_context/单方法文件每个测试文件专门测试单个方法的各种场景fixture scope用pytest.fixture管理依赖注意指定scope如 session 级test_context只 init 一次导入不用srcfrom one_dragon.base.operation import Operation✓from src.one_dragon...✗异步超时异步测试方法必须加超时如pytest.mark.timeout(3)防止无限挂起。8.2 测试 fixture 图尽量 webp q90测试 fixture 的整屏截图默认转 webp q90省约 90% 体积整屏识别无损效。原则满足测试为准——转后跑测试过的留 webp实测不过的保留 PNG。能压整屏画面匹配 / 事件识别容差大保留 PNG精度敏感小地图角度、含细文字 OCRwebp q90 致 OCR 空、模板裁剪源webp lossy → 裁剪放大 artifacts → 模板 conf 降转换cv2.imencode(.webp, img, [cv2.IMWRITE_WEBP_QUALITY, 90])ndarray.tofile(path)中文路径安全非cv2.imwrite批量转换可参考 convert_to_webp.py。原 PNG 保留确认无引用且测试过后手动删改引用转后同步改测试代码.png→.webp保留 PNG 的不改。截图存档zzz-od-test/screens/screen/state.webp的格式约定与加图流程详见 screenshot_archive.mdwebp q90 整屏识别无损conf 损耗 0.006、1080p 原生不缩放以对齐 screen_info 的pc_rect坐标、文件名 子态可读名、冒号转下划线等。9. 方法论小结这套测试方法论的核心闭环是从 app/op 出发 → 动作一逐节点数全分支写单测并对照下游node_from守 status 契约 → 动作二对返回round_wait/用until_*的节点补 FixtureController 流程测试 → 自检 checklist → 在独立仓提交。它与操作框架的运行时语义WAIT/RETRY 同节点自循环、node_clicked标志、ignore_status兜底边、拓扑加载校验严格对齐既不重复框架职责拓扑校验也不把流转逻辑全部交给底层是一套「框架只管拓扑、测试守 status 与画面推进」的分层测试策略。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐如何不再拖窗口边缘macOS 窗口管理工具 Loop 的 3 步上手如何不再拖窗口边缘macOS 窗口管理工具 Loop 的 3 步上手 你肯定也遇到过这种场面想把两个窗口切成三栏拖了 5 分钟窗口边缘还是对不齐切屏之后桌面应用终极BottomNavigation测试指南从单元测试到UI自动化的完整实践方案终极BottomNavigation测试指南从单元测试到UI自动化的完整实践方案 BottomNavigation是一个帮助开发者轻松实现Google底部导航语言运行时后端开发工具包管理器前端构建测试Huma框架深度解析Go语言中构建现代化REST API的完整指南Huma框架深度解析Go语言中构建现代化REST API的完整指南 Huma是一个专为Go语言设计的REST/HTTP API框架它提供了OpenAPI 3后端开发工具上一篇Windows窗口置顶终极指南AlwaysOnTop让你的重要窗口永不遮挡下一篇网盘直链下载助手3分钟解决网盘限速难题的终极方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考