接触接口测试已经有一个月时间了，从最初感觉上手有些艰难，到现在基本能够独立完成脚本，这个过程中自己感觉收获了很多。

　　记得刚开始接触接口测试的时候就产生了一个很浅显的疑问：我们为什么要做接口测试？其实接口测试的必要性不言而喻，接口测试有助于软件项目的后期质量保障，也通过持续回归的方式保证系统的准确可用。

　　众所周知，接口测试首先和业务流程是分不开的，对于业务规则的掌握有助于我们更好地梳理开发代码，并从中获得相关逻辑。在分析完代码后，我们应该在脑海中形成业务主流程，根据思维导向图设计我们的测试用例，并编写相关测试方法。在基于业务和代码的基础上，自己总结了代码覆盖的一些思路和方法：

　　1）正常的业务分支流程：基于这点我们还可以细化成满足规则实现最终目标的业务流，以及因规则过滤而正常中断的业务流。对于实现目标的业务流，我们的思路从了解业务的主流程开始，考虑业务请求顺利到达业务终点的各种情形；而对于中断的业务流，通常是因为不符合业务规则的流程数据导致程序的返回，编写此类用例需要在熟悉业务主流程的基础上特别明确业务规则，阅读代码，形成包含各分支的业务流程图，编写接口用例。

　　2）系统异常流：我们也分为两点来思考这个问题，一类是If(***==null)获取对象为空判断。这类判断出现时，往往是因为系统原因或者条件不满足导致。这类接口数据的准备往往需要我们手工制造空数据来进入分支流程，实现代码覆盖。另一类是try｛…｝catch｛…｝异常处理，系统抛出异常一般无法编写用例进行覆盖catch(  ){…}里的内容。

　　接口测试用例往往还伴随着数据准备，这就要求我们具体关心到业务所涉及的相关表及其字段。在数据准备的过程中，我们也应该注意到一下几点：

　　1）excel表格加载数据。虽然用excel表格准备数据会略为繁琐，但它是有效避免数据冲突的一种好方法，因为在这个数据准备过程中我们需要创建每一个字段，进而思考每一个表字段的意义。对于表字段比较多的数据表，在这里告诉大家一个小技巧，就是我们在用SQL查询数据时，可以点击“导出”导出数据的，这就为我们手动创建表节省了时间，但是对于每个表字段的审阅仍然不能忽视，还需要一提的是，个别数据类型通过数据导出可能会产生乱码。

　　2）较难数据的创建。在准备数据的过程中，一般的数据都是可以通过我们手工输入的，但对于一些特殊的数据，我们却需要通过思考才可以得到，例如加密数据或者唯一数据等，这就需要测试人员考虑更多，掌握一定的方法和技术去解决数据准备的问题。

　　3）避免数据冲突。在相同业务逻辑的测试用例中，我们也许可以直接用update操作同一条数据。而对于不同流程的业务，我们有必要考虑是否该准备新的数据，而不仅是在原有的数据上进行修改。毕竟，业务间所关心的表及字段是不同的，上一类业务逻辑的产生的新数据有可能会对接下来的用例执行造成影响，从而因数据混乱造成用例的失败。

　　4）遗留数据的复用性。通常我们在执行完一条用例后，表中的数据会根据业务逻辑进行处理更新。而对于执行后的数据是否可以再次被利用，是否已经是脏数据都应该纳入我们用例的设计范围，我们的方法一定是可以被多次重复执行的。

　　对于接口测试的熟悉无疑能让测试人员更深层次的理解业务逻辑，但是我们怎样竟可能的保证测试类及方法的完善准确？ TCC和Hudson给予了我们帮助。

　　TCC会根据测试方法的运行实时生成代码覆盖率报告，我们可以参考代码覆盖率去查看到没有覆盖的代码，从而增加缺少的用例。虽然覆盖率是我们需要关注的，但我觉得覆盖率不是唯一的目的，如果仅仅为追求覆盖率，也许一个用例就够了。我们需要的是把业务和覆盖率有机结合起来，必须从业务的角度出发思考自己测试用例及方法的缺陷，把重点放在原因的分析上，把TCC作为编写接口测试的一个辅助工具。

　　Hudson也是持续集成的一种工具。在每日回归的质量报告中，我们都可以看到它的身影。通过它我们需要关心到每个失败用例的原因，这样才发挥了持续集成环境的作用。

　　接口测试的必要性和其带来的好处是无可厚非的。一方面，接口测试具有较强的针对性和目的性。对于我们而言，不仅熟悉了模块之间接口的组装和调用关系，对于以后的功能测试也有很大的启发和帮助。第二，接口测试具较强的重复性。发现问题后，由于接口的透明我们可以较容易定位问题，有效地加快了测试进度。