破解敏捷测试的十大＂神话＂

　　对于敏捷测试，可定义如下：

　　项目中使用敏捷技术的相关测试实践，开发作为测试的顾客，强调测试先行的设计理念。在敏捷开发中，测试被整合到整个开发的生命周期中。

　　敏捷测试

　　敏捷将被越来越多的人所接受，这很容易理解，如果从开发者和用户的角度去看的话。

　　对于用户，他们不愿意花费大量的时间被人盘问关于整个系统的需求和过程，而且需要评审大量的规格说明，而且开发团队可能会在后期拿着这些规格说明来与他们"对质"。

　　对于开发人员，他们希望发挥自己的想象空间和创意，不愿意遵循规格说明的约束，尤其是在他们看到有更好的解决方案的时候。

　　然而，对于QA人员来说，敏捷意味着什么呢?敏捷会给他们带来诸多不便。在理想的世界里，他们会获取一个"已完成"的产品来针对规格说明进行验证。现实中，他们被要求对"正在移动"的目标进行验证，这是违背直觉的。这意味着一些技术和自动化的使用变得困难，需要新的测试方式。

　　所有敏捷方法都有一个共同点，就是它们对QA角色造成影响。

　　随着TDD(Test Driven Development)的出现，有人开始质疑QA存在的必要性(既然TDD的关键就是测试)。但是，最重要的问题是QA需要直接全程参与到敏捷过程中，作为团队的整体对测试进行设计，与此同时，需要应对需求和解决方案的不断演变。

　　QA需要知道敏捷方法论的真正影响，对业界关于敏捷测试的各种"神话"作出正确的诠释和回应，以下列举了10大著名的"神话"：

　　神话1："你只需要单元测试就行了—TDD的测试是足够的"

　　这显然是不对的。即使是狂热的敏捷开发者也意识到需要包括很多其他的测试技术。例如，Scott W . Ambler就在他的FLOOT(Full Life Cycle Object-Oriented Testing)方法论中列举了21种不同的测试技术，包括白盒测试、黑盒测试、回归测试、压力测试和用户验收测试(User Acceptance Testing)，参见http://www.ambysoft.com/essays/floot.html

　　TDD中的程序员依赖这些测试来验证他们代码的正确性。如果需求(或者说测试用例)没有被正确地描述，那么你可能构建了足够健壮的代码，但是不能满足目标。

　　因此，大部分敏捷项目包括调查性质的测试(黑盒)，用于补充白盒的测试。好的调查性质的测试能尽早揭露开发人员遗漏的问题。

　　神话2："你可以重用单元测试来构建回归测试套件"

　　有些TDD的追捧者提出传统的测试不再需要，因为每一行代码都有相应的单元测试用例了;他们认为，通过重新组合单元测试，可以替代从用户验收测试到回归测试的所有测试类型。

　　虽然这听起来很诱人，但是这不现实，因为：TDD中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。

　　单元测试的总体目标是用于证明代码是如预期般工作的，而回归测试的目的是确保修改的代码不会引起非预期的结果。两者存在的意义是不一样的，例如，"检查某个属性的日期格式是正确的"，就与"对于给定的输入，检查其值具有预期的日期"不一样。

　　神话3："我们不再需要测试人员、或者自动化工具"

　　专业的测试人员履行了不一样的职责，与开发同僚们一样是不可或缺的项目组角色之一。

　　不得不承认：传统的自动化测试工具并没有像厂商们所鼓吹的那样神奇。但是这不意味着我们要放弃自动化工具，我们仍然期待更多更好的自动化工具的出现。

　　神话4："有了单元测试，手工测试就没有存在的必要性了"

　　手工测试时重复性的劳动，代价高、繁琐、容易出错。然而，虽然TDD能减少一定量的手工功能测试，它并不能废除进一步的黑盒测试的需要(无论是手工的还是自动化的)。

　　通过自动化的捕获测试人员的操作过程，并且将他们的键盘和鼠标点击事件文档化，测试人员可以把更多的时间放在有趣的、增值的活动上，例如测试那些自动化很难实现，或者是根本不可能实现的复杂测试场景。虽然通过手工测试寻找bug是一个耗时的、代价高昂的过程，但是如果不采用这种手段而遗漏了BUG，代价会更高。

原文转自：http://www.uml.org.cn/Test/200907026.asp