接口自动化测试重要性（为什么要做接口自动化测试）

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

本文目录一览：

• 1、我眼中的接口测试和接口自动化测试
• 2、接口测试的优点
• 3、如何有效的开展自动化测试
• 4、自动化测试的成本高效果差，那么自动化测试的意义在哪呢？
• 5、「自动化测试」是否有必要做自动化测试？

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

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

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

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

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

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

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

接口测试的优点

接口测试的好处：
由于接口测试代码本身就是用junit（当然接口的类型不同，不一定是Junit来实现）来实现的，是属于自动化测试的范畴，因此必定也包含自动化测试所固有的优势。
1） 提高测试质量
软件开发的过程是一个持续集成和改进的过程，而每一次的改进都可能引进新bug,因此当软件的一部，或者全部修改时，都需要对软件产品重新进行测试。其目的是要验证修改后的产品是符合需求的，而当没有自动化测试代码时，往往会由于各种各样的原因，回归不充分，导致bug遗漏。
2） 提高测试效率
软件系统的规模越来越大，功能点越来越多，开发人员的自测或者测试人员的人工测试非常耗时和繁琐，势必导致测试效率的低下，而自动化测试正好解决这些耗时繁琐的任务，在对外接口功能不变的情况下，达到了一次编写，永久使用的效果。
3） 提高测试覆盖
通过手工测试很难测试到一些更深层次的异常和安全的问题，通过一些辅助的一些测试工具，能分析出代码的覆盖率，通过覆盖率的提高来提高测试的深度。
4） 更好地重现软件缺陷
由于每次执行都是相同的代码，一旦代码出错，必定回归出错
5） 更好定位错误
由于接口测试是一种自下向上的测试，因此一量出错，非常容易定位出错，不向系统测试那样了，一旦有Bug，需要几层验证之后才能确定出错位置
6） 降低修改bug的成本接口测试基本和开发人员的编码平行工作，因此发现问题会比系统测试早很多，因此减少了修改bug的成本。
7） 增进测试人员和开发人员之间的合作关系，测试工程师为了更好地开展工作，需要对开发技术有深入的理解和实践，有了与开发工程师更多的交流。
8） 降低了项目不能按时发布的风险由于接口测试很早就介入，在提交给系统测试前对项目代码的核心模块已经做了详尽的测试，必定加速系统测试的时间，由此来保证项目的按时发布。
9）提升测试人员的技能。做接口测试必须了解开发人员的开发流程和一些开发技能，也需要了解测试工具的一些使用方法和一些测试思想，提升了测试人员的技术附加值，提高了自身的竟争力。
10）促使项目开发过程的规范化
要进行接口，需要完善的文档进行保障 ，没有测试文档，接口测试将寸步难行，接口测试将增加开发过程规范化产出，而规范化产出也保证了项目质量。

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

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

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

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

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

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

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

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

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

目录

一、前言

二、自动化目接口自动化测试重要性的

三、自动化分类

四、自动化实现

一、前言

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

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

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

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

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

二、自动化目的

自动化工作可以节省很多人工操作成本，减少人工重复性操作，提高整个团队的研发效率。但是如果搭建自动化体系需要耗费很长时间，投入很多人力资源，但是用户只要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。

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

关注【嘎嘎软件测试】

搞测试，不迷路

呱呱大王本呱带你飞接口自动化测试重要性！

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

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

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