接口测试（第二篇）

Posted 2021-04-24 软件测试分享

今天这篇文章是继前天的接口测试篇来接着讲解的相关接口测试的内容。

3、接口测试的定位

1）接口测试人员能力定位

应该是熟悉软件测试流程，测试理论和测试方法。能够根据测试需求，制定测试计划和设计测试用例。了解软件工程理论知识和开发流程，有一定的编程能力。能够根据测试用例，准备测试数据以及编写和执行测试脚本,并对软件bug进行跟踪分析和报告。掌握 JUnit,Spring,Maven,CruiseControl,DBunit,Unitils,Ibatis 等技能，并且能够运用这些技能搭建接口测试框架。思维活跃，善于发现问题，有较强的逻辑分析能力和学习能力。具备良好的表达和沟通能力。工作认真细致，踏实肯干，责任心强。

2）接口测试的职责定义

通常情况下客户是调用接口的人，而不是开发接口的人，同时对业务的理解要达到开发人员的水平，且掌握软件测试的理论知识也要能够独立设计和进行测试，有定位问题的能力也要能搭建系统的测试框架和有权利在质量不达到要求的情况下阻止产品（项目）的发布。

3）接口测试工作内容定义

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

4、接口测试的流程

1）项目工作流程如下图所示：

2） 接口测试的日常工作流程

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

3）接口测试流程步骤详解

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

几乎所有软件活动都是以需求分析开始的，接口测试也是如此。在本阶段我们有两个任务：一是充分理解需求，并保证所有人对需求的理解一致；二是尽可能找出需求本身所存在的问题。需求分析之后，紧接着就应该进入系统设计阶段了。系统设计不应该仅仅只是系统设计师或者开发人员的事情，作为接口测试人员，应该可以从测试的角度为系统的设计提供一些方案或者建议，优化设计的同时提高系统的可测性。

2）测试框架和技术选型

系统设计评审之后，系统实现所需要使用到的技术都应该已经选定了。在这个阶段，接口测试人员就需要根据系统设计来选定自己的测试框架和要使用到的技术。当然，这并不是必须的，如果你所测试的项目和之前已经测试过的项目技术架构都差不多的话，那么你可以沿用之前的测试框架和技术，或者在这个基础上稍加调整。如果所测试的项目采用的是一种不同的技术架构，那么你就需要仔细考虑如何选定与之相适应的测试框架和技术。接口测试框架和技术的选型有很多因素，原则就是选择一个能满足你的测试需要的最好用的框架和技术，并且尽量是你的项目成员都比较熟悉的框架和技术；没有必要单纯为了提高测试的技术含量而选用功能奇多但却复杂难懂的工具来使用。

3）测试计划制定

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

4）测试环境搭建

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

5）测试用例设计与评审

接口测试的测试用例设计是以接口为单位来设计的，在设计的过程中我们重点关注的是接口有哪些可能的输入参数和预期的输出结果是什么。当然在需要的时候，也要考虑接口的性能和所期望承受的压力等。在这个过程中很重要的一点就是为不同的测试划分优先级，这在测试资源不足的情况下将会指导你哪些测试应该优先完成，哪些测试可以延迟完成。即便是在测试资源很充足的情况下，你也可以按照优先级来完成测试，这样一旦遇到某个风险出现，那么基本上可以保证，优先级高的工作已经完成了，而不至于惊慌失措。测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实施的最终方案。评审最好由以下这些人员共同参与：需求方、设计人员、开发人员、功能测试人员、接口测试人员以及这些人员的直接主管。不同的角色会从不同角度对测试设计进行考虑，因此在这个过程中会使测试设计得到极大的完善。

6） 测试实现和执行

测试设计一旦产出并通过评审，那么测试实现相对来说就是一件比较简单的事情了。无非是将一个个测试用例用编程语言实现出来并运行通过。在测试实现的过程中可能会发现测试设计不够完善，或者是因为需求的变更而导致需要增加新的测试用例。不管是因为什么原因，在实现测试的过程中，一旦发现有可以完善的地方就应该记录下来，这样可以更有效地保证测试的完备性。在这个过程中我们还应该输出测试报告（包括日报和最终完整报告），让整个团队都能及时掌握项目的质量情况，以便不同角色正确安排工作。

7）持续集成

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

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

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

5、接口测试的质量评估标准

（1）接口覆盖率是否达到要求

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

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

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

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

1) 测试用例要覆盖接口的主要业务规则。 接口的主要业务规则，就是该接口的主要功能，它影响着接口的业务实现和调用状态。如在网上发布一个出售的宝贝，那么发布一个全新、二手、拍卖、闲置的宝贝等等就是主要功能。

2) 测试用例要覆盖接口的常用业务规则。 还是网上发布宝贝的例子，80%的卖家都会在“描述”中加入图片，旺旺链接等。这个业务规则不会影响接口的正常调用，但却影响着用户的使用习惯。所以测试用例中必须包含对“描 述”字段中含有图片链接，旺旺链接的验证。

