接口测试类型【service层】

逻辑测试

逻辑测试即正常输入的情况下得到正确的结果。

测试方法

等价类

将程序所有有效的和无效的划分成若干个等价类，然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类.
测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。

边界值

要求

Javadoc需包含前提条件、业务逻辑、输入参数、输出值的描述

出错测试

目的是保证数据的安全，及程序在异常情况的逻辑正确

测试方法

空值测试 当传入一个对象参数时，需进行NULL值的参数
参数属性的测试 如输入一个未赋值参数
异常的测试 制造一些异常的测试场景，测试的异常描述是否清晰如：超长、数据格式、异常格式数据

路径测试

单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，保证各种业务场景下数据是安全可操作的。

接口测试Control

服务器接口

第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中

外部接口

有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡，可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到

错误处理

最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认