一、详细知识点
1. 测试体系
| 类型 | 目标 | 示例 |
|---|---|---|
| 单元测试 | 验证纯逻辑 | 收藏切换、数据转换 |
| 组件测试 | 验证 UI 状态 | 空状态、按钮文案 |
| UI 测试 | 验证用户流程 | 首页到详情、收藏、设置 |
| 兼容测试 | 验证设备差异 | 手机、平板、横竖屏 |
| 回归测试 | 防止旧功能被破坏 | 发布前核心路径 |
2. 调试与日志
日志要能回答：哪个模块、哪个动作、哪个参数边界、失败原因是什么。不要输出 token、手机号、定位、身份证等敏感信息。
3. 性能优化
| 问题 | 原因 | 处理 |
|---|---|---|
| 首屏慢 | 初始化太多 | 首屏最小化，异步加载 |
| 列表卡顿 | item 复杂、重绘多 | 拆组件、缓存、分页 |
| 内存增长 | 监听和缓存未释放 | 生命周期清理 |
| 耗电 | 高频定位或后台任务 | 降频、按需启停 |
| 包体大 | 资源冗余 | 压缩、裁剪、按模块管理 |
4. 安全与隐私
生产实践鸿蒙工程必须做权限最小化、数据最小化、本地敏感数据保护、日志脱敏、网络安全和隐私政策对齐。上线前要确认申请权限与实际功能一致。
5. 发布治理
发布不是"能编译"。发布前需要版本号、签名、图标、名称、权限说明、隐私政策、崩溃回归、性能回归、弱网验证和灰度策略。
二、本章 demo
Demo 1：本地可运行验证
bash
cd /Users/liuyinghui/Documents/harmonyOS/harmonyos-knowledge-system/demo/web-preview
node server.js验收路径：
- 首页展示 4 条新闻。
- 点击卡片进入详情。
- 收藏一篇文章。
- 进入收藏页，能看到收藏文章。
- 进入设置页，切换深色模式和字体。
Demo 2：生产发布检查表
| 检查项 | demo 映射 |
|---|---|
| 首屏可用 | 首页列表加载 |
| 错误可恢复 | NewsService 可模拟失败后显示错误 |
| 空状态 | 收藏为空时显示 EmptyView |
| 状态可追踪 | 收藏和设置由 Store 管理 |
| 多端适配 | 页面使用自适应宽度和内容流 |
Demo 3：生产实践扩展任务
- 把
NewsService从 mock 替换成真实 HTTP。 - 把
FavoriteStore改成 Preferences 持久化。 - 增加搜索、分类、分页。
- 增加单元测试覆盖 Store。
- 增加发布前检查脚本。
三、面试题与详细答案
1. 如何证明一个鸿蒙应用可以发布？
要从功能、稳定性、性能、安全、合规和发布配置证明。功能上核心路径可跑通；稳定性上无高频崩溃；性能上首屏和列表不卡；安全上权限最小化、日志脱敏；合规上隐私政策和权限说明一致；发布配置上签名、版本、图标、包名正确。
2. 如何排查首页启动慢？
先看生命周期和首屏加载链路：onCreate、onWindowStageCreate 是否做了重任务；首页是否同步解析大数据；是否加载大图；是否等待非首屏接口。优化方向是首屏最小化、异步加载、缓存必要数据、延后非关键任务。
3. 收藏功能应该怎么测试？
至少测五类：默认未收藏；点击后收藏；再次点击取消；收藏页数量变化；重启后是否按设计保留。如果使用持久化，还要测缓存损坏、版本升级和清空数据。
4. 工程化开发者和普通开发者的差别是什么？
普通开发者能把功能写出来；工程化开发者能控制复杂度、处理失败路径、设计可测试架构、优化性能、保障隐私安全，并能把项目稳定发布和长期维护。
四、五倍扩展知识点矩阵
1. 质量保障全景
| 维度 | 基础 | 工程化 | 生产实践 |
|---|---|---|---|
| 功能测试 | 手工点核心流程 | 写验收清单 | 自动化覆盖关键路径 |
| 单元测试 | 测纯函数 | 测 Service/Store | Mock 数据源和异常 |
| UI 测试 | 看页面显示 | 覆盖跳转和状态 | 多设备回归 |
| 日志 | 打印错误 | 模块化日志 | traceId、脱敏、分级 |
| 性能 | 感觉不卡 | 测首屏和列表 | 指标化和回归门禁 |
| 安全 | 不硬编码密码 | 权限最小化 | 隐私合规审计 |
| 发布 | 能打包 | 检查签名版本 | 灰度、回滚、审计 |
| 监控 | 用户反馈 | 崩溃收集 | 指标趋势和复盘 |
| 文档 | 写运行说明 | 写架构说明 | 写故障和发布手册 |
| 团队协作 | 口头约定 | 代码规范 | 审查清单和责任边界 |
2. 测试金字塔
少量端到端测试
适量 UI/组件测试
大量单元测试
类型检查和静态检查
单元测试便宜，适合覆盖转换、筛选、收藏、设置等逻辑；UI 测试较贵，适合覆盖核心用户路径；端到端测试最贵，只覆盖登录、首页、详情、支付或提交等核心链路。
3. 性能问题拆解
| 指标 | 可能原因 | 优化 |
|---|---|---|
| 冷启动慢 | 初始化过多 | 延迟非关键任务 |
| 首屏慢 | 等待多个接口 | 缓存优先、并发加载 |
| 滚动卡 | item 复杂 | 拆组件、减少计算 |
| 点击慢 | 主线程阻塞 | 异步化、节流 |
| 内存高 | 缓存不清 | LRU、生命周期释放 |
| 包体大 | 图片和依赖冗余 | 压缩、裁剪 |
| 耗电高 | 后台任务频繁 | 降频、按需 |
| 流量高 | 重复请求 | 缓存、去重 |
| 发热 | 计算密集 | 降低频率 |
| 卡死 | 同步 IO | 移到异步 |
4. 安全和隐私扩展
| 风险 | 表现 | 处理 |
|---|---|---|
| 权限过度 | 申请无关权限 | 最小化权限 |
| 日志泄露 | 输出 token/手机号 | 脱敏 |
| 本地明文 | 保存敏感数据 | 使用安全能力 |
| 网络风险 | 明文传输 | 使用可信安全传输 |
| 截图泄露 | 敏感页面可截图 | 按场景限制 |
| 数据过量 | 收集无关信息 | 数据最小化 |
| 第三方 SDK | 未说明采集 | 审计 SDK |
| 用户撤回 | 无关闭入口 | 提供撤回路径 |
| 缓存残留 | 退出后仍保留 | 清理策略 |
| 调试包泄露 | debug 上线 | 发布前检查 |
5. 发布流程
需求冻结
代码冻结
测试回归
性能和安全检查
签名打包
灰度发布
监控
全量或回滚
发布治理的核心不是流程复杂，而是每一步都有可验证产物：测试报告、性能记录、权限清单、隐私说明、包信息、灰度指标和回滚方案。
五、生产实践扩展任务
| 任务 | 目标 | 验收 |
|---|---|---|
| 增加 Store 单测 | 验证收藏逻辑 | 收藏/取消/重复点击都正确 |
| 增加 Service 失败测试 | 验证错误路径 | 页面显示重试 |
| 增加日志规范 | 统一模块日志 | 日志含模块和动作 |
| 增加性能清单 | 控制首屏和列表 | 发布前逐项检查 |
| 增加权限清单 | 合规治理 | 权限与功能对应 |
| 增加隐私清单 | 避免过度采集 | 数据项有用途 |
| 增加发布清单 | 降低漏项 | 版本、签名、图标齐全 |
| 增加回滚方案 | 控制发布风险 | 可退回上一版本 |
| 增加弱网测试 | 验证用户体验 | 有缓存或错误提示 |
| 增加多端测试 | 验证适配 | 手机和平板可用 |
| 增加崩溃复盘模板 | 问题闭环 | 有原因、影响、修复 |
| 增加代码审查表 | 控制质量 | PR 可检查 |
示例：发布前检查表
| 类别 | 检查项 | 通过标准 |
|---|---|---|
| 功能 | 首页、详情、收藏、设置 | 核心流程无阻断 |
| 兼容 | 手机、平板、横竖屏 | 无布局遮挡 |
| 性能 | 首屏、列表滚动 | 无明显卡顿 |
| 稳定 | 重复刷新、快速切页 | 状态不乱 |
| 安全 | 日志、权限、本地数据 | 无敏感泄露 |
| 合规 | 隐私政策、权限说明 | 与实际功能一致 |
| 发布 | 包名、版本、签名 | 配置正确 |
| 回滚 | 上一版本包和策略 | 可执行 |
六、问题排查方法
1. 崩溃排查
先收集设备、系统版本、应用版本、操作路径、日志和复现概率。再判断是空值、越界、权限、资源、线程还是系统能力调用失败。修复后必须补回归用例。
2. 卡顿排查
先定位发生在启动、滚动、点击还是页面切换。再看是否有同步 IO、大量计算、大图加载、复杂布局、重复刷新。优化后要用同样设备和路径复测。
3. 状态错乱排查
检查状态来源是否重复、异步请求是否乱序、页面返回是否保留旧参数、Store 是否被多个入口修改。解决方案通常是统一状态入口、加请求版本、清理生命周期。
4. 发布事故复盘
复盘不只问"谁写的"，而是问：为什么测试没发现，为什么发布门禁没挡住，为什么监控没及时报警，为什么回滚不够快。工程团队用复盘改流程。
七、扩展面试题
5. 如何设计鸿蒙项目的测试策略？
先把纯逻辑和 Service/Store 做单元测试，再给核心页面做组件或 UI 测试，最后用少量端到端测试覆盖关键路径。测试重点不是数量，而是覆盖高风险路径：启动、登录、数据加载、提交、权限、弱网和发布回归。
6. 如何判断一个性能优化是否有效？
必须有优化前后的同路径、同设备、同数据量对比。只说"感觉快了"不够。要明确指标，例如首屏时间、列表滚动流畅度、内存峰值、请求次数、包体大小。没有指标就无法判断是否退化。
7. 日志应该如何设计？
日志要包含模块、动作、关键状态和错误原因，但不能包含敏感信息。普通信息、警告和错误要分级。线上日志要能帮助定位问题，也要控制量，避免影响性能和隐私。
8. 发布前为什么要做弱网测试？
移动应用常处在不稳定网络。弱网下如果没有超时、重试、缓存和错误提示，用户会看到无限加载或误以为操作成功。弱网测试能暴露真实用户环境中的失败路径。
9. 如何设计回滚策略？
保留上一稳定版本包和配置，明确触发回滚的指标，例如崩溃率、核心接口失败率、支付或提交失败率。灰度发布时先小流量观察，异常时快速停止扩量并回滚。
10. 可上线项目治理最重要的是什么？
最重要的是可验证和可复盘。功能、性能、安全、发布都要有清单和证据；事故发生后能定位、修复、补测试、改流程。生产实践不是写更多代码，而是让项目长期稳定演进。
八、质量治理详解库
1. 测试不是最后一步
如果测试只在开发结束后进行，很多架构问题已经很难修。生产实践做法是在设计阶段就考虑可测试性：Service 可替换、Store 可验证、页面状态可模拟。
2. 验收清单要绑定业务路径
"功能正常"太模糊。验收清单应写成具体路径：打开首页、点击详情、收藏文章、进入收藏页、切换主题、返回首页。每条都能执行。
3. 性能优化先定位再行动
不要看到卡顿就盲目重构。先确认卡顿发生在启动、渲染、网络、滚动还是图片，再选择优化方案。没有定位的优化容易引入新问题。
4. 安全问题常来自便利写法
为了调试输出 token、为了方便保存明文数据、为了省事申请全部权限，这些都会成为上线风险。安全要从编码阶段纳入规范。
5. 发布风险要用灰度控制
一次性全量发布风险高。灰度可以先暴露少量用户，观察崩溃、性能和核心业务指标，再逐步放量。
6. 回滚不是失败，是能力
没有回滚能力才是风险。发布必须准备上一稳定版本、配置回退方式和触发条件。
7. 线上事故要复盘流程
事故不是只找代码错误，还要看测试为什么没覆盖、监控为什么没发现、发布为什么没挡住、文档为什么没说明。
8. 日志要平衡信息和成本
日志太少定位不了问题，太多影响性能和隐私。要分级、脱敏、按模块记录，并控制线上日志量。
9. 隐私合规要和功能同步更新
新增权限、新增数据采集、新增第三方 SDK，都要同步更新隐私说明和权限说明。不能等发布前集中补。
10. 稳定交付不是 API 记忆
真正的稳定交付能力是面对失败、性能、兼容、安全和协作时仍能稳定交付。API 会变，但工程判断长期有效。
九、质量场景化实战库
| 场景 | 检查点 | 失败表现 | 改进 |
|---|---|---|---|
| 首次启动 | 首屏时间 | 长时间白屏 | 延迟非关键任务 |
| 新闻刷新 | 请求状态 | 无限加载 | 超时和重试 |
| 快速点击 | 并发状态 | 重复收藏 | 禁用或幂等 |
| 空收藏 | 空状态 | 空白页 | EmptyView |
| 断网 | 弱网体验 | 无提示 | 错误页和缓存 |
| 横屏 | 布局 | 挤压遮挡 | 自适应 |
| 大字号 | 无障碍 | 文本溢出 | 自适应高度 |
| 深色模式 | 对比度 | 看不清 | 主题变量 |
| 日志 | 安全 | 泄露信息 | 脱敏 |
| 发布包 | 配置 | 版本错误 | 发布检查 |
| 灰度 | 风险 | 全量事故 | 分批放量 |
| 回滚 | 恢复 | 无法退回 | 保留稳定包 |
十、扩展面试题库
11. 为什么测试要覆盖失败路径？
真实用户一定会遇到网络失败、权限拒绝、空数据和重复点击。只测成功路径会让应用在真实环境中不稳定。失败路径测试能验证产品是否可恢复。
12. 性能优化为什么要防止"优化错对象"？
如果没有定位，可能花时间优化无关代码。例如卡顿来自图片加载，却去改网络层；首屏慢来自同步初始化，却去改列表。指标和定位能避免无效优化。
13. 如何设计发布门禁？
发布门禁应包括自动化测试通过、核心手工验收通过、权限清单确认、隐私说明确认、版本签名确认、性能无明显退化、灰度和回滚方案准备。
14. 什么样的日志算好日志？
好日志能定位问题但不泄露隐私。它包含模块、动作、关键状态、错误原因和关联 id；同时分级清晰，不把调试噪声带到生产。
15. 如何培养可上线工程能力？
持续做三件事：写代码时考虑边界，交付时留下验证证据，出问题后复盘并改进流程。稳定交付不是不出错，而是能让错误影响更小、恢复更快、下次不再发生。
十一、质量体系补全
| 质量域 | 检查内容 | 工具/手段 | 交付证据 |
|---|---|---|---|
| 功能正确性 | 核心流程、异常流程、空状态 | 手工验收、自动化测试 | 验收清单 |
| 单元测试 | Model、Mapper、Store、Service | 测试框架 | 测试报告 |
| UI 测试 | 页面跳转、按钮、输入、状态 | DevEco 测试能力 | UI 测试记录 |
| 专项测试 | 兼容、性能、稳定、安全 | DevEco Testing、真机 | 专项报告 |
| 调试能力 | hilog、断点、hdc、设备日志 | IDE、命令行 | 问题定位记录 |
| 性能体验 | 启动、渲染、内存、功耗、包体 | Profiler、真机观测 | 性能基线 |
| 弱网体验 | 超时、重试、缓存、失败提示 | 网络模拟 | 弱网用例 |
| 安全隐私 | 权限、日志、数据存储、第三方 SDK | 清单审查 | 合规记录 |
| 发布质量 | 签名、版本、灰度、回滚 | AGC、发布平台 | 发布记录 |
| 运营反馈 | 崩溃、反馈、指标、复盘 | 监控和日志 | 复盘文档 |
十二、测试用例矩阵
| 模块 | 成功路径 | 失败路径 | 边界路径 |
|---|---|---|---|
| 首页 | 加载新闻列表 | 网络失败 | 空列表 |
| 详情 | 根据 id 打开 | id 不存在 | 数据被删除 |
| 收藏 | 收藏/取消 | Store 写入失败 | 重复点击 |
| 设置 | 切换主题 | 持久化失败 | 字号超界 |
| 搜索 | 命中结果 | 无结果 | 空关键字 |
| 权限 | 用户授权 | 用户拒绝 | 权限撤回 |
| 通知 | 成功发送 | 通知关闭 | 点击跳转异常 |
| 缓存 | 命中缓存 | 缓存损坏 | 版本迁移 |
| 发布 | 包可安装 | 签名错误 | 版本回滚 |
十三、性能专项
| 指标 | 目标 | 排查方向 | 优化动作 |
|---|---|---|---|
| 冷启动 | 首屏尽快可见 | Ability 初始化、首页请求 | 延迟非关键任务 |
| 页面切换 | 点击后快速响应 | 导航、参数、数据预取 | 缓存详情数据 |
| 列表滚动 | 稳定流畅 | item 复杂度、图片 | 懒加载、分页 |
| 内存 | 不持续增长 | 缓存、监听、图片 | 清理和上限 |
| 功耗 | 后台不过度运行 | 定位、轮询、动画 | 按需启停 |
| 包体 | 不引入冗余 | 图片、依赖 | 资源压缩 |
| 弱网 | 可恢复 | 超时、重试 | 缓存和错误页 |
十四、安全与隐私清单
| 检查项 | 问题 | 处理 |
|---|---|---|
| 权限 | 是否和功能一一对应 | 删除无关权限 |
| 用户说明 | 是否解释用途 | 在触发场景说明 |
| 日志 | 是否包含敏感信息 | 脱敏和分级 |
| 本地数据 | 是否明文保存敏感内容 | 使用安全能力 |
| 网络 | 是否处理证书和错误 | 统一网络层 |
| 第三方 SDK | 是否说明采集 | SDK 审查 |
| 数据删除 | 用户能否清理 | 提供清除入口 |
| 截图/录屏 | 敏感页面是否保护 | 按场景限制 |
| 调试包 | 是否误发布 | 发布门禁检查 |
十五、发布与运营流程
否
是
需求冻结
代码冻结
测试回归
性能与安全检查
签名打包
小范围发布
观察指标
是否异常
扩大范围
暂停 / 回滚 / 修复
发布前必须准备：
- 版本号和构建号。
- 签名和证书。
- 权限清单。
- 隐私说明。
- 核心流程验收结果。
- 性能和弱网检查结果。
- 回滚包和回滚条件。
- 发布后观察指标。
十六、架构治理能力
架构设计能力不是会画图，而是能把业务复杂度控制在可维护范围内。
| 治理点 | 判断标准 | 落地方式 |
|---|---|---|
| 模块边界 | 业务、公共、平台能力分开 | feature/common/platform |
| 依赖方向 | 单向、稳定 | 禁止 common 依赖 feature |
| 状态管理 | 来源清楚、可恢复 | ViewState + Store |
| 数据流 | 页面不接触底层系统 API | Service + Repository |
| 错误处理 | 用户可理解、日志可定位 | ErrorMapper |
| 可测试性 | 不依赖真实 UI 和网络 | mock Repository |
| 可观测性 | 日志可串联 | traceId |
| 可演进性 | 新需求不大改旧代码 | 接口和分层 |
十七、补充面试题
16. 如何建立发布门禁？
发布门禁要覆盖自动化测试、核心手工验收、性能基线、安全清单、权限清单、签名版本、灰度方案和回滚方案。任何一项缺失都可能让问题进入线上。
17. 如何设计鸿蒙应用的可观测性？
统一日志格式，记录模块、动作、traceId、结果和错误码；关键链路记录开始和结束；敏感信息脱敏；发布后关注崩溃、失败率、耗时和用户反馈。
18. 如何做架构评审？
看业务目标、模块划分、依赖方向、数据流、状态管理、错误处理、权限、安全、性能、测试和发布。评审结果要变成代码约束和检查清单，而不是只停留在会议纪要。
19. 如何判断项目是否具备长期维护能力？
看新人能否跑通，模块边界是否清楚，核心流程是否有测试，错误是否可定位，发布是否可回滚，文档是否解释架构和排错路径。
20. 如何从功能开发走向架构设计能力？
每做一个功能都追问：状态从哪里来，失败怎么处理，数据怎么缓存，权限怎么降级，如何测试，如何发布，如何回滚。长期这样训练，才能从写页面走到设计系统。