接口测试用例维护成本高（接口测试用例设计案例）

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

本文目录一览：

• 1、接口测试的缺点有哪些？
• 2、接口用例自动化用例区别
• 3、接口自动化测试工具有哪些？
• 4、YApi结合xxl-job自动化测试

接口测试的缺点有哪些？

接口测试用例维护成本高我们进行接口测试接口测试用例维护成本高，一是为了提高测试的力度接口测试用例维护成本高，二也是为了提高后端的回归效率。但是我们在做接口测试的时候接口测试用例维护成本高，一定要认知到它的缺点，真正认识到接口测试的弊端，才能更好地应用接口测试在测试流程中。

首先接口测试的第一个弊端是只能验证预期范围内的问题，接口测试的脚本是由测试人员根据产品需求和后端架构设计而产生的，所设计的所有用例均是接口测试人员所预期到的结果，与前端测试不同，无法测试出一些不可预见的问题。

第二点就是接口测试的维护成本比前端测试用力高很多，正常情况下，测试人员每天所产生的接口测试用力不会超过十个，但是前端测试用例每天可以生产几十到几百条。

接口用例自动化用例区别

jxzdsw
关注
接口测试、UI自动化、手工测试的差异 原创
2019-09-18 16:52:38
9点赞
jxzdsw
码龄14年
关注
接口测试、UI自动化、手工测试在适用性和执行方式上有差异。
接口测试通常以自动化的方式展开。接口自动化用于持续集成。每次代码提交之后都进行测试。接口自动化开发和维护的成本小。而且用例执行速度非常快，结果可靠性高。相比于UI的调整，接口的调整要少很多。所以接口自动化用例通常比较多，接口覆盖率也比较高。一个小时可以测试数千个接口。
UI自动化实现手工测试用例的内容，用于需求规格的覆盖。它比接口测试更充分，因为它模拟了用户对UI的操作。执行速度虽然比接口自动化慢很多，但是可以一天24小时不停的执行。一个小时通常可以测试十几个用例。如果有上千个用例，则需要数天时间来执行。可以多套环境（测试床）并行执行，提高执行速度。UI自动化执行的可靠性比接口自动化低。通常执行平台设置为fail的用例，自动再次执行。如果仍然fail，则需要人工确认。回归时间紧迫时，可以选择只执行高优先级用例。UI自动化实现和维护的成本高，所以通常只对稳定的基础功能做UI自动化，所以UI自动化的案例数目通常远低于接口的。
自动化测试主要用于回归测试。手工测试的重点在新特性、有修改的特性、可能受影响的特性。手工测试主要价值在于其探索性。用于发现缺陷。用来发现哪些情况下会出现故障。这些缺陷，

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

1、CTS，CTS 测试基于Android instrumentation 测试， 其又基于JUnit 测试。说白接口测试用例维护成本高了， CTS 就是一堆单元测试用例。这也是Java 语言的擅长部分。
2、 Monkey工具，Monkey是Android中的一个命令行工具，可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。
3、ASE，ASE 意思为Android 脚本环境， 即我们可以通过脚本（比如Python）调用Android 的功能，从而定制一些测试。比如打电话，发短信，浏览网页，等。我们可以扩充它的API（Java 部分）, 并用python 脚本调用这些API, 从而实现丰富的测试功能。用于API 部分可以访问到Android 全部API, python 又能灵活部署测试，所以ASE 的扩展性非常好。
4、Robotium，该工具用于黑盒的自动化测试。可以在有源码或者只有APK 的情况下对目标应用
进行测试。Robotimu 提供了模仿用户操作行为的API，比如在某个控件上点击，输入Text
等等。 http://mag.big-bit.com/
分层的自动化测试

这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。
相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么接口测试用例维护成本高！我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。
集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。
UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。
为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。
既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。
在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。
至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。

YApi结合xxl-job自动化测试

YApi旨在为开发、产品、测试人员提供更优雅的接口管理服务。可以帮助开发者轻松创建、发布、维护 API，包括提供了一系列可视化接口管理，还有自动化测试

传统的接口自动化测试成本高，大量的项目没有使用自动化测试保证接口的质量，仅仅依靠手动测试，是非常不可靠和容易出错的。

YApi 为了解决这个问题，开发了可视化接口自动化测试功能，只需要配置每个接口的入参和对 RESPONSE 断言，即可实现对接口的自动化测试。而且大部分接口支持Swagger导入或者从Idea配置直接导入。大大提升了接口测试的效率。

使用 YApi 自动化测试，第一步需要做得是创建测试集合和导入接口,点击添加集合创建，创建完成后导入接口(同一个接口可以多次导入)。

编写测试用例主要涉及两个方面，一个是请求参数，另外一个是断言脚本。

请求参数可以填写期望的字符串，YApi 还提供了 Mock 参数和 变量参数。Mock参数用来生成随机字符串，变量参数是为了解决请求参数依赖其他接口的返回数据或参数。

Mock 参数每次请求都会生成随机字符串

YApi 提供了强大的变量参数功能，你可以在测试的时候使用前面接口的 参数 或 返回值 作为 后面接口的参数 ，即使接口之间存在依赖，也可以轻松 一键测试~

格式： $.{key}.{params|body}.{path}

例如：现有两个接口，分别是“导航标题”和“文章列表”

文章列表接口需要传参数: 当前标题(id) ，而这个 id 需要通过 导航标题 的返回值获取，这时应在 文章列表 的参数输入框中根据前者的 key 找到对应 id。 导航标题 的参数和返回值有如下结构：

则 文章列表 的参数可以如下配置：

其中 .269. params** 即表示 key 值为 269 用例的请求参数，$.269. body 即表示 key 值为 269 用例的返回值。

如果 requestBody 是 json 格式也可以在 json 中写变量参数，如下图：

目前 yapi 中的 query ， body , header 和 pathParam 的输入参数已经支持点击选择功能。无需自己填写表达式，只需在弹窗中选择需要展示的表达式即可。 输入选项包括 常量 ， mock数据 ，在测试集合中也支持 变量 选择。具体用法：单击编辑按钮打开表达式生成器，点击需要的数据创建表达式，这里也可以实时查看表达式结果。

编写完请求参数，可通过 js 脚本写断言，实现精准测试，在接口用例页面点击 Test 编辑。

在测试列表可以看到每个测试用例的 key,还有 开始测试、报告等功能

点击开始测试会按照 case 定义的参数从上往下一个一个进行测试，如果顺序有问题，可以拖动调整

测试完成之后，点击报告查看该次请求的结果

参考： https://nodejs.org/dist/latest-v8.x/docs/api/assert.html

开始测试功能是在浏览器跑自动化测试，他依赖于浏览器的使用环境。服务端自动化测试功能是在YApi服务端跑自动化测试，不需要依赖浏览器环境，只需要访问 YApi 提供的 url 链接就能跑自动化测试，非常的简单易用，而且可以集成到 jenkins。

点击服务端测试，出现如下弹窗，用户访问该 url 就可以获取当前测试用例的所有测试结果。

然后可以在xxl-job添加这个脚本的地址，可以选择邮件通知，来进行定时的自动化测试

然后就能看到邮件了~

https://zhuanlan.zhihu.com/p/32202008

https://hellosean1025.github.io/yapi/

https://testerhome.com/topics/20437

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

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