接口自动化测试重要吗（接口自动化怎么测试）

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

本文目录一览：

• 1、接口测试有什么作用？
• 2、「自动化测试」是否有必要做自动化测试？
• 3、在软件测试中，我已经熟练了业务功能测试，还需要学习接口测试吗？
• 4、自动化测试的成本高效果差，那么自动化测试的意义在哪呢？
• 5、ui自动化测试有用吗
• 6、如何有效的开展自动化测试

接口测试有什么作用？

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

接口测试的主要作用是：
(1)能够提早发现 bug，符合质量来控制前移的理念。
(2)接口测自试低百成本高效益，因为接口测试可以自动化并且是持续集成的。
(3)接口测试从用户度的角度对系统接口进问行全面检测。实际项目中，接口测试会覆盖一定程答度的业务逻辑

「自动化测试」是否有必要做自动化测试？

目录

一、前言

二、自动化目的

三、自动化分类

四、自动化实现

一、前言

在一些测试交流群经常会看到有小伙伴在问，"怎么做自动化测试？学习自动化测试有什么资料吗？自动化测试是不是很牛逼？" ，甚至有些言论是"不会自动化的测试人员，真的要被淘汰了吗？"

不得不说一堆流量号主抓住大众心理，点进去的必然是卖课广告，或者是关注微信公众号领取测试资料大礼包。

实话实说，我之前也有同样的疑问，甚至带着担忧。每次又不甘心得领着测试资料大礼包......

当然，随着自己的认知不断扩大，自己的一套测试体系建设不断完善，于是这些担忧逐渐的消失。每项技术引用都要看适用场景，是否适合自己的团队，因地制宜才能发挥其最大的价值。

因此，我想通过这篇文章来分享下我对于自动化测试的理解。

二、自动化目的

自动化工作可以节省很多人工操作成本，减少人工重复性操作，提高整个团队的研发效率。但是如果搭建自动化体系需要耗费很长时间，投入很多人力资源，但是用户只要2-3分钟的手动工作就能解决，而且这个操作并不频繁，又或者需要自动化操作的平台变更迭代非常快并且没有规律，自动化工具在后面类似累活的跟着。那么自动化还是有必要吗？

我之前在的团队，造测试数据特别困难，严重影响了整个研发效率，但是当时也没有一个好的解决办法，后来基础研发组做了一个造数平台，这个平台需要自己去配置各种字段，并且梳理出各个表字段的关联，从头到尾一个一个去构建场景，一不小心就配置错误，看着提示你也找不到原因的那种。这给造数过程中又添了一个拦路虎，给本不充裕的测试时间，又耗时一把。

如果能在做执行任务前评估任务的投入和收益，那么是不是就能更加合理的开展这项任务。那么自动化测试的投入和收益是怎样的呢？

投入：通过测试人员借助脚本或者工具实现自动化，维护自动化平台。

收益：提高测试效率，提升测试人员的成长。

自动化测试真的提高测试效率吗？真的可以提升测试人员的成长吗？针对后者，我认为是有的。接下来我们就来聊聊自动化测试是否提高测试效率。

三、自动化分类

自动化一般分为接口自动化和UI自动化，其中UI自动化又分为Web UI自动化和App UI自动化，按照我的理解还应加上部署自动化。

接下来我将针对这四种自动化的场景做一个介绍。因为我对于UI自动化不是很熟悉，我认为投入产出比不是很高，主要还是因为我没咋接触过，所以后面仅做简单介绍，重点讲解接口自动化和部署自动化。

四、自动化实现

4.1、接口自动化

接口

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递过程，以及系统间的相互逻辑依赖关系等。

流程

填写接口，入参，对出参进行断言，每天定时构建，输出测试报告。

入参覆盖范围：必选，可选，有/无/null，类型，数值大小/数值范围，特殊字符；

出参：json，data；

接口关联：接口之间的依赖，数据传递；

断言：对响应做核验，可以对状态码或者msg做校验。

优点

接口测试可以做到更多的覆盖场景；

接口测试可以更快的发现服务端问题；

接口测试相对容易实现自动化持续集成；

接口测试相对于比单元测试比较贴近业务场景；

技术选型

1、MeterSphere

MeterSphere 是一站式测试平台，涵盖测试跟踪、接口测试、性能测试、 团队协作等功能，全面兼容 JMeter、Postman、Swagger 等开源、主流标准。

MeterSphere是一个功能交全的平台，并且是开源的，对于免费版就足够小团队使用了，使用门槛相对来说较低，对于技术能力要求不高，所以是一个不错的选择。MeterShpre使用的技术栈是SpringBoot+vue，以及一些中间件，也可以在此基础上进行二次开发。

2、Python

