接口测试主要考虑的问题:
1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失; -----确定数据完整
2.各个子功能组合起来,能否达到预期要求的父功能; ------集合后，达到需求目标
3.一个模块的功能是否对另一个模块的功能产生不利影响; -----集成后，不影响相关模块功能
4.全局数据结构是否有问题; ------集成后，保证系统数据的正确性
5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 -------集成后，确保误差不影响系统功能及性能
Service层接口测试，大致有三种测试类型：接口逻辑测试、出错测试、路径测试
接口逻辑测试，对开发人员输写的JavaDoc进行测试，后根据JavaDoc来编写测试用例，（一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述），在接口逻辑测试中主要是根据所描述的业务逻辑，进行用例的设计，主要目标是测试在正常输入的情况下能得出正确的结果，测试用例的设计方法跟黑盒测试差不多，主要运用等价类，边界值两种方法。
出错测试，做了接口逻辑测试后，可以正常使用了。为了保证数据的安全，及程序在异常情况的逻辑正确性，因此需要测试出错测试。出错测试主要考虑：空值输入（如当传入一个对象参数时，需进行NULL值的参数）、参数属性的测试（如输入一个未赋值参数）、异常的测试（制造一些异常的测试场景，测试的异常描述是否清晰）
路径测试，经过了上述处理后，单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的。
6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被 测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。