《软件测试的艺术》第九章敏捷开发模式下的测试9.0前言9.1敏捷开发的特点9.2敏捷测试9.3极限编程(XP )与测试9.3.2.1极限编程基础9.3.1 XP计划9.3.1
9.0前言
高于个体和互动流程和工具
工作的软件高于详细文档
高于客户合作合同谈判
相应变化高于合规计划
9.1敏捷开发的特点敏捷开发提倡迭代式和增量式开发模式，其中强调测试的重要作用。 这是一个围绕以用户为中心，以客户需求为导向的开发过程，在此过程中随时准备“迎接变化”。 敏捷方法引入了灵活性，但其重点是客户满意度。 客户是敏捷开发的重要一环。 这意味着，如果没有客户的参与，敏捷方法无异于失败。
敏捷开发没有单一固定的开发方法和流程，许多快速开发模式可以被视为敏捷。 但是，这些模式确实有三个共同点。依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
目前，我们面临的挑战是妥善选择敏捷软件。 这通常需要开发人员、管理员和客户的合作。 持续的测试和与顾客的充分对话，关系到产品的最终利益和顺利发布。
9.2敏捷测试本质上是一种协同测试形式，要求每个人参与测试计划的设计、实现和执行。客户参与通过定义用例和程序属性定义验收测试的设计。开发者和测试者共同制作可实现功能自动化的测试套件。 敏捷测试要求每个人都参与测试过程，而且往往伴随着交流与合作。
与敏捷开发的许多特点一样，敏捷测试要求客户尽早参与开发周期，直到结束。 例如，开发人员的代码库稳定下来后，客户需要开始验收测试并向开发团队提供反馈。 这同时也是测试并不是独立的一个阶段，而是和开发过程紧密联系并驱动开发。
为了确保经过验收测试的产品是稳定的版本，开发人员通常从编写单元测试开始，然后实现软件单元代码。 单元测试是失败验证测试，开发者从破坏的角度设计这些用例。 这是在实现软件功能的时候一定要有错误处理代码来“测试”自己的测试用例测试工具包准备好到达后，开发人员将开始编写可以通过单元测试验证的代码。
快速软件开发需要更及时的反馈，敏捷测试依赖于自动化测试。目前有大量开源和商业测试工具包可用，使用什么工具并不重要，只要保证测试和开发工作在同一个环境和工具中进行就没问题。
敏捷开发环境常常由小作战团队组成，在这里开发人员也要扮演测试角色。 具有更多资源的大型项目将配备独立的测试工程师或测试团队。 无论是测试工程师还是测试团队，测试人员都不能只是发现问题并交给开发人员修复。 他们的任务是通过不断的测试反馈推动项目前进，帮助开发人员修复错误、更改需求设计和其他常见的质量改进。
9.3极限编程(XP )和测试XP模型不仅需要客户参与，而且高度依赖于模块的单元和验收测试。 通常，开发人员必须对增量代码更改进行单元测试，以确保代码库满足规范说明的要求。 实际上，测试在XP中的地位非常重要，所以请参阅需要首先创建单元（模块）测试和验收测试，然后才能创建代码库。这种形式的测试称为极限测试（XT）。
9.3.1极限编程基础XP是开发人员能够快速生产高质量代码的软件开发过程。 在这种情况下，“质量”可以定义为该设计的基于代码的规格和客户满意度。
XP的关注点是：
实现简单的设计。 开发者与客户的沟通合作。 不断测试代码库。 为了应对规格说明的变更而重构。 征求用户的反馈。 XP倾向于中小规模的软件开发，这些软件的规格说明会频繁变更，也可以进行接近实时的交流。
XP与传统开发流程相比，有以下不同之处：
首先，在大型项目综合征——开始编码之前，客户与编程团队进行了协商，避免设计软件的细节。 )为了反映新的业务指导方针和市场状况，必须不断变更客户的规格说明和需求。 ) XP规划阶段的重点是收集APP交流的一般需求，而不是细节。 XP避免了创建不必要的功能。 如果客户认为某些功能是必需的，但不需要实现，则软件开发通常不包括此功能。 因此，您可以将中心集中在正在开发的任务上，从而为软件产品增加价值。 XP方法的主要区别在于专注于测试。 在经历了非常全面的设计阶段之后，传统的软件开发模型建议在生成测试界面之前进行编码。 然而，在XP方法中，首先生成单元测试用例，然后才编写代码通过测试XP开发模型通过12个核心实践来驱动该过程。
简而言之，这12个核心的XP实践可以归纳为4个概念：
聆听客户和其他程序员的谈话。与客户合作，开发应用程序的规格说明和测试用例。结对编程。反复测试代码库。 9.3.1.1 XP计划一个成功的计划阶段将为整个XP过程奠定了基础。XP的计划阶段和传统开发模型不同，通常需求收集与应用设计结合起来。XP中的计划重点是确定客户的应用需求，然后设计使用场景来满足客户的应用需求。
9.3.1.2 XP测试基于XP的方法取得成功的关键是进行连续的测试。虽然连续测试的原则包含了验收测试，但单元测试占了主要的部分。设计单元测试是用来导致程序失败。只有确保你的测试能够探测到错误，你才能开始修改你的代码以期它能通过测试。确保单元测试可以捕获错误，这是测试工作的关键。
连续测试的原则同样也支持为优化和调整代码库所进行的重构。
9.3.2 极限测试：概念为了满足XP的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试。极限测试主要由两种类型的测试组成：单元测试和验收测试。 设计测试用例时所采用的原理和第五章描述的原理没有明显差异，但是在开发过程的哪个阶段设计测试用例则有所不同。
9.3.2.1 极限单元测试单元测试具备两条简单规则：
所有代码模块在编码开始之前必须设计好单元测试用例。在产品发布之前须通过单元测试。极限测试中的单元测试与前面描述的单元测试之间的最大差别在于，极限测试中的单元测试必须在模块编码之前就完成设计和生成。
下面列出了在开始编码之前设计单元测试所带来的一些好处：
获得了代码将满足其规格说明的信心。在开始编码之前，就展现了代码的最终结果。更好地理解了应用程序的规格说明和需求。可以先实现一些简单的设计，稍后再放心地重构代码以改善程序的性能，而无需担心破坏应用程序的规格说明。通常要采用一个自动化的软件测试套件来减轻连续执行单元测试的负担。在这些测试套件的帮助下，编写测试脚本，然后执行全部或其中的一部分。除此之外，测试套件通常可以生成报告，并对应用程序中频繁出现的缺陷进行分类。该信息可以帮助我们在将来主动清除这些缺陷。
非常有趣的是，一旦设计并验证了单元测试，这些“测试”用例代码库就与试图编写的应用软件一样有价值。因此，应当将这些测试用例保存在一个代码库中。此外，还应确保进行足够的备份，并具备所需的安全保密措施。
9.3.2.2 验收测试验收测试的目的是判断应用程序是否满足如功能性和易用性等其他需求。在设计/计划阶段，由开发人员和客户来设计验收测试。
在这种方法中，客户对应用程序是否满足他们的要求进行客观、公正的确认。客户通过使用场景来设计验收测试。使用场景和验收测试之比通常是一对多，也就是说，每一个场景都可能需要不止一个的验收测试。如果应用程序与预期结果不一致，即被当做一个缺陷，报告给开发小组。如果客户发现了多个缺陷，那么在将列表传递给开发小组之前，得对缺陷进行优先级别排序。当缺陷被修正，或程序中发生任何变更时，客户都需要重新执行验收测试。从这点来看，验收测试也是回归测试的一种。
极限测试中的验收测试可以是自动化的和非自动化的。
需要特别提醒的是，程序有可能通过所有的单元测试，却不能通过验收测试。因为单元测试是确认程序单元是否满足特定的规格说明，而并非具体的可操作性或审美特性。
9.4 小结今天日益白热化的软件市场竞争对产品的发布速度提出了越来越苛刻的要求，严格遵循敏捷开发过程，为我们提供了一条通往更快速、更高品质软件的康庄大道，而这显然要比传统软件开发方法要更有效率。
极限编程模型是主流敏捷开发方法之一，这种轻量级的开发过程主要把目光集中于沟通、计划以及测试。极限编程中的测试称为“极限测试”。极限测试的重点在于单元测试和验收测试。一旦代码库发生变更，就需要进行单元测试。在重要的发布结点，由客户来执行验收测试。
极限测试还要求程序员在开始程序编码之前，要根据程序的规格说明设计测试配件。在这种方式中，开发的程序要通过单元测试，从而提高该程序满足其规格说明的概率。