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

发表于:2014-09-01来源:uml.org.cn作者:陈能技点击数: 标签:敏捷测试
项目中使用敏捷技术的相关测试实践,开发作为测试的顾客,强调测试先行的设计理念。在敏捷开发中,测试被整合到整个开发的生命周期中。

  对于敏捷测试,可定义如下:

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

  敏捷测试

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

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

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

  然而,对于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

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)