接口测试简介和项目流程中的应用

1. 接口测试的目地

接口测试的核心战略在于：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。

1.1提高测试效率

提高测试效率，提升用户体验，降低产品研发成本接口测试要为代码的编写保驾护航，增强开发人员和测试人员的自信，让隐含的 BUG提前暴露出来，要让开发人员在第一时间修复 BUG，要让功能测试人员和性能测试人员在测试的时候更加顺手，最大限度得减少底层 BUG 的出现数量，要让产品研发的流程更加敏 捷，要缩短产品的研发周期，最后在产品上线以后，要让用户用得更加顺畅，要让用户感觉产品服务零缺陷。

1.1可持续自动化回归测试

引入可持续的概念，在项目每次迭代发布上线前运行自动化接口。同时在项目重构中也可以避免重复的劳动力手工测试。

 

2. 接口测试的定位

 

2.1人员能力定位

 

• 熟悉软件测试流程,测试理论和测试方法。能够根据测试需求，制定测试计划和设计测试用例。

• 了解软件工程理论知识和开发流程，有一定的编程能力。能够根据测试用例，准备测试数据以及编写和执行测试脚本,并对软件 bug 进行跟踪分析和报告。

• 掌握 JUnit,Spring,Maven,TestNG 等技能，并且能够运用这些技能搭建接口测试框架。

• 思维活跃，善于发现问题，有较强的逻辑分析能力和学习能力。

• 具备良好的表达和沟通能力。

• 工作认真细致，踏实肯干，责任心强。

 

 

2.1工作内容定义

 

下图是接口测试在各个发展阶段的工作内容，在初期阶段以编码和持续集成为主，以后逐渐增加测试方案的设计和系统本身的分析、设计内容，最终为系统的整体质量负责。

 

 

3.接口测试流程

 

 

 

 

 

规范而统一的工作流程是大家分工合作的基础，只有每一个人都遵循统一的流程，项目才可能统一有序地进行。因而，规范的工作流程对提高团队的合作能力以及工作效率都有至关重要的作用。

 

3.1 流程步骤详解

根据以往的实践经验总结，接口测试可以分为以下几个步骤：需求分析和设计评审，测试框架和技术选型，测试计划制定，测试环境搭建，测试用例设计和评审，测试实现和执行， 持续集成。下面，将对每一个步骤作详细说明。

3.2 需求分析和设计评审

几乎所有软件活动都是以需求分析开始的，接口测试也是如此。在本阶段我们有两个任 务：一是充分理解需求，并保证所有人对需求的理解一致；二是尽可能找出需求本身所存在 的问题。

需求分析之后，紧接着就应该进入系统设计阶段了。系统设计不应该仅仅只是系统设计 师或者开发人员的事情，作为接口测试人员，应该可以从测试的角度为系统的设计提供一些 方案或者建议，优化设计的同时提高系统的可测性。

3.3 测试框架和技术选型

系统设计评审之后，系统实现所需要使用到的技术都应该已经选定。在这个阶段，接口 测试人员就需要根据系统设计来选定自己的测试框架和要使用到的技术。当然，这并不是必 须的，如果你所测试的项目和之前已经测试过的项目技术架构都差不多的话，那么你可以沿 用之前的测试框架和技术，或者在这个基础上稍加调整。如果所测试的项目采用的是一种不 同的技术架构，那么你就需要仔细考虑如何选定与之相适应的测试框架和技术。

接口测试框架和技术的选型有很多因素，原则就是选择一个能满足你的测试需要的最好 用的框架和技术，并且尽量是你的项目成员都比较熟悉的框架和技术。没有必要单纯为了提 高测试的技术含量而选用功能奇多但却复杂难懂的工具来使用。

3.4 测试计划制定

接口测试的测试计划制定基本上和功能测试差不多。这个阶段主要要明确有哪些测试资 源，测试资源如何分配，在整个测试过程中需要完成哪些事情，每个时间点应该完成哪些事 情，还有最重要的也是很容易被忽略掉的一点就是风险评估。虽然我们不可能识别出所有的 风险，但是我们可以根据经验值来识别出大部分的潜在风险并加以管理。良好的风险管理是 一个软件团队成熟的体现。

3.5 测试环境搭建

在测试框架和技术选型完成以后就可以开始进行测试环境的搭建了，在接口测试中典型 的环境搭建过程可能是这样的：首先你会为接口测试建立一个基本的工程，并为这个工程设 计一个良好的结构，在这个工程中引入你所选定的测试框架和依赖，为这些框架和依赖编写 好必要的配置文件，将该工程和待测系统的工程以某种形式联系在一起（通常是项目依赖）， 在该环境下能运行通过一个最基本的测试。