通过Python来做接口自动化的话，常用组件有：执行库Requests，断言库unittest，测试报告HTMLTestRunner，通过持续集成Jenkins做定时构建。

框架思想：封装，数据驱动。

使用Python的话则需要掌握一定的代码能力，当然这个对个人技能的提升是很有帮助的，但是如果在时间比较紧迫的并且没有足够的技术功底情况下，还是比较推荐MeterSphere的。

4.2、部署自动化

部署

部署就是将源代码编译成可运行软件包，比如jar包或者war包，并且将软件包放到目标环境，将软件包运行起来，并且能够被客户端调用。

流程

通过远程仓库拉取代码，前端编译，后端编译，下发软件包到目标机器，重启服务，启动失败则告警。

优点

相比传统手工部署，速度更快，不容易出错，提高交付效率。

技术选型

gitlab或者gitee：代码托管

git：版本管理

node：前端编译

maven：后端编译

ansible：下发文件

shell：重启服务

pipeline：流水线构建

Jenkins：CICD大总管，将以上工具整合起来，提供页面供用户操作部署流程。

4.3、Web UI自动化

UI自动化

通过页面元素定位定位到元素，模拟用户的操作行为，点击，输入，拖拽等。

流程

定位元素，模拟用户操作，发送测试报告。

优点

适用于回归主流程，并且变更不频繁的场景。可用于重复性的功能测试及验证。我之前在的团队做过一段Web UI自动化，但是因为需求频繁变更，并且精力有限，维护这个平台的成本较高，后面就没有持续维护了。

技术选型

Python，selenium。

4.4、App UI自动化

UI自动化

通过页面元素定位定位到元素，模拟用户的操作行为，点击，输入，拖拽等。

流程

定位元素，模拟用户操作，发送测试报告。

优点

适用于回归主流程，并且变更不频繁的场景。

技术选型

Appinum。

结论：我认为接口自动化和部署自动化是能够带来收益的，是真实能够提高效率的，并且也能够给测试人员的带来成长。

关注【嘎嘎软件测试】

搞测试，不迷路

呱呱大王本呱带你飞！

嘎嘎软件测试 分享个人成长、团队管理、软件测试技能知识等内容，做到有思想、有观点、有深度，欢迎订阅。

在软件测试中，我已经熟练了业务功能测试，还需要学习接口测试吗？

很高兴回答你的问题。

先说结论，是否要学习接口测试，我觉得是需要的。

首先来说，单纯的功能测试是很好做的，基本上就是对着软件点来点去，但如果仅是如此的话，那薪资是最低的。除非你比较满足于当前薪资水平，否则还是多学习点吧。然后，可能不但要学习接口自动化测试，最好是学习性能测试。一般人很少有机会接触性能测试，所以性能测试的薪资很高，但同样的性能测试要掌握的东西也是特别多的。另外，当前很流行的测试开发，也就是说测试也要会开发，这种是当前比较吃香的，但同样的要想做测试开发，其实还需要学习编程语言。不过学好了，10几，20k也没什么问题，我周围这样的同事大有人在的。

最后，我的建议就是能多学点就多学点，毕竟大家肯定都是想高薪的么，但想高薪，就要多付出。

自动化测试的成本高效果差，那么自动化测试的意义在哪呢？

本文章出自【码同学软件测试】

码同学公众号：自动化软件测试

码同学抖音号：小码哥聊软件测试

01 关于问题本身

我觉得这个问题带有很强的误导性，是典型的逻辑陷阱之一。 “自动化测试的成本高效果差”是真的吗？ 当然不是。而且我始终相信，回答问题的最好方式是把问题本身弄清楚。也就是问关于问题的问题。楼主也学可以进一步 说明下面几个问题，有助于自己理解自己的问题，更有助于问题得到准确的回答：

请定义“自动化测试”的范畴。 自动化测试简单来讲，包括用例的撰写，代码的实现，环境的搭建，用例的执行，报表的生成，结果的分析，缺陷报告等等 。每个项目自动化程度不一样，测试人员对自动化的理解有偏差，实际实行自动化的范畴差别很大

请定义“成本“包括哪些

请定义什么是“高”。 高是相对的。比较对象可以是另外的项目或者项目组，也可以是他人的期望

请定义什么是“效果”
请定义什么是“差”。 差也是相对的，可以是同手工测试比较，也可以是同老板的期望比较

如果楼主仔细思考并且回答了以上的问题，我有七成的把握楼主要么不想问这个问题，要么想换个问题。

换一种问法

好吧，为了避免灌水嫌疑，我且以最大的善意揣摩楼主的意图。楼主是想问：

如果有的项目的自动化测试，我们发现成本高于预期，效果不符合预期，那么问题可能出在哪里？怎么判断自动化测试是否有效？

