接口测试.docx

接口测试.docx

《接口测试.docx》由会员分享，可在线阅读，更多相关《接口测试.docx（9页珍藏版）》请在冰豆网上搜索。

接口测试

接口测试

1.接口测试的背景

1.1什么是接口测试

接口测试是测试系统组件间接口的一种测试。

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

1.2为什么做接口测试

测试用例设计更有针对性

i.黑盒用例设计——————根据产品需求设计用例

ii.产品需求特点：

a）由产品经理提出，针对功能，一般不关注实现方式，满足需求即可

b）可能出现的一种情况，简单的功能需要较复杂的逻辑才能实现

c）为实现需求，可能需要多个开发人员协作完成

接口用例设计——————根据接口需求设计用例

i.接口需求特点

a）开发为了实现产品的需求，给其它开发提出的需求

b）各子模块各自实现的功能比较清晰明确

c）可能多个接口共同实现一个产品需求

测试人员提前介入

降低成本

首先，随着系统复杂程度的上升，传统的测试方法测试成本急剧增加，测试效率大幅下降（数据模型推算，底层的一个bug能够引发上层的8个左右bug，而且底层的bug很容易引起全网的宕机。

相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。

其次，接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。

最后，接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。

总之接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下

的最佳解决方案，接口测试是一个完整的体系，也包括功能测试、性能测试。

1.3接口测试的适用范围

接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。

接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。

接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。

也就是说接口测试是一个自下而上的发展过程。

接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。

接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力。

平台越复杂，系统越庞大，接口测试的效果越明显。

2.接口测试的目的

接口测试的核心战略在于：

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

核心：

保证系统的稳定

质量管理的目标是保证系统的正确和稳定，接口测试作为软件质量管理的一部分也是保证系统的正确和稳定的，更准确的是保证系统服务端的正确和稳定，一个系统的服务端，越接近底层，对系统的影响就越大，甚至有可能牵一发而动全身，服务端的一个缺陷可能会引起客户端的几个甚至十几个缺陷，更可怕的是服务端的缺陷有可能引起系统的崩溃，这对整个系统来说，损失将是不可估量的，因此服务端接口的质量将直接影响到系统的正确和稳定。

手段：

持续集成

什么是以持续集成为手段，关键在于“持续构建”、“业务”、“集成化”以及“文档体系”，我们需要让被测代码进行持续构建集成，我们需要用业务化的思维去考虑接口定义的合理性，我们需要从性能、安全的角度去思考代码的正确性，我们还需要从集成化的角度去甄别接口间数据传递的正确性，我们更需要确定我们的测试范围，也就是我们测什么、不测什么。

目的：

提高测试效率，提升用户体验，降低产品研发成本

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

首先我们需要以一种更加干净的层面也就是从业务的层面对接口进行隔离测试，同时为了模拟真实场景，也需要在真实的环境中对系统内根据业务流程对各个接口进行串联测试，最后以持续集成系统保证被测代码的稳定性。

再次要充分重视文档的重要性，包括需求文档，开发技术方案，测试技术方案，接口定义文档，测试用例文档等等，完善这些文档可以大大减少软件工程周期中各个团队配合障碍，也可以降低后期软件维护成本。

因此贯彻和落实接口测试的战略可以最大程度地提高软件质量的稳定性。

为其它测试提供帮助

在工作的流程上，各个测试角色是可以互补的，接口测试的设计、用例可以跟功能和性能测试共享，接口测试的报告可以作为功能测试的重要参考，让其了解底层都经历了哪些测试，哪里是bug的密集区，哪里相对安全一些。

在功能测试工程师找到bug之后，接口测试工程师可以用代码直接覆盖这个bug产生的代码，使这个bug永远不会出现第二次。

接口测试人员还可以直接绕过页面，对底层系统进行性能和压力的测试，在测试中各个角色的密切配合，也减少了测试的成本，提供系统全方位的质量保障。

3.接口测试的定位

3.1人员能力定位

熟悉软件测试流程,测试理论和测试方法。

能够根据测试需求，制定测试计划和设

计测试用例。

了解软件工程理论知识和开发流程，有一定的编程能力。

能够根据测试用例，准备测试数据以及编写和执行测试脚本,并对软件bug进行跟踪分析和报告。

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

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

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

3.2职责定义

我们的客户是调用接口的人，不是开发接口的人

对业务的理解要达到开发人员的水平

掌握软件测试的理论知识

要能够独立设计和开发测试，有定位问题的能力

要能搭建系统的测试框架

有权利在质量不达到要求的情况下阻止产品（项目）的发布

3.3工作内容定位

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

4.接口测试的流程

4.1项目工作流程

4.2日常工作流程

规范而统一的工作流程是大家分工合作的基础，只有每一个人都遵循统一的流程，项目才可能统一有序地进行。

因而，规范的工作流程对提高团队的合作能力以及工作效率都有至关重要的作用。

4.3流程步骤详解

接口测试可以分为以下几个步骤：

需求分析和设计评审，测试框架和技术选型，测试计划制定，测试环境搭建，测试用例设计和评审，测试实现和执行，持续集成。

下面，将对每一个步骤作详细说明。

4.3.1需求分析和设计评审

几乎所有软件活动都是以需求分析开始的，接口测试也是如此。

在本阶段我们有两个任务：

一是充分理解需求，并保证所有人对需求的理解一致；二是尽可能找出需求本身所存在的问题。

需求分析之后，紧接着就应该进入系统设计阶段了。

