软件测试:软件测试挖掘需求的实用战术

 　　不论测试部门还是兄弟部门，规模扩展都非常迅速，以前做不同的项目开发测试人员就这么几个，现在可不同了，一个项目中，前期与后期的人员都存在变化的可能。 　　正因为"人"这个重要因素，我们可以看到，项目与项目的过程之间，有着非常大的不可控性。尽管最后有使命感的驱使完成了项目发布，但我们的感受与成长却千差万别。
　　无论是业务型项目还是改进型项目，测一个项目最大的风险可能就是需求的不确定性，当然项目的风险又岂只这一点，或许我们都经历过这样的问题：
　　1.在准备测试用例编写时，才分配进入项目介入的项目涉及一个未接触的业务领域项目的需求朝令夕改，跟不上变化需求不了解，测试不深入，不敢承诺质量项目测试时间来不及了，把不熟悉业务的人调来测试等等为此，我们有很多方法，比如管理上保证在项目立项时测试资源到位；需要支持时尽量找相关业务的测试人员；流程上保证需求变更有基线与变更流程控制；保证测试阶段的执行；等等,方法肯定多于问题的。但同样的给予，每个项目却未必有同样好的效果是为什么呢？因为不够主动。
　　那怎么占据主动呢？有很多时候，我们进入到这样的境地是不知道自己还有不知道的需求，怎么让需求自己能够跳出来找你呢？
　　1. 集中式扫描需求文档。 　　这一条对于不擅长多线程思维的同学特别有效。这里突出的是"集中式"，找出自己每天记性最强，思维清晰的区间，把手上的工作排好，专门空出这样的区间去阅读需求类文档，不要受其他干扰。你会发现理解需求其实像阅读一样富有意境，让你思绪澎湃，自然而然发出这样的问题：这点功能没有表达清楚是做什么的？这点和那点业务有关系吗？过了这一环，需求错误，需求描述不清晰，这类型的需求问题能打扫出很多。当然，这是体能战，感冒发烧稀里糊涂时，此招收效甚微。
　　2. 珍惜每一次预审的机会。
　　特别是评审前的预审，更为重要。因为技术型人员多数都有这样特点，自尊心特别强，如果在预审中，能找出问题，并且一对一去和相应人员沟通，不光你的问题及时解答，又能帮助其需求得到完善，更是帮助其相关能力得到提高，这时比较容易与这位同学建立起亲密战友关系，相辅相成，交流越多，越能发散出问题，最能找到像需求的遗漏这样的大问题。呵呵，这个心理战使用时，还需要考验大家的沟通能力与技巧。 　　3. 亲自动手展现项目需求。
　　这一点必须强调，哪怕项目需求文档，设计文档，UC文档已经非常精细了，
　　但还是请你自己，再动手画一画系统结构图，业务活动图，甚至是系统交互图，因为看的明白和画的明白，运用的是人脑的不同功能，视觉是理解的来源，动作是理解的表现。在制作的过程中，会要求你的大脑去串连所有需求片段，信息不断地做着加法，一旦需求有遗漏或是需求理解有错误，都会让你拼不出完整的各式图表，于是这个项目的各种需求问题不断的蹦发出来。当拼接的各式图表成功时，原先杂乱的大脑信息碎片开始迅速做起减法，让你倍感轻松，快乐无比。无疑，这是实打实的技术战，凭的是经验，拼的是能力。
　　至此，挖掘需求的实用战术简介完毕。三招而已，三招之后能攻下需求之不确定性吗？无他，勤练。