首先要说明的是，“对API的测试”和“利用API进行测试”是两个概念；

　　对API的测试是以API为测试目标；那为何要进行对API的测试呢？

　　几个原因：

　　1、产品本身提供了API给外部客户，比如现在很多网站提供了OPEN API，还有很多微软的产品，诸如SharePoint，WSUS，都提供API给用户，这样用户可以做一些定制化，甚至是第二次的开发；

　　这种情况下，对API的测试，除了要测试API本身可以被使用之外（功能测试）；还要经过性能测试，压力测试，兼容性测试，易用性测试；因为API本身是产品； 这个时候相当于对API进行了黑盒测试（不是说对API的测试一定是白盒测试或者灰盒测试），因为你相当于代表外面的客户（或者说是开发人员）对API进行使用；

　　2、产品本身并不提供API给外部客户，但是研发团队分析出对API进行测试有利于产品质量的稳定；或者说有利于提高“工程质量”（Engineering Quality），注意，不是Product Quality，因为测试了API，只能证明工程质量是OK的，API本身并不开放给终用户，终产品可能是桌面的程序，或者Web 程序，或者其他的UI；这些UI的体验还有提供的功能决定了终产品的质量；因为测试的模型像一个金字塔模型，越是底层的东西越容易自动化，规模化；所以通过对API进行测试，可以在回归测试的时候保证regression不会有太大问题；

　　讨论完了对API进行测试之后，再讨论一下利用API进行测试；

　　利用API进行测试，API不是测试的目标；比如说我想测试一个计算器的加法是否正确；通过UI我可以得到加法的结果，然后和期望的值进行比较；但是UI容易变；万一加号的ID变了或者其他因素变了，UI自动化得重写；维护成本相当高；那么如何更好的减少对UI的依赖呢？我可以通过调用产品本身用来计算加法的API，然后得出实际结果，再和期望值进行比较；因为API本身的变动小；所以测试的自动化的改动小；维护成本低；

　　另外一点对API进行测试或者利用API进行测试，不能Assume API是正确的，Dev也不觉得说这个API是正确的；所以我们调用这些API是想拿到实际的值（也是通过UI获得的值，我们姑且认为这2个是一致的，因为有小概率事件，这2者不一定一致，比如实际的UI调用的函数的参数和你所调用的函数的参数可能不一样）；而期望的值是需要我们自己通过别的方式拿到的，不能用API来拿到（除非这个API已经被证明是正确的，比如OS API）

　　总而言之；研发本身是为了提高效果和效率；或者说是ROI；尽量减少对外界的依赖；尽量减少维护的成本，那么通过对API进行测试，或者利用API进行测试是可以从某种程度达到这样的目标。