3.6 测试用例设计与评审

接口测试的测试用例设计是以接口为单位来设计测试，在设计的过程中我们重点关注的是接口有哪些可能的输入参数和预期的输出结果是什么。当然在需要的时候，也要考虑接口 的性能和所期望承受的压力等。在这个过程中很重要的一点就是为不同的测试划分优先级， 这在测试资源不足的情况下将会指导你哪些测试应该优先完成，哪些测试可以延迟完成。即 便是在测试资源很充足的情况下，你也可以按照优先级来完成测试，这样一旦遇到某个风险 爆发，那么基本上可以保证，优先级高的工作已经完成了，而不至于惊慌失措。

测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实 施的最终方案。评审最好由以下这些人员共同参与：需求方、设计人员、开发人员、功能测 试人员、接口测试人员以及这些人员的直接主管。不同的角色会从不同角度对测试设计进行 考虑，因此在这个过程中会使测试设计得到极大的完善。

3.7 测试实现与执行

测试设计一旦产出并通过评审，那么测试实现相对来说就是一件比较简单的事情了。无 非是将一个个测试用例用编程语言实现出来并运行通过。

在测试实现的过程中可能会发现测试设计不够完善，或者是因为需求的变更而导致需要 增加新的测试用例。不管是因为什么原因，在实现测试的过程中，一旦发现有可以完善的地 方就应该立刻记录下来，这样可以更有效地保证测试的完备性。

在这个过程中我们还应该产出测试报告（包括日报和最终报告），让整个团队都及时掌 握项目的质量情况，以便不同角色正确安排工作。

3.8 持续集成

持续集成是接口测试实现全面自动化回归测试的重要技术手段。简单来说，持续集成就 是把写好的测试代码持续不断地运行起来，并且利用版本控制技术，让测试代码测试的始终 是最新版本的系统接口。

当接口测试进行到这个阶段的时候，我们的目标就是要让测试代码持续不断的运行，并 且保证在运行不通过的时候及时定位并解决问题。在开发人员维护系统的时候，我们同时也 会根据持续集成的结果来维护我们的测试代码。

最后，需要注意的是，虽然以上提及的步骤是我们接口测试人员遵循的规范，但是不同 于功能测试等其他测试，接口测试需要与开发同步进行。如下图所示，在项目启动的时候我 们就要参与进去，在编码结束时测试也基本完成，中间的每个步骤也与开发紧密相关。因此， 我们接口测试的工程师又叫测试开发工程师，我们既需要测试的知识，又必须具有一定的编 码能力。

3.9 质量评估标准

接口覆盖率是否达到要求。

1) 所有供外部调用的接口必须有相对应的测试用例，覆盖率要达到 95%以上。

2) 所有供内部调用并涉及到产品主要功能的接口测试用例覆盖率要达到 90%以上。

3) 所有供内部调用并涉及到次要功能的接口，测试代码覆盖率可以随接口复杂度和重 要程度增高而增加。

测试用例中对接口业务规则的验证是否完整。

1) 测试用例要覆盖接口的主要业务规则。 接口的主要业务规则，就是该接口的主要功能，它影响着接口的业务实现和调用状态。

如发布一个宝贝，那么发布一个全新、二手、拍卖、闲置的宝贝等等就是主要功能。

2) 测试用例要覆盖接口的常用业务规则。 还是发布宝贝的例子，80%的卖家都会在“描述”中加入图片，旺旺链接等。这个业务

规则不会影响接口的正常调用。但却影响着用户的使用习惯。所以测试用例中必须包含对“描 述”字段中含有图片链接，旺旺链接的验证。

3) 参数验证要覆盖对边界值和参数特有业务规则的验证。 很多接口中都会对其参数有一定的限制，如一个字段长度限制为<5，那么就至少要存在

对该字段的长度为 4，5 的测试用例。

 测试用例中是否覆盖接口之间的关联性测试。 如：一个添加接口的关联性测试，就要以该添加接口的返回值为参数，来调用其他关联

接口如修改和删除接口，验证其是否可调用并且调用成功。

遗留的 bug 对系统的影响程度。

1) 经常调用的接口，不可含有主要业务规则和常用业务规则相关的 bug，次要业务规 则的 bug 遗留率为 0.2%以下。

2) 不常调用的接口，不可含有主要业务规则的 bug，常用业务规则的 bug 遗漏率为 2%

以下，次要业务规则的 bug 遗漏率为 5%以下。

测试用例与测试代码是否一致。

测试用例是否可持续回归。

经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设 计说明书所设计的应用。