前言
软件开发生命周期的测试
本章简要介绍了软件开发项目中常用的生命周期模型，并解释了测试在每个模型中扮演的角色。它讨论了各种测试级别和测试类型之间的区别，并解释了这些在开发过程中的应用位置和方式。
大多数软件开发项目是按照事先选择的软件开发生命周期模型来计划和执行的。这种模型也被称为软件开发过程模型，或者更简洁地称为开发模型。
这样的模型将项目划分为独立的部分、阶段或迭代，并将由此产生的任务和活动安排在相应的逻辑顺序中。此外，该模型通常描述了每项任务所分配的角色，以及项目的哪位参与者负责每项任务。在各个阶段要使用的开发方法通常也会被详细描述。
每个开发模型都有自己的测试概念，
这些概念在意义和范围上可能有很大的不同。下面几节将从测试人员的角度详细介绍流行的开发模式。
- 生命周期模型的类型
目前使用的两种基本的开发模式是顺序式和迭代式/增量式。下面的章节包括对这两种类型的讨论。
一、顺序式开发模型
顺序式开发模型将开发过程中涉及的活动以线性方式安排。这里的假设是，当开发模型的所有阶段都完成后，产品及其特征集的开发就完成了。这个模型没有考虑到各阶段或产品迭代之间的重叠。以这种方式运行的项目的计划交付日期可能在未来几个月甚至几年。
二、 瀑布模型
每个开发阶段只有在前一个阶段完成后才能开始。然而，该模型可以在相邻的阶段之间产生反馈回路，要求在前一个阶段进行修改。图3-1显示了罗伊斯的原始模型中所包含的阶段：
这个模型的主要缺点是，它把测试作为一个单一的活动捆绑在项目的最后。测试只有在所有其他开发活动完成后才进行，因此被看作是一种 “最终检查”，类似于检查出厂的货物。在这种情况下，测试并不被看作是在整个开发过程中进行的活动。
三 、V型模型
V模型是瀑布模型的延伸 [ISO/IEC 12207]）。这个模型的出现对开发过程中的测试方式产生了巨大而持久的影响。每个测试人员和每个开发人员都应该学习V模型，了解它是如何整合测试过程的。即使项目是基于不同的开发模式，这里说明的原则仍然可以应用。
其基本思想是，开发和测试是具有同等价值的相应活动。在图中，它们由 "V "的两个分支来说明：
- 我们是否正确的建立了系统？
验证(Verification)包括检查测试对象是否完全和正确地履行了它的规格。换句话说，测试对象（即相应开发阶段的输出）被检查是否按照其规格（相应阶段的输入）"正确 "开发。
- 我们是否建立了正确的系统？
确认(Validation)包括检查测试对象在其预期的环境中是否真正可用。换句话说，测试人员检查测试对象是否真正解决了分配给它的问题，以及它是否适合其预期用途。
实际上，每个测试都包括这两个方面，尽管验证的份额随着每个抽象层次的增加而增加。组件测试主要侧重于验证，而验收测试则主要是确认。
V型模式的特点：
开发和测试活动分别进行（用左边和右边的分支表示），但对项目的成功同样重要。
有助于直观地了解测试的验证/确认方面。
区分了协作测试的层次，即每个层次都是针对其相应的开发层次进行测试。
尽早测试的原则
V型模型给人的印象是测试在开发过程的后期开始，在实施之后。这是不对的! 在模型的右侧分支的测试级别代表了测试执行的不同阶段。测试准备（计划、分析和设计）必须在左侧分支的相应开发步骤中开始。
四、迭代和增量开发模型
- 迭代开发
迭代开发的基本思想是，开发团队可以利用他们从以前的开发阶段获得的经验，以及现实世界和客户对早期系统版本的反馈，在未来的迭代中改进该产品。这种改进可以采取故障修正或改变、扩展或增加特定功能的形式。所有这些方案的主要目标是一步一步地改进产品，以便越来越准确地满足客户的期望。
- 增量开发
增量开发背后的理念是按预先计划的阶段开发产品，每完成一个阶段就提供一个功能更全面的产品版本（增量）。增量的大小可以有很大的不同–例如，从改变一个简单的网页布局到增加一个具有额外功能的完整新模块。增量开发的主要目的是尽量缩短上市时间–即发布一个简单的产品版本（或一个功能的简单版本），以尽快为客户提供一个产品或功能的工作版本。然后，根据客户的反应和愿望，不断地提供进一步的改进。
- 迭代-增量式开发
在实践中，这两种方法论的边界是模糊的，它们通常被称为迭代-增量开发。两者的一个决定性特征是，每个产品的发布都能使你从客户和/或终端用户那里获得定期的、早期的反馈。这减少了开发一个不符合客户期望的系统的风险。
迭代-递增组合模型的例子有：螺旋模型、快速应用开发（RAD）、Rational统一流程（RUP）和进化开发。
- 敏捷软件开发
所有形式的敏捷软件开发都是迭代-递增的开发模式。最著名的敏捷模型是： 极限编程（XP），看板，以及Scrum。近年来，Scrum已经成为其中最流行的一种，并得到了极大的普及。
- 根据迭代的节奏进行测试
创建新的增量/版本的速度因模式不同而不同。非敏捷的迭代增量项目倾向于预见六个月到一年的发布周期，有时甚至更长，相反，敏捷模式试图将发布周期减少到每季度、每月、甚至每周的节奏。
在这里，测试必须适应这样短的发布周期。例如，这意味着每个组件都需要可重复使用的测试用例，这些测试用例可以很容易地在每个新的增量中立即重复。如果不满足这个条件，你就有可能减少系统的可靠性，从增量到增量。
每个增量还需要新的测试用例，涵盖任何额外的功能，这意味着你需要维护和执行的测试用例的数量（在每个版本）随着时间的推移而增加。发布周期越短，所有的测试用例在所有分配的发布时间框架内得到满意的执行仍然很关键，但变得更加困难。因此，在使你的测试适应敏捷开发时，测试自动化是一个重要工具。
- 持续集成和持续部署
一旦你建立了可靠的自动化测试环境，你就可以把它用于每一个新的构建。当组件被修改时，它会被集成到之前的完整构建中，然后再进行一次新的自动化测试运行。任何出现的故障都应该在短期内修复。这样一来，项目总是有一个完全集成和测试的系统在其测试环境中运行。这种方法被称为 “持续集成”（CI）。
这种方法可以用 “持续部署”（CD）来加强： 如果测试运行（在CI期间）是无故障的，经过测试的系统会自动复制到生产环境中，并安装在那里，从而以准备运行的状态部署。
- 持续交付=持续测试
将CI和CD结合起来的结果是叫做 "持续交付 "的过程。只有当你有基本自动化的测试环境，使你能够进行 "持续测试 "时，这些技术才能成功应用。
五、 项目和产品背景下的软件开发
对开发和测试的计划和可追溯性的要求因环境不同而不同。生命周期模型对特定产品的开发是否合适，也取决于其开发和使用的背景。以下基于项目和产品的因素在决定使用哪种模式时起着作用：
公司的业务重点、项目目标和风险状况。例如，如果进入市场的时间是主要要求。
正在开发的产品的类型。一个小的（也许是部门内部的）系统的开发过程没有大型项目的要求那么高。我们的VSR-II案例研究项目。这样的大型产品往往是使用多种模型开发的。
产品使用的市场条件和技术环境。例如，为物联网（IoT）使用而开发的产品系列可以由多种类型的对象（设备、服务、平台等）组成，每一种对象都使用特定的、合适的生命周期模型来开发。由于物联网对象被长期大量使用，如果它们的操作使用（分发、更新、退役等）被反映在生命周期模型中的特定阶段或任务目录中，那是有意义的。这使得开发这种系统的新版本特别具有挑战性。
产品风险。例如，在设计和实施车辆制动系统时涉及的安全方面。
组织和文化方面。例如，国际团队内部沟通产生的困难会使迭代或敏捷开发更加困难。
案例研究： VSR-II项目中的混合开发模式
VSR-II项目的目标之一是使其 “尽可能的敏捷”，所以DreamCar模块和所有基于浏览器的前端组件和子系统都是在敏捷Scrum环境下开发的。然而，由于它们是安全关键型的，ConnectedCar组件将使用传统的V型模式开发。
原型开发也是项目早期的一个选择，一旦实验阶段完成，你可以在项目的其余部分改用渐进式方法。
- 定制
开发模型可以而且应该被调整和定制，以便在特定的项目中使用。这种适应过程被称为 “定制”。
定制可以涉及结合测试层次或某些测试活动，并特别组织它们以适应手头的项目。例如，当把现成的商业软件集成到更大的系统中时，集成测试阶段的互操作性测试（例如，当与现有的基础设施或系统集成时）可以由客户而不是供应商进行，验收测试（功能和非功能的操作和客户验收测试）也是如此。更多细节见3.4和3.5节。
然后，量身定制的开发模型包括对所有项目参与者具有约束力的所需活动、时间尺度和目标的看法。任何详细的计划（时间表、人员配置和基础设施分配）都可以利用并建立在定制的开发模型上。
- 好的测试的属性
无论你选择哪种生命周期模型，你的定制应该支持良好和有效的测试。你的测试方法应该包括以下属性：
- 测试及其相关活动尽可能早地包括在生命周期中–例如，起草测试用例和建立测试环境（见上文早期测试的原则）。
- 每一个开发活动，都有相应的测试活动计划和执行。
- 测试活动被专门计划和管理，以适应它们所属的测试级别的目标。
- 测试分析和测试设计在相应的开发阶段开始。
- 一旦工作产品（需求、用户故事、设计文档、代码等）存在，测试人员就会参与讨论，完善它们。测试人员应该尽早并持续地参与这个完善的过程。