应用问题：
检查与修复

从可复现的症状开始

移动应用的问题可能出在界面、服务端、集成或流程定义本身。“应用很慢”不足以决定修复方法，需要记录设备、操作系统版本、构建编号、网络状态和操作步骤。

使用约定的测试账号和数据排查。每个问题都应记录预期结果、实际结果、时间和屏幕录像。不要在群聊中发布访问令牌、个人数据或工作文档内容。如果问题只在客户处出现，先取得不含敏感信息的环境描述。

这张表只提供排查方向，不会自动确定原因。同一症状可能由不同原因引起。修复后必须重现最初的条件，否则检查就会流于形式。

错误：仅凭界面图估算开发

设计图上有“保存”按钮，却没有定义数据存到哪里、谁能修改、断网时怎么办。这些决定只能在开发中补做，结果是范围争议不断，已经完成的界面也反复修改。

检查方法：选择三个主要流程，要求从头到实际结果完整演示。明确角色、字段、数据来源、其他可能状态和验收标准。如果各方对同一功能描述的结果不同，说明需求尚未达成一致。

如何修复：记录首个版本的边界并维护变更日志。每个新功能都要有估算、优先级以及客户授权代表的决定。不要只为增加界面数量而削减错误处理；安全地重试操作有时比多一个栏目更重要。

在外勤工程师应用的教学示例中，“关闭工单”可能意味着将报告保存在本地、发送给调度员，或收到验收确认。这是三种不同状态。需求准备的详细步骤见应用开发指南。

错误：只测试理想状态下的界面

短标签的设计稿看起来整齐，但真实记录中的长地址可能挡住按钮。键盘遮住输入框，放大的文字被截断，空列表看起来像应用卡死。用户无法判断应用是否正常工作。

1. 使用实际流程可能出现的长内容和空值填充界面。
2. 调大系统字号，再走一遍主要流程。
3. 在最后一个输入框调出键盘，检查错误提示和按钮是否仍可见。
4. 分别使用系统返回方式和应用内控件返回。
5. 检查读屏软件能否读出重要元素，以及操作标签是否清晰。

修复应包括换行、滚动、标签和状态规则，而不只是缩小字体。还要检查防误删措施和输入错误后的恢复方式。仅用红色标记，并不能说明究竟需要改什么。

合格的结果是：用户理解当前状态，看得到下一步，并能在不丢失已填数据的情况下纠正输入。应在大小不同的屏幕上复测，也要覆盖系统无障碍设置。

错误：断网变成数据丢失

手机会切换网络，应用会被切到后台，系统也可能结束应用进程。如果团队只在稳定 Wi-Fi 下测试，草稿和提交行为就可能难以预料。不是每个应用都必须完全离线运行，但都应清楚说明限制。

1. 开始填写工单，然后断开网络。
2. 按设计支持的方式保存，然后重启应用。
3. 检查约定应保留的字段和附件是否仍在。
4. 恢复网络，等待数据交换确认。
5. 再测试提交后断网、操作结果尚不明确的情况。

用户应能看到待发送队列。如果某条记录与服务端修改冲突，不能悄悄用旧副本覆盖最新数据。冲突处理规则应与流程负责人商定。

错误：仅靠隐藏按钮控制权限

如果应用在列表中隐藏了别人的工单，但服务器收到请求仍会返回它，就没有真正实现访问隔离。另一个风险是退出账号后，上一位用户的数据仍留在共用设备上。

在测试环境中设置两个角色和归属不同用户的记录。检查列表、搜索、通知直达链接和账号切换。请开发人员或安全专家确认服务端也对这些对象执行了权限检查。未经授权，不要测试他人的系统或真实账号。

另行测试拒绝摄像头、定位或通知权限的情况。应用应说明哪项功能不可用，并在流程允许时保留其他能力。权限申请最好对应明确操作，而不是首次打开就索要所有权限。

