就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。

2、为什么要做测试需求分析

如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。

测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。

3、测试需求的依据与收集

测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软件的主要工作内容。

测试需求主要通过以下途径来收集：

1） 与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。

2） 与客户或系统分析员的沟通。

3） 业务背景资料。如待测软件业务领域的知识等。

4） 正式与非正式的培训。

5） 其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。

4、测试需求的分析

目前不少的书籍与网站资料开始重视测试需求的分析，同时也提出了一些测试需求分析的方法。这里也提出一些自己的看法。

测试需求需要考虑几个层面的因素：

第一层：测试阶段。系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试，不过也是见仁见智的做法，要看测试管理者对测试策略与风险的平衡能力了。

目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。此种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。

第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。

第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出 的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，那些已经是很好的测试需求参考了，在此仅列出业务流的测试分析方法。

任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：

1） 常用的或规定的业务流程

2） 各业务流程分支的遍历

3） 明确规定不可使用的业务流程

4） 没有明确规定但是应该不可以执行的业务流程

5） 其他异常或不符合规定的操作

然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该导致的结果，便形成了软件业务流的基本测试需求。

在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。

5、测试需求的优先级

优先级别的确定，利于测试工作有的放矢的展开，使测试人员清晰了解核心的功能、特性与流程有哪些，客户最为关注的是什么，由此可确定测试的工作重点在何处，更方便处理测试进度发生问题时，实现不同优先级别的功能、模块、系统等迭代递交或取舍，从而缓和测试风险。

通常，需求管理规范的客户，会规定用户需求/软件需求的优先级别，测试需求的优先级可根据其直接定义。如果没有规定项目需求的优先级，则可与客户沟通，确定哪些功能或特性是需要尤其关注的，从而确定测试需求的优先级。

6、测试需求的覆盖率与覆盖程度

测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经跟测试需求存在了一对一或一对多的对应关系，可以说测试需求已经覆盖了该功能点，以此类推，如果确定了所有的软件需求都建立了对应的测试需求，那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%，但并不意味着测试需求的覆盖程度高。因为测试需求的覆盖率只计算了显性的（即被明确规定的功能与特性）因素，而隐性的（即没有被明确规定但是有可能或不应该拥有的功能与特性）因素并未计算在内。因此根据不断的完善或实际测试中发生的缺陷，可以对测试需求进行补充或优化，并更新进测试用例中，以此来提高测试需求的覆盖程度。

企业级自动化测试工具WinRunner

提名理由：Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

工业标准级负载测试工具Loadrunner

提名理由：LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

全球测试管理系统testdirector

提名理由：TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

功能测试工具Rational Robot

提名理由：IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

单元测试工具xUnit系列

提名理由：目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。

功能测试工具SilkTest

提名理由：Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。

性能测试工具WAS

提名理由：Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

自动化白盒测试工具Jtest

提名理由：Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。

功能和性能测试的工具JMeter

提名理由：JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

性能测试和分析工具WEBLODE

提名理由：webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。