同样是测试"用户能不能完成购买流程"，两种任务描述方式会带来完全不同的测试结果：

版本 A："请点击页面右上角的购物车图标，然后完成结账流程。"
版本 B："你刚才浏览了一件喜欢的外套，现在想把它买下来。"

版本 A 在任务描述里告诉了用户答案——购物车在右上角，用户看到任务就知道第一步该做什么。这不是在测试用户能不能找到购买入口，而是在告诉用户入口在哪里然后让他们点过去。测试的核心信息被任务本身提前消除了。

版本 B 给了用户一个场景和目标。用户要自己决定从哪里开始，要自己找到购买路径。主持人能观察到用户的第一反应是什么，视线停在哪里，第一步点了哪里，走了几步才到达结账——这些才是测试想要收集的行为数据。

一. 好的测试任务的三个特征

1. 基于场景

好的测试任务设定，会给用户一个真实的使用动机，让他们知道自己为什么要完成这个操作，而不是直接告诉他们要完成什么操作。场景让任务有了背景，用户的行为会更接近真实使用时的样子。"查一下上周你的话费消费了多少"比"找到账单页面"更有场景感——前者让用户进入了一个真实的使用情境，后者只是在描述一个导航操作。

2. 目标导向

写测试任务时只需要告诉用户想要什么结果，不要把操作步骤写进去。比如同样是测试"用户能不能关闭推送通知"，"进入设置，找到通知管理，关闭推送通知"把每一步都写出来了，用户照着走就行，测试观察不到用户自己会怎么找。而"你觉得 App 推送太频繁了，想把它关掉"只告诉用户想要的结果，用户需要自己决定从哪里入手、走哪条路径——这些自主决策的过程，才是测试要观察的行为。

3. 不包含界面提示词

界面上出现的按钮名称、菜单标签、图标描述，不能出现在任务里。这些词是线索，用户看到任务里有"点击'我的'图标"，就知道要去找标着"我的"的地方。测试想观察的，恰恰是用户在没有这些提示的情况下能不能找到正确的入口。检查任务的方法很简单：把任务文字和界面截图放在一起，看任务里有没有词语和界面上的元素文字完全一致，如果有的话，替换掉。