从敏捷开发模式来认知什么是软件测试，这也是讨论什么是敏捷测试，包括在敏捷开发模式下软件测试的思想、原则等。先研究如下敏捷宣言背后所蕴含的12条原则。

① 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。

② 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程、掌控变化。

③ 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

④ 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

⑤ 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

⑥ 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。

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

⑧ 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

⑨ 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

⑩ 以简洁为本，它是极力减少不必要工作量的艺术。

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

团队定期地反思如何能提高成效，并依此调整自身的举止表现。

这12条原则中没有一条直接谈到测试，那是否说明敏捷开发对软件测试没有影响呢？有开发就有测试，只是原来参加敏捷宣言的17人，基本是清一色的程序员，没有在原则中单独阐述一下测试的原则。但如下的一些原则和测试的关联性很强。

① 软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？这就是我们经常在敏捷测试中强调的“自动化测试”。如果没有自动化测试，就没有敏捷，就不能持续不断地及早交付有价值的软件，而且还要“使客户满意”。

② “欣然面对需求变化，即使在开发后期也一样”和传统的开发原则是不同的，传统的开发希望有严格的需求变更控制，越到后期控制越严。而敏捷开发拥抱变化，那么测试如何适应这种变化？如何快速地完成回归测试？这可能要依赖于开发做好单元测试，或全员参与测试，以及全面支持系统级的、端到端的回归测试的自动化测试执行。

③ 传统的开发也要求“业务人员和开发人员必须相互合作”，但存在一定的阶段性，例如前期需求评审、期间产品走查（product walk-through）、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？这样可以减少测试文档，刚开始也没必要把测试计划写得很详细，而是写一页纸测试计划就可以，将来再持续地加以完善和调整。

④ “可工作的软件是进度的首要度量标准”，不再是测试计划完成情况、完成的测试用例数目、测试脚本量等，而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量，而是看多少个具体的用户故事（功能特性）被实现了（done）。某个开发说已完成了某个用户故事，要么是通过他自己的验证，要么是通过测试人员的验证，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。

⑤ “坚持不懈地追求技术卓越和良好设计”，一方面要求测试的技术要不断提高，在处理每个测试任务时，都应该找到最有效的办法；另一方面，在前期要更多地参与设计评审，及时发现设计的问题。只有良好的设计，才能更好地支持系统的功能扩充和不断的重构。

基于这些原则，我们就可以概括出敏捷测试的下列特点。

① 敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其他成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。

② 敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），可以见笔者的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，敏捷测试，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务和代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员。

③ 敏捷测试无处不在、无时不在。在传统测试中也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。

④ 敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长（几个月到几年），即使没有自动化测试也是可以应付的。一般来说，回归测试能够获得几周时间，甚至1～2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在1～3天内就能完成整个的验收测试（包括回归测试）。没有自动化，就没有敏捷。

敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，并具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。敏捷测试和传统测试的区分，可以概括如下。

① 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。

② 传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。

③ 传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。

④ 传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离开用户需求，将验证和确认统一起来。

⑤ 传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。

⑥ 传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。

⑦ 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响。但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

从另一个角度看，有什么实现，就有相应的构建。任何构建的东西，没经过验证都是不靠谱的。理解这个角度，V模型是最好的，笔者适当做了一些修改，如图1-4所示。 +GoFWpvGfL4oA8EaLCXJs8UMQ5JSkydMR1ZE4jRK5f/Mqvo5c3RPFcKa8EeqamXe