在软件缺陷的8020原则中指出，软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%;系统测试阶段引入测试手段，能发现剩余缺陷中80%的缺陷;在运行维护阶段经过长时间、大量运行软件后，能够发现最后剩余的20%缺陷。(来自于官方引用)也就是说明需求阶段是软件缺陷存在问题较多的地方。

　　在需求阶段中，用户一般是非计算机专业人员，软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。由于软件产品还没有设计、实现，完全靠想象去描述系统的实现结果，所以有些特性在当时不可能很清晰。需求变化的不一致性，用户的需求总是在不断地变化，这些变化应该在与需求相关的各类文档中得到描述，但往往被忽略，并容易引起前后文、上下文的矛盾。没有得到开发团队或管理层的足够重视，在需求分析和定义上投入的人力、时间不足。

　　在整个开发队伍中没有进行充分沟通，不同角色之间对需求的理解不一致。那么怎么能够高效率获取需求呢?咱们今天来分析一波。

　　测试需求分析过程包括需求采集、需求分析和需求评审三个环节。其中测试需求采集的输入是需求规格说明书，测试需求分析的输入是测试要点分析、功能交互分析、质量特性分析和测试类型分析，而需求评审的输入是测试需求。测试需求分析的输出包括：原始测试需求表、测试需求跟踪矩阵和评审结论。

　　首先在收集测试需求阶段，通过和软件相关的文档以及参考手册，整理出原始的测试需求列表。

　　有了原始测试需求列表，接下来就可以进行测试需求分析，是测试人员将原始测试需求列表中的需求进行分析，分析软件测试的测试类型、测试阶段以及需求文档本身未阐述清楚问题，形成测试需求跟踪矩阵。

　　需求文档不完善时，可通过上图各方面去分析，并与用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。

　　经过可测性分析，整理出测试需求之后，进行需求评审，确认需求和软件目标的一致性，识别出功能、非功能需求，为后续测试工作提供依据;确认需求规格说明书的正确性——经验在丰富的需求人员也可能有需求遗漏或疏忽;使项目相关角色，对需求理解达成一致，降低修改和沟通成本;需求评审的主要对象是需求规格说明书。

　　需求评审会议结束后，如果没有问题，那么测试人员在此阶段结束后，明确了测试范围。