软件测试人员对单元测试的五个错误认识[2]

发表于:2010-01-28来源:作者:点击数: 标签:软件测试单元错误认识
软件 测试人员 对单元测试的五个错误认识[2] 软件测试 错误4:自动测试达到75%的覆盖率——任务完成 许多人认为,如果自动 测试工具 能够生成近75%覆盖率的测试,他就能跟老板说自动测试已经完成了。这绝对是个错误的想法。虽然这是一个非常好的开始,但你不

       软件测试人员对单元测试的五个错误认识[2]   软件测试 

   错误4:自动测试达到75%的覆盖率——任务完成

  许多人认为,如果自动测试工具能够生成近75%覆盖率的测试,他就能跟老板说自动测试已经完成了。这绝对是个错误的想法。虽然这是一个非常好的开始,但你不能仅仅因为这一点就认为已经做完单元测试。实际上你只是刚刚开始而已,你还需要验证软件的具体功能。

  自动测试很有用,但必须让这些测试与需求挂钩。为了实现这一点,你可以检验并了解这些工具给你生成的测试,然后利用这些免费“礼物”去实现更多的价值。

  大多数自动测试工具都会提供一些工具集,使你能够扩展这些自动生成的测试。比如Parasoft Jtest里就有对象库、桩、测试用例参数化和追踪工具Tracer(一个只需在应用程序中运行用例便可以生成功能测试用例的工具)。

  错误5:单元测试不值得费工夫

  每个了解单元测试的人都知道,这绝不是一份简单的工作,但这并不意味着不值得在这方面花费工夫。

  单元测试确实有很高的门槛:测试团队必须了解什么是单元测试、怎样进行单元测试、用它测试什么,以及如何使用工具简化单元测试。如果测试团队真的对单元测试不感兴趣、不了解,甚至根本没有时间开始尝试它,那么他们可能就不会感觉到单元测试的紧迫性。有些团队可能认识到单元测试的重要性,但他们只是被问题缠得团团转,而没有花时间在真正的方向上迈出第一步。归根到底,这需要对单元测试的价值、对质量方面的责任,以及它将为项目争取到的额外时间有一个清楚的认识。

  那么,是什么让单元测试的价值超过为此付出的努力呢?单元测试的一个很大优势在于,发现问题的时间越早,在后期遇到的深层错误就越少。这里说的深层错误是指那些并没有形成真正破坏,但它们在API里隐藏得越来越深,直到最后诱发真正问题的错误。这种情况发生的时候,通常很难发现问题的源头。即使你找到源头,也会发现已经有太多的代码层依赖于这个API。

  如果正确地进行单元测试,验证代码能够准确地实现功能,就能更早、更有效地发现问题。如果能及早发现问题,缺陷就不会被带入源代码库中,也就是说以后也无需再对它进行修改——通常这时再修改的困难度、成本与时间都会指数叠加。

  从我的经验来看,那些真正采用单元测试的开发人员最终都能写出更为优秀的代码,工作效率自然也更高。而原因则在于他们不会被各种缺陷绕得团团转,无须一次又一次地重写同一段代码。任何接受了单元测试,并将其作为所有开发项目标准来实践的企业都能显著地提高质量,减少软件开发过程中的缺陷,并最终获得巨大的竞争优势。

原文转自:http://www.ltesting.net