一套产品功能做完了功能测试也跑过了但用户上手后还是觉得“哪儿哪儿都不顺手”问题到底出在哪我之前带过的几个项目里已经把尼尔森十大易用性原则驱动的测试当成发版前的固定动作严格来说它是拿十项被验证过无数次的可用性规律当“检查尺”把“好不好用”这种模糊感受拆成一条条可查、可判、可打分的用例以此作为测试方案的核心线索。这套方法不挑岗位产品、测试、研发、运营都能上手而且迭代越快的团队越划算。这篇文章就聊聊我实际跑这套流程时踩过的坑、总结出的用例模板以及每条原则到底对应哪些测试动作。1. 为什么拿十大原则当测试标准1.1 原则测试与功能测试的互补关系功能测试回答的是“这个按钮点了有没有反应”易用性测试回答的是“用户知不知道这个按钮该点、点了之后发生的事能不能看懂”。两者考察维度完全不同。我之前遇到过一款数据后台功能测试全部通过字段校验、接口返回值都正常线上用户却频繁提交工单说“保存完不知道成没成功”。开发看日志觉得一切正常问题就出在保存操作后缺少状态反馈。这类缺陷功能测试根本发现不了因为它不违反任何功能需求文档但违反了“系统状态可见性”这一条原则。把十项原则当成测试驱动框架最大的好处是给“体验问题”一个相对客观的标尺。没有这套标尺的时候大家讨论界面全靠个人喜好你说红色好看他说蓝色稳重最后吵不出结果。有了原则就能把争论转化为“你这处交互是否让用户明确知道当前流程走到了哪一步”讨论立刻有了落点。1.2 三个适合引入这套标准的时间点第一个时间点是需求评审阶段这时候可以用原则提前挑出交互方案里的隐患。比如需求里写“点击提交后跳转首页”拿“状态可见性”去对照就会发现缺少中间反馈可以当场让产品补充结果提示。第二个时间点是视觉稿走查阶段。视觉稿能看出信息层级、文案、色彩是否影响判断但看不出动态交互问题需要配合下面几条原则专门过一遍。第三个时间点就是功能测试收尾后、发版之前。在这个阶段系统功能基本稳定最适合把十条原则逐条过一遍专门补一轮“非功能性问题”。我比较推荐第三个时间点作为主阵地另外两个作为附加动作。因为发版前系统完整能真实暴露交互链路中的易用性缺陷而且这个时间点测出来的问题往往赶得上修复不会让自己陷入“明知有问题但只能等下一版”的尴尬。2. 十项原则逐条拆解成检查点2.1 状态可见性让用户随时知道系统在做什么这条是十个原则里出问题概率最高的。简单说就是系统一有动作必须让用户看见。测试时可以围绕这四类场景设计用例。文件上传和导出重点是进度反馈。我测试时总会把上传包尽量调大看它有没有一个百分比进度条、传输速率、剩余时间而不是一个干巴巴的“上传中”。一旦网络慢用户不知道是在传还是在卡焦虑感会直线上升。表单提交和保存操作重点看结果反馈。提交成功后有没有明确提示提示出现后会不会被快速覆盖。我之前测一个内部项目时保存后右上角弹了个轻提示结果某开发把遮罩层级调错提示被弹窗挡住了功能测试完全正常只有用手动场景才暴露出来。数据刷新和异步请求重点看加载态。数据列表下拉刷新刷新期间旧数据区是保持原样还是置灰有没有转圈或骨架屏刷新完成要不要告诉用户“已更新N条”。后台任务处理重点看任务状态入口。如果系统半夜批量跑任务用户第二天打开页面时能不能看到一个明显的结果入口而不是只能去问开发“跑完了吗”。这组用例跑完把“用户能不能随时回答出‘系统现在在干什么’”作为结论写在报告里非常直观。2.2 与真实世界匹配文案、术语和心智模型这条原则指的是系统里的话要像用户说的人话而不是像开发文档的机翻。测试时重点检查用词是否符合目标用户的习惯。我接手过一个人力资源系统职称字段在录入页面叫“岗位序列”在查询页面叫“职务类别”在报表里叫“职位等级”。功能上其实是同一个东西但测试时查了数据字典才知道普通用户早就被绕晕了。这类同义不同名的问题光靠眼睛看很难发现最好把同一个业务对象的全链路页面都翻一遍对照字段名称是否统一。还有一点容易被忽略界面不要出现纯技术语言。比如“服务器返回错误码500”“JSON解析失败”这类提示出现在给普通用户看的产品里完全不符合真实世界匹配原则。但对测试工程师来说这类问题往往被归类为“又不是不能用”我建议只要定位到就记为低级别问题提醒产品后续优化。除了文案还可以检查操作结果是否符合用户预期。搜索一个不存在的关键词时页面是只给一句“没有数据”还是会给出相近关键词建议用户习惯是输入搜索比对系统应该顺着这个节奏来而不是直接给一个结果空页。2.3 用户控制与自由给每一步操作留退路这一条原则翻译成大白话就是用户可以反悔用户可以退出系统要给人“兜底”的安全感。测试重点删除、重置这类高危险操作是否都提供了撤销路径。拿回收站来说如果删除后只有一条“删除成功”的提示没有任何恢复入口用户误删后心态会非常差。测试时应主动检查所有删除能力看数据是真删还是进回收站如果进回收站要确认恢复路径是否完整。弹窗和页面的退出路径也很值得测。很多后台页面的弹窗只提供右上角X关闭点蒙层不关ESC无效。我很早以前测试时觉得“有空点X就行了”后来做用户观察发现相当一部分用户会下意识按ESC或点蒙层关了没反应就开始怀疑“是不是卡住了”。现在我的测试用例里专门有一项打开所有弹窗分别用ESC、点击遮罩、浏览器返回三种方式测试关闭行为至少保留两种以上可用路径。还有表单页的离开保护。如果用户填了一半不小心点到菜单栏页面直接跳走填的内容全没了这会让他极度反感。测试时我会在表单页填上内容再尝试各种方式离开看系统有没有“当前页面有未保存内容确认离开吗”的拦截。这条原则的检查给用户一种“容器感”——感觉自己掌控着整个流程而不是被系统推着走。2.4 一致性与标准让用户不必重新学习一致性分几个层级系统内部一致性、平台生态一致性、行业惯例一致性。内部一致性最好测就是同一类操作在不同页面必须长一个样。保存按钮在列表页在右上角在详情页却在左下角这种就是典型的不一致。测的时候把同类操作的入口、按钮位置、图标、弹窗文案拉一张对照表逐屏比对。平台层面的一致性主要看交互是否符合用户已经习惯的操作方式。iOS用户拿到安卓App点返回手势没反应网页端用户习惯“浏览器后退能回到上一页”结果某些单页应用后退直接退出系统。这类问题会让用户产生强烈的违和感。行业惯例更隐蔽。用户会在潜意识里认为“垃圾箱里的东西可以在垃圾箱里恢复”“点击公司logo能回到首页”“消息列表里的红色数字可以点进去查看”。如果系统不遵循这些约定俗成的习惯用户就需要额外花时间去学学习的每一分钟都在消耗耐心。测试时可以把平台规范文档和竞品交互当参考线拿自家产品和参考线逐项比对既能发现问题给开发的解释也清楚别人家都这么做的用户已经被教育过了咱们没必要反着来。2.5 错误预防、识别与恢复先防错再救错这条原则是一组动作对应测试里最有技术含量的一部分。错误预防核心是“在用户犯错之前拦住他”。输入环节要检查实时校验手机号输到第11位才弹红字提示属于“事后批评”输错第3位立刻提示格式属于“事前预防”。测试时要把非法输入尽量前置能当场校验的绝不给到最后提交才报错。高危险操作要设置二次确认比如删除、批量更新、覆盖文件。但确认弹窗也不能滥用我见过连最低等级的“查看详情”都要弹窗确认的系统用户点三下就烦了。错误识别与恢复测试重点是错误提示信息的质量。一条合格的报错应该包含三块发生了什么、为什么发生、下一步怎么解决。拿登录失败举例只说“登录失败”是最差提示“账号或密码错误”是及格“账号或密码错误忘记密码可点击这里重置”才是优秀。很多系统的报错只做到了及格线甚至只给个“请求失败”这就把用户丢在迷雾里。恢复类测试还要模拟错误现场断网、服务器超时、服务异常然后观察页面有没有重试按钮、数据有没有保留、刷新后能不能回到原状态。最容易出问题的是半提交状态比如表单提交超时实际后台已经写入成功前端却报“提交失败”用户一刷新看到数据在了反而更迷茫。2.6 减轻记忆负担、灵活高效、极简与帮助四类易被漏测的细节“识别而非回忆”这条特别适合测试流程类场景。比如多步流程走到第3步切个页面再回来填过的内容还在吗历史搜索记录有没有被保存下拉框能不能看到当前选中的值用户不欠系统一个“记住我上一步做了什么”的记忆。灵活性与效率主要测两类人群的体验新手走默认流程是否顺畅高频用户有没有快捷操作。批量选择、快捷键、自定义列、草稿箱这类能力不一定在需求文档里但对重度用户来说有和没有体验差一个量级。测试时可以把当前角色模拟成使用频率最高的那类用户凡是每天重复做三次以上的操作都值得想想有没有更顺手的路径。美观与极简设计测试时看的是“信息有没有干扰项”。一个页面上同时挂着三四个运营提示、两个弹窗、一个通知条用户根本找不到自己要点的东西。测的时候可以截图然后把页面上的文字遮住看主要操作按钮还能不能被迅速定位。帮助与文档这块很容易被忽略反而是用户工单的高发区。空状态有没有引导下一步的文案和按钮复杂功能有没有帮助入口404页面有没有返回首页的通道测试时要清空数据、故意走坏路径把系统逼到绝境看它怎么救你。3. 实操把原则转成能直接用的测试用例3.1 用例模板与字段说明光背十项原则没用得落成用例。我用的模板有七个字段用例编号、归属原则、操作路径、操作步骤、预期结果、判定标准、严重度。用例编号规则统一比如VIS001代表状态可见性第1条MAT002代表现实匹配第2条后续按优先级排序。归属原则标明这条用例是在查哪一条原则方便统计哪条原则出问题最多。操作路径从哪个页面、经过哪些环节到达测试位置要写到能复现。操作步骤一步一步写清楚别人照着做能得出同样结果。预期结果依据原则写“应该是什么样”而不是依据现有实现写“现状是什么样”。判定标准设定一个相对明确的通过线。比如状态可见性的通过标准是“操作后3秒内出现结果反馈”错误提示的通过标准是“包含原因和下一步建议”。严重度P0阻断使用P1严重影响体验P2可优化项。用这个模板来管理一百多条用例不会乱。一张表格就能看出哪条原则覆盖薄弱哪条原则问题多发。3.2 打分与判定规则我会给每一条原则打个“原则符合度”分数1到5分。5分代表完全符合3分代表勉强能用但明显别扭1分代表严重违反。重点在于打分前先定清楚规则否则会陷入主观争论。我给团队常用的几个锚点是完全符合定义、部分符合但不阻碍任务、明显违反但不致命、严重违反导致任务无法完成。测试执行时先对照锚点再结合实际操作感受修正。整个项目跑完把十条原则的得分汇总成一张雷达表。哪条原则得分最低就说明产品最容易在这类体验上栽跟头。我们曾经一个项目整体得分都不错唯独“用户控制与自由”只有2.5分后来一查果然是全站弹窗都不敢用ESC关闭这种系统性缺陷如果只看总通过率根本揪不出来。3.3 角色分工与执行节奏这套测试最好别只派一个人闷头执行。我的做法是保证三个人参与一个测试负责主流程用例一个产品或者运营负责扮演“对系统不熟的新用户”还有一个前端或者交互负责记录细节并把问题翻译成修改建议。执行节奏上建议先花半小时逐条过一遍静态界面把明显问题快速标记掉再花两到三小时跑动态流程。动态流程一定要从真实用户的角度走不能开着开发者工具从半成品状态起步。比如测“状态可见性”就把上传动作真实执行一遍选一个大文件去找那个进度条测“错误恢复”就真的断一下网再看界面表现。跑完当天一定要输出原始问题清单别拖过夜。人在现场对问题的记忆最清晰隔一天很多细节就说不准了甚至还可能被“开发说的理由”给带偏把问题悄悄改写了。4. 一轮测试跑完后结果分级与推动修复4.1 严重度分级与优先级排序测试之后最怕的是和开发争论“这个问题要不要改”。我建议把问题按三个等级切分。P0级导致核心任务无法完成或者用户会产生强烈挫败感。比如上传后没有任何进度提示用户以为失败反复重试删除后没有恢复入口误删数据无法找回。这类问题必须当轮修复。P1级影响效率或体验但任务还能完成。比如搜索无结果时没有引导、按钮位置在不同页面不一致。这类问题尽量在本轮修复排期困难的可适当延后。P2级属于锦上添花或长期体验优化。比如帮助文档不完善、极简做得不够好。这类问题可以进迭代池。排序的时候优先处理影响面广、出现频率高、操作链路上靠前的问题。一个只在深层功能出现的文案不一致永远排在主路径表单报错后面。4.2 向开发描述易用性问题的方法开发不理解“体验问题”很正常。我一开始也吃过亏只写一句“这里体验不好”开发直接回了一句“怎么改”。后来总结出一个描述模板效果提升非常明显。描述格式是四步现状、违反了哪条原则、用户感受是什么、建议怎么改。举一个实际例子现状提交表单时点击“保存”按钮变成灰色1秒后恢复页面没有任何文字提示后台已经保存成功。违反原则状态可见性。用户感受不知道保存到底成没成功会重复点击。建议保存成功后弹出轻提示“保存成功”并提供“查看记录”入口。用这套框架描述开发不用猜意图直接用建议改基本没跑偏。讨论分歧时也只要回到原则本身争议而不是变为审美偏好之争。4.3 哪些检查可以交给自动化不是所有原则检查都适合阶段性地安排人工有几类可以沉淀成自动化用例比如“所有保存成功后必须出现提示元素”“所有列表加载必须有loading状态”“所有删除操作必须有二次确认弹窗”。前端测试框架能做这类断言比如等待一个toast出现检查按钮disabled状态确认弹窗文本非空。把基础的状态可见性和错误预防检查自动化掉人工集中精力做更依赖主观判断的检查。但自动化的边界也要清楚它只能判断“有没有”判断不了“够不够好”。一个进度条既能通过“元素存在”的断言也会因为“没有文字百分比”而让用户困惑。所以自动化代替不了人工只能帮人腾出时间。5. 常见问题与踩坑实录5.1 容易误判的几个场景有些问题刚看觉得很严重细想其实不违反原则。比如一个工具型产品操作界面就是密集的表格和参数拿“极简设计”去一刀切就没有意义。判断时要先明确产品边界工具类产品追求信息密度效率优先极简原则的适用标准要放宽。反过来有些细微的文案问题又容易被低估。比如“删除”写成了“作废”单个页面看问题不大但用户一旦误以为只是作废不是永久删除操作意愿就完全变了。所以文案类问题要看是否会造成行为误导不能只看眼缘。还有一个常见误区是把“新用户第一次不会用”直接等同于易用性缺陷。有些操作高频用户根本不会走新手路径只要提供学习入口和帮助引导就不算违反原则。测试时要区分典型用户不能总拿“完全没接触过的人”当标准。5.2 执行中的三个常见错误第一个错误是只测好路不测坏路。跑用例时不知不觉沿着主流程顺了一遍全是开心路径用户真实使用时总有各种异常情况不带数据、超长文本、重复点击、网络中断这些坏路才是易用性问题的高发区。第二个错误是测试时用了特殊账号。很多后台管理系统测试账号有全部权限导致很多权限相关的可见性、控制感问题测不出来。要用不同角色、不同权限的账号分别跑才能把真实的用户视角还原出来。第三个错误是发现问题后当场开始吵方案。测试时一旦觉得这里不好就开始想怎么改很容易忽略了“先确认原则受到侵犯”这个前提。我现在的做法是执行期间只记录现象统一收工后讨论解决方案效率反而更高。5.3 复盘时如何区分设计问题与测试问题复盘时经常发现上一轮的“问题”这轮还在并且不是开发没改而是测试步骤没有复现。这种情况要把用例步骤写得更精确把前置条件写清楚比如“必须上传超过10MB的文件”“必须先在无缓存状态下打开页面”。还有一种情况是设计本意和原则冲突。比如某些B端产品故意用密集信息提高老用户操作速度这就不适合打“极简设计”的P1。复盘遇到这类冲突要把判断依据写进用例备注里避免下一轮测试人员又重新提一遍。每次跑完把十条原则的得分和问题清单存档。下一轮发版前先看历史问题是否回归通过再跑新用例。我自己跑了十几个版本之后最大的感受是这套方法并不是给团队增加负担而是把原本零散的“我觉得这里怪怪的”给系统化了。如果你手头也有一个功能稳定但总觉得体验差一截的产品完全可以拿这十项原则当尺子组织一场两小时的专项测试把“感觉难用”变成“这里有七个具体问题可以改”。试试看应该比我当初自己瞎摸索省力得多。