制定技术检查项时，可参考 OWASP MASVS。讨论适用的数据存储、授权、通信和隐私要求。在报告中形式化地引用标准，不能替代对实际检查和已发现局限的说明。

错误：把成功提示当成操作真正成功

按钮有了响应，订单却没进入 CRM。通知收到了，打开的却是另一条记录。支付状态不明确，用户试图再次支付。这些问题应沿完整系统链路检查。

支付流程应先在服务商提供的测试环境中验证。生产环境测试另行约定。不能只凭客户端界面的显示结果确认支付成功。

每项数据交换都需要负责人，并能够通过标识查找到对应操作。如果只有代码作者能排查工单丢失的原因，就应补充必要的诊断能力和支持说明。相关工作包括 CRM 与集成配置。

错误：“在我们的手机上一切正常”

一种机型不能代表全部设备。性能取决于内存、数据量、网络和操作流程。用五条记录测试，不能证明数千条记录的目录也能正常运行；全新安装也无法验证已有使用历史的情况。

根据用户群约定设备矩阵，包括支持的系统版本、常见屏幕和低性能设备。测试冷启动、长列表、附件上传和从后台返回。记录耗时、条件和结果；修改后比较同一操作。

在 Google Play 发布前测试报告中，展开问题并选择设备。诊断材料有助于区分崩溃、卡死和界面问题。向开发人员提供构建编号及可用信息，然后在修复版本上复测。

不要以功能损失换取指标改善。隐藏照片、关闭同步或让界面消失，都需要评估对产品的影响。

错误：测了安装，却没测升级

新版本可能在空设备上正常运行，却在升级旧版本时丢失数据。服务端也不应突然破坏仍受支持的旧版本，因为用户不会同时更新。

1. 在测试设备上安装之前仍受支持的构建版本。
2. 创建需要保留的记录、草稿和状态。
3. 使用正常支持的方式更新应用。
4. 检查登录、数据、提交、通知，以及与当前服务端的协作。
5. 约定故障时的措施：暂停分发、修复，或在已有相应机制的情况下关闭问题功能。

回退服务端版本不一定兼容已经更新的数据。恢复方案应提前验证。在 iOS 上，TestFlight 可向不同测试组分发构建版本，并收集测试反馈。

针对应用商店拒审，应根据具体意见排查。将实际行为、应用描述、审核人员访问权限及数据声明，对照 App Store 审核指南或所选平台的规则。修正原因，附上说明，并重新测试构建版本。不能保证一定获批。

错误：只统计安装，不统计任务完成

应用不崩溃，也可能没有用：用户找不到需要的操作，不理解注册流程，或重新使用熟悉的渠道。首先确认分析事件反映的是真实结果。

完成一次测试流程，将事件链与服务端记录对照。检查重复点击和失败尝试，它们不应无条件增加成功次数。随后按版本、设备以及新老用户拆分数据。

如果流程在某一步中断，应观察用户并检查其使用条件。用户不知道必填项的答案时，改按钮颜色也没用。先消除障碍，再评估完成操作次数和支持请求的变化。

不要把不必要的表单内容加入分析数据。研究通常只需要事件名称、版本和技术结果。在核实用户能顺利完成有价值操作之后，再将获客计划与可衡量的营销结合起来。

解决原因并复测结果

将问题汇总到同一台账，区分已确认缺陷、新需求和需求疑问。每项都记录优先级、负责人、修复版本及复测结果。

修复后还要检查相邻功能。登录方式变化可能影响通知，本地存储更新可能影响草稿。“代码已经修好”不能替代对交付版本的实际测试。

同时检查后续维护所需条件：所有者权限、源代码、构建说明、服务清单和负责人。其他专业人员应能依据文档构建并运行项目。恢复与后续开发范围，可在移动应用项目服务中讨论；上线后的费用详见预算指南。

关闭问题前需要检查什么

应用问题常见问答