我们已经在做单元测试：每个人对“单元测试”都有不同的认识，不过大多数业界专家普遍认为，单元测试应该是测试应用程序的基础组成部分，即代码单元。换句话说，这是API层次上的测试。一些团队声称他们在做单元测试，而实际上他们做的是系统测试，或者是所谓的“开发测试”。还有一些团队做了部分API层次的测试，但他们并没有把单元测试作为开发过程中的必要组成部分。除非团队把持续进行API层次的单元测试作为开发过程中不可缺少的组成部分，否则单元测试必然会随着日程与预算带来压力的提升、政策与项目的发展，以及人员的流动而灭亡。那些极少数长期保持傲人业绩的企业正是把单元测试安排为例行任务的企业。因此，不但要利用自动化测试来保证单元测试尽量全面、顺畅、高效地执行，还要为保证这一质量过程能够长期执行并根据需求而调整来确定基本的工作规范，比如把各个报告中的问题直接指向负责的开发人员，以及让管理人员能够及时方便地看到各开发人员的测试任务分配情况等。自动测试并没多大用处：许多开发人员认为，除非是亲自编写单元测试，否则其一点利用价值都没有。这就大错特错了。由于生成测试的方式与算法的发展，测试工具也变得越来越有效。即使是最基本的自动化方法，也可以在很短时间里生成几千个原来根本无法完成的测试。这可是毫不费力就可以得到的好处。除了可以给你生成测试，甚至“免费”帮你找到一些缺陷，自动测试还能让你集中精力进行那些更重要、更复杂、更全面的测试，那些真正需要专业技术的测试。当前工具所能提供的高层次的自动测试能够显着减少开发团队在这些方面的工作，从而节省大量的时间与精力。如果没有这些工具的帮助，单元测试可能会消耗团队的大量资源，而这正是让许多团队认为单元测试是一种理论上有用但实际却很难实行的测试方法的原因所在。要做的只是购买一个优秀的单元测试工具：单元测试工具并不是可以解决所有问题的王牌。事实上，它只是一个开始。开发人员需要的不仅仅是工具，他们还需要适当的指导、训练、支持设施和工作流程。如果真的希望这个工具能够成为开发过程的一部分，你就得积极主动地学习和使用它，寻找让它能在既定工作环境下发挥作用的办法，并保证这些使用方法都简单易行。目前有许多可以使用的工具，但是除非测试团队真正去使用它——部署、扩展并根据情况进行调整，否则你买到的只是“闲置工具”而已。自动测试达到75%的覆盖率——任务完成：许多人认为，如果自动测试工具能够生成近75%覆盖率的测试，他就能跟老板说自动测试已经完成了。这绝对是个错误的想法。虽然这是一个非常好的开始，但你不能仅仅因为这一点就认为已经做完单元测试。实际上你只是刚刚开始而已，你还需要验证软件的具体功能。自动测试很有用，但必须让这些测试与需求挂钩。为了实现这一点，你可以检验并了解这些工具给你生成的测试，然后利用这些免费“礼物”去实现更多的价值。大多数自动测试工具都会提供一些工具集，使你能够扩展这些自动生成的测试。比如Parasoft Jtest里就有对象库、桩、测试用例参数化和追踪工具Tracer（一个只需在应用程序中运行用例便可以生成功能测试用例的工具）。单元测试不值得费工夫：每个了解单元测试的人都知道，这绝不是一份简单的工作，但这并不意味着不值得在这方面花费工夫。单元测试确实有很高的门槛：测试团队必须了解什么是单元测试、怎样进行单元测试、用它测试什么，以及如何使用工具简化单元测试。如果测试团队真的对单元测试不感兴趣、不了解，甚至根本没有时间开始尝试它，那么他们可能就不会感觉到单元测试的紧迫性。有些团队可能认识到单元测试的重要性，但他们只是被问题缠得团团转，而没有花时间在真正的方向上迈出第一步。归根到底，这需要对单元测试的价值、对质量方面的责任，以及它将为项目争取到的额外时间有一个清楚的认识。
上一篇：如何学会开汽车