《软件测试的艺术》第九章 敏捷开发模式下的测试

9.0 前言

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
相应变化 高于 遵循计划

9.1 敏捷开发的特征

敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。这是一个围绕以用户为中心，以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备。尽管敏捷方法引入了灵活性，但其重点仍在于客户满意度。客户是敏捷开发的关键环节，也就是说，如果没有客户的参与，敏捷方法等同失败。

敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看做是敏捷。然而这些模式的确有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。

现在我们面临的挑战是正确选择敏捷方法，这通常需要开发人员、管理人员以及客户的通力合作。而不断的测试以及充分地与客户互动将使产品最终获益并顺利发布。

9.2 敏捷测试

本质上，敏捷测试是协同测试的一种形式，它要求每一个人都参与到测试计划的设计、实现以及执行中去。客户通过定义用例以及程序属性参与到定义验收测试的设计中来。开发者和测试者共同打造可以进行功能自动化的测试配件。敏捷测试需要每个人都参与到测试过程中，这往往伴随着大量的沟通与协作工作。

和敏捷开发的大多数特征无异，敏捷测试需要客户尽早参与到开发周期中来并一直到其结束。举个例子，一旦开发者的代码库稳定之后，客户需要开始验收测试并向开发团队提供反馈。这同时也意味着测试并不是独立的一个阶段，而是和开发过程紧密联系并驱动开发。

为了保证交付验收测试的产品是稳定的版本，开发者通常从创建单元测试开始，然后实现软件单元代码。单元测试是失败验证测试，开发者从破坏的角度设计这些用例。这意味着在实现软件功能的时候一定要有错误处理代码来“测试”自己的测试用例。而一旦测试配件准备就位，开发者就开始编写可以通过单元测试验证的代码。

快速软件开发需要更及时的反馈，敏捷测试依赖于自动化测试。 现在已经有大量的开源和商业测试套件可用，使用什么样的工具并不重要，只要保证测试和开发工作在相同的环境和工具下就没问题。

敏捷开发环境常常由小型作战团队构成，这里开发人员也要分饰测试角色。拥有较多资源的大一点的项目会配备一个独立的测试工程师或一个测试小组。不管是测试工程师还是测试小组，测试者都不能仅仅是把问题找出来并交给开发人员修复，他们的任务是通过持续的测试反馈推动项目前行，帮助开发者修复bug、改变需求设计以及其他的一般性质量提升。

9.3 极限编程（XP）与测试

XP模型除了需要客户参与之外，还高度依赖模块的单元和验收测试。总体来说，对任何一个递增的代码变更，开发人员都必须进行单元测试，以确保代码库满足其规格说明的要求。事实上，测试在XP中的地位非常重要，所以需要首先创建单元（模块）测试和验收测试，然后才能创建代码库。这种形式的测试称为极限测试（XT）。

9.3.1 极限编程基础

XP是一种可以使开发人员快速生产高质量代码的软件开发过程。在这种情况下，我们可以将“质量”定义为代码库对其设计的规格以及客户的满意程度。

XP的关注点是：

• 实现简单的设计。
• 开发人员与客户的沟通协作。
• 不断地测试代码库。
• 重构以适应规格说明的变更。
• 寻求用户的反馈。

XP更倾向于适合中小规模的软件开发，这些软件的规格说明变更非常频繁，而且它们还可以进行接近实时的沟通。

XP与传统的开发过程相比有以下几处不同：

1. 首先，它避免了大规模项目的综合症——在开始编码之前客户与编程小组碰头，设计软件的每一个细节。（为了反映新的业务准则或市场情况，客户的规格说明和需求必须不停地变更。）XP的策划阶段的重点将集中于收集应用程序的一般性需求，而非在所有的小细节上。
2. XP避免了编写不需要的功能。如果客户认为某个功能虽然需要，但并不要求实现它，那么在软件开发时通常不包含此项功能。因此我们可以把中心集中在正在开发的任务上，为软件产品增加价值。
3. XP方法的主要不同之处是将精力集中在测试上。在经历了一个非常全面的设计阶段之后，传统的软件开发模型会建议首先编码，然后才生成测试接口。但在XP方法中，我们必须首先生成单元测试用例，然后才编写代码通过测试。

XP开发模型用12个核心实践来驱动该过程。

