下单接口自动化测试（接口自动化怎么测试）

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

本文目录一览：

• 1、关于自动化测试用例失败重试的一些思考
• 2、接口自动化测试流程是什么？
• 3、自动化测试的建设与应用
• 4、python接口自动化-pytest-依赖测试
• 5、使用jmeter做接口验证测试
• 6、接口自动化测试工具有哪些？

关于自动化测试用例失败重试的一些思考

自动化测试用例失败重跑有助于提高自动化用例的稳定性，那我们来看一下，python和java生态里都有哪些具体做法？

如果是在python生态里，用pytest做测试驱动，那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑，具体的使用方式有两种，一种是通过命令行指定pytest --reruns 2 --reruns-delay 1，reruns表示重复运行次数，reruns-delay 表示重复运行是的延迟时间。另一种方式是通过@pytest.mark.flaky(reruns=2, reruns_delay=1)，这种方式一般运用，不想全局所有的测试用例都重跑，只是特定的测试用例需要跑，那就在特定的测试方法上使用这个标记。

如果是在java生态里，用junit做测试驱动，junit5提供了注解@RepeatTest(2)，可以试下测试类或者测试方法的重复运行，也可以自定义，通过实现个TestRule接口，来控制测试用例的运行。

还有就是如果使用到了maven可以添加一个rerunFailingTestsCount参数，不过这个是控制所有的用例了。

为什么要让失败用例重跑呢
因为自动化一般都会在测试环境或者其他非线上的环境，由于环境的不稳定可能会导致测试用例莫名其妙的失败，是用例的稳定性大打折扣。这个时候加入失败重跑机制，能够在一定范围内提高测试用例的稳定性，做出更多的产出。

接口自动化测试用以建议可以加入这种失败重跑，而对于UI接口接口自动化，失败重跑的话，觉得意义不大，因为往往当用例的失败的时候，要么是由于界面元素没加载出来，要么是用例的逻辑有问题，要么是意外的弹窗影响，这个时候应该让错误尽早的抛出来，好尽快的修复，而不是在哪儿一个劲的重试，没啥用。UI自动化应该做好显式和隐式等待。

在测试框架中，最好能区分出什么样的异常时服务异常，什么是测试框架本身的异常，对于服务异常可以适当重试，对于框架异常不进行重跑，直接抛出。断言失败当然更不需要重跑。所以在控制测试用例执行的时候，不要一股脑儿的全都重跑，有选择性的，既要保证稳定性，还要保证效率，让自动化发挥价值。

测试要做到有的放矢，在合适的时候做合适的事情，自动化测试的价值就是因为它能快速的检查系统，如果因为重试导致运行的时间成倍增加，是没有任何意义的，还不如抛出错了，尽快去解决。而且自动化测试用例的运行顺序也要控制，处于业务前方的接口尽量先跑，处于业务后方的接口尽量后跑。比如登陆接口和下单接口，登陆接口属于业务靠前的，下单是靠后的，一般在测试下单接口的时候都要初始化登陆状态，这个时候会调用登陆接口，在测试用例批量执行的时候，可以先让登陆接口测试用例先跑，如果这个接口有问题，那么其他需要登陆接口配合的用例全都会失败，那这样后面的用例就不用跑了，这样会节省很多的时间。

接口自动化测试流程是什么？

了解了接口测试是什么之后，怎么做接口测试呢?接口测试的流程其实和功能测试流程类似：接口测试计划-接口测试用例-接口测试执行-接口测试报告。测试用例设计的依赖对象主要是需求说明书和接口文档。
接口测试因其不是针对普通用户，而是针对的另外一个系统组件，所以不能直接测试，需要使用工具测试，比如服务端http接口测试，常用的工具有jmeter、postman、httpclient等。用工具测试，所以目标就是准备要测试数据测试脚本后直接执行即可， 在进行测试执行编写时，有如下的原则：
1.不同的接口参数覆盖不同的业务场景;
2.在后台构造合适的数据来满足接口的测试用例;
3.根据接口的返回值，断言其是否返回期望结果，并查看数据库验证;
4.测试用例涉及多个步骤的，应对涉及的步骤都验证;
5.删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

自动化测试的建设与应用

一、从UI自动化到接口自动化

1、UI自动化

框架：appium+airtest

模式：PO模式——用来管理维护一组页面元素的对象库

应用场景：

（1）app发版前的核心场景回归测试

（2）多渠道包的回归验证

（3）app大数据埋点自动化测试

2、接口自动化遇到的问题

（1）模式设计？

（2）用例管理？

（3）断言

