递增的迭代测试

测试驱动开发的原则应该运用于每一迭代周期的开发中。但是，测试驱动开发的单元测试仍然是以开发为目的的活动，虽然自动化测试，回归测试和用户的接收测试（User Acceptance Test）可以通过复用单元测试脚本提高以后的测试工作的效率，但单元测试不是我们敏捷测试讨论的重点。

敏捷测试活动的主要承载者还是敏捷测试人员。测试人员如何运用敏捷原则指导测试活动还是笔者在敏捷测试实践一文中要讲述的重点。以下，笔者将通过两个迭代测试模型来帮助了解测试人员如何结合敏捷原则实践敏捷的测试活动。

经典敏捷增量测试模型

测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。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）放在这个阶段，用以涵盖对以往关键功能的再度验证。

静态测试

在笔者的测试模型里，confirmative 测试增加了“静态测试”，本人认为这部分测试是对测试人员最具挑战的部分。一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力和也得以发挥了团队的最佳战斗力。在笔者的项目经历中，往往这个阶段会需要一个迭代周期 1/4 左右的时间。这同时也说明了静态测试在敏捷测试类型中的重要性。

在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。

图 6. 静态测试需要的 Strategy Thinking

对于静态测试的方法，我们在这里需要推广 RUP 的 Use Case，这是个很好的分析需求的方法，也是测试人员作为静态测试的使用的方法之一。对产品长期战略和业务的熟悉可以帮助测试人员更好的理解团队的用例设计，视图、模块等，也能够通过对比分析，直接找出某些设计中的缺陷，以提高设计的质量。项目的开发前期阶段，设计是占有非常重要的比例，而设计是直接影响产品质量的环节，因而确保这一阶段的质量对产品的品质提高起到决定性作用。针对开发出来的用例，设计者对用例的描述通常故事情节比较简单，缺乏完备和逻辑的缜密。而开发和测试需要的是详细的设计，这个用例设计和各种辅助的逻辑应该将用例定义的清晰和明确，例如边界条件，例外条件，数据的格式和其他性能指标的界定等等都需要涵盖。因此，测试人员应该领导团队帮助明确出用例更多的细节。比如，在一次设计用例讨论中，设计者提出“我需要一个 Overlayer”。那么测试人员应该要问：“如何打开这样一个 Overlayer，如何关闭？”“这个 Overlayer 需要多大平面尺寸，是否支持调整，是否支持对屏幕大小的自动适应”，“Overlayer 的打开

和关闭是否需要有动态渐变的效果？”，“Overlayer 的是否需要滚动条？”，等等。

这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。这是个非常关键的过程。尤其是对测试人员而言，任何“假设“都是有害的，所以一定需要把不清楚和模棱两可的问题从一开始就理清楚。

回页首

敏捷测试的计划与管理

做好了测试的思想准备，并了解如何从需求开发出测试用例，敏捷测试人员接着需要做的就是参考产品需求和团队的设计制定和计划测试任务和各种测试活动，即测试策略和测试计划的制定。每个迭代敏捷开发都将关系产品的功能点和非功能点的需求作为产品的 Backlog 编入待开发的序列，敏捷团队从中会选择适量的 Backlog 项目来作为当前迭代的 Backlog 去实现。测试人员同样根据需要制定出相应的测试工作，并罗列于团队的 Backlog 项目中，承诺了在迭代结束时可以做好的足够的测试工作。

对于测试计划中的 confirmative 测试，这部分必须做到高质量的按时完成。而对于 Investigative 部分，我们应该适量的计划到当前迭代中，切忌不要做 over commit。

图 7. 计划测试 Backlog 项目

接着，测试人员需要撰写测试用例和测试脚本了。测试用例的撰写和传统测试基本没什么差异，按照已有的模式撰写就好了。笔者的测试团队，使用了 XML 文件格式保存所有测试用例，原因主要是沿用了测试团队原有的习惯，而同时也因为 XML 测试用例能够更好的匹配自动化测试的需要，并且便于更新。测试