解析敏捷测试的十大“神话”
对于敏捷测试，可定义如下：
项目中使用敏捷技术的相关测试实践，开发作为测试的顾客，强调 测试先行的设计理念。在敏捷开发中，
测试被整合到整个开发的生命周期中。
敏捷测试
敏捷将被越来越多的人所 接受，这很容易理解，如果从开发者和用户的角度去看的话。
对于用户，他们不愿意花费大量的时间 被人盘问关于整个系统的需求和过程，而且需要评审大量的规格说明，而且开发团队可能会在后期拿着这些规格说明来与他们"对质"。
对于开发人员，他们希望发 挥自己的想象空间和创意，不愿意遵循规格说明的约束，尤其是在他们看到有更好的解决方案的时候。然而，对于QA人员来说，敏捷意味着什么呢？敏捷会给他们带来诸多不 便。在理想的世界里，他们会获取一个"已完成"的产品来针对规格说明进行验证。现实中，他们被要求对"正在移动"的目标进行验证， 这是违背直觉的。这意味着一些技术和自动化的使用变得困难，需要新的测试方式。
所有敏捷方法都有一个共同点，就是它们对QA角色造成影响。
随着TDD（Test Driven Development）的出现，有人开 始质疑QA存在的必要性（既然TDD的关键就是测试）。但是，最重要的问题是QA需要直接全程参与到敏捷过程中，作为团队的整体对测试进行设计，与 此同时，需要应对需求和解决方案的不断演变。
QA需要知道敏捷方法论的真正影响，对业界关于敏捷 测试的各种"神话"作出正确的诠释和回应，以下列举了10大著名的"神话"：
神话1："你只需要单元测试就行了―TDD的测试是足够 的"这显然是不对的。
即使是狂热的敏捷开发者也意识到需要包括很多其他的测试技术。例如，Scott W . Ambler就在他的FLOOT（Full Life Cycle Object-Oriented Testing）方法论中列举了21种不同的测 试技术，包括白盒测试、黑盒测试、回归测试、压力测试和用户验收测试（UserAcceptance Testing）
TDD中的程序员依赖这些测试来验证他们代码的正确性。如果需求（或者说测试用例）没有被正确 地描述 ，那么你可能构建了足够健壮的代码，但是不能满足目标。
因此，大部分敏捷项目包括调查性质 的测试（黑盒），用于补充白盒的测试。好的调查性质的测试能尽早揭露开发人员遗漏的问题。
神话2："你可以重用单元测试来构建回归测试套件 "
有些TDD的追捧者提出传统的测试不再需要，因为每一行代码都有相应的单元测试用例了；他们认为 ，通过重新组合单元测试，可以替代从用户验收测试到回归测试的所有测试类型。
虽然这听起来很诱 人，但是这不现实，因为：TDD中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。
单元测试的总体目标是用于证明代码是如预期般工作的，而回归测试的目的是确保修改的 代码不会引起非预期的结果。两者存在的意义是不一样的，例如，"检查某个属性的日期格式是正确的"，就与"对于给定的输入，检查其值具有预期的日期"不一样。
神话3："我们不再需要测试人员 、或者自动化工具"
专业的测试人员履行了不一样的职责，与开发同僚们一样是不可或缺的项目组角色之一。
不得不承认：传统的自动化测试工具并没有像厂商们所鼓吹的那样神奇。但是这不意味着我们要放弃自动化工具，我们仍然期待更多更好的自动化工具的出现。
神话4："有了单元测试 ，手工测试就没有存在的必要性了"
手工测试时重复性的劳动，代价高、繁琐、容易出错。然而，虽然TDD能减少一定量的手工功能测试，它并不能废除进一步的黑盒测试的需要（无论是手工的还是自动化的）。
通过自动化的捕获测试人 员的操作过程，并且将他们的键盘和鼠标点击事件文档化，测试人员可以把更多的时间放在有趣的、增值的活动上，例如测试那些自动化很难实现，或者是根本不可能实现的复杂测 试场景。虽然通过手工测试寻找bug是一个耗时的、代价高昂的过程，但是如果不采用这种手段而遗漏了 BUG，代价会更高。
神话5："不再需要用户验收测试"
在敏捷开发中，用户验收敏捷测试通常用于与顾客一起解决"不正确的需求"的问题，而不是用于纠正功能问题。当用户最初定义需求时，他们是基于自己的初始想法和愿景来定义的。当他们看到"活生生的" 真正的系统后，他们总是会有不同的、额外的需求。虽然敏捷测试方法可以减少这种情况发生的频率，但是也不可能杜绝，因此也就不可避免地需要用户验收测试。
神话6："自动化是不可能的"
在敏捷项目的早期阶段开展自动化敏捷测试通常是很困难的，但是随着系统的演进，某些方面稳定下来之后就 可以开始实施自动化测试了。洞悉自动化测试开展的正确时机并不容易，因此，使用某些技术， 让早期的手工测试可以顺利过渡到自动化测试是很关键的。如果早期的测试设计和手工测试可以被很好地记录下来，以备重用的话，后面的自动化测试将大大受益。
神话7："开发人员拥有足够的测试技巧"
如果测试是 很容易的，那么每个人都可以做，则每次我们都可以发布和交付优质的代码。一个独立的测试组的目标是作为第三方、能够从全局出发、验证和确认软件功能的质量。而开发人员趋向于证明系统是正常工作的。一个好的测试者会倾向于"假设"某些场景的出现，再加上业务用户的测试，则确保系统满足预期目的将变得容易。虽然可能引起很多开发人员的争辩，但是事实上很多开发人员不愿意花很多时间去先写测试，然后开发代码来证明测试通过了。
神话8："单元测试就是设计规格说明书"
无论你采 用哪一种开发模式，在开发代码之前你都必须对需求进行思考。虽然TDD的单元测试产物可以让我们理解相当一部分的设计规格说明，但是仍然存在差距。定义敏捷测试用例用于检查需求并不是新鲜事。不管你采用的是什么开发模式，最重要的是针对每一项需求提出这样的问题"我将如何测试它？"，这样你的敏捷测试用例是在落实到代码之前就被充分考虑过的，而不 是等待将来的"重构"。
神话9："TDD适用于任何项目"
随着项目规模的扩大，执行敏捷测试所需要的时间也在增加。这可以通过划分项目和测试范围来解决。但是无论如何都会导致测试运行的频率不一致，这样就需要测试的计划和测试执行的管理，因此，除了白盒测试，我们还需要考虑以下几种测试：
集成测试 - "我需要运行哪些测试来确保新的代码与其关联的 代码有效地工作在一起？"
系统测试 - "新的代码在系统层面的功能是够正确，与其他系统工作在一 起的流程是否正确?"
回归测试 - "我需要隔多久运行一次回归测试来确保新的代码没有造成非预期的 影响？"自动化的回归测试为敏捷开发提供了一张安全网。
用户验收测试 - "TDD不仅需要确保某项功能正确地工作了，还 要确保它们对于业务用户来说是可接受的。"
然而，随着项目组的扩大，测试的"自我文档化"（self-documenting）不再可接受，因为参与的项目组成员越多，不同的人对需求的不同理解，项目的风险随之增加。
随着项目规模增加，需要开发的测试代码也大大增加，测试代码的维护工作量也大大增加，对测试自动化的需求也在增加，需要更多的自动化测试用于缩短每个测试周期的时间。
神话 10："开发人员和测试人员是水火不相容的"
长久以来，开发和测试之间存在"你我之分"的紧张局面。这其实会是一种"共生共赢"的健康关系，如果能很好地一起正确地工作的话，这种关系可以为顾客产生更高的产品交付质量。
讨论的焦点应该集中在：
・ 交付的软件需要满足业务目标（满足需求、按时、控制成本），而不是讨论谁拥有哪一部 分流程的权责问题。
・ 测试人员在需求收集阶段可以做出什么贡献？如何让他们更好地融入到TDD的过程中 。
・ 测试人员如何最大化地重用开发过程中产生的各项"资产"？
・ 在TDD中是否有一个"传统测 试人员"的角色？或者他们是否需要像开发人员一样掌握新的技术来适应新的开发模式？
・ 在新的开发和测试工具中，开发人员和测试人员如何互相找到自己需要的东西？
结论