如何对一个类中的某个接口进行接口测试？想必大家都会通过以下步骤完成接口测试，

　　1、根据需求 ，写业务相关的接口测试用例

　　2、了解接口参数，写接口参数相关的接口测试用例

　　3、了解代码结构，写主流程或异常流的接口测试用例，保证接口内部所涉及的各个方法都有测试用例覆盖

　　4、执行测试脚本，通过clover插件统计该接口所有涉及的方法的覆盖情况

　　如果通过clover工具统计出的所有方法都是100%覆盖，我们能确保测试是完全的吗？有经验的接口测试人员会说非也，例如有些代码含有if（a==b || c==d） ，只要你有用例符合a==b或者c==d其中的一个条件，这个代码都会被clover统计出已覆盖，这种情况我们常常会通过业务需求结合看开发代码的逻辑设计不同场景的测试用例，确保条件判断的每种情况都有用例覆盖，达到真正的100%覆盖。通过以上的测试方法，确实能提高代码的覆盖率，也能大大的确保产品的质量，可是随着开发技术的提升，如果不了解开发人员设计的思想，仅仅通过看java类中方法的覆盖率是远远不够的，我遇到过一个这样的问题：

　　● 测试需求：更新XXX对象 （起初确认需求时并没有告诉我更新xxx对象时要清缓存中的XXX对象）

　　● 被测接口：更新XXX对象的方法 updateXXX （Object xxx）；

　　● 开发代码实现：开发人员编写更新XXX对象的逻辑时，同时采用了spring aop编程的思想设计清XXX对象缓存的功能，清XXX对象缓存具体实现如下：

　　在配置文件中配置pointcut，表明在处理XXXDAO.updateXXX(ObjectXXX)之后需要调用CleanObjectCacheAspect类中的updateXXX方法。在CleanObjectCacheAspect类中含有对切入点updateXXX方法的清缓存业务逻辑的处理。

　　通过以上配置文件和CleanObjectCacheAspect类的清XXX对象的缓存方法，开发人员实现了更新XXX对象后清缓存中XXX对象的功能。同样别的对象要做类似清缓存的功能时，也可以在此配置文件中通过添加aop配置、在此java类中通过添加业务方法来实现。可以很灵活的处理类似的问题，不用再编写冗余的代码。

　　● 我是如何对这个接口进行测试的呢？ 在起初进行接口测试的时候，通过需求只知道要覆盖更新XXX方法的所有路径和内部涉及到的所有方法，所以在验证测试结果的时候，都是校验数据库中的数据是不是被更新了，是不是和我预期的数据一致，并没有考虑去验证要清缓存中的XXX对象，写完所有的接口测试脚本，统计该接口覆盖率也是100%，所以就提交完成接口测试，让开发部署到daily进行功能测试了。而在daily的测试中被其他人发现该功能存在bug，更新数据库XXX对象的数据是正确的，但未成功删除缓存中的老数据。天哪，需求又与开发的不完全一致，开发在设计功能的时候后面加了清缓存中XXX的需求并且提交了错误的清缓存XXX的代码，这个bug的遗漏，我总结一下，首先是需求不一致，需求的变更未通知到接口测试。其次，为什么接口测试的用例一直在hudson跑并没有发现此问题？而且我通过clover统计的被测接口是100%覆盖？这两个问题让我好好研究了一下开发代码和测试脚本，才发现开发通过spring-aop进行清缓存中的XXX对象，对于updateXXX接口来说并没有直接引用到，是通过在配置文件中进行aop拦截的，所以覆盖率是100%，设计脚本时并不知道要清缓存XXX对象，所以也未对缓存中的XXX对象进行验证，所以hudson中的测试用例可以pass。

　　综上所述 ，接口测试人员在业务能力、代码能力的提高的同时，还要关注系统的架构，这样才能真正做好测试。