接口测试用例管理平台（接口测试用例管理平台怎么用）

本篇文章给大家谈谈接口测试用例管理平台，以及接口测试用例管理平台怎么用对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口测试用例管理平台的知识，其中也会对接口测试用例管理平台怎么用进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、接口测试注意的点
• 2、如何做接口测试？
• 3、接口测试的测试点有哪些

接口测试注意的点

接口测试作为集成测试的一部分，通过直接调用被测试的接口来确定系统在功能性、可靠性、安全性和性能方面是否能达到预期，有些情况是功能测试无法覆盖的，所以接口测试是非常必要的。

接口测试分为两种，一种是webservice接口，走soap协议通过http传输，请求报文和返回报文都是xml格式的，测试时通过工具soapUI进行测试。使用情况比较少；另一种http api接口，走http传输协议，通过路径来区分调用的方法，最常用的是get和post请求。

get请求和post请求的区别在哪里呢？网上的答案为：

1、get请求可以在浏览器中请求到，post请求的测试需要借助工具

2、get请求使用url和cookie传参，post的数据放在body中

3、post比get更安全，因为传递的参数在url上是看不到的

4、get请求的url会有限制，而post请求的数据可以非常大

5、一般get请求是来获取数据，post请求是传递数据的

其实，对于现在飞速发展的 互联网来说，上面的说法已经不严谨了。首先，post请求的参数也可以写在url里，但是这种情况不多见；其次表面上看起来，post利用body传参，比get的url传参安全，但其实只要用抓包工具（fiddler，Charles等），post的参数也是一览无余；再次，现在的浏览器非常强大，可以输入支持很长的URL，所以也不再有限制一说了。这么说来，种种区别只有最后一条是最根本的了。

　怎么来测试接口呢？根据什么来测呢？这就需要开发提供的接口文档了，接口文档和功能测试的需求说明书的功能是一样的。包括：接口说明、调用的url，请求方式（get or post），请求参数、参数类型、请求参数说明，返回结果说明。这里接口文档生成可以使用apipost接口文档生成工具。有了接口文档后，我们就可以设计用例了，一般接口测试的用例分为以下几种：

1、通过性验证，说白了就是传递正确的参数，是否返回正常的结果

2、参数组合，因为参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些限制，所以在设计用例时，就要排列组合这些情况，保证所有情况都能覆盖到

3、接口的安全性，这个又分为几种情况：

1)绕过验证，比如提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包将订单金额一改，如果能以我改后的金额支付，那这个借口就有问题了。

2）绕过身份验证，就是某个功能只有有特殊权限的用户才能操作，那我传递一个普通的用户，是不是也能操作呢

3）参数是否加密，这个关系到一些账户的安全，比如我们在登录一些网站时，它要将我们的登录信息进行加密，如果不加密我们的信息就会暴露，危害性极大。

4) 密码安全规则，设置密码时复杂程度的校验。

4、根据业务逻辑来设计用例

用例设计完了，用什么来测试接口呢？我们可以借助一些工具，比如apipost和jmeter。apipost使用比较简单，可以在列表中选择请求方式，在输入框中输入URL，如果是get请求，直接点击发送就可以看返回结果了。

如果是post请求，会涉及到几种参数的上传方式和添加请求头、权限验证还有添加cookie等操作。apipost都可以简单实现

还有一种测试接口的工具是jmeter，用途比较广泛，不但能测接口的功能，还能对接口进行性能测试。比如：压力测试、负载测试等。在jmeter中需要创建线程组，如图：

Apipost官方链接： https://console.apipost.cn/register?utm_source=10008

如何做接口测试？

接口测试实际工作中一般分为以下两种实现方式：
（1）基于工具实现接口测试接口测试用例管理平台，常见的接口测试工具如Postman、Jmeter等
（2）基于代码实现接口测试，如Python + Requests
黑马程序员的公开课上次把接口测试相关都讲清楚接口测试用例管理平台了。

接口测试的测试点有哪些

接口测试是测试系统组件间接口接口测试用例管理平台的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换接口测试用例管理平台，传递和控制管理过程接口测试用例管理平台，以及系统间的相互逻辑依赖关系等。

测试的策略：

接口测试也是属于功能测试，所以跟接口测试用例管理平台我们以往的功能测试流程并没有太大区别，测试流程依旧是：

评审测试接口文档（需求文档）

根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）

执行测试，查看不同的参数请求，接口的返回的数据是否达到预期

那么设计测试用例时我们主要考虑如下几个方面：

功能测试：

接口的功能是否正确实现了

接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）

兼容性测试： 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式

错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况

返回值测试： 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析

参数边界值、等价类测试

json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code

默认值测试： 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。

逻辑业务：

是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie

业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作

异常测试：

异常分为两类，参数异常和数据异常

参数异常：

关键字参数：将参数写为开发语言中的关键字

参数为空：比如去掉了username参数

多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理

错误参数：比如将username参数写为了user等看是否能返回相应的error code

数据异常：

关键字数据：将参数的值填为开发语言中的关键字

数据为空：将参数的额值填为空

长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证

错误数据：就是将参数的值任意填写，或填写不存在的数值

异常类型测试： 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断

性能测试：

响应时间

吞吐量

并发用户数

占用内存，CPU等

安全性测试：

敏感信息是否加密

必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）

接口是否防恶意请求（SQL注入）

cookie：就是将header中的cookie修改或删除后看是否能返回相应的error code

header：就是删除或修改header中部分参数的值，看是否能返回相应的error code

唯一识别码：删除修改唯一识别码测试

关于接口测试用例管理平台和接口测试用例管理平台怎么用的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口测试用例管理平台的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口测试用例管理平台怎么用、接口测试用例管理平台的信息别忘了在本站进行查找喔。

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