当一个测试团队发展到一定规模，各个项目进行测试的时候，都需要对活动进行管理，保证各个活动正常有序的进行，那么该如何进行系统测试管理呢？大概归纳了一下，包括一下6个方面：

一、测试套件管理

测试套件包括：测试用例、驱动和桩。特别地，自主开发的专有测试工具也是测试套件。测试用例包括文字描述型测试用例、脚本型测试用例和测试输入、预期的输出数据。所有这些测试套件的选择使用都是按计划，有步骤地进行的所有的测试套件都和被测软件的版本有着密切的对应关系。

主要对测试套件进行这样一些管理要求：

1) 驱动和桩以及自主开发的专用测试工具能在对应的测试版本情况下立即提取并正确运行；

2) 脚本型测试用例能在对应的测试版本情况下立即提取并正确运行；

3) 用例集的执行状态和执行结果；

4) 用例状态和系统需求的对应关系等。

因此，测试套件应该是有版本的，能唯一标识的，执行状态和结果是可报告和有追踪性的

二、测试工具管理

建议按照四个步骤来进行：

1. 定义软件测试工具的需求：分析组织的能力和准备程度，定义组织的需求，定义成功的准则，建立软件测试工具采用策略。

2. 评价和选择软件测试工具：评审软件测试工具的工具市场，对测试工具进行评价和选择。

3. 进行实施试点：决定试点特性，计划试点，执行试点，评价试点，决定是否购买。

4. 推广使用工具：定期评审，收集使用效果。

对于自制工具，经过归档后，可以参照上述四个步骤进行管理

三、系统测试活动管理

测试相关人员在项目生命周期的每个子周期或迭代中各个阶段的测试活动分别如下：

a） 立项阶段

在项目启动阶段，开始测试前期准备，拟制初步的测试计划，主要关注点为：相关业务知识和测试技术培训，测试角色分配。确认验收准则：测试团队对产品经理和用户达成一致的验收准则进行审核，确保它们的正确性，可读性，可测试性

b） 需求分析阶段

项目进入需求分析阶段，测试团队的工作开始全面展开，需要确定项目的范围验证，质量要求定义，测试策略制订，测试流程剪裁，测试工具、测试环境和设备准备，测试风险识别。主要活动如下：

1、 对软件需求的验证：在软件需求被系统人员分析完成后，测试团队开始参与需求评审，对需求说明书进行验证，主要关注点是：软件需求的准确性，一致性，完整性，相关性，依赖性，可跟踪性，可测试性，可理解性。以使软件需求成为项目开发的基础和测试计划的起点。

2、 如果需要自主设计开发测试工具，还需进行测试工具的需求采集和分析。

3、 编写《系统测试计划》

c） 设计阶段

1、 系统架构评审：在设计阶段，测试团队参与设计评审，了解设计架构，对软件架构的可测试性提出意见。

2、 系统测试设计：根据系统需求、系统方案和系统测试计划编写系统测试方案，并根据系统需求和系统测试方案编写系统测试规程。

3、 系统测试开发：根据系统测试规程进行测试用例开发。

4、 如果需要自主设计开发测试工具，进行方案设计。

d） 系统测试阶段

当系统通过对内交付基线后，项目进入系统测试阶段。系统测试是将软件系统，作为整个系统的一个元素，与硬件、某些支持系统元素结合在一起，在实际运行环境下，对系统进行一系列的测试活动。系统测试的目的是验证系统的需求。

1、 系统测试执行：

2、 BUG定级, 跟踪和管理。在系统测试过程中发现的问题以BUG或者建议形式提交给软件开发组，这些BUG的级别需要给出定义。每个级别的BUG定义见附录A。

3、 测试度量和分析活动。

4、 测试评价和总结

四、测试计划管理

a） 测试计划

测试计划用于明确测试思路，指导测试活动，是成功执行和管理测试项目的保证，通过测试计划可以提高可交流性，避免测试的随意性。测试过程一定要按测试计划来进行。

系统测试计划分为两级管理：系统测试计划和系统测试方案。

由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。制定测试计划需遵循以下原则：

1． 制定计划的人应该是最了解项目和测试资源的人。测试计划要经过项目组的评审，避免出现不合理的计划。

2． 计划安排要结合需求，执行优先级要体现需求的优先级。在同等优先级的情况下，要先安排技术难度高的测试项，增加计划的可调控性。

3． 测试一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。

4． 制定的计划应明确、可及、可度量、可追踪。

5． 计划表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。推荐微软50% 缓冲规则。

6． 由于内外部因素可能需要对测试计划进行调整，这时需要及时对测试计划进行变更和维护

b） 系统测试计划

系统测试计划的内容应该包含以下几大部分：测试范围、策略、测试配置和环境、暂停和再启动标准、进度、人力资源、风险和应对等。

系统测试计划属于项目计划的一个部分。项目计划是在项目生命周期里对项目资源、进度的一个规划，而测试计划是对里程碑范围内测试资源、活动、进度等的规划。测试活动的启动和暂停受控于项目进度计划。

测试计划也应该和项目计划一起纳入配置管理，和项目计划同步进行更新

c） 系统测试方案

因为系统测试往往是以版本迭代测试的方式开展，因此，针对每次测试，为了有效地规范测试执行的过程，所以还应当制定系统测试方案。一般来说，系统测试方案可以分为两个层面：测试负责人层面和测试人员层面，二者考虑的重点有所不同。

系统测试方案在评审通过后应归档管理，它是系统测试执行的依据，系统测试的执行活动应遵照该计划执行。一般来说，参加系统测试方案评审的人员应包含但不限于以下人员：测试组组长，测试人员，测试申请中指定的本次系统测试的版本负责人。

五、测试风险管理

a） 测试风险和管理承诺

了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和资源上的准备，用以规避风险，把风险的影响降到最低。

测试风险可分为外部风险和内部风险：

外部风险就是导致测试实际情况和计划不一致的外部因素。包括：需求项变更，项目进度调整，提交测试工作产品的质量不符合要求等。

内部风险就是测试团队内的一些不确定因素。包括测试进度延误，测试工程师流失，测试工具不到位等。

对风险的防范，高层的支持是很重要的，他能决定相关资源的保障，规避项目进度的失控情况，对需求项的更改也能起到控制作用。所以在测试管理里，风险管理和高层承诺都要考虑，高层管理的承诺其实也是一种风险。

b） 测试常见风险

测试常见风险：

1. 测试计划过于乐观；

2. 开发组没能按计划提交相应的测试工作产品；

3. 测试计划要求的硬件和软件设备或资源未能满足；

4. 测试工具的应用没能达到预期深度；

5. 测试人员的流失，或因出差或休假造成的人力资源不足；

6. 过多的临时任务；

7. 重要测试数据丢失等

测试计划阶段的典型风险有：

1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；

2、测试计划的组织者可能缺乏足够的测试经验；

3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制

六、测试文档管理

项目测试计划、测试方案、测试规程会因项目开发活动的变更而变更，应置于适当的管理和控制之下，测试活动相关的工作产品的变更依据变更管理过程的原则实施。

测试规程作为组织测试活动的基础和有形财富，应当得到有效地积累、维护和管理。可以选择配置管理工具如SVN或QualityCenter。（主要采用QualityCenter管理测试规程）测试管理人员应确保测试方案中准备测试的条目都应有测试规程对应，测试报告中的测试记录和BUG记录都对应于某条或某组测试规程，如果测试中发现的问题不能与某条测试规程对应，测试规程应及时得到补充和完善。通过度量测试用例在测试完成之后对应的结果或状态（通过、失败）以及当次测试使用的测试用例数来辅助判断测试的结果。