简单来说，这12个核心的XP实践可以归纳为4个概念：

1. 聆听客户和其他程序员的谈话。
2. 与客户合作，开发应用程序的规格说明和测试用例。
3. 结对编程。
4. 反复测试代码库。

9.3.1.1 XP计划

一个成功的计划阶段将为整个XP过程奠定了基础。XP的计划阶段和传统开发模型不同，通常需求收集与应用设计结合起来。XP中的计划重点是确定客户的应用需求，然后设计使用场景来满足客户的应用需求。

9.3.1.2 XP测试

基于XP的方法取得成功的关键是进行连续的测试。虽然连续测试的原则包含了验收测试，但单元测试占了主要的部分。设计单元测试是用来导致程序失败。只有确保你的测试能够探测到错误，你才能开始修改你的代码以期它能通过测试。确保单元测试可以捕获错误，这是测试工作的关键。

连续测试的原则同样也支持为优化和调整代码库所进行的重构。

9.3.2 极限测试：概念

为了满足XP的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试。极限测试主要由两种类型的测试组成：单元测试和验收测试。 设计测试用例时所采用的原理和第五章描述的原理没有明显差异，但是在开发过程的哪个阶段设计测试用例则有所不同。

9.3.2.1 极限单元测试

单元测试具备两条简单规则：

1. 所有代码模块在编码开始之前必须设计好单元测试用例。
2. 在产品发布之前须通过单元测试。

极限测试中的单元测试与前面描述的单元测试之间的最大差别在于，极限测试中的单元测试必须在模块编码之前就完成设计和生成。

下面列出了在开始编码之前设计单元测试所带来的一些好处：

• 获得了代码将满足其规格说明的信心。
• 在开始编码之前，就展现了代码的最终结果。
• 更好地理解了应用程序的规格说明和需求。
• 可以先实现一些简单的设计，稍后再放心地重构代码以改善程序的性能，而无需担心破坏应用程序的规格说明。

通常要采用一个自动化的软件测试套件来减轻连续执行单元测试的负担。在这些测试套件的帮助下，编写测试脚本，然后执行全部或其中的一部分。除此之外，测试套件通常可以生成报告，并对应用程序中频繁出现的缺陷进行分类。该信息可以帮助我们在将来主动清除这些缺陷。

非常有趣的是，一旦设计并验证了单元测试，这些“测试”用例代码库就与试图编写的应用软件一样有价值。因此，应当将这些测试用例保存在一个代码库中。此外，还应确保进行足够的备份，并具备所需的安全保密措施。

9.3.2.2 验收测试

验收测试的目的是判断应用程序是否满足如功能性和易用性等其他需求。在设计/计划阶段，由开发人员和客户来设计验收测试。

在这种方法中，客户对应用程序是否满足他们的要求进行客观、公正的确认。客户通过使用场景来设计验收测试。使用场景和验收测试之比通常是一对多，也就是说，每一个场景都可能需要不止一个的验收测试。如果应用程序与预期结果不一致，即被当做一个缺陷，报告给开发小组。如果客户发现了多个缺陷，那么在将列表传递给开发小组之前，得对缺陷进行优先级别排序。当缺陷被修正，或程序中发生任何变更时，客户都需要重新执行验收测试。从这点来看，验收测试也是回归测试的一种。

极限测试中的验收测试可以是自动化的和非自动化的。

需要特别提醒的是，程序有可能通过所有的单元测试，却不能通过验收测试。因为单元测试是确认程序单元是否满足特定的规格说明，而并非具体的可操作性或审美特性。

9.4 小结

今天日益白热化的软件市场竞争对产品的发布速度提出了越来越苛刻的要求，严格遵循敏捷开发过程，为我们提供了一条通往更快速、更高品质软件的康庄大道，而这显然要比传统软件开发方法要更有效率。

极限编程模型是主流敏捷开发方法之一，这种轻量级的开发过程主要把目光集中于沟通、计划以及测试。极限编程中的测试称为“极限测试”。极限测试的重点在于单元测试和验收测试。一旦代码库发生变更，就需要进行单元测试。在重要的发布结点，由客户来执行验收测试。

极限测试还要求程序员在开始程序编码之前，要根据程序的规格说明设计测试配件。在这种方式中，开发的程序要通过单元测试，从而提高该程序满足其规格说明的概率。