usability-tester

可用性测试员

概述

通过系统化观察和专家评估，验证用户能否成功完成核心任务。涵盖有主持和无主持测试、启发式评估、无障碍检查和问题严重性评分。不能替代分析或 A/B 测试——它们衡量会发生什么，而可用性测试揭示为什么会发生。

适用场景： 测试用户流程、验证设计、找出阻碍点、开展启发式评估、确保用户能够完成核心任务，以及规划和执行可用性测试环节。

不适用场景： 设置分析或 A/B 测试、未基于任务评估的视觉设计评审、自动化 UI 测试（使用测试框架）、性能基准测试。

快速参考

方法	最适合的场景	参与者	适用时机
有主持测试	深入洞察、复杂流程	每种用户画像 5-8 人	设计和原型阶段
无主持测试	大规模测试、量化数据	20-50 人以上	发布前和发布后
街头测试	快速验证、早期概念	5-10 名随机参与者	早期概念阶段
首次点击测试	导航、信息架构	20-50 人	任意阶段，尤其适用于 IA 改版
启发式评估	根据原则开展专家评审	3-5 名评估员	用户测试前、设计审查时
认知走查	任务流程分析	2-3 名评估员	设计早期、新功能评审时
无障碍审核	包容性设计验证	3-5 名残障用户	发布前、合规审查时
合成用户测试	使用 AI Agent 大规模验证任务	不适用（自动化）	持续进行、回归测试时
AI 主持测试环节	大规模异步主持测试	10-50 人以上	主持人资源有限时

核心指标

指标	目标	衡量内容
任务成功率	核心任务达到 80% 或更高	用户能否完成任务
任务用时	简单任务低于 30 秒，中等任务 1-2 分钟，复杂任务 3-5 分钟	效率
错误率	每项任务少于 2 次	易学性和清晰度
任务后满意度	5 分制达到 4.0 或更高	主观易用性
SUS 评分	68+（行业平均水平），80+（优秀）	整体可用性

问题严重性

严重性等于影响程度（1-3）乘以发生频率（1-3）。严重（8-9）：发布前修复。高（6-7）：发布前修复。中（4-5）：下次发布时修复。低（1-3）：加入待办。

常见错误

错误	正确做法
用产品术语或分步说明编写任务场景	使用自然语言，结合真实情境和明确目标来测试用户是否能找到功能
在测试过程中帮助用户或解释 UI	保持安静地观察，让用户自己摸索；困惑之处能揭示真实问题
只用理想输入测试顺利路径	在测试计划中加入错误状态、边缘情况和恢复场景
每种用户画像的参与者少于 5 人	每种用户画像招募 5-8 位用户；根据 Nielsen 的研究，超过 5 人后收益递减
收集发现的问题，却不评定严重程度或制定后续行动	根据影响程度乘以发生频率为每个问题评分，并分配修复优先级
在用户测试前跳过启发式评估	先进行专家评审，以较低成本发现明显问题，再投入资源招募参与者
在测试计划中忽视无障碍需求	纳入残障参与者，并使用辅助技术进行测试
只开展一轮测试	分批测试：先测试 5 位用户，修复问题，再测试 5 位，直至成功率达到目标

委派

• 测试计划和场景创建：使用 Task agent 为每种用户画像起草目标、研究问题和真实的任务场景
• 启发式评估：使用 Task agent 根据 Nielsen 的 10 项启发式原则检查界面，并记录违规项及其严重程度
• 指标分析和严重程度评分：使用 Task agent 根据原始测试数据计算 SUS 分数、任务成功率和严重程度评分
• 测试报告生成：使用 Task agent 将发现的问题整理成结构化报告，并附上按优先级排序的建议
• 测试基础设施规划：使用 Plan agent 选择测试方法、定义招募标准并安排测试批次

如果有 quality-auditor 技能，请将完整的代码库质量审计和评分工作委派给它。 否则，建议使用：pnpm dlx skills add oakoss/agent-skills -s quality-auditor -a claude-code -y

参考资料

• 测试计划 -- 目标、研究问题、招募、任务场景模板、筛选标准
• 开展测试 -- 出声思考协议、主持规则、任务后问题、场次结构
• 测试方法 -- 无主持测试、游击测试、首次点击测试、认知走查、按生命周期阶段选择方法
• 启发式评估 -- Nielsen 的 10 项启发式原则、评估流程、严重程度评级、与用户测试结合
• 指标和严重程度 -- 成功率、任务用时、错误、满意度、SUS 评分、严重程度公式
• 报告 -- 测试报告模板、关键洞察格式、向利益相关者汇报、建议行动
• 无障碍测试 -- 包容性招募、辅助技术测试、与 WCAG 对齐、无障碍启发式原则
• 远程测试和工具 -- 远程与现场测试对比、测试工具、测试频率、清单