测试计划是一个过程，而不仅仅是一个文档。测试计划有助于测试范围的确定，测试策略的优化和测试风险的规避。
在项目启动之后，就要着手软件项目的计划，包括软件测试计划。软件测试计划是整个开发计划的组成部分，同时，它又依赖于软件组织过程、项目的总体计划、质量计划和方针。在测试活动中，首先要确定测试目标、范围和需求，然后制定测试策略，并对测试任务、时间、资源、成本和风险等进行估算和评估。
测试强调的是一个过程，计划（Planning）过程，而不仅仅是为了一个文档——“测试计划书”（Test Plan）
测试计划活动过程伴随着需求文档的审查，而需求文档的评审反过来也有利于测试计划的制定。而且，测试计划必须定义在软件测试需求定义之上，为软件的质量需求验证和确认活动的开展进行规划和指导。
1 质量需求审查与评审
1.1 需求评审的重要性
需求评审对软件测试和质量的作用表现在一下几个方面，显示了其重要性。
1） 对软件需求进行正确性的检查，以发现需求定义中的问题，尽早地降缺陷发现出来，降低成本，并使后续过程的变更减少，降低风险
2） 保证软件需求的可测试性，即确认任何客户需求或产品质量需求都是明确的、可预见的并被描述在文档中，将来可以用某种方法来判断、验证这种需求或特性是否已得到实现
3） 通过产品需求文档的评审，与市场、产品。开发等各部门相关人员沟通，使得大家认识一致，必满在后期产生不同的理解，引起争吵
4） 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求，为制定测试计划和测试方法打下基础，特别是为测试范围、工作量等方面的分析、评估工作积累充足的信息
5） 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更，但可以得到有效的控制，这样可降低测试的风险
评审分为：管理评审、技术评审、文档评审和流程评审
1.2 测试人员在需求评审中的角色
需求评审，通常通过正式的评审会议来进行。在正式的评审小组中，一般存在多种角色，包括协调人、作者、评审员、用户代表等。而测试人员，主要起着评审员的角色，检查需求文档是否按照相应的模板要求严格进行，需求定义是否合理和清楚等。
测试人员作为评审员，在评审过程中，要注意下列事项：
1）明确自己的角色和职责
2）熟悉评审内容，为评审做好准备，做细做到位
3）在评审会上，针对问题阐述观点，而不是针对个人
4）可以分别讨论主要的问题和次要的问题
5）在会议前或者会议后可以就存在的问题提出自己建设性的意见
6）提高自己的沟通能力，采取适当的、灵活的表述方式
7）对发现的问题跟踪下去
测试人员作为评审员，在获得需求文档后应仔细阅读，将阅读中发现的问题、不明白的地方一一记下来，通过邮件发给文档作者，或通过其他形式进行交流。其中重要的一点就是要善于提问，要向自己问问题。
1）这些问题都是用户提出来的？有没有画蛇添足的需求？
2）有没有漏掉什么需求？有没有忽视竞争对手的产品特性？
3）需求文档中，是否正确的描述了需求？
4）我的理解和他们的理解一致吗？
1.3 需求评审的标准
1）正确性：检查在任意条件下软件系统需求定义及其说明的正确性。
2）完备性：涵盖系统需求的功能、性能、输入/输出、条件限制、应用范围等方面，覆盖率越高，完备性越好
3）易理解性：需求文档的描述性被理解的难易程度，包括清晰性。如需求描述是否足够清楚和明确，使其已能作为开发设计说明书和功能性测试数据的基础。。。。
4）一致性：包含了兼容性，如所定义的需求之间是否一致，是否有冲突和毛肚？是否使用了标准术语和同意形式？使用的术语是否唯一的、、、、、
5）可行性：需求中所定义的功能是否具有可执行性、可操作性等。
6）易修改性：对需求定义的描述抑郁修改的程度
7）易测试性：所定义的功能正确性是否能被判断？系统的非功能需求是否有炎症的标准和方法。。。
8）易追溯性：每一项需求定义是否可追溯来源？是否可以根据上下文找到所需要的依据或支持数据？。。。。。。
原文：http://www.cnblogs.com/sdxyuyu/p/5048817.html