2.1 测试人员选择
1)熟悉测试方法，能够根据需求制定出测试计划及测试用例
熟悉软件测试流程, 测试理论和测试方法。能够根据测试需求，制定测试计划和设计测试用例。了解软件工程理论知识和开发流程，有一定的编程能力。能够根据测试用例，准备测试数据以及编写和执行测试脚本, 并对软件bug 进行跟踪分析和报告。
2)具备一定的编程能力
掌握java、TestNG、Spring、Maven、Dbunit、Unitils、httpclient、unirest等技能，并且能够运用这些技能搭建接口测试框架。
3)了解数据库知识
进行接口测试时，对业务逻辑中的数据流转的校验是非常重要的，这就需要对数据库知识有一定的了解，能够对数据库进行增删改查的相关操作。
4)有较强的学习能力，能够分析业务逻辑中可能存在的问题
思维活跃，善于发现问题，有较强的逻辑分析能力和学习能力并且需要具备良好的表达和沟通能力，工作认真细致，踏实肯干，责任心强。
2.2 职责定义
1)能够搭建测试框架
2)对系统要深入了解
3)能够对系统可能存在的问题进行预判
4)严格把控产品质量
对于调用接口的人来说，不是开发接口的人对业务的理解要达到开发人员的水平，掌握软件测试的理论知识要能够独立设计和开发测试，有定位问题的能力，要能搭建系统的测试框架，有权利在质量不达到要求的情况下阻止产品（项目）的发布。
2.3 接口测试的具体实现及环境部署
接口测试的脚本实现是建立在测试用例的基础之上的，所以，完善的测试用例是必需的，其中测试用例中，数据准备、数据清理、请求接口的URL、请求方式、参数、请求的头文件等这些因素都是必需的，对于响应的response, 返回的状态码，返回的数据的检查点，都是必须要事先说明好的，用例完善后，我们的脚本在写起来就会效率很高，在脚本中，我们需要保证的一点，就是稳定，因为请求的响应时间也是我们要考虑的方面。
接口测试的脚本必须随着接口本身的改变而改变，为了达到这种效果，建立良好的沟通机制是很有必要的。(文档更新、邮件沟通或查看接口提交LOG都是可行的)。
环境部署是测试人员的基本素质，为了使接口测试的结果的稳定性及正确性，我们的环境必须与生产环境保持一致，且与生产环境保持同步更新。
规范而统一的工作流程是大家分工合作的基础，只有每一个人都遵循统一的流程，项目才可能统一有序地进行。因而，规范的工作流程对提高团队的合作能力以及工作效率都有至关重要的作用。
2.4 流程步骤详解
根据自己以往的实践经验总结，接口测试可以分为以下几个步骤：需求分析和设计评审、测试框架和技术选型、测试计划制定、测试环境搭建、测试用例设计和评审、测试实现和执行、持续集成。下面，将对每一个步骤作详细说明。
2.4.1 需求分析和设计评审
几乎所有软件活动都是以需求分析开始的，接口测试也是如此。在本阶段我们有两个任务：一是充分理解需求，并保证所有人对需求的理解一致；二是尽可能找出需求本身所存在的问题。
需求分析之后，紧接着就应该进入系统设计阶段了。系统设计不应该仅仅只是系统设计师或者开发人员的事情，作为接口测试人员，应该可以从测试的角度为系统的设计提供一些方案或者建议，优化设计的同时提高系统的可测性。
2.4.2 测试框架和技术选型
系统设计评审之后，系统实现所需要使用到的技术都应该已经选定。在这个阶段，接口测试人员就需要根据系统设计来选定自己的测试框架和要使用到的技术。当然，这并不是必须的，如果你所测试的项目和之前已经测试过的项目技术架构都差不多的话，那么你可以沿用之前的测试框架和技术，或者在这个基础上稍加调整。如果所测试的项目采用的是一种不同的技术架构，那么你就需要仔细考虑如何选定与之相适应的测试框架和技术。
接口测试框架和技术的选型有很多因素，原则就是选择一个能满足你的测试需要的最好用的框架和技术，并且尽量使你的项目成员都比较熟悉的框架和技术。没有必要单纯为了提高测试的技术含量而选用功能奇多但却复杂难懂的工具来使用。
接口测试在某种程度上来说，还是属于灰盒测试，测试框架的选择与系统本身的语言并无太大的关系。
如果测试框架与被测试系统的语言一致，有些基础文件可能还可以复用一下；如果不一致，则要重新的构建数据类型，重新的分析业务逻辑，这样对测试系统本身也是有极大的好处的。
测试框架的选择，有一个最重要的点，就是要让大多数的测试人员都能接受的语言，且有大量的资料可以查阅的语言，这样才能快速的搭建框架及后期快速的编写接口测试用例，比如接口测试中JAVA、Python都用的比较多。
2.4.3 测试计划制定
接口测试的测试计划制定基本上和功能测试差不多。这个阶段主要要明确有哪些测试资源，测试资源如何分配，在整个测试过程中需要完成哪些事情，每个时间点应该完成哪些事情，还有最重要的也是很容易被忽略掉的一点就是风险评估。虽然我们不可能识别出所有的风险，但是我们可以根据经验值来识别出大部分的潜在风险并加以管理。良好的风险管理是一个软件团队成熟的体现。
2.4.4 测试环境搭建
在测试框架和技术选型完成以后就可以开始进行测试环境的搭建了，在接口测试中典型的环境搭建过程可能是这样的：首先你会为接口测试建立一个基本的工程，并为这个工程设计一个良好的结构，在这个工程中引入你所选定的测试框架和依赖，为这些框架和依赖编写好必要的配置文件，将该工程和待测系统的工程以某种形式联系在一起（通常是项目依赖） ，在该环境下能运行通过一个最基本的测试。
2.4.5 测试用例设计和评审
接口测试的测试用例设计是以接口为单位来设计测试用例的，在设计的过程中我们重点关注的是接口有哪些可能的输入参数和预期的输出结果是什么。当然在需要的时候，也要考虑接口的性能和所期望承受的压力等。在这个过程中很重要的一点就是为不同的测试划分优先级，这在测试资源不足的情况下将会指导你哪些测试应该优先完成，哪些测试可以延迟完成。即便是在测试资源很充足的情况下，你也可以按照优先级来完成测试，这样一旦遇到某个风险爆发，那么基本上可以保证，优先级高的工作已经完成了，而不至于惊慌失措。
测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实施的最终方案。评审最好由以下这些人员共同参与：需求方、设计人员、开发人员、功能测试人员、接口测试人员以及这些人员的直接主管。不同的角色会从不同角度对测试设计进行考虑，因此在这个过程中会使测试设计得到极大的完善。
2.4.6 测试实现和执行
测试设计一旦产出并通过评审，那么测试实现相对来说就是一件比较简单的事情了。无非是将一个个测试用例用编程语言实现出来并运行通过。
在测试实现的过程中可能会发现测试设计不够完善，或者是因为需求的变更而导致需要增加新的测试用例。不管是因为什么原因，在实现测试的过程中，一旦发现有可以完善的地方就应该立刻记录下来，这样可以更有效地保证测试的完备性。
在这个过程中我们还应该产出测试报告（包括日报和最终报告） ，让整个团队都及时掌握项目的质量情况，以便不同角色正确安排工作。
2.4.7 持续集成
持续集成是接口测试实现全面自动化回归测试的重要技术手段。简单来说，持续集成就是把写好的测试代码持续不断地运行起来，并且利用版本控制技术，让测试代码测试的始终是最新版本的系统接口。
当接口测试进行到这个阶段的时候，我们的目标就是要让测试代码持续不断的运行，并且保证在运行不通过的时候及时定位并解决问题。在开发人员维护系统的时候，我们同时也会根据持续集成的结果来维护我们的测试代码。
最后，需要注意的是，虽然以上提及的步骤是我们接口测试人员遵循的规范，但是不同于功能测试等其他测试，接口测试需要与开发同步进行。在项目启动的时候我们就要参与进去，在编码结束时测试也基本完成，中间的每个步骤也与开发紧密相关。因此，我们接口测试的工程师又叫测试开发工程师，我们既需要测试的知识，又必须具有一定的编码能力。
2.4.8 质量评估标准
接口覆盖率是否达到要求。
1) 所有供外部调用的接口必须有相对应的测试用例，覆盖率要达到95%以上。
2) 所有供内部调用并涉及到产品主要功能的接口测试用例覆盖率要达到90%以上。
3) 所有供内部调用并涉及到次要功能的接口，测试代码覆盖率可以随接口复杂度和重要程度增高而增加。
测试用例中对接口业务规则的验证是否完整。
1) 测试用例要覆盖接口的主要业务规则。
接口的主要业务规则，就是该接口的主要功能，它影响着接口的业务实现和调用状态。如发布一个宝贝，那么发布一个全新、二手、拍卖、闲置的宝贝等等就是主要功能。
2) 测试用例要覆盖接口的常用业务规则。
还是发布宝贝的例子， 80%的卖家都会在“描述”中加入图片，旺旺链接等。这个业务规则不会影响接口的正常调用。但却影响着用户的使用习惯。所以测试用例中必须包含对“描述”字段中含有图片链接，旺旺链接的验证。
3) 参数验证要覆盖对边界值和参数特有业务规则的验证。
很多接口中都会对其参数有一定的限制，如一个字段长度限制为测试用例中是否覆盖接口之间的关联性测试。
如：一个添加接口的关联性测试，就要以该添加接口的返回值为参数，来调用其他关联接口如修改和删除接口，验证其是否可调用并且调用成功。
遗留的bug 对系统的影响程度。
1) 经常调用的接口，不可含有主要业务规则和常用业务规则相关的bug ，次要业务规则的bug 遗留率为0.2% 以下。
2) 不常调用的接口， 不可含有主要业务规则的bug ， 常用业务规则的
bug遗漏率为2%以下，次要业务规则的 bug遗漏率为5%以下。
测试用例与测试代码是否一致。
测试用例是否可持续回归。
经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设计说明书所设计的应用。