02 这里是正文开始

关于错误的预期

我一点都不奇怪有人会告诉我说：

我都不知道我或者我的老板对自动化测试有什么预期，没人跟我说过。

或者：
自动化不就是不用手工测试了吗？用例用代码实现都能自己跑，测试人员就可以去干别的了，可以少招几个不产生价值的测试攻城狮了。老板就是这样计划的。

这是两种非常典型的关于自动化测试的预期问题：

每个人对自动化测试理解都不一样，每个项目组做自动化的方式都不一样。我讲个故事，是我认识之前一个印度自动化项目的真实例子。这个项目95%以上的测试场景都是比较复杂的UI测试（Web +Windows Application）他们的自动化是这样做的：

你觉得这个自动化做的怎么样？我当时的感觉是几乎要吐血了，因为这个项目是我要接手的。更加吐血的还在后面，这个部门的QA的VP对自动化测试的效果很不满意（绝对的），他的设想包括：

免费领取 码同学软件测试 课程笔记+超多学习资料+完整视频+最新面试题，可以 转发文章 + 私信「码同学666」获取资料哦

这个就是一个典型的 不懂自动化的团队+期望脱离现实的老板 。

关于什么是自动化

James Bach 曾经在一篇博文提到，自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了，就像一个自动的咖啡机一样，我只需要把杯子放在那里，按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思，就是 好的测试用例是没有办法100%被自动化的 ，测试人员的经验，逻辑判断和 探索 性的测试方法都不能被有效自动化。

我非常同意这个观点。作为这个论断的补充和扩展，自动化应该是审视软件研发活动的每一个环节，去发现那些可以被工具化自动化的重复性活动，然后去实现。广义的自动化应该包括但不限于以下环节：

一个过于简化的公式可以这样写：

自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

或者如果假设迭代次数和维护次数近视相等，这个在某些情况下可以成立，比如一个比较新的产品：

自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本

解读：

自动化的收益与迭代次数成正比
自动化收益可能为负数：即当自动化成本和维护成本比手动执行成本还高时

很多时候自动化成本并不比手动成本高，但是维护成本很高

为什么强调过于简化，因为这里的自动化收益仅仅考虑时间和资源成本的节省。 好的自动化带来的迭代周期的缩短，是可以缩短项目周期 ，在某些时候能变不能做为能做，进而带来的机会收益是巨大的，也是很难量化的。这个就要求决策者对软件工程和自动化有比较正确的直觉和理解。片面追求自动化的资源节省，或者要求精确量化自动化的收益，本人觉得都不可取。

推论1：什么项目适合自动化

从ROI的简化公式可以看出，下面几中情况比较适合自动化：

回归测试为主的Support Engineering项目，即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品（比如企业软件，操作系统等）一个版本在发布之后往往需要支持好多年，做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数，并且每次产品变动都非常有限，维护成本相对偏低，自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化。

接口比较稳定的产品，同上
手动测试特别费时费力，甚至无法达到测试目的的项目。比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持。

推论2：自动化的介入时间点

同样从ROI的简化公式推断出，一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口没有稳定，自动化代码会被动的被要求频繁改变，维护成本非常高。自动化收益不好。而反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益。

推论3：自动化的程度和自动化率

这里自动化的程度是指整个软件研发活动中引入自动化的程度。推论2中说，有些项目早期可能不太适合高度自动化，但是项目早期仍然可以选定某些环节进行自动化。比如稳定的公用接口，软件的编译和部署，环境的搭建等从一开始就比较稳定的部分。

自动化率同样也要看产品和项目的特性 ，对于产品的UI部分如果会频繁改动，可以做比较低的自动化。对于接口比较稳定的服务组件可以提高自动化率。

你有什么样的团队 ，工具和基础设施，其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架，架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力，那么怎么去做自动化，是做最原始的录制回放，还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统，就不用自己去开发，省下的资源和人力也是很可观的。

工具是另外一块 ，如果公司有实力支持商业测试软件和管理软件，就可以降低编程要求（当然这会带来一些其他问题）。如果没有办法用商业工具，只能考虑开源和自己开发，这个对自动化测试开发的能力要求就高。总之必须选择和团队，技能储备，基础设施与工具匹配的自动化策略。

管理层的理解程度和支持

这个就不再展开。我见过很糟糕的情况，一个带好几百人兼顾产品技术的VP，越3到4级直接给测试团队提技术需求和建议。你说是做还是不做，怎么做？还有一个团队，自动化测试人员从来没有写过Java或者其他OO语言的程序，被要求从头设计自动化框架，那就是一场灾难。还有一个团队，管理层几次要求更换自动化工具，相当于整体重写自动化脚本。

