软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求和设计的确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）。

    又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。

    再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。

    最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。

    读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。测试需求的开发总是有赖于相应层次的软件规格说明书

    只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。

    除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。哪些测试需求项应该先测，哪些可以延后，那些是可以并行等等，都需要在测试需求开发阶段一并分析清楚。

    此外，需求分析过程组还将涉及测试需求的管理。这一部分工作包括测试需求制定依据获得、测试需求评审与确认、测试需求变更管理等内容。其中，“测试需求制定依据获得”是指获取产生测试需求所需的原始文档和信息、制定判定和筛选测试需求的原则及依据、明确各测试需求项优先关系排序的依据等等;“测试需求评审与确认”是指测试团队就形成测试需求项与客户代表、同行、管理层、团队骨干人员、项目发起人等Stakeholder进行沟通、确认的过程;“测试需求变更管理”是指对于测试需求的变更应通过“变更控制委员会”（CCB）进行统一控制。事实上，不管是测试服务型企业还是产品开发型企业，都应将测试需求作为一个重要的配置项。[在纯测试项目中测试需求作为一个配置项其地位甚至等同于项目范围说明书]。

    以上笔者结合工程实践，对软件测试项目的启动规划与需求分析做了一个概要的介绍和说明。请读者朋友结合本公司的特点对这里提到的相关流程做进一步裁剪和细化。

    图1:测试项目实施的过程组模型

    项目章程的主要内容

    1）项目名称及背景描述;

    2）项目经理任命及职责范围界定;

    3）项目业务需求描述;

    4）项目发起的原因;

    5）主要项目干系人及其初步需求;

    6）产品及预期交付成果描述;

    7）项目假设和约束条件。