虽然如此，基于API的方法在许多方面存在着优越性，可以在大多数应用中使用，因为应用程序随时间改变的程序非常大，所以花在测试程序维护上的时间比测试程序的创建时间占的比例更大。而且recorded macro方法有一个致命限制：只有在应用代码写完之后你才能建立测试。如果你们的开发习惯是不在程序完成前测试，那非常好。否则，如果你坚持测试先行的习惯，正如作者推荐的，那非常不幸recorded macros不适合你，因为在记录宏进行重放之前，你必须有一个能运行的应用程序。
好的方案可能既有recorded macros测试，又有基于API的程序化测试。通过鼠标拖点式测试你可以让最终用户参与到测试中来，保证你的程序满足业务需求。通过程序化测试则可以在技术角度确保程序组件按预计的情况工作。
使用程序化测试，你有两种选择：功能测试和单元测试。功能测试也叫做黑盒测试，是指在不知道(或者忽略)内部实现的情况下，在一个较高的层次上进行测试。功能测试用于验证程序是否完成业务需求，它模拟采用与最终用户一致的方式与程序进行交互。最终用户可能是使用基于web应用的业务人员，也可能是通过你所提供的API来使用你的类库的开发人员。如果你一定要纠缠概念，功能测试和黑盒测试还是有一些区别的，因为技术上功能测试可以在容器内进行(如果要测得是web程序的话)，但实际上绝大多数功能测试是在黑盒中做，除了公布的接口外你一无所知。相反，单元测试包括底层代码的验证，为了对确保内部组件没有问题，必须了解程序的内部结构。你还需要知道那些类和方法的实现。如果要测的程序是给开发人员使用的软件库，你的单元测试包括所有重要的类和方法，甚至在发布给用户的API文档中没有列出的内容。功能测试与程序交互的方式是通过点击按钮和信息入口，进入程序可见的forms。单元测试与程序的交互是通过Java方法调用来访问。
对前面提到的手工测试的四个缺陷，自动测试都给出了很好的解决：
排除重复。用自动测试你可以把这项工作交给计算机去办，它们将严格按照你每次测试的流程进行操作。
减少错误。计算机每次都用同样的方式执行重复操作。而且，因为测试是cumulative，而且容易调用，即使某一些代码修改在直接影响范围之外很远的地方造成破坏，你仍然能找到这个错误，因为你以前写的检查那些(被破坏的部分)代码的测试会告诉你。自动测试的cumulative是一个非常有用的特点，也是相对手工测试来说一个重要的优点。用手工测试来检查程序的其它部分是不切实际的。
文章来源于领测软件测试网 https://www.ltesting.net/