总结

以上应该是一个很粗浅的回答。自动化测试是一个很专门化的领域，自动化测试又是对工程师的技术广度深度要求很高的工作。对于团队管理和决策者来讲，请不要简单化和孤立看待自动测试。最重要的是确保听取真正理解产品，团队和自动化测试的技术人员的判断。

END

本文著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

ui自动化测试有用吗

现在客户端流行的ui自动化测试框架层出不穷,但是也有很多人质疑UI自动化测试对测试本身的投入产出比,甚至认为UI自动化测试有用吗.

一.UI异常

UI异常包括白屏,黑屏,数据加载异常,花屏,重影,错位,覆盖等.

二.UI自动化测试的使用场景

UI测试主要测试的是产品的功能需求.那么,功能主要验证的方面有:

我们每测一轮测试,在回归和兼容性方面投入的人力是巨大的.而这些人力做的都是重复的劳动.UI自动化在降低人力方面,发挥着重要的作用.而最近热门的图像识别和深度学习,又给UI自动化测试在页面样式识别方面补足了短板.

三.UI自动化元素定位

很多人反应UI自动化脚本维护成本高,因为页面布局总是在变.所以,UI自动化测试更适合业务相对稳定的产品.而且我们在写自动化脚本时,主要是通过

1.控件识别,控件识别的方法有:

等.而其中最不稳定的就是classPath,最稳定的是id.所以我们如何巧妙的定位控件,成为了其中脚本是否稳定的关键.

2.图片识别:

sikuli/airtest;

3.图片对比:

感知哈希算法;图片缩放;图片像素值对比.

其次，要做好失败重试，和显式隐式等待等，pom模型，用例步骤原子化，独立性。

四.UI自动化测试效果

接口测试我们很容易很清楚的可以拿到接口的成功与失败,响应时间,响应内容.但是客户端琳琅满目.

接口成功了,客户端就一定能看到页面数据吗?这个问题值得我们思考.

从发起请求,到页面呈现.其中诸多环节和诸多耗时.而客户端作为检验产品的最后一个环节,无疑起着决定性的作用.是用户最直观的感受.UI自动化测试就是作为真实用户的角色去检验产品,检验端到端的可用性.

六. 效果对比

如何有效的开展自动化测试

自动化测试不宜大力投入
不管是自动化测试还是接口测试，都不宜在前期大量投入。当前业务是否适用自动化，哪些框架或者工具更适合，适合做接口自动化还是 UI 的自动化？如何让自动化达到收益和效果？
这些问题都需要根据团队和业务具体的情况去尝试，找到合适的才行。如果前期投入太大，团队对其期望太高，非常容易在遇到一点挫折的时候对自动化丧失信心。
另外，投入太大，毕竟加大人力或者减少手工测试的投入，会造成测试资源的紧张。在项目时间和成本的压力下，测试管理者需要顶着巨大的压力，这本身就很难成功。
可以安排一些技术强或者技术兴趣浓厚的成员，在项目允许的情况下减少其手工测试工作量，让其可以利用部分工作时间和部分业余时间尝试做自动化，先局部功能尝试，能够有效果，在扩大范围。逐步达到一定的自动化规模。
以接口为主UI为辅
UI 自动化因其运行环境的问题，会导致运行速度慢，对环境依赖过高。同时因程序界面的多变性，导致自动化脚本维护成本大大增加。
接口测试有很多优于 UI 自动化的地方。但是接口测试也自有其短板，对流程性质的测试并不适合用接口自动化来覆盖。接口自动化更适合覆盖单一接口功能的检查。
所以我们可以采用核心业务流程使用 UI 自动化，单一功能使用接口自动化，两种层面的自动化结合的方式来进行。
不轻谈自动化测试平台
目前测试界开始流行起自己开发测试平台（以接口为主）。简单来说就是模仿常见的接口测试工具，用 Python 或者 Java 写成了一个 web 版本的。
当然也有其理由，“定制性更强！”但是毕竟是软件都需要进行测试，花大量精力开发的平台并不稳定，而本身功能和理念上并没有太多更新。而这样的一些功能，市面上的绝大部分测试工具都能胜任。
如果是为了提高个人能力，项目时间有空余，怎么玩都可以。若是要在实际工作中应用，那么就有点得不偿失了。
自动化测试中，工具的重要性始终是最低的。理念、思维和环境治理才是最重要的。
通过不断小范围试错，找到适合自己团队的自动化策略才是最重要的。任何技术脱离实际应用都是耍流氓。 关于接口自动化测试重要吗和接口自动化怎么测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口自动化测试重要吗的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化怎么测试、接口自动化测试重要吗的信息别忘了在本站进行查找喔。

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