不论测试部门还是兄弟部门，规模扩展都非常迅速，以前做不同的项目开发测试人员就这么几个，现在可不同了，一个项目中，前期与后期的人员都存在变化的可能。

　　正因为“人”这个重要因素，我们可以看到，项目与项目的过程之间，有着非常大的不可控性。尽管最后有使命感的驱使完成了项目发布，但我们的感受与成长却千差万别。

　　无论是业务型项目还是改进型项目，测一个项目最大的风险可能就是需求的不确定性，当然项目的风险又岂只这一点，或许我们都经历过这样的问题：

　　1.在准备测试用例编写时，才分配进入项目

　　2.介入的项目涉及一个未接触的业务领域

　　3.项目的需求朝令夕改，跟不上变化

　　4.需求不了解，测试不深入，不敢承诺质量

　　5.项目测试时间来不及了，把不熟悉业务的人调来测试 等等为此，我们有很多方法，比如管理上保证在项目立项时测试资源到位；需要支持时尽量找相关业务的测试人员；流程上保证需求变更有基线与变更流程控制；保证测试阶段的执行；等等,方法肯定多于问题的。但同样的给予，每个项目却未必有同样好的效果是为什么呢？因为不够主动。

　　那怎么占据主动呢？有很多时候，我们进入到这样的境地是不知道自己还有不知道的需求，怎么让需求自己能够跳出来找你呢？

　　1. 集中式扫描需求文档。

　　这一条对于不擅长多线程思维的同学特别有效。这里突出的是“集中式”，找出自己每天记性最强，思维清晰的区间，把手上的工作排好，专门空出这样的区间去阅读需求类文档，不要受其他干扰。你会发现理解需求其实像阅读一样富有意境，让你思绪澎湃，自然而然发出这样的问题：这点功能没有表达清楚是做什么的？这点和那点业务有关系吗？过了这一环，需求错误，需求描述不清晰，这类型的需求问题能打扫出很多。当然，这是体能战，感冒发烧稀里糊涂时，此招收效甚微。

　　2. 珍惜每一次预审的机会。

　　特别是评审前的预审，更为重要。因为技术型人员多数都有这样特点，自尊心特别强，如果在预审中，能找出问题，并且一对一去和相应人员沟通，不光你的问题及时解答，又能帮助其需求得到完善，更是帮助其相关能力得到提高，这时比较容易与这位同学建立起亲密战友关系，相辅相成，交流越多，越能发散出问题，最能找到像需求的遗漏这样的大问题。呵呵，这个心理战使用时，还需要考验大家的沟通能力与技巧。

　　3. 亲自动手展现项目需求。

　　这一点必须强调，哪怕项目需求文档，设计文档，UC文档已经非常精细了，但还是请你自己，再动手画一画系统结构图，业务活动图，甚至是系统交互图，因为看的明白和画的明白，运用的是人脑的不同功能，视觉是理解的来源，动作是理解的表现。在制作的过程中，会要求你的大脑去串连所有需求片段，信息不断地做着加法，一旦需求有遗漏或是需求理解有错误，都会让你拼不出完整的各式图表，于是这个项目的各种需求问题不断的蹦发出来。当拼接的各式图表成功时，原先杂乱的大脑信息碎片开始迅速做起减法，让你倍感轻松，快乐无比。无疑，这是实打实的技术战，凭的是经验，拼的是能力。

　　至此，挖掘需求的实用战术简介完毕。三招而已，三招之后能攻下需求之不确定性吗？无他，勤练。