测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。Scott W. Ambler 认为就整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，Confirmatory 测试和 Investigative 测试。 1 下面，我们来讲讲迭代的测试的这两个方面。
图 3. 敏捷测试生命周期
Confirmative 测试就是对 build 的有效性和关键的功能是否正确进行验证，测试人员依据测试用例和测试脚本的完整测试是工作的重心。原文中的 Confirmative 测试包含了开发人员的单元测试（必不可少的重要开发活动）和被称之为 Agile Acceptance Testing 的测试部分，这段时间的测试任务用来保障迭代的必须输出的质量。基本的功能、非功能的任务，但凡是在迭代开始时制定的计划中承诺的高优先级需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。
Investigative 测试是对 Confirmative 测试的补充和是更广泛的测试活动，测试团队在完成 Confirmative 测试后的时间用来做这部分测试，它包含功能测试，文档测试和系统测试以及和其他产品、环境之间产生的必然的 Integration 测试，还有个非常有趣的测试活动叫做 Exploratory 测试，笔者认为这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品。就好比“猴子敲键盘”一样，测试员使用各种手段来考验 build 和产品的稳定和正确性等。
图 4. 敏捷测试的 Incremental Testing
我们在敏捷项目开发的过程中使用了定制的测试流程，我们同样有相同的两部分测试，即 Confirmative 和 Investigative 两部分。不同的是，我们原则的将这两部分测试都放在当前迭代的计划内完成。原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。而同时，因为 Product Owner 和 STAKEHOLDER 的期望是团队能够高效的完成当前迭代的任务，完成更高优先级的工作，每个迭代的考核亦非常清晰。为了完成服从当前的高优先级任务，计划，也为了 STAKEHOLDER 更好的关注和帮助当前问题的及时解决，测试人员对以往 Build 的测试应应合理的计入先前迭代的任务而不是当前迭代计划。倘若真要测试以往的产品而不是最新的，敏捷测试的管理也将变得有些困难，同时测试团队所关注的问题也只能是过时的，只能成为团队的低优先级的问题。这不是与团队整体的目标背离吗？因此，我们建议测试团队使用我们改进后的敏捷增量测试模型，即在当前迭代仅仅完成当前迭代的计划，而所有测试都需要围绕最新的产品 Build 进行。
图 5. 定制的 Incremental Testing
在我们新的增量测试模型中 Confirmative 测试包含对需求的静态测试，开发人员做的单元测试，以及 Build 验证测试，功能测试（仅限于对当前迭代功能）和重要的其他类型测试。通过了 Confirmative 测试的产品 Build 就可以作为在迭代结束时发布了。而为了产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，我们需要针对性的做系统测试，压力，并发，安全甚至全球化的测试，这部分我们把它叫做 Investigative 测试。还需要强调的是，为了保障产品的最终稳定，为了产品不会出现在代码重构后的质量回归现象，我们将回归测试（Regression Test）放在这个阶段，用以涵盖对以往关键功能的再度验证。
文章来源于领测软件测试网 https://www.ltesting.net/
