JB测试之旅-浅谈自动化知识

本篇不会讲解某种语言或某种框架，这种事情请直接找google，

本篇是面向小白或对自动化不熟悉的同学，或是想深入了解自动化理论知识的同学，因此，大神请右上；

理论为主，只有明白更多的理论，做事才更加有条理性；

大环境

在测试行业里面，自动化这个词是跑不掉的，无论您是应届生，还是工作几年的老鸟，简历上没有 自动化 这个词，都会被打折扣，基本上可以用 全民自动化 这个词来形容，随便打开一个招聘网站，基本上所有测试的岗位都要求会自动化，或者会自动化优先的字眼；

关于自动化，想问的问题非常多，比如：

• 自动化是什么？
• 为什么都在搞自动化？
• 自动化能带来什么收益？
• 自动化能代替人肉测试吗？
• 自动化需要掌握啥？
• 面试的时候，关于自动化一般会问什么 ...

这一串问题，一起聊聊吧，有不对或者有争议的，欢迎大家一起讨论；

聊点没用的

什么是自动化

经常说自动化自动化，那到底什么是自动化？

直接贴上某度的回答：

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

关键词：自动、按照人的要求、执行

那自动化测试就可以理解成，把人对软件的测试行为转化成机器对软件的测试行为；

本质不就是写一段代码，去测试另外一段代码？

自动化测试是做什么

根据上面的定义， 按照人的要求就是自动化测试要做的内容 ，而这个 按照人的要求 换在软件测试里面，就是所谓的测试用例；

那自动化测试就是按照这份用例进行特定的操作；

为什么需要自动化测试

举个例子，之前负责的seo项目， tkd、标签、robots.txt 这种文件是不允许出错的，一旦出错，就会跟产品数据带来严重的影响；

既然是不允许出错，意味着每个版本发布前都需要验证；

既然每次验证的规则跟条件是一样的，那是不是就可以通过机器去替代人完成这件事？在这里，自动化能帮忙解决 回归 这么一个事情；

别人怎么玩

很多中大型企业，内部都会有个发布的平台，比如输入一个tag，然后就 自动构建、稳定性测试、UI测试、各种配置检查，最后把结果输出各项检查结果 ；

而上面的稳定性测试、UI测试、配置检查，无疑都是定义好的用例脚本，每次打包都执行一遍，千篇一律，达到了 回归 的效果；

自动化的意义就是解放人工，不用去做这些重复且并“没有意义”的事么；

最常用的场景，冒烟，回归；

举个例子：

本来每天早上都要花固定一个小时冒烟，要是这部分能做自动化，
不就节省了这1个小时的人工了么~
复制代码

那做了自动化，会有什么好处吗？

优势

• 可以替代大量的重复性工作，测试同学就可以把更多的时间花在用例设计及新功能测试上；
• 自动化可以提高执行回归测试的效率、并可以利用非工作时间进行测试；
• 自动化支持24小时不间断执行，适合进行压测，并且可以利用非工作时间进行测试，提高工作效率；
• 自动化能确保每次执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽；；

关键词：大量重复、提升效率、准确性和可靠性

劣势

自动化不是万能的，虽然有上面那么多优势，但还是有不少劣势，也间接说明，自动化不能代替人肉；

• 自动化只能替代人肉测试中执行频率高且重复的工作；
• 自动化不能随机变化，只能按照定义好的步骤执行；
• 自动化发现的问题远比人肉的要少；
• 自动化测试效率很大程度上依赖测试用例的设计及实现质量；
• 自动化测试容易依赖模块的稳定度，随着版本迭代，旧版本的自动化用例可能会失效，这增加了自动化测试维护的工作量，也逐渐打击了自动化测试开发者的积极性；

关键词：不懂变通、强依赖用例及模块稳定性

什么样的项目适合自动化

• 需求文档不会频繁变更；
• 功能稳定；
• 维护周期长，需要频繁执行回归用例；
• 某些场景无法通过手工测试重现，比如联系点击2K次；
• 进度压力不大；
• 被测系统开发比较规范，可测试性强；

要记住， 一旦维护成本高于节省的测试时间，就不适合自动化了 ；

价值

• 公司：没有自动化测试不会影响公司和测试团队的生存；
• 个人：没有自动化测试经验并不影响找工作，但会影响找高薪水跟大公司的机会；
• 兼容性：没有自动化，兼容性是肯定做不好的，毕竟也不会有那么多时间把所有的功能都回归，这时候能做的就是祈祷不同平台没有兼容问题，祈祷研发少写点bug；
• 非功能：弱网、性能都需要在具体条件下才触发，没有自动化，人力是否有足够多时间且可重复在不同场景下回归测试；
• 持续集成\持续交付：如何快速的给出质量反馈；
• 公司压力：领导对测试团队的执行效率表示怀疑，如何解决？减少测试的需求、免测、降低公司发展速度、招人、找外包、提高手速？

