软件测试的调用接口怎么调用，逻辑是什么？

一、什么是接口测试？

接口测试是测试系统组件之间接口的测试。接口主要用于检测外部系统和内部子系统之间的交互点。测试的重点是检查数据交换、传输、控制和管理过程，以及系统之间的相互逻辑依赖。

二、为什么要做接口测试？

在淘宝系统的历史上，功能测试和性能测试最早出现，随后是自动化测试。但是今天，淘宝的架构已经不再是传统的MVC结构，系统正在朝着分布式、以业务为中心、高可用的方向发展。今天的系统架构很复杂，系统之间有很多接口。传统的功能测试、性能测试和自动化测试已经不能满足系统开发的需要，迫切需要一种更加有效、实用和可持续的测试方法。

界面测试就是在这种需求下产生的。首先，随着系统复杂度的不断增加，传统测试方法的测试成本急剧增加，测试效率急剧下降(根据数据模型，一个底层的bug可以造成8个左右的顶层bug，底层的bug很容易导致整个网络的宕机。相反，当系统复杂性增加时，接口测试可以提供低成本、高效率的解决方案。

其次，界面测试不同于传统的单元测试，是从用户的角度对系统界面进行全面、高效、持续的测试。

最后，接口测试是自动化和持续集成的，这就是为什么接口测试可以是低成本、高收益的根源。

总之，接口测试是高复杂度系统质量和低成本经济效益内在要求驱动下的最佳解决方案。接口测试是一个完整的系统，包括功能测试和性能测试。

三、接口测试的流程

根据以往的实践经验，接口测试可以分为以下几个步骤:需求分析与设计评审、测试框架与技术选择、测试计划制定、测试环境构建、测试用例设计与评审、测试实施与执行、持续集成。接下来，将详细描述每个步骤。

1、需求分析和设计评审

几乎所有的软件活动都是从需求分析开始的，接口测试也是如此。在这个阶段，我们有两个任务:第一，充分理解需求，确保所有人对需求有相同的理解；第二，尽量找出需求本身存在的问题。

需求分析结束后，进入系统设计阶段。系统设计不应该仅仅是系统设计者或开发者的事情。作为接口测试人员，应该能够从测试的角度为系统设计提供一些解决方案或建议，优化设计，提高系统的可测试性。

2、测试框架和技术选型

在系统设计审查之后，应该已经选择了实现系统所需的所有技术。在这个阶段，接口测试人员需要根据系统设计选择自己的测试框架和要使用的技术。当然，这不是必须的。如果你正在测试的项目的技术框架和你之前测试过的项目的技术框架相似，可以沿用之前的测试框架和技术，或者在此基础上做一些调整。如果被测试的项目采用了不同的技术架构，那么就需要仔细考虑如何选择合适的测试框架和技术。

界面框架和技术的选择有很多因素。原则是选择最能满足你测试需求的框架和技术，尽量让你的项目成员熟悉。不需要单纯为了提高测试的技术含量而选择功能多但复杂难懂的工具。

3、试验计划的制定

接口测试的测试规划基本类似于功能测试。在这个阶段，需要明确哪些测试资源可用，如何分配测试资源，整个测试过程需要做什么，每个时间点应该做什么，最重要也是最容易被忽视的一点就是风险评估。虽然我们不可能识别所有风险，但我们可以识别大多数潜在风险，并根据经验值进行管理。良好的风险管理是软件团队成熟的体现。

4、测试环境的构建

测试框架和技术选择完成后，就可以开始构建测试环境了。在界面测试中构建环境的典型过程可能如下:首先，您将为界面测试构建一个基础项目，并为该项目设计一个良好的结构。在这个项目中，你将引入你选的测试框架和依赖项，为这些框架和依赖项准备必要的配置文件，并以某种形式(通常是项目依赖)将这个项目与要测试的系统的项目相链接。在这种环境下，能做到运行通过一个最基本的测试。

5、测试用例的设计和评审

接口的测试用例设计是以接口为单元设计测试。在设计过程中，我们重点关注接口可能的输入参数以及预期的输出结果是什么。当然，必要的时候也要考虑界面的表现和预期的压力。在这个过程中，区分不同测试的优先级是非常重要的，这会指导你哪些测试应该先完成，哪些测试在测试资源不足时可以延迟。也就是在测试资源充足的情况下，也可以按照优先级完成测试，这样一旦出现一定的风险，基本上可以保证高优先级的工作已经完成，不会出现恐慌。

测试用例设计完成后，要进行评审，评审的结果要以某种形式记录下来，作为测试实施的最终方案。评估最好由以下人员参加:需求方、设计方、开发方、功能测试方、接口测试方及其直接主管。不同的角色会从不同的角度考虑测试设计，所以测试设计在这个过程中会有很大的提升。

6、测试实施和执行

一旦设计完成并通过评审，测试实现就相对简单了。没有什么意味着一个测试用例是通过编程语言实现和运行的。

在测试实现的过程中，可能会发现测试设计不完善，或者因为需求的变化，需要增加新的测试用例。不管什么原因，在实施测试的过程中，一旦发现有完善的地方，就要立即记录下来，这样才能更有效地保证测试的完整性。

在这个过程中，我们还应该制作测试报告(包括每日报告和最终报告)，让整个团队能够及时掌握项目的质量，让不同的角色能够正确安排工作。

7、持续集成

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

当接口测试进行到这个阶段，我们的目标是让测试代码持续运行，保证当测试代码失败时，能够及时定位并解决问题。当开发人员维护系统时，我们也会根据持续集成的结果来维护我们的测试代码。

最后，需要注意的是，虽然上面提到的步骤是我们的接口测试人员遵循的规范，但与其他测试(如功能测试)不同，接口测试需要与开发同时进行。项目开始的时候我们就应该参与，编码完成的时候测试基本完成。中间的每一步也与开发息息相关。因此，我们的接口测试工程师也被称为测试开发工程师，我们既需要测试知识，也需要编码能力。

8、质量评价标准

接口覆盖率是否符合要求。

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

2)所有内部使用的、涉及产品主要功能的接口测试用例覆盖率应在90%以上。

3)对于所有内部使用的、涉及二级功能的接口，测试代码的覆盖率会随着接口复杂度和重要性的增加而增加。

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

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

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

2)测试用例应该覆盖接口的通用业务规则。或者一个发布宝贝的例子，80%的卖家会添加图片、想要想要的链接等。根据描述。这生意

规则不会影响接口的正常调用。但是会影响用户的使用习惯。因此，测试用例必须在描述字段中包括图片链接和想要的链接的验证。

3)参数验证应涵盖边界值和参数特定业务规则的验证。许多接口对其参数有一定的限制，例如，字段长度限制为。

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

是否覆盖测试用例中接口之间的相关性测试。例如，在添加的接口的关联测试中，其他关联应该以添加的接口的返回值作为参数来调用。

例如，修改和删除接口，并验证它们是否可以被调用和成功调用。

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

1)频繁调用的接口不得包含与主要业务规则和常见业务规则相关的bug，次要业务规则的bug遗留率应在0.2%以下。

2)不经常调用的接口不能包含主要业务规则的bug，常见业务规则的bug漏报率为2%以下，次要的业务规则的bug漏报率在5%以下。

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

测试案例是否可以持续回归。

被测接口是否符合调用者的标准，调用者能否使用该接口开发产品设计规范设计的应用。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

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