在测试负责人接受到测试任务后，应该按照以下流程规范完成测试工作。

2.1    测试需求分析
产品开发负责人在完成某产品功能的接口文档编写后，在核对无误后下发给对应的接口测试负责人。测试负责人拿到接口文档需要首先做以下两方面的工作。一方面，测试人员要对接口文档中各个接口的功能以及接口中涉及的各个字段的意义和用途进行理解。另一方面，测试人员也应该充分与开发人员交流，理解清楚每个接口用到协议以及各个字段的取值规范和范围。
各测试人员编制完成测试案例后，需要提交给测试组长审核或参加测试组长组织的案例评审会对案例进行评审，案例审核合格后才可开始后续的工作。
因为考虑到敏捷测试时间的紧迫性，需求分析可从开发召开kickoff会（T-7）时开始介入。

2.2    制定测试计划
接口测试负责人与测试组长或者项目经理沟通测试计划安排。单独一个接口文档涉及的接口过多时，由测试组长按照接口功能的相关性以及复杂性划分接口分发给不同的测试人员进行测试，并制定测试时间以及每日测试工作量。

2.3    设计测试案例
接口测试任务划分后，对于接口的测试负责人需依据接口文档，编写接口测试案例，并明确哪些案例可以实现自动化，哪些案例需要手工测试。为后续的编制自动化测试脚本提供指引，保证测试的全面性。案例的设计中需要参考本指南下面章节中提出的接口测试要点。案例需要做到覆盖所有的测试要点，并针对某些特殊的接口，要考虑到接口的特殊性，编制有针对性的测试案例。
测试案例编写完成后，要进行案例评审，评审通过才可执行测试工作。

2.4    测试环境的准备
接口测试所需的自动化工具JMeter安装、java环境配置等由测试人员自己负责完成。接口测试所需的后台环境，若无单独的测试环境，需要在开发环境上测试的情况，环境由对应的开发负责人负责维护，开发负责人需要配合测试人员，保证环境的稳定以及测试版本的正确。若有单独的测试环境，测试环境维护人员需要从开发经理那获取最新的测试版本部署在测试环境上，并维护好初始的参数配置以及初始测试数据。

2.5    实施测试
在前期准备工作完善后，按照计划就可以实施测试了。测试实施上建议优先进行手工测试，把所有接口的案例手工测试一遍，这样一方面可以加强测试人员对接口各个细节的理解，另一方面可以快速发现接口存在的bug，及时反馈给开发人员进行修改。待主要bug开发已经解决，接口各字段配置已经稳定的情况下开展自动化脚本录制、编写等工作，对能够实现自动化测试的案例要编制测试脚本，并按照脚本编写规范，组织好脚本的结构，方便后期的脚本维护和管理。脚本编写规范参考下面的脚本编写规范章节。
在测试阶段根据测试情况、测试出的缺陷情况以及对接口的理解加深，可能会对测试案例进行补充或修改，需要测试人员及时维护好测试案例，保证每个案例的准确，方便后期回归测试。
对各个接口测试完成后，提交测试报告。并对测试相关的文档进行整理总结。

2.6    测试成果评审
该阶段为测试的最后阶段，测试组长负责组织测试成果评审会议。会议上依次对每个测试人员的成果物（包括案例、测试脚本、bug单、测试报告等测试产出物）进行评审。发现问题和不足及时纠正，规范测试工作。评审通过的测试成果物注意汇总保存，形成公司测试资产的一部分。

2.7    测试过程的持续优化

在接口自动化测试进行一段时间后，要定期对测试情况进行总结。对发现的问题进行改进，对测试指南进行完善，对测试的流程进行持续的优化。

接口测试相关文档管理规范

3.1    测试文档范围

接口自动化测试主要需要管理的文档类型如下：
接口说明文档、测试用例文档、测试报告（结果）文档、测试脚本（jmx类型）、会议纪要、评审文档等测试相关文档。

3.2    测试文档创建说明
需求类的文档（如：接口说明文档）在测试初期由开发提供给测试人员，测试人员依据接口文档编写用例，文档不规范的地方需要及时向开发反馈，督促修改提供规范的接口文档。
测试用例文档是在测试人员拿到接口说明文档后，理解好需求即开始编写该文档，后期会经过评审不断的对测试用例文档进行优化。完成测试用例文档编写后，即可开始测试脚本的编制，脚本编制用例的依据来自测试用例文档。
测试脚本是在测试人员执行测试过程中形成的测试产出，要求脚本编写要符合该文档下面对脚本编写的规范要求，这样方便后期的脚本维护和管理。
测试报告文档是测试人员在完成测试后，对该阶段测试结果的一个总结性报告，要求按照公司提供的规范模板编写，并提交给测试组长审核，审核无误后发给对应的产品或项目的开发、业务、领导等相关人员。
会议纪要、评审文档等文档是在整个测试过程中依据项目的需要产生的，这些文档可以划归到需求文档中，用作指导和规范测试人员的测试工作。

