HarmonyOS学习笔记68：权限拒绝与异常分支回归测试

HarmonyOS学习笔记68：权限拒绝与异常分支回归测试

大家好，我是杨利杰 YJlio。

一个功能在“正常输入、权限已授予、网络可用”的情况下跑通，只能说明主路径有机会工作。用户拒绝权限、请求失败或数据为空时，页面会不会卡住、误报成功，往往要靠有针对性的回归用例才能看出来。

这篇笔记不提供未经验证的 ArkTS API 代码，也不把示意图当成真机截图。我会从用例结构开始，整理权限拒绝、网络异常和空数据等分支该怎么设计、记录和复测。原稿没有给出实际 DevEco Studio、SDK、设备与运行证据，相关环境和结果都留待实测后填写。

一、先把测试用例写成可复现的记录

回归测试的起点不是先点按钮，而是先说清楚“在什么条件下，执行什么操作，应该看到什么”。如果前置状态不明确，同一个用例在不同设备或不同权限状态下得到不同结果，很难判断是产品行为、环境差异，还是步骤本身不一致。

建议每条用例至少记录这些字段：

**预期结果与实际结果分开填写。**如果测试尚未运行，实际结果就留空或标为“待实测”，不要用预期代替观察结论。

二、权限被拒绝后，相关功能要有清楚的退路

涉及系统权限的功能，需要分别考虑已授权、首次拒绝，以及用户拒绝后不再授权等状态。华为开发者文档指出，权限申请应遵循最小化原则；用户拒绝某项权限时，与该权限无关的其他功能应尽量保持可用。具体权限等级、声明方式和申请接口会随工程配置与系统版本变化，写入代码前应核对当前工程对应的官方文档。

设计和验证时可以逐项检查：

1. 拒绝后，页面是否给出能理解的说明，而不是只留下无响应的按钮。
2. 依赖该权限的功能是否明确降级或暂不可用。
3. 不依赖该权限的其他页面和操作是否仍能正常工作。
4. 是否避免重复弹窗或自动绕过用户选择；需要继续使用时，再解释如何由用户主动处理。
5. 用户后来改变授权状态并返回应用后，页面是否能重新检查状态并恢复合适的交互。

不要把“用户拒绝”简单处理成应用整体异常，也不要把拒绝视为可以由应用静默覆盖的状态。测试应覆盖用户选择后的页面反馈和可恢复路径。

三、网络失败与超时要验证反馈和恢复

网络请求至少要区分成功与失败。断网、服务暂时不可用、请求超时等条件，可以在可控的测试环境中逐一构造；不要通过生产数据或不可控的外部服务制造测试结果。

针对失败分支，重点观察：

• 页面是否明确告诉用户请求没有完成，避免把旧数据或空白页误当成成功结果；
• 用户已经填写的内容是否按需求保留，避免失败后无提示丢失；
• 重试入口是否清晰，重复点击是否会造成重复提交；
• 加载状态在失败后是否结束，按钮是否恢复到可操作状态；
• 网络恢复后重新执行，页面和数据是否回到一致状态。

**重试策略要有边界。**是否允许自动重试、重试次数与间隔都取决于具体业务；在需求没有说明时，不应把无限重试写成默认方案。本文不提供实际接口、超时阈值或运行结果，因为原稿没有这些信息。

四、空数据、请求异常和权限拒绝不是同一种状态

这三种情况都可能让页面暂时没有可展示的内容，但原因和后续操作并不相同。把它们全部映射成“暂无数据”，会掩盖真正的失败；一律显示错误，又会让正常的空结果显得像故障。

可以先按原因区分，再决定页面反馈：

测试时要确认底层结果对应的页面状态，而不只是看屏幕上有没有文字。不同状态应有可辨认的反馈，也要检查从一种状态恢复到另一种状态时，旧提示是否被清除。

五、用正常、异常和边界输入补全覆盖

