小华是一名设计师，她准备给新改版的注册流程做可用性测试。她行动力很强——当天就开始招人，不一会就招到五个用户，于是她写好了几个任务，约好时间，第二周就把测试做完了。

五场测试记录了三十多条观察：有用户在第二步停了很久，有用户跳过了邮箱验证，有用户把"下一步"看成了"提交"，有用户全程顺利但结束后说"不确定注册成没成功"。每一条单独看都像是值得关注的发现，但放在一起看，她分不清哪些是严重的设计缺陷、哪些只是个别用户的操作习惯。她也说不出这次测试到底回答了什么问题——因为她从一开始就没有定义过测试要回答什么。

做了测试、收集了数据，确得不出结论，这里面缺的不是执行，而是在执行之前就应该想清楚"这次测试要回答哪几个问题"。这就是测试正式开始前，测试计划该做的事。

一、测试计划的作用

没有测试计划的测试，数据是混乱的——分析的人不知道哪条观察重要，不知道从哪里下手，不知道做完之后应该对产品做出怎样的判断。有了测试计划，每条观察都有了参照系：比如这条数据和测试目标有没有关系，帮助回答了哪个问题。

测试计划还有另一个价值：让团队其他人知道这次测试在做什么。产品经理、开发、老板——在测试开始前让这些角色看到计划，这里面的好处不止一个。他们可以决定要不要来现场观摩；如果亲眼看到用户卡住，他们对测试结论的接受度会高很多。他们也可以提出自己关心的问题，补充到测试目标里，让测试结论覆盖更多人在意的议题。测试结论能不能推动设计改动，很大程度上取决于关键决策者是否在测试之前就参与了目标的制定——看到自己提过的问题被回答了，他们更愿意接受结论、支持后续行动。

二、确定测试目标

测试目标的来源是产品层面的疑问或风险——某个地方设计师不确定用户能不能顺利通过，某个功能刚改版还没有经过用户验证，某个流程的数据显示出异常的流失。

把这些疑问转化成测试目标，最为关键的一步是：从"我们想知道什么"变成"我们能观察到什么"。举个例子：

产品的疑问是"新手用户能不能顺利完成注册"。这个表述太模糊，无法直接指导任务设计，测试做完后也无法判断这个问题是否已经被回答。

转化成测试目标之后，应该变成："观察新手用户在不接受任何帮助的情况下，能否在五分钟内独立完成注册并进入主界面，以及在哪些步骤出现了停顿或错误操作。"转化后的表述有了可观察的行为（完成注册）、可记录的参数（五分钟内、不接受帮助）、具体的观察焦点（哪些步骤出现了问题）。

测试目标的数量不要超过三到四个。目标太多意味着任务太多，测试时间拉长，用户的注意力和耐心都会在后半段下降，越到后面的任务数据质量越差。一次测试回答三个清晰的问题，比模糊地覆盖十个问题更有价值。

如果有多个目标，还需要区分哪些是主要目标、哪些是次要目标。主要目标决定任务的设计，必须在任务里有直接对应；次要目标可以在测试过程中附带观察，不专门为它设计任务，但主持人知道如果有相关情况出现，要多留意。