接口自动化测试实践指导（中）：接口测试场景有哪些

接口自动化测试实践指导（中）：接口测试场景有哪些

在第一篇文章 ​​接口自动化测试实践指导（上）：接口自动化需要做哪些准备工作​​中详细给小伙伴们讲解了一下接口自动化需要做哪些准备工作，准备工作中最后一步接口测试用例设计是非常重要的一个环节，用例设计的好不好，直接关系到我们的测试质量，那如何进行测试用例设计呢，这里呢我结合自身经验，帮助大家梳理一下接口测试用例设计思路，希望对大家后续接口测试工作有所帮助和提升。

1 接口测试场景梳理

1.1 设计思路

在接口测试中，很大程度上，我们的测试质量依赖于接口测试场景的设计，而接口的测试场景和传统的功能测试场景又有所不同，不少测试同学一时无法很好的转换，一上来进行接口测试思路上会比较乱，这里呢给大家梳理一下接口的常用测试场景，并进行了分类，感兴趣的同学建议反复多看几遍，并多思考一下。

注：性能角度和安全角度的实际测试要比功能角度测试复杂的多，本篇重点讲解功能角度测试，后续再写专题文章来详细讲解接口的性能和安全测试如何进行。

1.2 功能角度讲解

接口测试的功能角度划分，依据侧重的角度不同，可以有多种划分方法，目前我实际测试工作中主要使用的测试场景可以划分为五类：基础检查、正常多角度、异常多角度、必录项检查、边界值检查。 大家注意这个顺序安排：基础检查->正常多角度->异常多角度->必录项检查->边界值检查；优先级是依次降低的。实际在进行接口测试时，建议按照这个优先级顺序进行测试用例设计，不一定所有接口的测试都要设计这么全面，需要综合考虑时间成本、接口的重要性等多重因素来决定。 下面分别解说一下功能角度下的每个场景分类，利于大家理解清楚： 1） 基础检查 该角度主要目的是对接口进行通过性验证，通过输入有效入参，检查接口返回正常，可通过返回状态码或关键字段来进行判断。但内容是不是返回正确，不在该角度检查范围内。 2） 正常多角度 该角度主要验证多种有效入参组合，检查接口均能返回符合预期的正确数据。类似于普通的功能测试，从黑盒角度考虑，利用等价类的思想，划分接口各个入参可能的正常场景组合值，并检查接口返回结果的正确性，是否符合我们入参设置的预期结果。 3） 异常多角度 该角度主要验证多种无效入参组合，检查接口均返回符合预期的报错信息。需要注意的是，该角度更多的是考虑业务角度的异常场景，而非针对某个入参的异常数据测试。针对每个入参的异常数据测试将更多的放到边界值检查场景中。 4） 必录项检查 该角度检查比较明确，就是依据接口文档，检查各个必录的入参是否真的被设为了必录项，在场景设计上，需要测试当只录入必录项入参时，接口应该能够返回处理成功的信息，否则要么是文档写的有问题，要么是接口代码逻辑有问题。 5） 边界值检查 该角度主要从入参要素级角度进行检查，针对接口的每个入参进行特殊字符检查、长度边界值检查等。这个角度的检查优先级最低，原因是一般系统前端都会有控制，这种非法的数据一般是无法正常传递给后端，但如果为了接口更好的健壮性，前端虽然进行了控制，但后端接口也加一下校验控制，安全性和健壮性上会更高。当然实际项目中，后端开发人员往往因为这块处理比较费时，往往没有做到太全面的控制，针对这种情况，我们测试可以依据具体系统使用场景，综合评估一下风险，如果有比较大的风险，还是要具体要求开发人员完善一下后台校验。

2 用例设计实战演示

对于接口用例的维护，这里呢推荐两款工具，一款是单兵神器Jmeter，一款是可以免费且非常好用的API接口协作平台Eolink，该平台不仅支持API接口的协作开发，更有丰富的接口测试功能，支持对接口的测试。Eolink对接口的测试用例维护样例如下：

下图为用Jmeter维护的一组对创建应用接口的接口测试用例，后续会以此为例子给大家解说一下上面章节所说的接口测试场景。

说明：上图展示的是对“创建应用接口”编写的测试用例，该接口的用例是完全按照5个场景分类来设计测试用例，并且在设计用例时，按照每个场景分类优先级依次进行用例设计，这样做的好处是整个设计思路比较清晰明了，最大限度避免遗漏某些场景用例编写。

2.1 基础检查类用例展示

说明：该用例入参随机设置一套可使接口返回正常的一套参数即可。

说明：断言的设置也比较简单，检查接口返回某个关键字段即认为成功

2.2 正常多角度用例展示

说明：该用例主要设置检查各种不同构建类型的应用能否创建成功。

2.3 异常多角度用例展示

说明：该用例是来检查当language字段设置了不存在的值，检查接口返回失败（这类错误数据，接口会返回非200错误码）

2.4 必输检查用例展示

说明：该用例是来检查当language字段设置为null后，检查接口返回预期失败信息，失败信息为：“必须为你的应用选择他的开发语言”

​​边界值检查用例展示

说明：该用例是来检查tag字段多种不合法入参，检查接口返回预期失败信息，失败信息为：“项目名称只能包含字母、数字、中划线，且不能以中划线为开头和结尾。长度2-50个字符”

最后，再给小伙伴们介绍一下Eolink在测试用例方面的神奇特性：支持自动生成测试用例的能力。该能力可以智能生成多种场景的测试用例，并实现快速生成各种正常类型，异常类型，边界值，必填值的用例。有兴趣的小伙伴建议去官网详细了解一下：​​客户端（本地）：

服务器测试（在线）：

插件（本地）：

2）一键进行回归/冒烟测试 在以往的协作方式中，测试人员工作总是排在最后进行，无法参与项目讨论，无法进行快速大范围回归测试，甚至无法按时完成测试任务，导致项目延期或带着忐忑上线。在 API研发管理平台 中，由于协作是基于 API 文档进行的，当后端开发人员将 API 文档写好之后，测试人员就可以马上介入，在 API 文档的基础上编写测试用例，让测试工作前移。当 API 开发完成之后，测试人员可以一键将 API 的测试用例全部测完，并且得到详细的测试报告。后端开发只需要看到测试结果就能够知道自己的 API 是否满足测试需求，如果有异常则可针对性改进。想了解更多，可以参见：​​​该平台也提供了丰富详细的测试报告，方便查看和分析测试结果，想了解更多，可以参见：​​​赠送规则：本文三连并分享 进抽奖群：加臻哥福利小助手进群中奖概率会保持在25%以上

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。