接口自动化测试用例拆解（接口自动化测试用例设计）

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

本文目录一览：

• 1、接口自动化测试怎么做的
• 2、云南java课程分享接口自动化测试文档架构分析
• 3、关于自动化测试用例失败重试的一些思考
• 4、接口自动化测试工具seldom分享
• 5、我眼中的接口测试和接口自动化测试

接口自动化测试怎么做的

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

云南java课程分享接口自动化测试文档架构分析

自动化测试是互联网软件开发行业发展之后的新的产物，而今天我们就一起来了解一下，关于接口的自动化测试都需要包含哪些内容以及接口测试的文档架构。

接口都有那些部分组成呢?

接口文档应该包含以下内容：

1、接口说明

2、调用url

3、请求方法(get\post)

4、请求参数、参数类型、请求参数说明

5、返回参数说明

如果是测http接口，你需要至少需要调用一个发送http请求的库，例如httpclient来发送不同类型的请求给到待测的接口，如GET,POST,PUT,DELETE，带上你的请求头header和请求体body，然后通过xml库来解析感兴趣的返回值的字段，与期望值做比较，从而判断用例成功还是失败。

接口自动化整体思路

说简单的接口自动化大致三个步骤：a-发送请求;b-解析结果;c-验证结果

为了方便起见，你应该自定义三个和业务相关的测试类：

1.一个用来封装httpclient，用来发送请求的类，云南java课程http://www.kmbdqn.com/建议用于发送各类测试请求。

2.一个解析结果xml的类，用来获取感兴趣的结果值。

3.一个用于比较测试结果和期望值的类，用于验证。

当然这是简单的一个http借口测试框架，如果你愿意还可以做的更强大，比如自动生成测试数据，生成自定义格式的测试报告，自动发送测试报告，检查服务端数据内容是否正确等等。

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

自动化测试用例失败重跑有助于提高自动化用例的稳定性，那我们来看一下，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自动化应该做好显式和隐式等待。

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

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

接口自动化测试工具seldom分享

在编写接口用例的过程中，针对一个接口，往往只是参数不同，那么参数化就非常有必要了。

seldom 中参数化的用法非常灵活，这里仅介绍 @file_data() 的N种玩法。

当参数比较简单时可以试试下面的方式。

当参数很多时，不便于阅读，可以通过字典的方式定义。

我们可以将接口的入参、出参进一步拆分。

虽然不推荐用文件写用例，你想写也是可以的。

最后的这种写法不是seldom推荐的，假如要测试的接口足够简单，设计一个测试方法来处理简单的接口也未尝不可。当然，往往实际项目中的用例并不足够简单。回到代码的方式编写才能足够兼具灵活性和易用性。

我眼中的接口测试和接口自动化测试

接口测试的目的是为了增加测试覆盖度、深入度 ，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是，那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试，前端测试完成就上线了。

如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面？是不是用例设计的时候默认按照正常的取值范围？按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。

自动化测试的主要目的不是发现多少 bug ，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。

整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。

个人觉得如果团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。

以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看？欢迎点击 原文链接 在原帖共同讨论。

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

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