3) 参数验证要覆盖对边界值和参数特有业务规则的验证。 很多接口中都会对其参数有一定的限制，如一个字段长度限制为<5，那么就至少要存在对该字段的长度为 4和5 的测试用例。 测试用例中是否覆盖接口之间的关联性测试。 如：一个添加接口的关联性测试，就要以该添加接口的返回值为参数，来调用其他关联接口如修改和删除接口，验证其是否可调用并且调用成功。

（3）遗留的 bug 对系统的影响程度

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

2) 不常调用的接口，不可含有主要业务规则的 bug，常用业务规则的 bug 遗漏率为 2%以下，次要业务规则的 bug 遗漏率为 5%以下。测试用例与测试代码是否一致。测试用例是否可持续回归。经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设计说明书所设计预期的应用功能。

6、接口测试的方向

在经历了接口测试的发起、稳定、成型以后，我们有必要探讨一下接口测试的发展未来。现实是这是一个十分困难的命题，因为，未来永远是一个谜。任何形式的预测，最终结果常常成为笑料，IT 业界尤其如此。鉴于此，我们需要把更多的目光关注到接口测试的发展方向上，而不是接口测试发展的最终结果的预测上。接口测试框架改进的现状，我们已经形成了完整的接口测试框架。但在不同的项目中，差别仍然很大，没有形成统一的基础架构，从而导致构建接口测试框架的过程比较繁琐，因此，我们可以在以下几个方面进行改进与优化：

1）测试数据管理框架构建与统一；

2）接口测试项目构建基础框架； 

3）mock 框架化； 

4）高比例代码自动生成框架；

5）接口测试工具集成与三方库的本地化应用。 

接口测试之持续集成对于接口测试的技术而言，核心内容是持续集成，即自动化。其实这个内容和其他的测试也是一致的，从本质上来说，自动化代表了未来测试发展的主流方向。目前，我们已经实现了接口测试的持续集成，而更高程度的自动化、更加广泛的自动化是我们未来的发展方向。

更高程度的自动化应包含如下内容：

1）持续集成框架的柔性改进，包括更加丰富的测试结果、更加人性化的结果展现，测试结果邮件推送，而不仅仅是项目构建失败的提醒；

2）持续集成中接口测试项目自动构建与部署。

更加广泛的自动化包含：

1、各种开发语言接口测试持续集成，HUDSON 的研究与应用；

2、 将接口测试应用到更加广泛的项目当中；

3、持续集成框架与测试框架（用例、缺陷）的整合。

接口测试之测试驱动接口测试是白盒测试的一部分。作为接口测试而言，我们不仅需要保证代码的质量、系统的性能，我们还需要保证系统开发过程的正确性与高效性。测试驱动开发是接口测试的一个重要思想。

在接口测试的过程中，我们要力求做到覆盖到更多的代码行，覆盖到更多的逻辑过程， 驱动开发更加准确、高效的实现自己的代码。同时，我们需要对代码进行分析与评审，驱动开发提高代码的质量。

接口定义在系统级架构的过程中，是非常重要的一个环节。接口定义是否合理，需要从更高层面，譬如系统的交互性、系统的易用性、系统的可扩展等方面来考虑。接口测试的职责，需要从这些方面来约束和规范系统的接口定义过程，驱动开发完善设计，避免接口定义的随意性以及接口改动的频繁性。接口的改动对系统的伤害是不言而喻的。因此，从一开始就驱动开发完善接口定义是接口测试的一个重要发展方向。

7、接口测试之未来遐思

我们生活在信息膨胀的时代，IT 行业的发展越来越快，也对测试提出了更高的要求。提出成本更低，效率更高的测试技术、测试框架、测试方法、测试理论，这些是我们未来能适应高速发展的 IT 行业的基本要求。因此，我们提出如下的设想：

1）测试虚拟化：提供接口测试虚拟机，构建测试虚拟化层。将被测系统运行在虚拟机中， 与外部系统剥离，进行内部代码检测、内存检测、数据校验与逻辑检测。

2）测试智能化：智能分析系统代码，智能生成测试代码，智能 mock 外部系统，智能执行测试代码，智能分析测试结果，智能定位缺陷，智能修复缺陷。

End，今天本篇文章是讲解下接口测试的相关内容和发展方向，个人之言，不能代表以后发展。

号外！飞软学院软件测试就业班已经上线啦，想转行的小白们可以好好看下哦（全网性价比最高的课程），详细内容可点击如下链接文章：

如上文章如有用，自己收藏或推荐给需要的同学朋友皆可，后续继续更新这方面的文章（同时也欢迎各位有写作爱好和乐于分享朋友同学来稿，测试题材皆可，也可以是自己做软件测试的心得体会方面的内容）

本篇结束。

/

老潘观点：“学习是一个循序渐进的过程，没有办法速成，每天坚持阅读实践也是一种进步。”

CTE老潘

2018-03-25

老潘后续发布文章

长按二维码/微信扫码  关注：feiruan18

自动化测试群QQ可加：79887633和469830587

有问题，欢迎留言

文章如有用，欢迎转发 、分享 

让更多测试从业者受益 

喜欢请告诉老潘，并推荐给朋友、同学，相识皆有缘