相信很多人跟我有过一样的困惑，那就是在需求阶段我们测试人员到底应该如何对需求进行测试？大家应该都经历过因为需求的缘故而导致大量的返工，造成进度上的delay以及线上BUG的遗漏，要想得到好的result当然离不开一个好的process支持。那么我们在项目的前期，应该如何对需求进行把关呢？个人建议可以从需求的完整性、正确性、二义性这三个方面来着手，随着测试经验的积累，逐渐培养自己挖掘隐藏需求的能力，充分发现需求中不完善，不严密的地方。那么我们具体应该怎么做呢？
第一步,先收集一切与需求有关的资料，如果可能的话，最好能拿到PD与运营方会议的讨论细节，里面一般会包含一些用户使用场景的讨论，这对我们的测试工作应该是很有帮助的。我们可以按模块去确定所包含的功能点，分析该功能所对应的actor，明确actor之间的关系。针对单独的usecase去分析其对应的输入、处理、和输出,将自己的分析有条理的写出来：不同条件下执行某操作后得到不同的结果。?
第二步，分析业务流程，明确需求分析中不同的usecase所组成的业务，形成一系列的业务场景活动图：拆点: 对应的每一个功能点将其对应的输入,处理和输出进行提取; 连线 :将每一功能所对应的输入,处理和输出形成业务活动图;
第三步，了解系统所涉及到的数据流，分析功能入口和角色权限。确定系统的数据流动，包括系统的内部模块间数据流和系统间的数据流接口，在这些地方一般都比较容易出问题。确定系统拥有多少角色（业务），他们负责什么样的工作，在系统中体现在那些模块中。然后画出这些角色的用例，或者他们涉及的业务。我们可以先把每一个角色所做的每一个功能点列出来，然后再将它们放到一个完整的业务流中去；或者先画出整个的业务流，然后再分配给角色。最后得到一个完整的图，它包含整个系统所有业务流程，并且有哪些 角色在某个节点上能够做哪些操作（拥有哪些权限），这些其实就是我们测试的重点。
第四步，确定公共部分需要测试的需求。系统中有一些部分是很多角色所共同拥有的，并且不涉及具体的业务流程。将这部分内容整理出来，一般来说这些内容只会涉及到界面和普通功能的测试，如定义系统界面风格。?
针对需求完整性的验证方法：
1.项目范围是否清晰？应该能清楚的标明哪些功能要实现，哪些功能本期不实现，这样我们才能确定测试范围。
2.是否说明了对每个输入的验证措施，并描述了每个输入的属性，如：边界值、时序要求等以及对于出错时的处理
3.是否清楚描述了系统中与其它子系统、模块间的关系，包括页面的跳转，传递的参数，对于业务逻辑的控制是否需要两边都进行控制还是只需要调用方进行控制即可？这个主要是用于项目中涉及到系统之间的调用的情况
4.对于是改造型的项目，是否已经说明了对历史数据的处理？如果对于新老系统共存的情况下，要说明两个系统之间数据的处理关系，以及数据迁移时需要关注的内容
5.页面展现的处理：对于不允许进行操作的控制，是直接进行屏蔽还是展示后进行相关控件的disable处理
6.借助数据流图以及状态转化图对需求进行测试，检查每个路径的步骤是否都清晰明了，主干过程、分支过程、异常处理的每个步骤是否都已经描述清楚了参与者要干什么？系统要响应什么？是否还存在开环的情况？
7.是否有对用户类型的描述？需求组合是否充分地考虑了所有异常的情况?是否已经考虑到了所有人的需求？是否充分地提出了边界情况？所有到其它需求的交叉引用是否都正确?
针对需求正确性，二义性的检查：
主要是考虑文档中是否存在描述模糊的地方，对于模棱两可的问题，一定要明确具体的输出是什么，可以