自动化思路

从用户的角度触发

• 能够正式模拟用户的操作；

实现现有手工测试用例

• 能够替代现有的手工测试用例；
• 能够考虑各种异常情况；

能够替代繁琐的重复操作

• 每次重复执行的操作；
• 下次能代替进行手工测试的操作；

测试金字塔

测试金字塔，也是后来的分层自动化测试概念；

传统的自动化测试

也就是大家说的最多的UI自动化测试，是将黑盒功能测试转化成有程序执行的一种自动化测试；

传统自动化困惑

• 太多的原因导致case的失败，界面、关联、数据、库；
• 代码的变更，不能及时修改用例，不能及时反馈；
• 不能完整的覆盖测试点，毕竟不是所有的用例都会自动化；
• 维护成本高；
• 定位问题颗粒度大，只停留在表面；

分层自动化测试

提倡的就是由原来的UI自动化单层到UI\API\UNIT多层的自动化测试体系，从黑盒自动化测试到对不同层次进行自动化测试，也就是上面的图；

UI自动化（GUI界面层）

UI层是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层；

常见的测试 工具 有QTP、Robot Framework、Selenium、Appium等；

测试策略

手工为主，自动化为辅；

手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试， 而 自动化测试的往往只覆盖最核心且直接影响主营业务流程的场景 ；

ui自动化是不是没意义？

不是的，要看具体需求，在一些注重用户体验的产品，对前端要求高，对应的UI测试需要也会增加，如电子政务、财务软件；

对于一些金融类的行业来说，前端相对于后端简单很多，所以UI测试就不怎么需要了，这种重点应该是在API测试；

如下场景可以不用UI自动化

• 产品单元测试、接口测试非常成熟，前端团队很给力，基本不出UI问题，有靠谱的研发团队在为质量兜底；
• 自动化水平很差，搞自动化非但不成功还让公司损失惨重，你用血一般的教训成功让领导接纳了UI自动化测试无用论；
• 不愁用户，就算有Bug用户也不流失；
• 你是大佬，自己了算；

要付出的，远比想着多

做过UI自动化的同学，肯定会有过下面的经历：

• 为什么这个用例跑10遍会出现1次失败？
• 为什么点了这个按钮会有概率没有反应？

这些问题会影响自动化测试结果的可信度。

所以得收集日志、截图，得收集更多的运行时数据来便于找出失败原因（ 无法定位出错原因或者忽略 fail 都会逐步扩展并最终让 UI 自动化变得不可信，然后就没有然后了。。。），所以要做的事情不仅仅是让程序帮点就够了。

做UI自动化测试，需要什么技能

前端相关技术HTML、XML、http协议等；

一门编程语言python，Java等都可以做自动化，但实际py较多，因为简单，方便，因此受众多；

合适的工具选型比如selenium，appium等；

需求分析项目类型，特质，是否适合开展自动化测试等；

接口自动化（业务逻辑层）

主要检查 验证模块间的调用返回以及不同系统、服务间的数据交换 ；

模块接口测试主要测试模块之间的调用与返回； 跟单元测试类似，强调的是一个类、函数的调用，并对返回的结果进行验证；

服务器接口测试指产品与服务器的接口，前端通过调用这些接口来获取需要的数据，基本上是通过http协议来进行数据传递；

常见的接口测试工具有postman、jmeter、loadrunner等；

一般来说，api测试是测试重点，原因：

• 稳定；
• 测试周期短；
• 测试用例、流程规范，一般就是准备数据、发起请求、验证response；
• api改动少，而且部分情况是向后兼容；

如果要采用api自动化测试，对于测试用例，通常包含3个步骤：

• 准备api调用时需要的测试数据；
• 准备api的调用参数并发起api的调用；
• 验证api调用的返回结果；

接口测试可能遇到的问题

问题1：

Q:有个问题，如果以前是用postman、jmeter做测试工具的，有一定的用例，那要做自动化，
怎么搞？

A：这是个好问题，因为类似postman是单一调试，
如果此时要做自动化，意味着需要把大量用例用代码的方式重写一遍，好恶心的；

建议是，开发一个自动化代码转换生成的工具，这个工具输入所以postman的json文件
（用例数据），输出是符合要接入的api框架规范的测试用例，这样就能把原来积累的
用例直接转换成可以在CI直接接入的测试用例了；

postman集成CI/CD，通过Postman+newman+jenkins，在Postman导出一个json文件，
在另一个服务器部署newman，命令行执行Postman导出的json文件，然后直接在
服务器用newman工具就能测试并生成测试报告；
复制代码

