目的：对于测试人员来说，要做好测试工作、让产品质量更高，用户体验更好，那就需要尽早介入，通常在需求文档形成后需求评审前，分析需求文档，做好讲解前的测试准备工作，这样就可以帮助完善需求文档，并为后续的测试工作铺平道路，节省沟通成本、避免后续过多的需求变更和实现变更带来的各种麻烦。
一、分析需求目的合理性
分析为什么会提出这个需求，该需求的目的对用户来说是否可接受。即这个需求能给用户带来什么，用户需要通过什么路径来得到需求带来的结果。
例：
浏览器四周年时的刮刮乐扩展，此需求提出是为了借助四周年的契机，向沉默用户推送安装刮刮乐扩展，以此唤起沉默用户。扩展的功能是登录通行证后可以参与刮刮乐活动，此活动的奖品是几个苹果产品，中奖率很低。看到这里，你是否开始否定这个需求了呢？我们可以分析一下，首先要明确一点，沉默用户是很久没有使用搜狗浏览器的了，对于这些人，面对参与刮奖还需要登录通行证的繁琐操作和中奖率极低的奖品诱惑时，是否会去参与活动呢？上线后该活动的参与用户为几百人。
二、细看需求描述，画出流程图
这里的流程图是需求流程图，也就是完全基于需求文档的流程图，不涉及到开发实现。
例：
需求描述：用户可以在选项中打开或者关闭直播录制功能，关闭直播录制功能后直播录制按钮不再出现。当检测到用户在浏览器页面中观看直播时，显示直播录制功能按钮。
需求流程：
三、根据流程，提出问题
根据需求流程图，争取在每一环节都提出问题，然后记录下来。
例：
1.开启直播录制
（1）怎样开启直播录制？
（2）都支持哪些直播网站？
2.检测用户行为
（3）怎样检测用户行为？
3.观看直播
（4）怎样才算观看直播呢？
4.显示/不显示直播录制按钮
（5）什么时机显示直播录制按钮？
（6）在哪里显示直播录制按钮？
（7）直播录制按钮长什么样子？
（8）滚动页面，直播录制按钮还显示么？
（9）什么时机直播录制按钮会消失呢？
四、根据需求描述，补充问题
例：
上面需求描述是：用户可以在选项中打开或者关闭直播录制功能，关闭直播录制功能后直播录制按钮不再出现。当检测到用户在浏览器页面中观看直播时，显示直播录制功能按钮。
补充问题：
在选项中哪里打开直播录制？
既然在选项中有开关，那么该项纪录在config.xml还是commcfg.xml？
这一项的字段是什么？
这一项是否跟随通行证同步？
五、问题回顾，增删问题
将文档全部看完后 ，回顾记录的问题，有的可能已经被解答，有的联系上下文可能还说不通，产生新的问题，再次记录。
例：
第一个问题问怎样开启直播录制，而在需求描述中已经说了在选项中打开或者关闭直播录制功能，所以第一个问题已经解答，可以删掉。
六、评估已有需求是否符合需求目的
主要是从已有需求是否符合需求目的、本需求是否符合需求目的、是否有更简单便捷的路径满足需求目的三方面考虑。
例：
追剧需求中的弹泡提醒时间，分为连续观看和固定星期观看。最近三天，每天都有同一剧集的观影记录，对于观看日期连续的剧集，需要每日提醒。同一剧集，连续两周的观看星期时间相同，则成为固定星期时间观看，需要在相应的星期时间提醒。
其实对于用户来说，分的这么仔细更容易让用户混淆，还不如直接采用最近一次观看剧集的时间进行提醒更简单，更容易让用户理解和接受。
七、找寻缺陷，完善需求
找寻缺陷，主要指的是在需求中没有说明的但是又是必不可少的一项。
例：
需求统计pingback，隐性需求。
八、提出建议，锦上添花
可以从系统规范、产品UI、需求细节合理性以及产品易用性几个方面入手，站在用户角度进行思考。
......
源自《51测试天地》原创测试文章系列(四十四）
