移动 App 可用性测试：任务、指标与记录模板

把一轮任务研究准备成同事能够复查的方案：观察之前先确定参与者、任务说明、停止规则与结果编码。

移动 App 可用性测试，是观察目标用户在手机或平板上完成真实任务，判断他们能否独立完成、哪里犹豫、哪里需要帮助。测试前先定义成功规则，用不透露操作路径的任务说明，单独记录协助，再把观察到的问题与线上行为数据结合，验证具体改动。

先选一个研究能回答的问题

结账漏斗能显示用户停在配送方式之后，却不能单独解释原因：是看不懂费用、找不到继续按钮，还是遇到了错误？可用性测试通过观察实际操作，帮助区分这些可能性；它与验证按钮是否按设计执行的功能测试不同。

把目标写具体：「新客户能否选择自提地点、理解领取时间，并在没有提示的情况下到达订单确认页？」这个问题能指导招募和结果判定。「把 App 的问题都找出来」则很容易产生零散意见。

NN/g 的可用性测试介绍以参与者、任务和主持过程解释研究结构。本文据此讨论手机场景，并提供原创记录表；没有声称 TapCub 实际开展过下文的用户研究。

根据不确定性选择方法

是否有主持，与是否远程是两条维度。远程也可以有主持，不应把「远程」直接当成「无主持」。

可点击原型适合测试文案和信息结构；键盘遮挡、权限、网络等待、辅助技术和故障恢复，需要能体现这些行为的真实构建版本。报告里写清测试的是哪个原型或版本，避免把局部结论扩大到整个产品。

招募与任务有关的人

先列出相关经验：过去有没有类似购买行为、是否用过本服务、任务中有哪些限制。研究学习成本时，把新用户与熟练用户分开。参与设计的同事可以帮助发现实现问题，但不能代替不熟悉界面的用户。

设备与无障碍要求也应写进计划，包括操作系统、屏幕大小、字号缩放，以及与任务有关的输入方式或辅助技术。需要了解屏幕阅读器使用者的困难，就招募日常使用这种配置的人，而不是让研究员临时模拟。

没有一个固定人数能证明 App 已经好用。小规模探索可以发现具体障碍；若想估计总体成功率，需要另设抽样和分析计划。观察到五次失败，能够证明这五次发生了失败，不能直接变成整个市场的失败比例。

使用测试账户和虚构记录，说明录制范围并取得相应同意。身份信息与分析表分开存放。任务可能显示私人消息、支付凭据或个人通知时，应调整任务或暂停录制，避免收集与问题无关的信息。

写不带路的任务与成功规则

预先写好停止条件：到达确认页、参与者放弃，或达到本研究设定的时间上限。投屏中断与设备异常另外记录，不能把技术中断自动算成界面失败。

结果至少区分独立成功、协助成功、失败和技术中断。事先约定什么叫协助：「你现在在想什么？」是在邀请解释；「试试右上角的图标」则透露了路径。给出后者提示之后，不能仍记为独立成功。

正式开始前先试跑

试跑用于确认账户可用、任务能理解、目标状态存在、录制范围合适。检查键盘、权限弹窗、加载，以及切换 App 后返回的状态。试跑后若大幅修改任务，试跑数据与正式任务总数分开。

正式测试时保持指令一致，少解释设计，也不替产品辩护。先记观察，再写推断：「连续点了领取日期三次」是可观察事实；「不信任这个日期」是需要进一步问清的解释。

记录任务开始、关键障碍和结束的时间，也记录提示、错误与结果。边想边说可能改变操作速度，因此这类时间只能称为研究中的观察，不应直接当作日常线上速度。

用记录表复算指标

以下为示例数据，只演示记录与计算，不是实际用户研究或行业基准。时间单位为秒。

独立成功率为 4 ÷ 8 = 50%，协助完成占 2 ÷ 8 = 25%，包含协助的总完成率为 6 ÷ 8 = 75%。三个数字回答不同问题，不能用总完成率冒充无需帮助的成功率。

独立成功者的用时排序为 70、85、95、110 秒，中位数是（85 + 95）÷ 2 = 90 秒。这只是独立成功者的中位用时，不是所有参与者的完成时间。达到上限但失败的尝试，也不能被当成已完成记录混进去。

在表中保留每个指标的纳入规则。如果下一轮把协助成功也加入时间统计，就不能直接与这一轮比较。研究团队应能从匿名单行记录复算总数，同时不向报告读者暴露参与者身份。

app.tapcub.com

分开记录任务结果

结果	参与者	比例
独立成功	4	50%
协助成功	2	25%
失败	2	25%

八次虚构尝试，独立成功者中位用时为 90 秒。

示例数据

补上手机与无障碍情境

根据受众选择较大字号、网络中断、单手使用、屏幕键盘和权限选择等条件。它们是设备矩阵中的候选项，不代表要求每位参与者覆盖所有组合。

Android 无障碍测试文档区分人工、工具、自动化与用户测试，并讨论屏幕阅读器能否到达控件、是否读出用途。自动检查能发现一部分问题，但不能替代观察真实使用者完成任务。

也要区分功能故障与理解障碍：点击没有触发处理，是实现问题；按钮工作正常但标签没人理解，是可用性问题。两者都能阻断任务，但应交给合适负责人，采用对应方式验证。

把发现变成复测计划

每项发现写成「证据、影响、拟采取动作、后续验证」。「P03 与 P07 在同一个控件处需要导航提示」比「导航不好」更便于复查。优先级结合任务严重度、受影响人群和线上触达，不只按评论条数排序。

线上数据用于判断问题发生范围，不应把研究样本包装成整体用户。TapCub 的 全端分析 › 行为分析 › 事件分析 用于事件趋势，行为分析中可选择漏斗和留存，具体见模型选择文档。原生 App 需采集相应业务事件；网站回放或热图能力不等于自动录制原生 App 的研究过程。

自提示例可记录任务开始、地点确认和到达订单确认页。研究发现可能是标签不清，漏斗帮助判断这一环节的使用规模。改动后保持成功规则复测，再观察应用参与度指标。单纯前后改善仍不能证明因果。

FAQ

可用性测试就是功能测试吗？

不是。功能测试核对是否符合需求，可用性研究观察目标用户能否完成任务并理解结果。功能全部按设计工作，流程仍可能令人困惑。

有分析数据还需要观察用户吗？

分析数据帮助定位模式和中断位置，任务观察帮助理解障碍。两者结合使用，并保留各自能证明什么、不能证明什么的边界。

得到提示后完成，算成功吗？

记为协助成功，并写明帮助内容。可以另外报告总完成率，但独立成功必须保留，避免把主持人提供的路线当成用户自行找到的路线。

可以先测原型吗？

可以，但只回答原型能体现的问题。涉及设备、辅助技术、权限、延迟和恢复时，应使用相应真实构建，并在报告中注明测试对象。

资料来源与下一步

2026 年 11 月 7 日核对：NN/g 可用性测试、Android 无障碍测试、TapCub 分析模型。示例任务、记录表和计算由本文构造。可先结合UX 审计指南选一个旅程，再试跑一条中性任务。