3.3    测试文档归档要求
测试任务结束后，测试人员都需要整理各种相关测试文档，上传到SVN服务器相应目录下。形成整个测试组的测试资产。要求每个测试人员重视该环节，测试结束后必须归档各类测试文档。
强烈建议每个地区的测试组有自己的SVN管理目录，测试人员在完成项目或产品的测试中，因为产品或项目都有自己的SVN目录，测试过程中，开发经理也会要求如测试用例、测试报告等测试文档上传到对应项目的SVN上。但测试结束后，测试人员还需把最后的完整的测试相关文档（接口说明文档、测试用例文档、测试报告（结果）文档、测试脚本（jmx类型）、会议纪要、评审文档等）按类型归档到自己测试组下的SVN管理目录，使测试文档受控于测试组的管理，形成测试组自己的资产。
下面举例说明一下北京测试组的测试文档归档要求，其他地方测试组可以进行参考，依据自己项目的情况整理归档测试文档。

接口测试要点

4.1    接口可用性

接口可用性主要测试接口是否可用、接口是否存在、接口的协议类型，测试案例中应包括：
〖R1〗    依据接口文档中给定的接口地址和协议方法能够访问到该接口。
〖R2〗    使用错误的协议方法无法按照接口地址进行访问。
〖R3〗    使用正确的协议方法无法按照错误的接口地址进行访问。

4.2    输入输出参数个数及命名
输入输出参数个数及命名主要测试接口包含的输入输出参数的个数以及各个参数的命名是否正确，测试案例中应包括：
〖R1〗    依据接口文档检查输入参数的个数以及命名是否和文档一致。
〖R2〗    依据接口文档检查输出参数的个数以及命名是否和文档一致（注意检查输出的正常参数和异常参数）。
〖R3〗    输入错误的参数名，接口会报错，并有错误信息返回。

4.3    输入参数的必输项
输入参数的必输项主要测试接口对输入参数的可选与必输的要求，测试案例中应包括：
〖R1〗    按照接口文档对所有必输的输入项依次不输入，检查接口是否给予报错信息返回。
〖R2〗    按照接口文档对所有选输的输入项依次检查是否可以不输入参数接口也有正确数据返回，无报错信息。

4.4    输入参数的合法性
输入参数的合法性的合法性主要对参数的录入规范要求进行检查，测试案例中应包括：
〖R1〗    依据接口文档，有明确的要求的（如：只能由数字组成、在以下几个可选值中选择、只能由字母组成、长度最多为多少、格式为时间格式）输入参数，检查是否符合这些要求。
〖R2〗    依据接口文档，没有明确要求的输入参数，依次测试长度超长、含有特殊字符、全角半角等情况。检查接口是否报错，给予错误返回信息。

4.5    输出参数内容的正确性
输出参数内容的正确性主要对输出参数的内容是否和后台真实数据一致进行检查，测试案例中应包括：
〖R1〗    考虑多种输入参数的组合情况，依次测试在这些组合情况下接口返回的数据的各字段内容是否正确，要具体检查每个字段的内容。一般通过与后台数据库数据比较来进行检查。
〖R2〗    考虑多种输入参数的组合情况，依次测试在这些组合情况下接口返回的数据中涉及输入参数的项，是否和最初输入的值一致。

4.6    接口实现功能验证
接口实现功能验证主要对接口操作的具体功能是否正常运转进行检查，测试案例中应包括：
〖R1〗    输入正确的参数，检查接口对应的要实现的后台功能是否正确运转。例如：对一个启动接口发送启动的命令，接口对应的后台系统能够正确启动并返回正确的参数。
〖R2〗    输入错误的参数，检查接口对应的要实现的后台功能是否没有运转。
4.7    接口文档规范性
接口文档规范性主要对开发提供的接口文档是否规范准确进行检查，测试案例中应包括：
〖R1〗    接口文档中对于输入输出参数都有准确的命名，不存在模糊的情况。
〖R2〗    接口文档对于每一个参数都有明确的类型说明，是否可选还是必输，是否有默认值。
〖R3〗    接口文档对于每一个输入参数都要明确好基本的录入条件，比如长度最长多少、只能为数字还是字母、不能含有特殊字符等。

〖R4〗    针对一个接口如果有多种类型的输出参数组合且参数的命名或个数有不同，这种情况，要在接口文档中罗列清晰，并明确指出出现这种类型的输出参数的条件。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！