问题2：

Q：后端返回的字段几十个，没可能每个都做assert，那没做assert的字段，如果
后面的版本都改动到了，而且没有做测试的话，那旧版本调用同一个接口的时候，
有可能就会报错了，这种情况怎么办？

A：有一个骚操作，数据入库，每次request跟response的结果都用数据库记录，当下次
发送相同的requests时，自动会上一次的response多对比，有变化就报警；
复制代码

问题3：

Q：被测业务操作是由多个api调用协助完成
A：既然单一api的调用能获取解析结果，那多个api也一样的，把上一个内容
返回的response的Neri传递给下一个用例里的requests即可；
复制代码

问题4:

Q:API依赖别的API，但别的API还不可用，怎么办？
A：实际项目中，这种情况非常多，毕竟api开发也是需要时间的，中间会有间隔，
解决方案也很简单，mock即可；
复制代码

问题5：

Q：异步api怎么测试？
A：什么是异步api，是指调用后会立即返回，
但实际任务并没有真正完成，需要稍后查询或回调的api；

一般这种api，分两种情况，有回调跟没回调，有回调的话，直接等回调就好；
那没回调怎么办？一般会说，会这样：
发起请求后，轮训执行一个查询对应状态的操作，等到发现状态正常后再进行后续操作，
如果状态异常/超时就报错；
复制代码

单元测试（数据处理层）

指对软件中最小的可测试单元进行检查和验证，一般需要借助单元测试框架；

如 java 的Junit、TestNG，python的unittest，常见的手段是code review等；

基于单元测试的自动化，目前想到的有2个：静态代码检查(Coverity、findbugs)、覆盖率（jacoco）

怎么做自动化测试

大家都很注重自动化测试，不过永远要记住下面一句话： 不要为了自动化测试而做自动化测试 ！

不管所处什么环境，有什么测试工作及测试方案、手段，但所有的一切一切，都是为了业务，脱离了业务，你的产生是为谁服务？

在开始做自动化之前，要先了解对应的业务，核心功能流程，具体的功能交互及实现，以后业务未来的发展及可能迭代的频率等做了解和估算，然后根据一定的思路来进行选择和开展你的自动化工作：

• 根据业务特点，选择自动化测试方案 ； 你的业务是前后端分离的吗？ 业务比较注重用户交互还是数据完整性？ 用户量有多大； 有没有一定不能出错的业务？ 通过考虑业务的特点，才能选择比较合适的方案。
• 根据业务侧重点，确认自动化覆盖范围和粒度 ； 比如说，要进行Web UI自动化测试，肯定不能直接看着页面就去写自动化测试用例，要根据业务重点来确认； 哪些业务流程是核心，必须覆盖? 哪些功能暂时有技术难点，或是变化比较快，可以以后再实现； 通过对手工用例的评审，来准确确定自动化测试的范围，实现用例的粒度。
• 根据自动化测试用例范围，选择实现框架和语言 ； 目前业务自动化测试工具，开源框架虽多，但不同框架都有侧重点； 需要根据测试用例的范围和特点，参与人员的水平，用例的使用场景和未来的计划来选择合适的框架； 比如说，要做接口自动化测试，而参与人员大部分不会代码 ，那选择Python+Unittest+HtmlTestRuner+Jenkins就比选择Java+Httpclient+TestNG+Jenkins实现起来成本更低。
• 根据用例用途，选择执行策略 ; 一般来说，会划分出冒烟，发布性用例，不同场景的用例，后续策略也不一样，比如监控、预警等；

如何学习自动化测试

既然自动化测试是手工测试提升的一个必经之路，虽然自动化测试没有那么高大上，但也是必不可少的。

那作为一个有理想的测试人员，应该如何去学习自动化测试呢？

• 准确定位自己，明确目标 很多同学都意识到自动化的重要性，但网上的资料太多了，看着看着就懵逼了，到底怎样才算会？改改用例？或者是报个培训班学习，最后也类似，介于会与不会之间；

建议在开始之前，思考几个问题： 自己真实水平如何？ 如果要学习新东西，投入的精力是多少？ 想达成的目标，如一周、一个月、三个月后要达成怎样的目标； 别人怎么做？（业界是怎样的体系跟类型及流程）

• 全面了解，选好对手 目前自动化测试方向大概有以下几个：

