应用图谱还在走旧入口：HarmonyOS 7 功能开关变更后，稳定性遍历怎么绑定构建版本-育师

应用图谱还在走旧入口：HarmonyOS 7 功能开关变更后，稳定性遍历怎么绑定构建版本

稳定性测试报告看起来覆盖了首页、搜索、收藏和详情页，正式包却在新的登录入口崩溃。回头一看，遍历图谱来自上一个构建，测试时的功能开关也和提交包不同。官方应用探索测试会通过智能遍历构建应用特征图谱，并优先覆盖核心功能区域；工程上仍要回答一个更具体的问题：这张图谱到底证明了哪个构建、哪组开关和哪条用户路径。本文给出一套“图谱证据封套”，把看似绿色的覆盖率变成可追溯证据。

验证边界：本文的 HarmonyOS 7/API 26 能力与约束以文末当前官方资料为准；应用侧状态模型和断言已在本机 Node.js 环境执行。当前本机 SDK 为 API 24，且没有连接 HDC 真机，因此不声称完成 API 26 编译、真机拍摄、跨设备传输或 AppGallery 审核验证。

先复现“报告通过但新入口没被走到”

准备 build 211 和 build 212。211 中首页直接进入搜索，212 打开新功能开关后先经过账号选择页。对 211 完成一次应用探索测试，再把报告继续挂到 212 的发布材料中。记录 buildId、packageHash、featureFlagDigest、graphTaskId、entryRoute 和 coveredTaskIds。若报告仍显示核心路径已覆盖，而 212 的账号选择页从未出现在遍历地图中，问题就被稳定复现。

案例一：只改远程开关，包没变，图谱仍可能过期

包摘要没有变化不代表入口路径没变化。远程配置把“搜索”入口替换为“账号选择→搜索”，旧图谱的节点和边已经不能证明新路径可达。保存测试证据时必须同时保存开关快照摘要，并在快照变化后重新训练或补充模型。

案例二：弹窗遮住核心入口，遍历覆盖率仍看起来很高

新版本首次启动增加协议弹窗，智能遍历先在非核心区域兜圈。报告仍覆盖大量旧节点，却没有完成登录、搜索、编辑和提交四个关键任务。不能只看节点数量，要为核心任务建立独立的 taskId 和完成判定。

图谱不是永久资产，它有构建和场景版本

官方文档说明应用探索测试会构建应用特征图谱，先覆盖底部菜单、顶部频道和功能入口，再补充常见操作与非核心页面。这个机制非常适合发现未知路径，但图谱节点依赖当时的界面、控件语义和入口条件。业务路由、登录态、地区、灰度开关或权限前置一变，图谱就需要带版本，而不是继续被当作同一个模型。

覆盖率必须回到核心任务

把“登录完成、搜索得到结果、编辑保存成功、提交出现回执”定义为四个任务断言。遍历地图可以展示路径广度，任务断言负责证明业务闭环。每个任务保存起点条件、终点信号、关键日志和失败截图。这样即使图谱多出几百个节点，也不会掩盖提交按钮从未被点击。

功能开关变化时只补受影响子图

不必每次都从零训练整张图谱。先比较 buildId、路由表摘要和 featureFlagDigest，找出改变入口、页面结构或权限前置的区域，标记受影响子图并重跑。若全局导航、登录或账号体系变化，再执行完整探索。这个分层策略比“永远复用”可靠，也比“任何修改都全量重跑”更经济。

可直接复用的工程切片

typeGraphEvidence={buildId:stringpackageHash:stringfeatureFlagDigest:stringgraphTaskId:stringcoveredTaskIds:string[]}functioncanReuseGraph(oldItem:GraphEvidence,current:GraphEvidence):boolean{returnoldItem.buildId===current.buildId&&oldItem.packageHash===current.packageHash&&oldItem.featureFlagDigest===current.featureFlagDigest}

上面是围绕官方能力位置整理的 ArkTS/工程接入片段，仍需在 API 26 工具链和目标设备上编译验证。下面把最容易出错的应用侧判定抽成可执行断言，避免把接口示意写成“已经真机跑通”。

functiondecision(oldE,currentE,critical){if(oldE.packageHash!==currentE.packageHash)return'rebuild';if(oldE.flagDigest!==currentE.flagDigest)returncritical?'rebuild':'partial';return'reuse';}constoldE={packageHash:'a1',flagDigest:'f1'};if(decision(oldE,{packageHash:'a1',flagDigest:'f2'},true)!=='rebuild')thrownewError('关键入口变化仍复用旧图谱');if(decision(oldE,{packageHash:'a1',flagDigest:'f1'},false)!=='reuse')thrownewError('相同证据无法复用');

方案对比

方案	优点	风险或限制
只看节点覆盖率	快速观察遍历广度	无法证明核心任务完成
每次全量重训	最保守	耗时高，难以定位变化影响
构建/开关绑定 + 子图重跑	可追溯且成本可控	需要维护任务与版本元数据

选择“证据封套 + 核心任务 + 受影响子图”方案。它不改变 DevEco Testing 的遍历能力，而是为报告补上构建归属和业务闭环。