在项目进行过程中，测试需求不是保持不变的，随着项目的进行，项目的“业务需求规格”、“软件需求规格”、“接口规范”、“设计规格”都有可能发生变化，对应的测试需求也可能发生变化；另外，测试策略、测试方法的调整也可能会导致测试需求的调整，需要采用规范的方法对测试需求进行管理，主要包括四个测试需求管理活动：需求评审、需求变更控制、需求跟踪和需求的一致性检查

测试需求评审

经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。

同样，测试管理部门应组织相关的技术人员、环境管理人员、测试人员和其他相关人员对系统连接测试需求分析导出的系统连接测试需求，对系统集成测试需求分析导出的系统集成测试需求进行评审，确保系统连接测试需求和系统集成测试需求通过评审。

对于内部测试需求分析中导出的内部测试需求，应由开发中心质量控制部组织相关业务人员、开发项目组进行评审，确保达成一致意见。

当各类测试需求通过评审后，它们将被导入 MQC 中进行版本标识，并进行统一管理。

测试需求跟踪

测试需求的跟踪是通过建立测试需求与之来源、与之测试用例之间的双向跟踪关系来实现的。具体为：

当发生需求变更时，可以根据此双向跟踪关系分析变更影响范围。如针对一个业务功能的变更，可以分析出这个变更将影响到哪些软件需求功能，这些软件功能是否需要变更，相应的哪些设计模块、代码文件、测试需求、测试用例会受到影响，它们是否需要变更。

QC 可以管理测试需求与测试案例的双向跟踪关系，但是不能管理系统概要设计规格、系统详细设计规格、软件需求分析规格、业务需求规格与它们的测试需求之间的双向跟踪关系。这需要单独的需求管理工具，如 Telelogic Doors 或 IBM Rational RequesitePro 等需求管理工具，如果没有这些专业的需求管理工具，也可以使用 Excel 表格等方法手工进行管理。

测试需求变更控制

在测试需求的跟踪关系建立起来以后，可借此跟踪关系进行测试需求的变更控制。

对由于缺陷修复、系统功能增减、业务需求变更等原因导致的变更，应遵循规范的变更过程，使测试需求变更有序、可控、可管理。其变更的控制过程如下：

测试需求的一致性检查