系统设计不应该仅仅只是系统设计师或者开发人员的事情，作为接口测试人员，应该可以从测试的角度为系统的设计提供一些方案或者建议，优化设计的同时提高系统的可测性。

4.3.2测试框架和技术选型

系统设计评审之后，系统实现所需要使用到的技术都应该已经选定。

在这个阶段，接口测试人员就需要根据系统设计来选定自己的测试框架和要使用到的技术。

当然，这并不是必须的，如果你所测试的项目和之前已经测试过的项目技术架构都差不多的话，那么你可以沿用之前的测试框架和技术，或者在这个基础上稍加调整。

如果所测试的项目采用的是一种不同的技术架构，那么你就需要仔细考虑如何选定与之相适应的测试框架和技术。

接口测试框架和技术的选型有很多因素，原则就是选择一个能满足你的测试需要的最好用的框架和技术，并且尽量是你的项目成员都比较熟悉的框架和技术。

没有必要单纯为了提高测试的技术含量而选用功能奇多但却复杂难懂的工具来使用。

4.3.3测试计划制定

接口测试的测试计划制定基本上和功能测试差不多。

这个阶段主要要明确有哪些测试资源，测试资源如何分配，在整个测试过程中需要完成哪些事情，每个时间点应该完成哪些事情，还有最重要的也是很容易被忽略掉的一点就是风险评估。

虽然我们不可能识别出所有的风险，但是我们可以根据经验值来识别出大部分的潜在风险并加以管理。

良好的风险管理是一个软件团队成熟的体现。

4.3.4测试环境搭建

在测试框架和技术选型完成以后就可以开始进行测试环境的搭建了，在接口测试中典型的环境搭建过程可能是这样的：

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

4.3.5测试用例设计和评审

接口测试的测试用例设计是以接口为单位来设计测试，在设计的过程中我们重点关注的是接口有哪些可能的输入参数和预期的输出结果是什么。

当然在需要的时候，也要考虑接口的性能和所期望承受的压力等。

在这个过程中很重要的一点就是为不同的测试划分优先级，这在测试资源不足的情况下将会指导你哪些测试应该优先完成，哪些测试可以延迟完成。

即便是在测试资源很充足的情况下，你也可以按照优先级来完成测试，这样一旦遇到某个风险爆发，那么基本上可以保证，优先级高的工作已经完成了，而不至于惊慌失措。

测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实施的最终方案。

评审最好由以下这些人员共同参与：

需求方、设计人员、开发人员、功能测试人员、接口测试人员以及这些人员的直接主管。

不同的角色会从不同角度对测试设计进行考虑，因此在这个过程中会使测试设计得到极大的完善。

4.3.6测试实现和执行

测试设计一旦产出并通过评审，那么测试实现相对来说就是一件比较简单的事情了。

无非是将一个个测试用例用编程语言实现出来并运行通过。

在测试实现的过程中可能会发现测试设计不够完善，或者是因为需求的变更而导致需要增加新的测试用例。

不管是因为什么原因，在实现测试的过程中，一旦发现有可以完善的地方就应该立刻记录下来，这样可以更有效地保证测试的完备性。

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

4.3.7持续集成

持续集成是接口测试实现全面自动化回归测试的重要技术手段。

简单来说，持续集成就是把写好的测试代码持续不断地运行起来，并且利用版本控制技术，让测试代码测试的始终是最新版本的系统接口。

当接口测试进行到这个阶段的时候，我们的目标就是要让测试代码持续不断的运行，并且保证在运行不通过的时候及时定位并解决问题。

在开发人员维护系统的时候，我们同时也会根据持续集成的结果来维护我们的测试代码。

最后，需要注意的是，虽然以上提及的步骤是我们接口测试人员遵循的规范，但是不同于功能测试等其他测试，接口测试需要与开发同步进行。

4.4质量评估标准

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

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

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

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

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

1）测试用例要覆盖接口的主要业务规则。

接口的主要业务规则，就是该接口的主要功能，它影响着接口的业务实现和调用状态。

2）测试用例要覆盖接口的常用业务规则。

3）参数验证要覆盖对边界值和参数特有业务规则的验证。

很多接口中都会对其参数有一定的限制，如一个字段长度限制为<5，那么就至少要存在对该字段的长度为4，5的测试用例。

测试用例中是否覆盖接口之间的关联性测试。

如：

一个添加接口的关联性测试，就要以该添加接口的返回值为参数，来调用其他关联接口如修改和删除接口，验证其是否可调用并且调用成功。

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

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

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

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

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

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

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

5.接口测试工具-jmeter

5.1Jmeter工具简介

XX百科：

ApacheJMeter是Apache组织开发的基于Java的压力测试工具。

用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。

它可以用于测试静态和动态资源例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库，FTP服务器，等等。

压力测试工具一般都可以用于接口测试，app接口测试只需用到Sampler中的“HTTP请求”。

Jmeter相比LR的优点在于：

开源、安装简单。

5.2接口测试工具原理

调用接口

给接口传递参数调用

接收接口的返回值

与预期返回值比较来校验

6.接口测试用例编写

6.1接口测试用例编写要点

测试每个参数类型不合法的情况

测试每个参数取值范围不合法的情况

测试参数为空的情况

测试参数前后台定义的一致性

测试每个参数的上下限

测试每个参数取值不合理的情况

如果两个请求有严格的先后顺序，需要测试调转顺序的情况

未登录直接下订单和支付的情况