编者按：

　　相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。在各种不同的敏捷实践中，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”，“行为驱动开发”，都离不开测试的支持。本专题将要以“敏捷测试”为主题展开，为广大用户网友提供一个交流学习的平台，针对本期主题，小编从51Testing网站中，对与敏捷测试相关的一系列文章进行整理，形成专题，为大家提供一场技术盛宴。

　　什么是敏捷软件测试

　　在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。

　　确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”，“行为驱动开发”，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。

　　既然是这样，为什么我们还要在这个专栏中专门来讨论“敏捷软件测试”？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的“下一个阶段”，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。

　　那么，到底什么是敏捷软件测试？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。【详细】

专题入口：http://www.51testing.com/zhuanti/agile/agile.html

　　敏捷开发与敏捷测试

　　敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

　　我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。

　　敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。 改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

　　敏捷开发的理念：

　　· 个体和交互 胜过 过程和工具

　　· 可以工作的软件 胜过 面面俱到的文档

　　· 客户合作 胜过 合同谈判

　　· 响应变化 胜过 遵循计划

　　并提出了以下遵循的原则：

　　· 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

　　· 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

　　· 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

　　· 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

　　· 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

　　· 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

　　· 工作的软件是首要的进度度量标准。

　　· 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

　　· 不断地关注优秀的技能和好的设计会增强敏捷能力。

　　· 简单是最根本的。

　　· 最好的构架、需求和设计出于自组织团队。

　　· 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

　　敏捷测试流程总结：

　　在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试，在敏捷团队中，测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。

　　根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：

　　1. 验证需求和设计

　　需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（2）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）包括(Architecture Document， Project Scope Statement， Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.

　　在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。

　　产出物：测试需要提交评审结果文档，可以让测试更多的参与DB Design，框架的评审中来 【详细】

专题入口：http://www.51testing.com/zhuanti/agile/agile.html