为什么做自动化测试,自动化测试?
自动化测试的成本高效果差，那么自动化测试的意义在哪呢？
本文章出自【码同学软件测试】
码同学公众号：自动化软件测试
码同学抖音号：小码哥聊软件测试
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
本文著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
自动化测试有哪些优势?
1. 自动化测试可以替代大量的手工重复性操作, 可以让测试人员留出更多的时间和精力去更加全面的设计测试用例或展开对新功能的测试工作
2. 自动化测试可以大大提高回归测试的效率, 这一点可以充分迎合敏捷开发过程
3. 自动化测试可以让测试人员更加合理的安排测试执行时间, 方便调整工作进度安排
4. 自动化测试可以完成一些手工测试难以达成的测试类型, 譬如性能测试里的高并发场景压测等
5. 自动化测试也可以尽最大程度的避免由于人为原因导致的错误和遗漏
更多实战小技巧可以到网络上找下黑马程序员相关视频，之前在他们官网上看过视频中老师的经验分享。
为什么要进行自动化测试,自动化测试有哪些限制
自动化可以让人从重复的劳动中解放出来，建议是功能比较稳定，需求变动不频繁的功能，维护成本不太高，以及有很多重复步骤的测试用例可以做自动化测试。限制的话主要是看自动化测试工具支不支持操作你想要操作的元素
自动化测试是软件测试的重要手段，自动化测试有什么优势？和手工测试有什么不同？
自动化测试相对于手工测试优点如下：
1、可以模拟人工测试，减少重复机械的测试工作量，大量用于回归测试；
2、可以提高测试精度，例如进行大数据量的正确性校验；
3、进行人工难以执行的测试，例如单元测试、统计测试覆盖率等等；
4、用于模拟多线程的并发；
5、更好地利用资源。将繁琐的任务自动化。
6、测试具有一致性和可重复性。
7、测试的复用性。由于自动测试通常采用脚本技术，领测认为这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
8、增加软件信任度。
为什么很多测试人员都会把自动化测试当成很厉害的资本？
因为自动化测试将QA从繁重的重复劳动中解放出来，优化测试资源，提高测试效率，对产品质量保证起到积极的作用。另外，一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力也是一件毋庸置疑的事情。
首先，我们不能否认自动化测试的作用，这肯定是将来软件测试发展的一个大方向。一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。
但凡做过测试工程师的朋友都知道。一些逻辑非常复杂的场景是很难用自动化脚本实现的，就算要强行实现，也性价比很低，因为太费时费力了。所以用手工测试来执行一些奇葩的场景更灵活方便并且可以发现很多问题。而且，从事过测试的人应该很清楚。同样的一个测试任务，交给不同的测试人员是会有特别不一样的结果，发现的bug数量和最终产品的质量都不一样。
所以，手工测试不是手工执行测试，其更重要的部分应该是测试思路和用例设计灵感，这点往往是最困难的，也是需要经验积累以及自我沉淀的地方，更不是自动化代码可以替代的。如果没有一个很好的测试用例和测试思路，纯有代码和工具，那也是巧妇难为无米之炊。所以，不论自动化测试还是手工测试，都只是一种测试手段或者说是一种测试工具，他们各有自己所服务和侧重的领域，并无高低贵贱之分。
而且实施自动化测试之前需要对软件开发过程进行分析，如果软件需求变动过于频繁，测试人员需根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
「自动化测试」是否有必要做自动化测试？
目录
一、前言
二、自动化目的
三、自动化分类
四、自动化实现
一、前言
在一些测试交流群经常会看到有小伙伴在问，"怎么做自动化测试？学习自动化测试有什么资料吗？自动化测试是不是很牛逼？" ，甚至有些言论是"不会自动化的测试人员，真的要被淘汰了吗？"
不得不说一堆流量号主抓住大众心理，点进去的必然是卖课广告，或者是关注微信公众号领取测试资料大礼包。
实话实说，我之前也有同样的疑问，甚至带着担忧。每次又不甘心得领着测试资料大礼包......
当然，随着自己的认知不断扩大，自己的一套测试体系建设不断完善，于是这些担忧逐渐的消失。每项技术引用都要看适用场景，是否适合自己的团队，因地制宜才能发挥其最大的价值。
因此，我想通过这篇文章来分享下我对于自动化测试的理解。
二、自动化目的
自动化工作可以节省很多人工操作成本，减少人工重复性操作，提高整个团队的研发效率。但是如果搭建自动化体系需要耗费很长时间，投入很多人力资源，但是用户只要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。
结论：我认为接口自动化和部署自动化是能够带来收益的，是真实能够提高效率的，并且也能够给测试人员的带来成长。
关注【嘎嘎软件测试】
搞测试，不迷路
呱呱大王本呱带你飞！
嘎嘎软件测试 分享个人成长、团队管理、软件测试技能知识等内容，做到有思想、有观点、有深度，欢迎订阅。