[如需转载，请在转载时注明出处，并保证本文的完整性]
刚开始做测试的时候，认为作为测试依据的需求文档或功能说明书应该是条理清晰，一目了然的。可是后来才发现：
经过两周苦逼的研究需求文档的过程，我总结了一下两个原因：
（1）由于测试人员对于业务的不理解，面对一个陌生的业务领域，生僻的各类名词术语，不知所云。可是我们测试人员从何处来理解业务呢？除了公共的业务知识可以从网络上获取外，最重要的系统专业相关的业务知识，我们只能从文档中获取，或者从开发人员或需求人员或有经验的测试人员那里获取。
可是在很多公司的测试人员流动性很大，常常面对这样的状况：因为是维护项目或者新增特性，那么开发或需求人员不可能再从头至尾给你系统详细的讲解业务需求。而熟悉需求业务的测试人员可能已经离职，又没有较好的文档，那么就没有良好的获取业务知识的途径了。
（2）需求文档或功能说明书思路不清晰，信息不全，前后矛盾。造成这种现象的主要原因是写文档的开发人员或需求人员的水平问题。很不幸，我们现实中常常需要面对这样的文档。那么有人就要说了，干嘛不直接问写文档的人或者让他重新写呢？假设我们可以实现这样的要求，那么你想这样思路不清晰的需求或开发人员能给你讲清楚吗？即使让他重写，你保证就能理解吗？
那么就好像玩推理游戏，反复的研究文档，找关键字，加以各种猜测、推理。然后整理出自己认为的流程和规则，逐条与需求或开发来确认。
当然问题是要解决的，现状是需要改善的。第一个问题可以通过本维护项目测试经验的积累来解决，同时积累良好的文档来方便后来者。第二个问题却比较难解决了，这样的测试外包项目，我们站在比较被动一方，不好对客户有太多的要求，只有祈祷能潜移默化的影响他们了，哪天他们看我们的问题列表看烦了，突然觉悟能写出更清晰的文档来给我们。
够狠
