错误4：自动测试达到75%的覆盖率——任务完成
许多人认为，如果自动测试工具能够生成近75%覆盖率的测试，他就能跟老板说自动测试已经完成了。这绝对是个错误的想法。虽然这是一个非常好的开始，但你不能仅仅因为这一点就认为已经做完单元测试。实际上你只是刚刚开始而已，你还需要验证软件的具体功能。
自动测试很有用，但必须让这些测试与需求挂钩。为了实现这一点，你可以检验并了解这些工具给你生成的测试，然后利用这些免费“礼物”去实现更多的价值。
大多数自动测试工具都会提供一些工具集，使你能够扩展这些自动生成的测试。比如Parasoft Jtest里就有对象库、桩、测试用例参数化和追踪工具Tracer(一个只需在应用程序中运行用例便可以生成功能测试用例的工具)。
错误5：单元测试不值得费工夫
每个了解单元测试的人都知道，这绝不是一份简单的工作，但这并不意味着不值得在这方面花费工夫。
单元测试确实有很高的门槛：测试团队必须了解什么是单元测试、怎样进行单元测试、用它测试什么，以及如何使用工具简化单元测试。如果测试团队真的对单元测试不感兴趣、不了解，甚至根本没有时间开始尝试它，那么他们可能就不会感觉到单元测试的紧迫性。有些团队可能认识到单元测试的重要性，但他们只是被问题缠得团团转，而没有花时间在真正的方向上迈出第一步。归根到底，这需要对单元测试的价值、对质量方面的责任，以及它将为项目争取到的额外时间有一个清楚的认识。
那么，是什么让单元测试的价值超过为此付出的努力呢?单元测试的一个很大优势在于，发现问题的时间越早，在后期遇到的深层错误就越少。这里说的深层错误是指那些并没有形成真正破坏，但它们在API里隐藏得越来越深，直到最后诱发真正问题的错误。这种情况发生的时候，通常很难发现问题的源头。即使你找到源头，也会发现已经有太多的代码层依赖于这个API。
如果正确地进行单元测试，验证代码能够准确地实现功能，就能更早、更有效地发现问题。如果能及早发现问题，缺陷就不会被带入源代码库中，也就是说以后也无需再对它进行修改——通常这时再修改的困难度、成本与时间都会指数叠加。
从我的经验来看，那些真正采用单元测试的开发人员最终都能写出更为优秀的代码，工作效率自然也更高。而原因则在于他们不会被各种缺陷绕得团团转，无须一次又一次地重写同一段代码。任何接受了单元测试，并将其作为所有开发项目标准来实践的企业都能显著地提高质量，减少软件开发过程中的缺陷，并最终获得巨大的竞争优势。
文章来源于领测软件测试网 https://www.ltesting.net/
