简介这是一份用户测试计划Word文档面向软件测试工程师、项目经理及测试相关岗位用于规范用户测试各环节的工作流程。文档系统梳理了用户测试的定义、重要性、计划组成、实施步骤与优缺点并提供了引言、用户需求测试、现成软件测试、网络安全测试、缺陷管理、风险管理、可追溯性分析、评审、附录等九个板块的可编辑模板模板中的测试方案表格覆盖人员、条件与环境、工具、方法、通过准则等关键字段可直接填充项目信息后使用。资源共1个doc文件大小约73KB属于轻量级模板便于下载后快速修改。已有525人学习下载适合需要快速搭建软件项目用户测试方案或建立团队测试规范的读者参考使用。1. 用户测试计划先回答三个问题再开 Word用户测试的计划.doc这个文件名的平淡程度和它在产品改动中的分量刚好成反比。一次没有计划书的用户测试很容易沦为“找几个朋友点点原型”结论听起来都对回头开发问“改动依据是哪几条记录”所有人沉默。一份写清楚被测用户画像、任务清单、成功标准、数据记录方式、风险预案的用户测试计划才是后续所有改动能够被复盘、被量化、被排进迭代的证据链。下面的内容既写给第一次筹划用户测试的产品新人也写给那些做过多次但总觉得结论“不硬”的团队——它的核心答案是三个问题测谁、让他们做什么、事后根据什么说这件事成立。2. 可不可做先算清用户测试的时间和预算接到写用户测试计划的需求我第一件事不是打开 Word而是先做可行性判断。原因很简单用户测试的成本是显性可算的收益却是概率性的文档写得再细也救不了一场没有时间、预算和用户的测试。我会先回答一个最小问题在这个项目阶段最该做哪种用户测试。2.1 按项目阶段选测试类型成本差三倍测试类型的选择通常由产品所处阶段决定而不是由用户活跃度决定。判定基准有三个有没有可交互的原型、有没有真实用户可触达、有没有数据埋点。按这三个维度常见需求大致分为三类见下表。项目阶段测试类型准备工作量建议用户数最怕出现的状况只有低保真原型或概念图概念测试 / 纸面原型测试4~8 人时5~8 人用户把注意力放在视觉上讨论变成偏好之争可点击的高保真原型可用性测试主路径8~16 人时5~8 人交互细节太少用户反复问“这里能点吗”已上线或接近上线的完整环境真实环境诊断测试16~24 人时8~12 人数据埋点不全无法定位中断点三者的准备工程量能差出三到四倍所以计划的第一步是把测试类型写死。常见做法是只测主路径上最有争议的三个流程而不是把整个功能列表铺开。测试计划的作用不是证明功能都能用而是把最不确定的交互在用户面前验证一遍。2.2 成本估算与“测 5 个人”的经验基线确定了类型预估工作量就比较机械了。我会把成本分成五块测试设计、内部预演、用户招募、现场执行、数据整理复盘。以一个 5 人可用性测试为例常见做法是这么算的。预估工作量 测试设计(4h) 内部预演(1h) 用户招募(3h) 现场执行(5人 × 1h) 数据整理与复盘(4h) ≈ 17 人时测试设计不只包括写任务书还要准备原型入口、测试账户、录屏工具和数据重置脚本。用户招募 3 小时是按“从现有用户群筛选并约时间”来估的如果要从外部招募至少再加 4 小时。用户人数方面行业内常用的小样本基线是 5 到 8 人。前 5 位用户能暴露大多数可用性问题再加人时成本会直线上升这条基线作为经验规律来执行不代表统计显著。预算不足以支撑 17 人时时我一般会把测试缩成“单任务测试”只测一个高争议流程找 5 个人半天跑完结论聚焦。注意单任务测试不适合验证端到端体验但适合在改动范围较小时快速给出判断。2.3 内部预检15 分钟把环境问题挡在门外预算与人数确认后并不急着写任务而是先做一轮内部预检。测试失败最常见的原因不是任务设计得不好而是环境没准备好用户到了原型打不开录屏没权限账户被上一位用户污染。这轮预检我会用一个最简脚本固定步骤。2.3.1 预检脚本与参数说明#!/bin/bash # preflight.sh —— 用户测试开始前的 15 分钟内部预检 items(测试设备可联网 原型入口链接可打开 测试账户/数据已重置 录屏软件可用且磁盘空间充足) checked0 for item in ${items[]}; do read -p 确认$item ? [回车继续] _ checked$((checked 1)) done echo 已确认 $checked 项预检完毕。当前时间$(date %H:%M)脚本的逻辑是把预检项放进 items 数组逐项等人确认最后打印确认数量和结束时间。这里不追求自动化断言因为“测试账户已重置”“录屏可用”这类状态没法用脚本可靠判断必须由人来确认。items 数组是核心参数每次测试前按实际环境增删read -p 里的提示文案要写成可验证的状态避免出现“一切正常”这类空话。2.3.2 最常翻车的三项环境问题预检中最常翻车的三项按概率排序原型只监听本机回环地址测试机上打不开这在本地开发时特别常见解决办法是改用局域网地址或临时部署的预览链接测试数据没清理上一位用户留下的订单、消息和通知会影响下一位录屏软件没有权限或磁盘已满等到访谈开始才发现整场只有笔记没有画面。这三项能在第一次预检时全部暴露出来等于替后面每一轮节省了时间。3. 用户测试计划的结构从 Markdown 骨架到可执行配置可行性确认后才轮到文档结构。团队交付习惯是 .doc所以最终交付可能就叫“用户测试的计划.doc”。但编辑过程中我会用 Markdown 做源文件理由是测试计划在测试前会经历多轮改动任务描述要反复调整Markdown 方便在编辑器中做 diff、合并和留痕导出 doc 只是最后一步。3.1 用 Markdown 起草用 pandoc 导出 docpandoc user-test-plan.md -o user-test-plan.docx-o 指定输出文件pandoc 会把 Markdown 里的标题层级、表格和代码块转换成 docx 的原生格式。注意导出的是 .docx不是 .doc如果团队要求 .doc再在转换后另存一次。不要把导出结果当源文件继续改否则下次转换会覆盖手工调整的格式。团队协作时把 .md 提交到仓库docx 作为分享附件测试计划就不容易散落在聊天记录里。3.2 六段式模板结构上一份用户测试计划我会写成六段测试目标、被测用户、测试环境与设备、测试任务、数据记录指标、风险与预案。下面是一个可直接抄走的骨架字段先留空填值的过程才是测试设计的过程。# 用户测试计划功能名 版本号 ## 1. 测试目标 - 目标 1行为 指标 - 目标 2行为 指标 ## 2. 被测用户 - 人数5~8 人 - 主要画像年龄/使用频率/操作经验 - 招募条件必须出现的行为特征 ## 3. 测试环境与设备 - 设备型号/浏览器/分辨率 - 数据初始状态账户/内容/权限 - 录制方式录屏/眼动/仅笔记 ## 4. 测试任务 - 任务 1目标式描述 - 任务 2目标式描述 - 任务 3目标式描述 ## 5. 数据记录指标 - 任务完成率 / 完成时间 / 求助次数 - 用户操作路径与预期路径的偏差点 ## 6. 风险与预案 - 用户临时缺席补位标准 - 主流程崩溃换用备用原型或任务降级 - 严重 Bug是否当场打断如何记录这个骨架的价值不在格式而在强制填空。比如“测试目标”不写清楚后面的任务和数据指标都无从谈起“数据初始状态”不写执行人就会自己造数据测试条件在用户之间不一致。3.3 字段参数说明字段作用常见错误写法建议写法测试目标定义什么是成功“验证功能可不可用”“新用户 60 秒内完成注册并进入首页”被测用户画像界定样本范围“找平时不用的用户”“过去 30 天使用过同类应用但从未用过本产品”数据初始状态保证测试可重复不写或写“登录后即可”“账户 A 含 3 条订单、1 条未读消息无购物车”任务描述让用户执行真实行为“点击右上角头像再点击设置”“你想更换头像请自己找到入口并完成替换”字段填得是否有用取决于能不能倒推出执行动作。测试目标写“验证支付流程是否顺畅”执行时不知道“顺畅”怎么度量改成“首次使用的用户 90 秒内完成从商品页到支付成功页的操作”完成率、时间和求助次数就都有了参照。这是把目标写成可观测行为的基本做法。3.4 从“确认需求”改写为“可观测行为”改写目标有一个公式在什么状态下谁做了什么多长时间内完成完成标志是什么。举例来说“验证支付流程是否顺畅”是一个弱目标它听起来像需求文档验收项改成“在清空购物车且余额充足的状态下新注册用户能独立完成支付且从点击支付到看到成功页不超过 30 秒”之后测试任务、指标和严重级别全部跟着明确了。如果用户没在 30 秒内完成也不能直接判定功能有问题还要结合求助次数和观察记录去看阻塞点在哪里。4. 设计用户测试任务目标式描述、指标与轮转设计具体任务时最常见的问题是任务描述写成了操作步骤。“点击右上角头像再点击设置找到修改密码”这类写法测的是用户顺从度而不是可用性。正确的做法是给场景和目标让用户自己找路径。4.1 任务书模板先场景后动作### 任务 2重新登录 - 场景描述“你上一次登录是在昨天今天再次使用时想登录但忘记密码。” - 起始状态已用测试账户退出登录进入登录页 - 完成标志用户成功登录并看到信息主页 - 允许操作可以手动输入任意内容可以向主持人提问 - 记录重点从“忘记密码”入口出现到用户点击的时长用户是否反复回到登录页场景描述放在最前面是为了让用户进入真实使用状态起始状态和完成标志是给执行人用的确保每个用户从同一条件出发。允许操作里写明“可以向主持人提问”是有意为之如果用户卡住完全不提示会尴尬立刻给出答案又会污染数据所以在计划里事先约定可以提问并把提问内容作为求助信号记下来。记录重点给出的是观察维度不是要求用户回答的问题。4.2 数据记录一张表加一个严重级别测试现场通常有主持人和观察员两个人。主持人负责引导和提问观察员只做记录。记录表我会设计成一行一个用户一列一个任务另加严重级别方便结束后快速排序。任务完成情况用时求助次数关键事件严重级别任务1 登录完成35 秒0在验证码环节犹豫 3 秒后直接输入低任务2 找回密码未完成120 秒2认为“手机验证”与“密码找回”是两个入口高任务3 发布内容部分完成180 秒1进入页面后先找上传按钮没看到说明文案中严重级别不按是否完成来分而是按业务影响判断任务失败且可能带来数据丢失、付费损失或账号安全问题的记高能完成但路径明显偏离或反复求助的记中顺手完成的记低。不写严重级别最后整理一小时视频时会不知道先剪哪段。4.3 任务轮转一段 Python 脚本打散顺序效应任务顺序也会影响数据。所有用户都从注册开始到第三个任务时已经熟悉了整体结构后面的数据可能偏乐观。常见做法是让任务顺序在不同用户之间轮转我会用一段 Python 生成轮转表。tasks [注册, 发布内容, 接收通知, 退出登录] rotations [tasks[i:] tasks[:i] for i in range(len(tasks))] for person, order in enumerate(rotations, 1): print(f被测者{person}: - .join(order))rotations 列表通过列表推导做循环移位len(tasks) 为 4 时生成 4 条不同顺序。脚本思路是把顺序效应从“全部用户同一个方向”变成“均匀分散”并不能真正消除它。5 位用户就安排前 4 人用轮转顺序第 5 人再用第 1 条顺序。如果任务数量多到没法完全轮转至少要保证关键路径不会成为每个人的最后一个任务因为最后一段操作会被“累了想结束”影响。4.4 用 20 分钟的同事预演修正任务书任务书写完后下一步不是约用户而是抓一位还没参与项目讨论的同事做预演。重点看三类问题任务描述里的假设是不是太多比如“假设你已经把商品加入了购物车”用户可能根本不理解这个概念完成标志是不是唯一比如“登录成功”和“进入信息主页”各代表什么演示数据是不是足够自然使用“测试账户 123”会给用户不必要的暗示。预演只能暴露任务书的文字问题数据污染要交给预检脚本解决。5. 用户测试执行当天的三项现场控制5.1 提前 15 分钟把运行状态重置回“零”执行当天最怕的是每场测试之间状态不干净。第 2 章的预检脚本在这里仍然用得上但我会额外加一步在每位用户开始前把原型、账户和录屏软件恢复到同一起点。录制文件也按用户编号分目录避免多场数据混在一起。5.2 用五级难度表和一句话转述收尾任务结束后立刻让用户填一张最小问卷趁记忆还在。任务__ 用户编号__ Q1 完成情况完成 / 部分完成 / 未完成 Q2 整体难度1(非常困难) ~ 5(非常容易) Q3 哪个环节让你犹豫最久___ Q4 一句话向朋友转述这个功能___Q2 的数字很容易被用户个体打分习惯影响有人从不用最高分有人从不用最低分所以只看均值没有意义。真正有用的是把难度数字和 Q3 的具体犹豫点绑在一起看。Q4 看起来随意却能判断用户是否理解了功能的价值能一句话说清楚说明心智模型基本成立转述出来变成另一个功能说明入口文案或页面结构出了问题。每个用户结束时再口头补一句提醒这个问题没有对错目的是找出哪里让你停顿了。5.3 每场结束后的 10 分钟复盘三问每场测试结束回到准备间花 10 分钟记录三个问题哪些任务和计划里的预期差异最大哪些问题指向同一个流程节点下一个用户开始前计划要改什么。第三个问题经常被人忽略觉得中途改计划会影响数据一致性。我的做法是区分两种改动字面描述不清的就改任务逻辑和起止状态的不改。前者不应继续浪费下一个用户的 20 分钟后者要保持统一。如果时间只够回答一个问题就回答第二个——它决定了这轮改动真正要动刀的位置。本文还有配套的精品资源点击获取
用户测试计划编写指南：从成本估算到执行控制
简介这是一份用户测试计划Word文档面向软件测试工程师、项目经理及测试相关岗位用于规范用户测试各环节的工作流程。文档系统梳理了用户测试的定义、重要性、计划组成、实施步骤与优缺点并提供了引言、用户需求测试、现成软件测试、网络安全测试、缺陷管理、风险管理、可追溯性分析、评审、附录等九个板块的可编辑模板模板中的测试方案表格覆盖人员、条件与环境、工具、方法、通过准则等关键字段可直接填充项目信息后使用。资源共1个doc文件大小约73KB属于轻量级模板便于下载后快速修改。已有525人学习下载适合需要快速搭建软件项目用户测试方案或建立团队测试规范的读者参考使用。1. 用户测试计划先回答三个问题再开 Word用户测试的计划.doc这个文件名的平淡程度和它在产品改动中的分量刚好成反比。一次没有计划书的用户测试很容易沦为“找几个朋友点点原型”结论听起来都对回头开发问“改动依据是哪几条记录”所有人沉默。一份写清楚被测用户画像、任务清单、成功标准、数据记录方式、风险预案的用户测试计划才是后续所有改动能够被复盘、被量化、被排进迭代的证据链。下面的内容既写给第一次筹划用户测试的产品新人也写给那些做过多次但总觉得结论“不硬”的团队——它的核心答案是三个问题测谁、让他们做什么、事后根据什么说这件事成立。2. 可不可做先算清用户测试的时间和预算接到写用户测试计划的需求我第一件事不是打开 Word而是先做可行性判断。原因很简单用户测试的成本是显性可算的收益却是概率性的文档写得再细也救不了一场没有时间、预算和用户的测试。我会先回答一个最小问题在这个项目阶段最该做哪种用户测试。2.1 按项目阶段选测试类型成本差三倍测试类型的选择通常由产品所处阶段决定而不是由用户活跃度决定。判定基准有三个有没有可交互的原型、有没有真实用户可触达、有没有数据埋点。按这三个维度常见需求大致分为三类见下表。项目阶段测试类型准备工作量建议用户数最怕出现的状况只有低保真原型或概念图概念测试 / 纸面原型测试4~8 人时5~8 人用户把注意力放在视觉上讨论变成偏好之争可点击的高保真原型可用性测试主路径8~16 人时5~8 人交互细节太少用户反复问“这里能点吗”已上线或接近上线的完整环境真实环境诊断测试16~24 人时8~12 人数据埋点不全无法定位中断点三者的准备工程量能差出三到四倍所以计划的第一步是把测试类型写死。常见做法是只测主路径上最有争议的三个流程而不是把整个功能列表铺开。测试计划的作用不是证明功能都能用而是把最不确定的交互在用户面前验证一遍。2.2 成本估算与“测 5 个人”的经验基线确定了类型预估工作量就比较机械了。我会把成本分成五块测试设计、内部预演、用户招募、现场执行、数据整理复盘。以一个 5 人可用性测试为例常见做法是这么算的。预估工作量 测试设计(4h) 内部预演(1h) 用户招募(3h) 现场执行(5人 × 1h) 数据整理与复盘(4h) ≈ 17 人时测试设计不只包括写任务书还要准备原型入口、测试账户、录屏工具和数据重置脚本。用户招募 3 小时是按“从现有用户群筛选并约时间”来估的如果要从外部招募至少再加 4 小时。用户人数方面行业内常用的小样本基线是 5 到 8 人。前 5 位用户能暴露大多数可用性问题再加人时成本会直线上升这条基线作为经验规律来执行不代表统计显著。预算不足以支撑 17 人时时我一般会把测试缩成“单任务测试”只测一个高争议流程找 5 个人半天跑完结论聚焦。注意单任务测试不适合验证端到端体验但适合在改动范围较小时快速给出判断。2.3 内部预检15 分钟把环境问题挡在门外预算与人数确认后并不急着写任务而是先做一轮内部预检。测试失败最常见的原因不是任务设计得不好而是环境没准备好用户到了原型打不开录屏没权限账户被上一位用户污染。这轮预检我会用一个最简脚本固定步骤。2.3.1 预检脚本与参数说明#!/bin/bash # preflight.sh —— 用户测试开始前的 15 分钟内部预检 items(测试设备可联网 原型入口链接可打开 测试账户/数据已重置 录屏软件可用且磁盘空间充足) checked0 for item in ${items[]}; do read -p 确认$item ? [回车继续] _ checked$((checked 1)) done echo 已确认 $checked 项预检完毕。当前时间$(date %H:%M)脚本的逻辑是把预检项放进 items 数组逐项等人确认最后打印确认数量和结束时间。这里不追求自动化断言因为“测试账户已重置”“录屏可用”这类状态没法用脚本可靠判断必须由人来确认。items 数组是核心参数每次测试前按实际环境增删read -p 里的提示文案要写成可验证的状态避免出现“一切正常”这类空话。2.3.2 最常翻车的三项环境问题预检中最常翻车的三项按概率排序原型只监听本机回环地址测试机上打不开这在本地开发时特别常见解决办法是改用局域网地址或临时部署的预览链接测试数据没清理上一位用户留下的订单、消息和通知会影响下一位录屏软件没有权限或磁盘已满等到访谈开始才发现整场只有笔记没有画面。这三项能在第一次预检时全部暴露出来等于替后面每一轮节省了时间。3. 用户测试计划的结构从 Markdown 骨架到可执行配置可行性确认后才轮到文档结构。团队交付习惯是 .doc所以最终交付可能就叫“用户测试的计划.doc”。但编辑过程中我会用 Markdown 做源文件理由是测试计划在测试前会经历多轮改动任务描述要反复调整Markdown 方便在编辑器中做 diff、合并和留痕导出 doc 只是最后一步。3.1 用 Markdown 起草用 pandoc 导出 docpandoc user-test-plan.md -o user-test-plan.docx-o 指定输出文件pandoc 会把 Markdown 里的标题层级、表格和代码块转换成 docx 的原生格式。注意导出的是 .docx不是 .doc如果团队要求 .doc再在转换后另存一次。不要把导出结果当源文件继续改否则下次转换会覆盖手工调整的格式。团队协作时把 .md 提交到仓库docx 作为分享附件测试计划就不容易散落在聊天记录里。3.2 六段式模板结构上一份用户测试计划我会写成六段测试目标、被测用户、测试环境与设备、测试任务、数据记录指标、风险与预案。下面是一个可直接抄走的骨架字段先留空填值的过程才是测试设计的过程。# 用户测试计划功能名 版本号 ## 1. 测试目标 - 目标 1行为 指标 - 目标 2行为 指标 ## 2. 被测用户 - 人数5~8 人 - 主要画像年龄/使用频率/操作经验 - 招募条件必须出现的行为特征 ## 3. 测试环境与设备 - 设备型号/浏览器/分辨率 - 数据初始状态账户/内容/权限 - 录制方式录屏/眼动/仅笔记 ## 4. 测试任务 - 任务 1目标式描述 - 任务 2目标式描述 - 任务 3目标式描述 ## 5. 数据记录指标 - 任务完成率 / 完成时间 / 求助次数 - 用户操作路径与预期路径的偏差点 ## 6. 风险与预案 - 用户临时缺席补位标准 - 主流程崩溃换用备用原型或任务降级 - 严重 Bug是否当场打断如何记录这个骨架的价值不在格式而在强制填空。比如“测试目标”不写清楚后面的任务和数据指标都无从谈起“数据初始状态”不写执行人就会自己造数据测试条件在用户之间不一致。3.3 字段参数说明字段作用常见错误写法建议写法测试目标定义什么是成功“验证功能可不可用”“新用户 60 秒内完成注册并进入首页”被测用户画像界定样本范围“找平时不用的用户”“过去 30 天使用过同类应用但从未用过本产品”数据初始状态保证测试可重复不写或写“登录后即可”“账户 A 含 3 条订单、1 条未读消息无购物车”任务描述让用户执行真实行为“点击右上角头像再点击设置”“你想更换头像请自己找到入口并完成替换”字段填得是否有用取决于能不能倒推出执行动作。测试目标写“验证支付流程是否顺畅”执行时不知道“顺畅”怎么度量改成“首次使用的用户 90 秒内完成从商品页到支付成功页的操作”完成率、时间和求助次数就都有了参照。这是把目标写成可观测行为的基本做法。3.4 从“确认需求”改写为“可观测行为”改写目标有一个公式在什么状态下谁做了什么多长时间内完成完成标志是什么。举例来说“验证支付流程是否顺畅”是一个弱目标它听起来像需求文档验收项改成“在清空购物车且余额充足的状态下新注册用户能独立完成支付且从点击支付到看到成功页不超过 30 秒”之后测试任务、指标和严重级别全部跟着明确了。如果用户没在 30 秒内完成也不能直接判定功能有问题还要结合求助次数和观察记录去看阻塞点在哪里。4. 设计用户测试任务目标式描述、指标与轮转设计具体任务时最常见的问题是任务描述写成了操作步骤。“点击右上角头像再点击设置找到修改密码”这类写法测的是用户顺从度而不是可用性。正确的做法是给场景和目标让用户自己找路径。4.1 任务书模板先场景后动作### 任务 2重新登录 - 场景描述“你上一次登录是在昨天今天再次使用时想登录但忘记密码。” - 起始状态已用测试账户退出登录进入登录页 - 完成标志用户成功登录并看到信息主页 - 允许操作可以手动输入任意内容可以向主持人提问 - 记录重点从“忘记密码”入口出现到用户点击的时长用户是否反复回到登录页场景描述放在最前面是为了让用户进入真实使用状态起始状态和完成标志是给执行人用的确保每个用户从同一条件出发。允许操作里写明“可以向主持人提问”是有意为之如果用户卡住完全不提示会尴尬立刻给出答案又会污染数据所以在计划里事先约定可以提问并把提问内容作为求助信号记下来。记录重点给出的是观察维度不是要求用户回答的问题。4.2 数据记录一张表加一个严重级别测试现场通常有主持人和观察员两个人。主持人负责引导和提问观察员只做记录。记录表我会设计成一行一个用户一列一个任务另加严重级别方便结束后快速排序。任务完成情况用时求助次数关键事件严重级别任务1 登录完成35 秒0在验证码环节犹豫 3 秒后直接输入低任务2 找回密码未完成120 秒2认为“手机验证”与“密码找回”是两个入口高任务3 发布内容部分完成180 秒1进入页面后先找上传按钮没看到说明文案中严重级别不按是否完成来分而是按业务影响判断任务失败且可能带来数据丢失、付费损失或账号安全问题的记高能完成但路径明显偏离或反复求助的记中顺手完成的记低。不写严重级别最后整理一小时视频时会不知道先剪哪段。4.3 任务轮转一段 Python 脚本打散顺序效应任务顺序也会影响数据。所有用户都从注册开始到第三个任务时已经熟悉了整体结构后面的数据可能偏乐观。常见做法是让任务顺序在不同用户之间轮转我会用一段 Python 生成轮转表。tasks [注册, 发布内容, 接收通知, 退出登录] rotations [tasks[i:] tasks[:i] for i in range(len(tasks))] for person, order in enumerate(rotations, 1): print(f被测者{person}: - .join(order))rotations 列表通过列表推导做循环移位len(tasks) 为 4 时生成 4 条不同顺序。脚本思路是把顺序效应从“全部用户同一个方向”变成“均匀分散”并不能真正消除它。5 位用户就安排前 4 人用轮转顺序第 5 人再用第 1 条顺序。如果任务数量多到没法完全轮转至少要保证关键路径不会成为每个人的最后一个任务因为最后一段操作会被“累了想结束”影响。4.4 用 20 分钟的同事预演修正任务书任务书写完后下一步不是约用户而是抓一位还没参与项目讨论的同事做预演。重点看三类问题任务描述里的假设是不是太多比如“假设你已经把商品加入了购物车”用户可能根本不理解这个概念完成标志是不是唯一比如“登录成功”和“进入信息主页”各代表什么演示数据是不是足够自然使用“测试账户 123”会给用户不必要的暗示。预演只能暴露任务书的文字问题数据污染要交给预检脚本解决。5. 用户测试执行当天的三项现场控制5.1 提前 15 分钟把运行状态重置回“零”执行当天最怕的是每场测试之间状态不干净。第 2 章的预检脚本在这里仍然用得上但我会额外加一步在每位用户开始前把原型、账户和录屏软件恢复到同一起点。录制文件也按用户编号分目录避免多场数据混在一起。5.2 用五级难度表和一句话转述收尾任务结束后立刻让用户填一张最小问卷趁记忆还在。任务__ 用户编号__ Q1 完成情况完成 / 部分完成 / 未完成 Q2 整体难度1(非常困难) ~ 5(非常容易) Q3 哪个环节让你犹豫最久___ Q4 一句话向朋友转述这个功能___Q2 的数字很容易被用户个体打分习惯影响有人从不用最高分有人从不用最低分所以只看均值没有意义。真正有用的是把难度数字和 Q3 的具体犹豫点绑在一起看。Q4 看起来随意却能判断用户是否理解了功能的价值能一句话说清楚说明心智模型基本成立转述出来变成另一个功能说明入口文案或页面结构出了问题。每个用户结束时再口头补一句提醒这个问题没有对错目的是找出哪里让你停顿了。5.3 每场结束后的 10 分钟复盘三问每场测试结束回到准备间花 10 分钟记录三个问题哪些任务和计划里的预期差异最大哪些问题指向同一个流程节点下一个用户开始前计划要改什么。第三个问题经常被人忽略觉得中途改计划会影响数据一致性。我的做法是区分两种改动字面描述不清的就改任务逻辑和起止状态的不改。前者不应继续浪费下一个用户的 20 分钟后者要保持统一。如果时间只够回答一个问题就回答第二个——它决定了这轮改动真正要动刀的位置。本文还有配套的精品资源点击获取
