API 26 升级只跑新系统不够：Change Assistant 结果怎么变成双版本回归矩阵
DevEco Studio 的 API Change Assistant 扫描完成，没有编译错误，新系统上首页也能打开，团队便认为升级结束。上线后，旧系统用户却在权限拒绝或后台恢复时崩溃。官方 HarmonyOS 7 升级适配指南同时要求评估 API 变化，并在新旧系统上验证兼容性。工具给的是变更线索，不是完整测试结论。
验证边界：本文依据华为开发者官网截至 2026-09-25 可访问的资料整理。文中的状态机、去重器和坐标计算已经在 Node.js 宿主环境执行断言；当前本机仍是 API 24 SDK，且没有连接 HDC 真机，因此不把这些断言写成 API 26 编译或真机实测。涉及窗口、拖拽和跨设备能力的正式交付，仍需在 API 26 SDK、模拟器或对应真机上补齐接口编译、交互录像与日志证据。
升级后最容易漏什么
扫描结果通常按 API 或文件列出，测试却按用户任务执行。直接把报告交给测试，容易只覆盖“新接口成功返回”，遗漏废弃接口仍在旧路径、默认行为变化、权限拒绝、异步取消和旧系统降级。另一个问题是只验证 target API 26 的新设备，没有确认最低支持版本仍能启动和完成核心任务。
把变更转成可执行规则
把每条变更映射成四个维度：受影响任务、旧系统路径、新系统路径、失败/取消路径。相同根因合并为一个风险族，生成最小回归矩阵。自动化负责静态命中、纯函数和协议断言；设备验证负责权限、生命周期、窗口和性能。每个格子必须写清设备、系统、步骤、预期与证据。
interface Change { api:string; tasks:string[]; behavior:'added'|'deprecated'|'changed' } interface Case { task:string; os:'old'|'new'; path:'success'|'failure' } export function matrix(changes:Change[]):Case[] { const keys=new Set<string>(), out:Case[]=[]; for(const c of changes) for(const task of c.tasks) for(const os of ['old','new'] as const) for(const path of ['success','failure'] as const){ const key=[task,os,path].join('|'); if(!keys.has(key)){keys.add(key);out.push({task,os,path});} } return out; }案例一：新增接口有降级，权限拒绝路径没测
新系统成功路径调用新 API，旧系统进入降级，看起来都正常；用户拒绝权限时，新 API 抛出新的错误码，页面没有恢复操作。矩阵要求新旧系统都覆盖 success/failure，失败格子因此不会被成功截图掩盖。
案例二：废弃接口仍藏在后台恢复路径
前台主流程已经替换，后台恢复或通知点击仍调用旧接口。按用户任务映射调用点，而不是按文件统计后，恢复任务会单独进入矩阵；设备测试通过生命周期操作触发它。
自动化与人工如何分工
| 观察项 | 容易写错 | 更可靠的处理 |
| 扫描报告 | 等同测试清单 | 先映射到用户任务与风险族 |
| 系统覆盖 | 只测 HarmonyOS 7 | 最低版本与 API 26 都执行 |
| 路径覆盖 | 只测成功返回 | 成功、拒绝、取消和恢复 |
| 证据 | 勾选通过 | 设备、步骤、日志与结果可追溯 |
双版本矩阵把“工具发现了什么”和“用户是否还能完成任务”连接起来。它不会无限扩大用例，因为相同任务和相同根因会去重；新增一次 API 变更，只补真正受影响的格子。
回归矩阵清单
- Change Assistant 每条命中都映射到用户任务。
- 最低支持系统与 API 26 都有设备证据。
- 成功、拒绝、取消和恢复路径齐全。
- 静态检查不冒充真机结果。
- 发布前没有未解释的空矩阵格子。
官方资料与适用范围
- HarmonyOS 7 应用升级适配指南
- 多设备通用适配指南
升级适配不是把红线清零，而是证明新旧系统上的核心任务都没有被行为变化破坏。扫描结果进入回归矩阵，才真正完成从代码到体验的闭环。
