测试计划&系统测试

1 测试计划

测试计划包括安排和估计系统测试过程，建立过程标准和描述应该进行的测试。

除了帮助管理人员分配资源和估计测试时间表外，测试计划还适用于参与设计和执行系统测试的软件工程师。他们帮助技术人员全面了解系统测试，并将自己的工作置于此背景下。Frewin 和 Hatton（弗雷温和哈顿，1986 年）。汉弗莱（Humphrey，1989）和基特（Kit，1995）也包括对测试计划的讨论。

测试计划在大型软件系统开发中尤为重要。除了列出测试时间表和程序外，测试计划还定义了所需的硬件和软件资源。这对于负责确保这些资源对测试团队可用的系统管理员很有用。测试计划通常应包括大量的意外事件，以便可以适应设计和实施中的失误，并将人员重新部署到其他活动中。

测试计划不是静态文档，而是在开发过程中不断演变。由于开发过程中其他阶段的延迟，测试计划会发生变化。如果系统的一部分不完整，则无法测试整个系统。然后，您必须修改测试计划，将测试人员重新部署到其他活动中，并在软件再次可用时将他们带回来。

对于中小型系统，可能会使用不太正式的测试计划，但仍然需要正式的文档来支持测试过程的规划。对于一些敏捷过程，比如极限编程，测试离不开开发。与其他计划活动一样，测试计划也是渐进的。在XP中，客户最终负责决定应该投入多少精力进行系统测试。

1.1 测试计划的结构

测试计划显然会有所不同，具体取决于参与测试的项目和组织。通常包含在大型系统中的部分是：

• 测试过程

  对系统测试过程主要阶段的描述。这可以分解为单个子系统的测试、外部系统接口的测试等。

• 需求可追溯性

  用户对满足其需求的系统最感兴趣，因此应对测试进行规划，以便对所有需求进行单独测试。

• 测试项目

  应指定要测试的软件过程的产品。

• 测试计划

  总体测试计划和资源分配。该进度表应与更通用的项目开发进度表相关联。

• 测试记录程序

  仅仅运行测试是不够的；必须系统地记录测试结果。必须可以审核测试过程以检查它是否已正确执行。

• 硬件和软件要求

  本节应列出所需的软件工具和估计的硬件利用率。

• 约束

  影响测试过程的约束，例如人员短缺，应该在本节中被预见到。

• 系统测试

  这部分可以完全独立于测试计划，定义应该应用于系统的测试用例。这些测试源自系统需求规范。

1.2 软件开发的V模型

所谓的软件开发 V 模型将测试的不同阶段与软件过程中的活动联系起来。对于软件过程中的每个阶段，都有一个相关的测试活动。如下图所示。V 模型用于严格控制的开发过程，例如用于安全关键系统的开发过程。

2 增量集成和测试

在测试系统时，您应该始终采用增量方法，逐步集成来自不同团队和供应商的组件。有时，您开发系统的整体结构，然后向其中添加组件。这称为自上而下的集成。或者，您可以先集成提供公共服务（例如网络和数据库访问）的基础结构组件，然后再添加功能组件。这是自下而上的整合。实际上，对于许多系统，集成策略是这些的混合，基础结构组件和功能组件都是递增添加的。在自上而下和自下而上的集成中，您通常必须开发​​额外的代码来模拟其他组件并允许系统执行。

您使用增量方法进行集成，以便更容易发现发生的交互错误。系统组件之间存在复杂的交互，当发现异常输出时，您可能会发现很难确定错误发生的位置。最初，您应该集成一个最小的系统配置并测试该系统。然后，您将组件添加到这个最小配置，并在每次添加增量后进行测试。

在下图所示的示例中，A、B、C 和 D 是组件，T1 到 T5 是系统中包含的功能的相关测试集。T1、T2、T3 首先运行在一个由组件 A 和组件 B 组成的系统（最小系统）上。如果这些发现缺陷，它们将被纠正。集成组件 C，并重复 T1、T2 和 T3，以确保没有与 A 和 B 发生意外交互。如果在这些测试中出现问题，这可能意味着它们是由于与新组件的交互引起的。问题的根源是本地化的，从而简化了缺陷定位和修复。测试集 T4 也在系统上运行。最后，组件 D 被集成并使用现有的和新的测试 (T5) 进行测试。