【专题】关于敏捷测试，我们到底知道多少？

　编者按：

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

　　什么是敏捷软件测试？

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

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

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

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

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

　　软件测试能够敏捷吗？

　　开发敏捷了，测试也想敏捷，结果有了“敏捷测试”。但测试真能敏捷吗？

　　我一直认为敏捷是以开发为中心的，如果敏捷宣言尚且是对传统软件开发模式原则上颠覆的话，那么敏捷所带来的N多最佳实践更是以开发过程改进为目标的，信手拈来的就是TDD、CI、XP、PP等诸多实践方式，就是跟测试拉上一点关系的UT和Acceptance Testing也是多由开发者自己来完成，那对专业测试工程师来说，当团队进入到Agile的环境后，会有怎样的不同遭遇呢？在Agile中如何到测试更有效呢？

　　测试在敏捷前后的不同

　　在敏捷环境中，测试可以早介入，从确认客户需求开始，到测试计划、测试案例、测试执行、缺陷跟踪、回归测试，一直到最后软件系统发布，测试会贯穿在整个流程中，这是明显区别于传统的瀑布型模式的。这样的优点毋庸置疑，让测试专家从客户的角度尽早的使用软件，及早发现与需求相悖的问题，尽量减小因设计实现所带来的缺陷问道所招致的维护成本。

　　这样的描述会在所有“敏捷测试”相关的国内外资料中都能看到的，也是为大家所承认的。但具体问题具体分析，在不同的团队构成、不同的软件系统等条件下，所谓“敏捷测试”总不得不去面对一些棘手的问题。

　　测试在敏捷中的困境及对策

　　虽然测试工作的内容无非包括计划、执行、回馈等几个环节，这在进入敏捷环境后也不会有怎样的变化，但面对采用了诸多开发最佳实践的开发者以及会产生快速迭代出新功能的软件系统，测试人员如何保持快速的响应，并实时地调整测试过程，是每个测试团队不得不面临的问题。即使是“敏捷测试”的推广者们，在宣扬了测试早介入之后，也鲜有值得推介的测试实践拿出手来。这对各个测试团队无疑是个考验，即使是采用了相同敏捷实践的开发者也不会表现出一样的生产力，只有测试工程师根据整个团队的特点，总结出一套最适合团队的测试模式，才是最理想的。

　　系统测试

　　不得不说的是，就算是“敏捷测试 ”也没有考虑到系统测试在敏捷环境中怎样做。这对一般不会太看重软件性能和集成性的系统来说不算个大问题，但对具有大大小小系统性能测试需求的测试团队来说，是不可想象的。测试早介入，在系统测试团队看来似乎是场噩梦，对尚未稳定的架构施加系统性能测试，多半会引起系统测试工程师们徒劳无功，因为开发人员这时不会太介意性能上的问题，他们有更重要的功能还没实现，但schedule如此紧张。如果中途需求变化甚至架构变化，开发者几乎可能把设计实现全部推到重来（这也是拜敏捷所赐了）。那之前系统测试工程师花费大量精力和时间，发现的问题很可能就此不可重现不再有效。相对白白付出的工作量，如果这段时间用来做技术调研准备和自动化测试开发，效益不可同日而语。这里需要开发团队和系统测试工程师相互配合，开发为测试定义一些系统测试的进入点，并及时对系统测试的defect作出响应，才是理想的行为。

　　分布式团队

　　敏捷专家推荐开发测试工程师们坐在一起工作，这样交流更加方便直接，减少沟通成本，这在软件快速迭代、快速响应需求变化的过程中是相当重要的。每天有scrum，有defect可以快速交互。但这在分布式团队中很难实现，两支不同时区的团队没有重合的工作时间，开会时间安排成了问题，如何把各自团队自己的scrum结果让另一方也知道呢？除了从分配story方面尽量减少两支团队的story依赖和耦合外，就是需要采用一些特定适合的方式来解决。如果能克服时差，一块scrum是最好的。不行的话，可以通过 scrum mail每天互相交换更新的状态。

　　迭代测试+自动化测试

　　每个迭代都会有一些新的功能被开发出来，如何制定计划既保证这些新功能的测试，又保证新功能或者defect的修复不会导致已有功能遭到破坏呢，这里有一些策略。首先是功能开发的迭代计划，项目经理需要仔细考量不同的story在各个迭代之间减少依赖和耦合，软件架构设计者也需要有同样的考虑，这里有软件可测试性的问题。这样在测试人员介入后，不会发生牵一发而动全身，顾此失彼的问题。

　　另外就是在软件系统随着迭代的不断进行，累加的功能越来越多，测试资源有限，不可能一直全面地测试到软件系统的所有方面。除了前面提到的不同迭代的软件交互很少依赖和耦合外，自动化的测试是保证不断迭代后继续保证软件质量的不可缺少的途径。自动化测试开发，这是另外一个话题，如果认为这全部只是测试工程师的责任，那就是短见和无知了。自动化测试要求软件系统开发者能够在UI上预先提供一些钩子，供自动化测试开发工具抓取UI对象进行识别并操纵，完成模拟用户的实际操作。如果这方面的软件可测性也无法保证的话，测试脚本维护成本居高不下，影响软件质量，除了测试工程师叫苦不迭之外，最终仍然会形成很多defect送到开发者的面前。所以，这是整个团队的责任。

　　缺陷管理

　　软件开始正式的迭代开发后，由持续集成所产生的软件交付成为测试工程师的工作目标，但如果一些功能还没有完全实现就因此产生了defect，测试工程师把它们记录在缺陷跟踪系统里面，越积越多，测试工程师据此为自己的工作量体现，姑且不说这对软件质量没什么意义，在功能实现彻底完成之后，之前的这些 defect中的大多数就会自行解掉设置无效，那么测试人员所做的又是大量的无用功了。需要时刻牢记在心的是，最终目标是软件质量的提升，而不是 defect的数量。测试和开发足量的沟通交流，足以消除掉大多数无谓的defect，只有那些已经完成的功能跟软件需求还相悖的话，才是真实有价值的 defect，值得记录值得跟踪。

　　这里有一篇好文：扔掉Bug 跟踪系统？，深得我心。

　　团队观念

　　说到底，“敏捷测试”需要的是一支紧密协作的团队，开发和测试工程师互相配合，充分沟通交流，为提升软件系统的质量致力工作，不在意无谓的defect数量，减少功能模块间的耦合依赖，提高软件可测试性，合作开发自动化测试脚本。其实根本无需太较真在“敏捷”这个字眼上，更重要的是改进出最适合自己团队的软件开发测试模式。

　　......

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