（1）被测系统相关的文档、资料。如：需求规格说明书、界面原型、项目会议、有关需求信息的会议记录及其他技术文档。
（2）与客户或系统需求分析人员进行沟通。都说要像用户一样对系统进行测试，和用户交流的过程中会让我们明确怎样的系统会让用户的工作更便捷、高效。
（3）正式或非正式的培训。对于专业领域性强的系统来说，培训是非常有必要的，更能发现业务的“潜规则”。
（4）如果待测试的系统有旧版本的话，旧系统的功能特性会成为最有效的测试需求来源。
（5）系统的业务背景资料。业务领域的专业知识等。
（1）保证软件需求的可测试性
就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充。
（2）确保需求文档中所描述的内容是真实可靠的
我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解。
总之通过测试需求分析的过程，划分系统的需求及其重要程度。测试需求的确定为我们制定进度计划、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。已被确定的测试需求是我们进行测试用例设计和测试覆盖的依据。让测试活动进行的“有理有据”。
推荐阅读：
sales@spasvo.com