“主流程可用”不等于“异常分支已覆盖”。可以按输入和外部条件整理用例，而不是只按页面按钮列清单。

对于本篇主题，至少可以从以下方向构造用例：

表中是测试设计方向，不是已完成的运行记录。实际输入应取自项目需求或测试环境，并把具体值、准备方法和结果写入用例，不要把示例方向误写成产品缺陷或已修复结论。

六、把用例整理成回归矩阵

当用例多起来后，可以用矩阵检查覆盖是否有遗漏。矩阵的每一行是一类待验证场景，每一列对应执行前后需要留下的信息。

建议先从最小集合开始：权限、网络、数据各至少准备一条正常情形和一条需要关注的异常情形；然后补充取消、重复操作和状态恢复等边界场景。若不同设备、方向或窗口模式会改变行为，再把这些维度加进矩阵。

矩阵不必穷举所有组合。**先覆盖高风险、高频以及会阻断核心任务的组合，再根据问题记录扩展。**执行后逐项填写实际结果和证据；没有执行的格子保持“待测”，不要用统一的“通过”填满表格。

七、记录环境、步骤和证据，保证问题能复现

看到异常时，尽量在修改代码前先固定复现条件。记录不完整会让后续排查反复猜测，也容易把设备差异误判成代码问题。

建议记录：

• DevEco Studio、工程 SDK/API 版本及依赖状态；
• 模拟器或真机型号、系统版本、设备形态和窗口状态；
• 操作前的权限、网络与数据条件；
• 从进入页面到问题出现的完整步骤；
• 实际界面现象、日志或截图，以及问题发生时间点；
• 复测时改变了什么条件，其他条件是否保持一致。

敏感信息和真实用户数据不要放进公开日志或截图。若需要分享问题记录，先按项目要求脱敏，并保留足以复现问题的上下文。

八、修复之后按原用例完整重跑

修复一个分支后，不能只点击一次确认页面能打开。要使用最初记录的前置条件和操作步骤重新执行，再把实际结果与预期逐项对照。

一个简洁的闭环可以是：

1. 保留能稳定复现问题的原用例。
2. 每次只引入一项必要变更，减少变量。
3. 使用相同条件重跑原步骤，记录实际表现。
4. 检查本次改动相关的正常路径和相邻异常分支。
5. 将代码版本、测试环境、结果和证据位置写回记录。

如果原问题暂时无法重现，记录“本次未复现”及对应条件，不要直接等同于问题已解决。只有按既定步骤完成复测并取得证据后，才能给出与证据相匹配的结论。

九、发布前的环境与运行记录

原始学习草稿没有包含可核验的工程版本、设备信息、编译输出或运行截图。正式发布前，请按实际情况补充：

**没有真实运行记录的内容，应明确标记为待实测，而不是描述成已经通过。**本文配图均为概念示意图，用来解释测试思路，不是实际工程界面、设备截图或测试结果。

总结

权限拒绝、网络异常和空数据都属于需要单独设计与验证的分支。回归测试真正有用的地方，在于把前置条件、操作、预期和实际观察记录清楚，再用相同用例复测变更带来的影响。

我会先把能复现的步骤留住，再逐项检查异常反馈和恢复路径；实际设备、版本与运行证据补齐之后，结论才有依据。没有跑过的用例，就老实标注待实测；跑过的结果，也要让别人能按记录复现。

参考资料

1. 华为 HarmonyOS 开发者文档：访问控制（权限）开发概述。权限等级、配置和接口使用前，请结合实际工程版本核对对应文档。
2. 华为 HarmonyOS 开发者文档：测试概述。本文仅借鉴其测试分类视角，不将其内容当作特定项目的测试结果。
3. 原始学习笔记：068_20261127_HarmonyOS学习笔记_权限拒绝与异常分支回归测试.md。

说明：本文为个人学习笔记模板。示意图不代表真实设备测试；接口、配置及实际运行结果请按工程所用 SDK 和设备核验后补充。

返回顶部