第二节 为什么做接口测试
我们为什么要做接口测试呢？
我们现在处于移动互联网时代，接触过移动客户端测试的人都知道，我们的移动端的功能是需要大量的后台服务来支撑。这里说的移动端包括IOS,Android,WP 原生应用以及混合应用。
为什么移动端的应用需要大量的后端服务来支撑呢？
最主要是两个原因，我们的手机计算能力有限，另外移动应用必须省电，因此大量的计算，数据存储，业务处理等活动需要放到服务端由大型服务器来完成。在服务器端完成计算后，通过REST接口来获取到想要的计算接口，然后展示。所以说服务端的接口的测试就尤其重要，随时移动互联网的普及，接口测试会越来越重要。
另外一个需要做接口测试的原因是在互联网时代，软件系统的开发不在遵循传统软件的开发模式，我们需要的是快速上线，快速发布。由于测试在整个软件开发流程的最后阶段，能不能快速上线，快速发布，测试能不能在保证一定质量的前提下快速完成就成为了很重要的一环。
测试的工作量是固定的，要想保证一定的质量，测试的过程大幅缩短的可能是并不高。但是我们知道在移动端产品中，大部分的业务计算是放在服务端的来做的。因此，我们想到了提前测试，也就是不等到客户端开发完成，提前测试服务端接口，也就是我们说的测试前置。
测试前置除了能够节省测试时间之外，还能够节省测试成本，由于接口测试阶段更接近底层，发现底层的问题的直接性更高，难度相对UI测试要低很多。所以节省测试成本，减少测试时间，也是我们做接口测试的一个重要原因。
可能看到这里会有疑问，为什么接口可以被提前测试呢？
这是由接口的开发过程，以及接口的使用方式所决定的。
先说接口的开发过程，开发人员在开发接口的过程中基本是按照一个依赖树的结构来进行的。接口在使用的过程中其实是有依赖的，接口A可能要依赖接口B的输出参数作为输入参数。那么开发在开发过程中，要想能够调试接口A，那就有可能需要先把B接口开发完。以此类推，开发最先开发出来的接口肯定是最基础，最底层，最没有依赖的接口。
再来说使用方式，我们使用接口都是每次调用一个接口，复杂些的情况无非就是输入参数是其他接口的输出参数而已。所以当开发人员开发完成一个接口后，你就可以立即开始测试，而不用等到所有接口都完成才开始测试。
基于上述原因，我们基本可以做到完成接口开发的同时，完成接口的测试工作。

第四节 接口测试的方式
我们怎么测试接口？
从测试策略上来说我们测试接口是基于业务来测试，和从UI端做功能测试是一样的，都是测试功能业务，只不过我们更进一步使用接口来测试。
前面小结也已经提到，接口是对业务处理结果的一种展现。测试实现上来说，REST接口是一个Http请求，所以对接口的测试主要是通过发送http请求，通过对比返回值来测试返回的结果是不是和我们期望的一致。不同的语言用来发送http请求的工具，类库都不太一样。我们这里以java语言为例，可以用来发送http请求的第三方包有httpclient,httpunit等，大家可以自由的选择使用。

第五节 测什么
我们要测试什么呢？
从第四小节，我们已经知道了接口测试的基本方式。其实在我们的具体测试过程中又可以将接口的测试分为两种：单一接口的测试；多接口组合测试。
单一接口功能的测试，主要测试返回的数据结构是否和接口文档给出的一致，接口的正常功能是否完成，接口的参数检查测试，接口的异常测试。
多接口组合测试，实际上是在测试一个业务流程。在测试过程中依次调用多个接口，这些接口相互依赖。这种依赖表现为接口A的输出是接口B的输入或者接口B需要接口A来修改某个状态。总之这样一个业务流程是不可能由单独的接口来完成。像这种多接口组合类的测试，我们说我们的这个测试场景ok，并不是说这个过程中的所有接口都ok就可以的。这个场景的验证点我们还是需要根据业务场景来确定。
对于中间接口的正确性却并不需要验证，因为在做多接口组合的测试之前，我们应该先保证单一接口的功能是ok的。
在测试接口的时候还是要考虑接口的业务特性，比如接口的某个参数可能有多个类型的值，每个值根据业务含义不同可能接口的返回值也是不一样的，遇到这种情况一定要根据业务设计测试点。
另外我们在对比返回值的时候一定要注意，不能只是简单的对比一下返回值了事。现实过程中有些接口的返回可能会简单到只返回一个code，但是这个接口的功能是不是正确却不一定有保证。所以我们一定要知道我们是在做测试，而不是在对比返回值。这就是接口最基本的测试方式，下面的小节我会写下一个相对完整的测试过程，供大家参考。

第六节 接口测试前准备
从项目角度来说，接口测试的第一步是要了解清楚和项目相关的信息。
这里所说的项目信息包括以下几个方面：
l 接口开发人员是谁
l 接口开始开发时间
l 接口结束开发时间
l 测试环境信息
l 数据库相关信息
l 需求文档，接口API文档
除了要获取信息外，还需要和开发人员，产品达成一些共识。这些共识包括：
l 第一次提测接口的时间
l 可测接口的提交频率
l Bug解决方式等
我们来说说这些信息，对我们来说有什么用处。开发人员，项目开始结束时间这些信息从项目角度来说，是必须的。
你需要知道在测试过程中和谁交互沟通，你需要根据项目开始结束时间来安排资源。
测试环境，数据库信息这些是我们接口测试的基础。
需求文档，API文档这是我们接口测试的依据。
第一次提测时间，是我们开始投入资源测试的时间，接口提交频率决定了我们能否在开发完成的同时完成测试。（这里说的同时是指开发在提交最后一批接口时完成了前面所有接口的测试）。
开发提交可测接口的频率过低，会导致测试介入过晚。从而不能完成测试。提测频率过高，有可能会影响开发的效率.

第七节 用例设计方法
我们再从测试的角度来说说在测试开始前应该做哪些事情。我们从文章开始就一直说的是接口测试，而且也说明白了接口测试其实是在做业务的测试。所以接口测试要想做好，有一项工作是基础。我们必须设计测试用例。
设计测试用例的依据对于接口测试来说，主要是根据需求文档和接口API文档。前面第5小节已经说了，我们在测试接口的主旨，其实还是在测试业务。所以我们需要根据需求文档，API接口文档设计多接口组合的场景用例，单接口功能用例，接口结构检查用例。
设计好了用例，那么我们就可以开始用代码实现用例了。具体怎么实现，本文不会涉及。在这主要说说怎么来检查结果。我们的接口返回值也会有两种：
一种是返回值是个常量或者叫固定值。对于这种类型的接口，我们可以采用直接对比字符串的方式来完成结果校验。
另外一种接口也是最常见的接口，接口的返回值是根据数据库中的数据来返回，是不固定的。这种接口在测试时，接口的期望值也就不再是固定的而是要根据数据库的数据来动态生成。
因此我们在测试过程中就必须要写代码来测试接口。

第八节 总结
本篇文章到此结束，到这基本上说了接口测试怎么做。可能很多人关心的是，接口的自动化测试。自动化说简单点其实就是已经做过的事不需要重复做，接口测试想要自动化那就需要我们保存好我们的接口测试用例，并保证能在任何情况下重复使用，这是自动化的基础。