• • 辅助测试脚本方向，以Shell，Python为主来简化重复的工作，过滤日志等；
• • 接口自动化测试方向， Python+Unittest+HtmlTestRuner+Jenkins 和 Java+Httpclient+TestNG+Jenkins ，当然还有很多其他二次开发的框架或工具，不过核心是一样的；
• • 页面自动化方向，主要有 Python+Webdriver+HtmlTestRunner+Jenkins , Java+Webdriver+TestNG+Jenkins ,以及其他的框架和工具；
• • App自动化测试方向，以 Robotium+Java+TestNG+Jenkins , Appium+Java/python+TestNG+Jenkins , Appium+Python+HtmlTestRunner 为主;

先从这几方面了解入手，选择一个语言体系，建议从接口自动化入后，然后再去学习页面和app。

记住，万变不离其中，看过、用过几个框架，会发现大家都类似，真的就是侧重点不一致而已，甚至会发现有很多轮子；

• 慢慢来，别着急学着学着，发现需要学的东西太多了，就会焦虑，学的太多容易产生混淆，而且不容易消化，仔细调研就会发现，很多东西都是相通的

  代码架构，用例管理，执行策略，持续化集成思想都可以举一反三，关键是自己要动手真正实施起来，在公司现在的框架上写用例，不管你写多少，不了解整体结构都是没有用的。

• 抛弃工具，多用开源 业界从来不缺少自动化测试工具，QTP，Robot Framework，LoadRunner等等，知名不知名的数不胜数。 先不说效果如何，目前大公司是从来不用这些工具的，都使用开源的框架， 工具进行定制化自己的测试方案 。 所以刚刚学习自动化测试的时候，也不要依赖工具，使用开源的Webdriver, Appium,Robotium等搭建自己的自动化测试工程。 掌握一个整体的自动化工程工作原理，为以后搭建自己的自动化工程，工具，平台做准备。

不管你对自动化测试是爱，是恨，它是从手工测试转为测试开发必经的阶段。 可能你了解到自动测试没有用，实施起来维护成本高，执行效率低等负面信息，其实这不是自动化测试的问题。

要知道，它只是一个工具，一种测试方案，最终的效果还是由实施的人来决定的。

在早几年的时候，用Jenkins做持续化集成比较热门，接下来几年好像没有那么火了，但是近两年 docker 技术的出现，又使CI，CD变得火热起来。

持续集成

持续集成的目的：

• 及时反馈；
• 能发挥自动化脚本最大的价值；
• 减少问题发生的范围；
• 流程自动化，提升效率；

持续集成思路

• 检测代码提交，自动执行代码检测，单元测试；
• 通过后，自动部署到测试环境\自动打包；
• push提交记录给相关同学，让其知道本次提交的内容；
• 自动执行对应的自动化测试；
• 自动化测试通过后，直接通知测试验收，测试通过后，发布；
• 在各环节，如果有失败情况，自动反馈给相应的人员；

让自动化更自动

自动化的弊端就是用例固定，那能否让用例不是固定呢？就是所谓的让自动化更自动？

比如接口自动化，所以的接口信息其实都是在用例或Excel里写明，那能否让接口是动态获取的呢？

比如先找开发找到项目接口文档存放地址，然后通过爬虫的时候获取，最终就是遍历并自动读取接口信息，请求参数及response来自动判断，这样是不是就能做到自动化自动执行？

又或者，用例里面很多数据都是hardcore的，能否通过读取数据库里面的内容动态生成？

意义

往往事故都是出现在： 新代码影响到老功能 但没有回归。

所以别问自动化有没有意义，肯定是有的，而且意义是自己去发现，不是靠别人来告诉你。

关于面试

之前有同学说想了解下关于自动化面试的内容；

之前去面试，问了最多的就是，做过自动化吗？做什么自动化？效果如何？怎么做的？这个自动化工具的架构是怎样的？有什么模块功能？怎么确保稳定性？

其实如果是真的亲自做过的，这些问题都能回答上，都很简单的问题；

而jb作为面试官，在自动化这块，一定会问这么一个问题： 在做自动化的时候，有遇到什么问题吗？怎么解决？

这样问的目的很简单，排除水军，也只有真正做过的人，才回答上；然后根据回答的内容，就能大致知道对自动化是怎样一个熟悉度；

当然，也见过别人会问框架原理，但这个jb不太赞成，因为自动化的框架百花缭乱，虽然说万变不离其中，但都有侧重点，逐个去看感觉意义不大；

小结

其实自动化这个话题太大了，很难面面俱到，而且讲细节会没有意思，所以才会选择讲点理论，而且刚好也是给内部培训使用（黑盒为主），目的就是让大家了解更多，别把自己太过局限；

本文章主要介绍自动化相关的理论知识，并且给出了一些怎么做、学习自动化，希望能给新同学起到帮助，也希望能快速的了解自动化；

最后在贴一个之前看到的图，看了就会发现自动化是可以做非常多的东西，而且这个流程是大部分企业都类似的流程，可复用；

最后，谢谢大家；