企业官网建设流程全解析

简介：这是一份用户测试计划Word文档，面向软件测试工程师、项目经理及测试相关岗位，用于规范用户测试各环节的工作流程。文档系统梳理了用户测试的定义、重要性、计划组成、实施步骤与优缺点，并提供了引言、用户需求测试、现成软件测试、网络安全测试、缺陷管理、风险管理、可追溯性分析、评审、附录等九个板块的可编辑模板，模板中的测试方案表格覆盖人员、条件与环境、工具、方法、通过准则等关键字段，可直接填充项目信息后使用。资源共1个doc文件，大小约73KB，属于轻量级模板，便于下载后快速修改。已有525人学习下载，适合需要快速搭建软件项目用户测试方案或建立团队测试规范的读者参考使用。

1. 用户测试计划，先回答三个问题再开 Word

用户测试的计划.doc，这个文件名的平淡程度和它在产品改动中的分量刚好成反比。一次没有计划书的用户测试，很容易沦为“找几个朋友点点原型”，结论听起来都对，回头开发问“改动依据是哪几条记录”，所有人沉默。一份写清楚被测用户画像、任务清单、成功标准、数据记录方式、风险预案的用户测试计划，才是后续所有改动能够被复盘、被量化、被排进迭代的证据链。下面的内容既写给第一次筹划用户测试的产品新人，也写给那些做过多次但总觉得结论“不硬”的团队——它的核心答案是三个问题：测谁、让他们做什么、事后根据什么说这件事成立。

2. 可不可做？先算清用户测试的时间和预算

接到写用户测试计划的需求，我第一件事不是打开 Word，而是先做可行性判断。原因很简单：用户测试的成本是显性可算的，收益却是概率性的，文档写得再细，也救不了一场没有时间、预算和用户的测试。我会先回答一个最小问题：在这个项目阶段，最该做哪种用户测试。

2.1 按项目阶段选测试类型，成本差三倍

测试类型的选择通常由产品所处阶段决定，而不是由用户活跃度决定。判定基准有三个：有没有可交互的原型、有没有真实用户可触达、有没有数据埋点。按这三个维度，常见需求大致分为三类，见下表。

三者的准备工程量能差出三到四倍，所以计划的第一步是把测试类型写死。常见做法是：只测主路径上最有争议的三个流程，而不是把整个功能列表铺开。测试计划的作用不是证明功能都能用，而是把最不确定的交互在用户面前验证一遍。

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=("测试设备可联网" "原型入口链接可打开" "测试账户/数据已重置" "录屏软件可用且磁盘空间充足") checked=0 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 导出 doc

pandoc 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 字段参数说明

字段填得是否有用，取决于能不能倒推出执行动作。测试目标写“验证支付流程是否顺畅”，执行时不知道“顺畅”怎么度量；改成“首次使用的用户 90 秒内完成从商品页到支付成功页的操作”，完成率、时间和求助次数就都有了参照。这是把目标写成可观测行为的基本做法。

3.4 从“确认需求”改写为“可观测行为”

改写目标有一个公式：在什么状态下，谁，做了什么，多长时间内完成，完成标志是什么。举例来说，“验证支付流程是否顺畅”是一个弱目标，它听起来像需求文档验收项；改成“在清空购物车且余额充足的状态下，新注册用户能独立完成支付，且从点击支付到看到成功页不超过 30 秒”之后，测试任务、指标和严重级别全部跟着明确了。如果用户没在 30 秒内完成，也不能直接判定功能有问题，还要结合求助次数和观察记录去看阻塞点在哪里。

4. 设计用户测试任务：目标式描述、指标与轮转

设计具体任务时，最常见的问题是任务描述写成了操作步骤。“点击右上角头像，再点击设置，找到修改密码”这类写法测的是用户顺从度，而不是可用性。正确的做法是给场景和目标，让用户自己找路径。

4.1 任务书模板：先场景后动作

### 任务 2：重新登录 - 场景描述：“你上一次登录是在昨天，今天再次使用时想登录但忘记密码。” - 起始状态：已用测试账户退出登录，进入登录页 - 完成标志：用户成功登录并看到信息主页 - 允许操作：可以手动输入任意内容，可以向主持人提问 - 记录重点：从“忘记密码”入口出现到用户点击的时长；用户是否反复回到登录页

场景描述放在最前面，是为了让用户进入真实使用状态；起始状态和完成标志是给执行人用的，确保每个用户从同一条件出发。允许操作里写明“可以向主持人提问”是有意为之：如果用户卡住，完全不提示会尴尬，立刻给出答案又会污染数据，所以在计划里事先约定可以提问，并把提问内容作为求助信号记下来。记录重点给出的是观察维度，不是要求用户回答的问题。

4.2 数据记录：一张表加一个严重级别

测试现场通常有主持人和观察员两个人。主持人负责引导和提问，观察员只做记录。记录表我会设计成一行一个用户，一列一个任务，另加严重级别，方便结束后快速排序。

严重级别不按是否完成来分，而是按业务影响判断：任务失败且可能带来数据丢失、付费损失或账号安全问题的，记高；能完成但路径明显偏离或反复求助的，记中；顺手完成的，记低。不写严重级别，最后整理一小时视频时会不知道先剪哪段。

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 分钟，后者要保持统一。如果时间只够回答一个问题，就回答第二个——它决定了这轮改动真正要动刀的位置。

本文还有配套的精品资源，点击获取