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