API测试有什么特殊的地方？
上文说过API的测试变成了被踢来踢去的皮球，游走在单元测试、系统测试之间；游走于白盒测试和黑盒测试之间（另一种归类法）。来看看为什么会这样呢，我们可以从下面Twitter的架构简图说起。
twitter.jpg
从图中我们可以看到几点：
API是分层的，一个读服务（Timeline Service）会通过Redis API读取数据；它又会暴露出API被前端（web，app等）读取。这张图没有关注组件调用的依赖关系，实际情况下，调用层次可能会超过个位数。
如果API是分层的，存在调用关系，测试的时候就要考虑这些调用关系。你需要真实的调用所依赖的API还是需要Mock，这是一个非常有学问的策略，不同的策略会造成测试成本、测试效率、测试有效性数倍的或者数十倍的差距。除了最基础的CURD功能，API会有很多非功能特性，比如图中强调的异步和push/pull策略等；twitter的API肯定还会有负载均衡，数据路由，防黑特性等；目前大部分网络的服务都是基于Http的web服务http的特性需要考虑（get/post、auth、https等等）,建立在http上的各种标准,协议（rest/webservice/xml-rpc/wireless-json等等）、各种数据格式（plain text，xml，json等）总之，采用不同技术实现的API的测试需要关注对应的技术。
设计不易、测试也不简单，你要保证做出来的东西实现了设计意图不是？-
API测试不仅仅要关注单API的业务，还需要关注API是否能够很好的协同工作。很多API的调用是有状态（上下文）的，这也给API测试带来了很大的挑战。设计API组成的测试场景有时候是接口测试的一个很大难题。
如需转载，请注明出处和作者@skytraveler （新浪微博）
