在上两篇文章《什么是敏捷软件测试》与《自动化测试-敏捷测试的基石》中，我们阐述了敏捷测试的概念，并简单介绍了敏捷测试中的自动化测试观点。在这篇文章中，我们将围绕“测试组如何在组织中组织敏捷测试”这个话题来展开讨论。

　　传统的软件测试有非常明确的测试阶段划分和测试过程定义，按照时间顺序开展每个阶段的测试，以及按照时间顺序组织每个阶段的测试构成了传统测试的主要组织方式。按照传统的软件测试阶段划分，软件测试可以在时间序上被分为单元、集成、系统与用户验收测试，分别对应软件的编码、设计与需求阶段。这种按照时间顺序的测试阶段划分对传统软件开发而言非常适用：测试的每个阶段用于对开发相应阶段的产出进行校验和确认，阶段之间通过固定的输入（通常以文档体现）和输出（例如测试报告）进行衔接。而传统的软件测试过程则一般被定义成测试需求、测试计划、测试设计、测试执行与测试评估总结这五个时间序的步骤，用以指导每个阶段中的测试。

　　在传统的软件开发模式中，这种明确的测试阶段划分和测试过程定义工作得非常好，但在敏捷的环境中，这种模式受到了很大的挑战。挑战首先在于测试阶段的划分上，敏捷测试鼓励为产品建立各层面的验证体系，从某种程度上来说，也可以将其对应到单元测试（代码级别的测试）、集成测试（接口与服务测试）、系统测试（UI级别的测试、系统性能测试等）以及用户验收测试（接受测试）上，但在敏捷环境下，各测试阶段间严格的时间顺序不复存在，敏捷开发鼓励并行，因此在一个敏捷项目中，单元、集成和系统等测试在时间顺序上通常是同时发生的。其次，挑战来自于敏捷中所采纳的方法：TDD、BDD和ATDD等技术的应用使得敏捷环境中的测试成为了超越“验证和确认开发阶段产出”的存在，测试一方面是验证和确认，另一方面是设计。在这种情况下，一定要将测试划分为时间序上的测试阶段是非常不合理的。因此，在敏捷测试中，我倾向于抛弃单元测试、集成测试与系统测试的概念，而代之以代码测试、服务/接口测试、系统测试 —— 后者突出的是测试的对象，而非阶段。总而言之，在敏捷测试范围内，我们不需要过多的关心什么类型的测试应该在什么时候发生，而是始终秉承“设置尽可能多的不同层次的测试”的理念，在整个开发过程中为产品设置尽可能多的测试。

　　相较于传统软件测试的测试过程而言，敏捷中的测试并不特别注重过程，但这并非意味着敏捷测试不需要过程的控制。实际上，如果考察敏捷开发的一个迭代，在一个迭代中发生的测试与传统软件测试在过程管理上还是有诸多类似之处的。通常一个迭代中的测试目标相对固定：针对迭代定义的新功能的验证、针对原有功能的验证、以及保证开发过程中的持续的开发质量。与传统的软件测试相比，在验证方面，敏捷测试的一个迭代的测试目标与其基本一致；另一方面，由于测试执行活动仍然需要依赖计划、用例等，对传统软件测试的过程稍加修改就可以将其应用在每个迭代的测试活动中。我建议在一个迭代中，针对验证目标的测试仍然按照测试需求、测试计划、测试设计与执行、以及测试评估总结的过程方式来管理，但是由于敏捷测试本身的特性（迭代周期短，因而每个迭代中新增内容的验证不多；大量依赖自动化测试；依赖沟通而非文档等），在具体的操作上有一些区别。以下是本人建议的在一个迭代中针对验证与确认工作的测试流程：

　　● 测试需求

　　收集和整理本迭代中的所有需求（主要体现为新增功能和原有功能的修改），建议以在线文档（例如google的google docs）的方式管理每个迭代中的需求变化。通常需要对来自产品的需求进行一定程度的细化，细化到本产品的测试工程师能够清楚理解需要验证的点即可。测试需求通常需要与产品负责人和开发组确认（非正式评审）。

　　● 测试计划

　　“一页纸（One Page）”的测试计划是一个很好的实践。测试计划中只需要包含本次迭代的目标，以及简单的时间和资源计划即可。

　　● 测试设计与执行

　　敏捷测试中的测试设计与执行通常是交织在一起的，对于新功能，测试工程师通常通过对新功能的使用和尝试来了解之，然后为其设计测试用例并用脚本（手工测试用例或自动化脚本）的方式将其固定下来；而对于原有功能的测试主要依靠自动化测试来进行。在测试设计阶段，测试工程师需要维护验收测试，以保证其准确地反映了每个迭代的目标。推荐使用在线表格或是轻量的用例管理软件对用例进行管理，在自动化程度比较高的情况下，甚至可以直接依赖测试需求列表和自动化测试脚本，而无需创建手工用例集合。