（4）测试结果展示

（5）不同环境管理

（6）不同场景测试

二、建设

1、框架：Junit5+Rest-assured下单接口自动化测试，采用类似PO的模式下单接口自动化测试，用例和参数分离下单接口自动化测试，数据驱动包装各个场景的下单接口自动化测试，完成各个场景的测试

2、yaml

（1） @ParameterizedTest来实现测试用例的参数化下单接口自动化测试，从数据驱动用例，动态管理用例

（2）创建ObjectModel对象和yaml文件对应起来，读取配置文件生成用例

（3）利用yaml文件管理环境和不同测试场景以及公共参数

3、断言——hamcrest

（1）不同于UI自动化的断言，接口返回数据的断言方式会更加丰富

（2）支持组合断言

（3）支持json schema断言

4、测试报告——Allure

（1）Allure 是一款非常轻量级并且非常灵活的开源测试报告生成框架，支持多种测试框架包括testng、junit5、pytest。

（2）支持@feature@story@step@addAttachment@description多个注释

（3）界面简洁，可延展性强

三、应用场景

1、分销中心的核心需求下单场景通过接口，把下单接口的各个场景管理起来，便于日常需求测试和用例管理

2、接口升级迭代完成后，可以通过接口自动化定时测试，及时发现问题

3、组合各个场景，一次性完成从下单-查询-退款的完成流程，也可以通过用例标签管理不通场景用例

四、后续规划

1、用例场景分类

2、用例优先级

3、断言优化

python接口自动化-pytest-依赖测试

我们在接口自动化过程中，总会存在依赖性较强的场景，比如批价-下单-支付，具备强依赖关系，这个时候就用到了依赖测试。
参考 https://blog.csdn.net/dingding_ting/article/details/117200319

在test_01函数前我们加上了@pytest.mark.dependency()，
在test_02函数前也写了@pytest.mark.dependency(depends=["test_01"])

在类中执行，不能直接写方法名，需要加上类名::方法名或者别名
在test_01函数前我们加上了@pytest.mark.dependency()，
在test_02函数前也写了@pytest.mark.dependency(depends=["类名::test_01"])

(1)class
作用于所属的类，外部类不会被关联
@pytest.mark.dependency(depends=["test_01"],scope="class")

(2)module
默认参数是’module’，作用于当前文件。只会查找当前文件的符合条件的文件名，类里同名的方法不会被依赖。
@pytest.mark.dependency(depends=["test_01"],scope="module")

(3)package
作用于当前目录同级的依赖函数，跨目录无法找到依赖的函数。
例如在dep2目录下，创建了test_dep_01.py和test_dep_02.py
@pytest.mark.dependency(depends=[" xxx.py ::类名::test_01"],scope="package")

(4)session
作用域全局，可跨目录调用。但被依赖的用例必须先执行
@pytest.mark.dependency(depends=["xx/ xx.py ::类名::test_01"],scope="session")
支持直接在类名上方添加，那么类下面所有方法都不执行

比如：依赖用例1满足条件（学员详情列表有数据），再执行用例2（检查学习进度）

比如：依赖用例1满足条件（学习进度100%），再执行用例2（新建完成课程的标签）

使用jmeter做接口验证测试

说明：最近在做老系统的接口自动化，老系统的接口欠缺维护；我一步步梳理清楚业务主流程，然后对主流程接口在jmeter上进行验证（顺便做下单接口的并发，下期讲），接口流程跑通后，就可以直接快速编写接口自动化测试用例啦

涉及知识点：登录、获取token、设置token为全局变量

步骤适合有点基础的同学
首先登录、然后提取登录接口返回参数 [多个参数使用json提取器，使用规则见下图]；
将接口默认设置配置元件中，最后将token设置为全局变量 [ 脚本见下图]

一、Response Assertion（响应断言）

二、Size Assertion（数据包字节大小断言）
判断响应结果是否包含正确数量的byte。可定义（=, !=, , <, =, <=）

三、Duration Assertion（持续时间断言）
判断是否在给定的时间内返回响应结果（ms）

四、beanshell 断言（自由断言）

接口自动化测试工具有哪些？

接口自动化工具有以下：

1、QTP。是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。

2、WinRunner。是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

3、AdventNetQEngine。是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。

自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。

自动化技术广泛用于工业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等方面。采用自动化技术不仅可以把人从繁重的体力劳动、部分脑力劳动以及恶劣、危险的工作环境中解放出来，而且能扩展人的器官功能，极大地提高劳动生产率，增强人类认识世界和改造世界的能力。

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

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