根据需求文档、需求规格说明书来对需要测试的功能点进行梳理，而且通过需求文档能够更加了解项目的业务场景，一般情况下，在项目中需求文档有3种现状：

1. 有详细的需求文档：

比较严谨负责的团队项目的实施是有详细的需求文档的，我们就可以详阅需求文档来进行测试点的梳理工作，对于需求中你认为不明确的地方可以找项目领导人进行沟通，做到对需求整体把握和理解，利于测试更好的进行。

2. 需求文档不明确即有文档但是文档很粗糙：

一般有两种办法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因比如时间紧张或者开发就是不愿意，那么就需要自己去沟通对于文档中不明确的点问清楚，切记不要含糊不清的测试，于人于己都没有好处。

3. 没有需求文档：

如果你运气很不好遇到了，虽然我很同情你，但是貌似同情没啥用，我们知道做测试很重要的一点是：我有一个预期，我要把软件运行的实际值跟我的预期去比对，如果达到了预期，那么就没问题，如果跟预期不一致那就是有问题。那么如果没有需求，我们该怎么办：

第一种靠嘴去问，大家去协调，协商沟通，然后大家都回答没问题了，我会自己写一个概要的需求描述，然后让他去确认，他说可以，那咱们就这样测，有问题就不断的口头沟通；

第二种要基于用户使用的场景和行业的经验来去做判断它是不是合理的。

不管你的公司处于哪种情况，作为一个测试人员必须尽可能获取更多详细的需求信息，否则测试用例的设计肯定也是无从谈起。那么如何判断自己掌握了足够的需求呢？

我个人分享一些经验，就是让负责梳理需求的测试人员直接当做产品人员一样去给测试团队的其他人去讲解需求，如果能够说清楚所有的模块、功能点和必要的流程，且不会被测试团队成员问太多自己回答不了的问题，我觉得需求就算理解的差不多了。如果做不到解答大部分测试人员问的需求问题，那么一定是你的需求还理解的不够到位，需要在进一步去了解和沟通，此过程直接决定着后续测试项目的质量，请大家务必重视！