背景
首先自动化的引入能够解决什么问题？只有清晰正确的认识到自动化测试能给我们带来的预期收益、目标。再结合团队的具体情况，避免对自动化工具产生过高的预期，避开一些常见的误区，有效的持续构建自动化测试，才有可能真正体现出自动化测试本身的价值。这是一个长期投入的过程。
“其路漫漫远兮, 吾将上下而求索”
目标是什么？
首先自动化测试的意义是能够帮助节省人力、时间或资源，提高测试效率。那么从个人和团队不同的视角去分析自动化目标：
- 个人角度：
- 通过自动化测试工具，节省时间、提升效率、保障质量。
// 真的么？ - 体现代码能力，提升自己的价值和议价能力。
// 目前看来好像是这样？ - 把重复执行工作解放，发挥主观能动性的其他相关测试，发现更深层的问题。（如：探索性测试）
// 觉得可行吗？
- 通过自动化测试工具，节省时间、提升效率、保障质量。
- 团队视角：
突破现有资源瓶颈，提升测试效能，降低人力成本。
// 不能把降低人力成本放在核心位置，否则容易适得其反。降低人为错误率，规避因为人的疲劳、惯性思维偏差、投机取巧导致的错误。
提升执行效率，以及应对高重复度任务，比如系统稳定性(回归)测试和高并发场景的压力测试。
-
增加软件的信任程度。
解释下这点: 通常当执行有效的自动化脚本并成功后，那么就可以说当前的交付物是基本可靠的，通常测试很难去决定或左右质量的上限，但是可以保障质量的下限。换个角度来讲，回归测试自动化的稳定执行，可以让团队有信心相信当前的交付物是可靠的。毕竟测试本身就是一种提升信心的活动。
指标如何度量？
自动化测试常见度量指标：用例数（新增及维护）、覆盖率(代码行、接口、功能)、ROI、通过率、执行率等等。不同的团队面临的问题不同，所采用的指标也不相同。即使是是这样，但是大致遇到的问题却是相识的。// 具体指标也可以通过团队实际的痛点或面临的现状，用结果来倒逼反推指标。
比如：
往往结果数据统计并不难。但是到最后会发现一个问题，就是实际度量数据反映的情况和预期存在很大的差异性，无论是从质量或效率来看。在特定的时间内很难达到预期的目标。
就比如发现度量数据呈现出的效率好像提升了，用例数大幅度增长，但实际业务测试的周期好像似乎没有变化？又或者下个月的度量指标数据下降了。但是测试周期反而又大幅度减少了？这样一来，测试效能度量、质量保障似乎是靠天吃饭的，咋一听起来有点搞笑或者不可思议。但是现实情况就是这样的0.0，那么问题到底在哪里？
?：这里可能或许存在人员在执行力方面的一些问题? 还是其他因素？思考一下？
问题会在哪里？
也许出在 "目标" 本身，目标即导向。那么效率提升的本质是不是就一定是 "用例数量多"、"覆盖率多"、"ROI就高" ？
好像也不全是，其实目标本质是简单直接: 在定时任务的背景下【快-> 时间缩短】，在定量任务的背景下【快-> 人力减少】
在具体指标设定时，除了"定性"、不可避免的还要"定量"，一方面视为了度量其绝对值，另一方面是与其"定性"相互佐证。
【定性】：时间缩短-> 例如: 项目平均测试交付周期缩短 X%
【定量】：累计节省人力投入（或累计节省额外人力投入）-> 例如: 累计节省回归测试 X 小时
近期有看到一个有意思的话题讨论：" 关于敏捷测试底能不能度量或者需不需要度量的思考?"
因为从敏捷测试宣言来看，度量本身就是不敏捷的。但不可否认度量指标可能是一个好的测试实践。但是，如果过度关注度量的指标数据，甚至用来考核指标，那么可能就会流于形式化，导致就会为了数据而数据。偏离了度量本身的初衷。
自动化测试存在的误区？
在最开始的时候，聊了引入自动化测试的目标和期待。在引入自动化工具之前如果未考虑引入的目的及具体能够解决什么问题及带来的价值。但如果团队对于自动化测试有过高的期待，觉得引入自动化测试就可以解决所有问题。
-
关于这些误区可以从以下几点来讨论：
-
为了做自动化而自动化？
事先没有做好规划，管理好引入自动化测试的目标和合理的预期，只是盲目的引入，认为自动化测试能够提效、降低成本、保障质量。关于自动化是否能够提效和保障质量有待商榷，尤其是质量一直是争议的点。其次是降低人力成本，这里也是有误区的，首先引入自动化的目的应该是替换重复的工作，解放测试人员的时间和精力，发挥人的主观能动性，间接地发现更多、更深层次的问题。这里应该要清晰的认识到自动化测试存在的局限性。
-
为什么发现不了更多的缺陷？
发现更多的缺陷应该是手工测试的主要目的，不能奢望自动化发现更多新的问题。事实上，自动化测试主要验证原有的功能（回归测试）
如果没有建立一个正确的软件测试自动化的观念认知，认为测试自动化可以完全代替手工测试，或者认为测试自动化可以发现大量缺陷，或者不愿在初期进行比较大投入的话，很容易导致半途而废。那么失败也将是必然的。
一定能提升效率和质量？
这里的也是最常见的误区，大部分人都以为只要在项目流程中引入自动化工具，那么就一定能提升效率并且线上的缺陷会大幅度下降，很显然这么想的大部分人都失望了，甚至会发出一些疑问？"为什么我们自动化都做了这么久，投入这么多人力、时间、成本，但是没能得到预期的结果呢？"
其实能合理的有效的持续构建自动化测试，是有可能提升效率并且保障回归阶段特定功能的可靠产品交付。但是由于引入的前期没有做技术选型、框架调研、以及项目成熟度等诸多因素的考虑，都会导致自动化测试落地的失败。
-
录制回放的自动化工具“真的好”？
在早期的自动化测试工具(Selenium、LoadRunner)中，都会有录制回放的功能。这个功能有多鸡肋，只要用过的都应该清楚，说多了都是泪。
现在又火起来了，为什么呢？因为现在的录制回放和以前的已经不是一回事了。早期的录制回放指提是录制某个用户的行为动作，然后通过协议回放出来。而现在的录制回放，更多的是基于流量的录制回放，录制的是大量用户在现网的实际请求，然后在测试环境中回放。
注意哈：这两个完全不是一个级别的事。后者需要依赖大量的基础能力，诸如基于中间件的流量录制、数据清洗改造等大量工作，一般公司不具备这种能力。即使具备这种能力，在投入较大的成本之后，会发现并没有多大实际的效果。ROI 较低，典型的吃力不讨好。
-
自动化测试平台是"高大上"？
从自动化工具→框架→自动化平台是逐渐过度的过程，也是必然的趋势，但是不包括所有的团队都适合这种情况。因为平台就意味着局限性，规范性。而大多数团队往往就做不到规范化。盲目的平台化只能引起水土不服。尤其是敏捷测试多变的模式下，大部分平台功能支撑会很难适应。
当然并不是说平台化一无是处。恰恰相反，如果平台足够规范化、贴合实际业务、优先考虑使用者感受等多个方面的来持续建设自动化测试平台，“高大上”指日可待。
-
引入自动化需要考虑那些方面的问题？
开展自动化测试，投入的基本上就是时间成本。当然还需要综合考量一些其他影响因数。主要有以下三个方面：
-
项目周期
-
项目的持续时间短
当有一些传统公司项目紧急程度非常高，从立项到结束只有一个月的时间，而这一个月的时间可能大部分时间都是在做前期需求沟通，产品需求频繁变更、开发实现变更、测试用例设计等，而测试又未能提前介入，导致提测之后，留给测试的时间是不多的。所以这个时候如果强行要做自动化测试，时间成本将会明显提升，ROI也低。甚至基本质量都无法得到保障。
-
项目的持续时间短
在单周、双周、甚至去迭代的团队，本身交付压力已经足够大的情况下，需要考虑自动化编写和维护的成本，不可能去牺牲和压榨原本手动测试的时间，这里质量的风险会大大提高。当然更不可能奢望成员利用业余或者周末在家的时间去实现自动化。这。。。很难有什么成效吧。
// 这里可以考虑从工具下手，降低编写和维护成本。
-
-
成本问题
- 人员能力
引入自动化测试，首先测试人员的能力要求也会相对高一些，例如要懂协议相关，编程语言、业务程度等，这类人员本身成本也会相对较高人的问题是最核心也是最重要的，因为团队成员的能力都是不同的，比如测试技能、兴趣、责任、执行力等。都是决定最终自动化能否成功的关键。
- 协作规范
想要自动化能够顺利高效的落地，前提得是有标准化的流程。比如接口自动化测试，
需要有规范的接口文档。目前大部分团队的文档管理方式不一，其维护程度较差。或者文档万年都没有维护。如果是仅仅依赖测试人员通过抓包来分析接口再进行代码编写测试脚本，浪费时间，效率低，后期维护成本极高。- 时间成本
不管是开发脚本还是维护脚本，都是需要时间投入。虽然从长远上来看，自动化的效率是能够体现出来的。但是针对某个迭代来说，是需要从原来的功能测试时间中抽出一部分时间来编写脚本和维护脚本的。那如何保证有限的时间既保证了功能测试的覆盖，又能实现自动化测试的覆盖？
显然这里是矛盾的，可能有些团队成员会说利用加班或者业余时间来投入的。
~有了解过这种类似的情况纯粹是靠爱发电，这种情况很难维持，并且用例的有效性有待考量。~ -
效率问题
在引入自动化测试之前有没有考虑过，工具本身是否解决效率的问题。那些地方做可以提升效率，那些反而会拖后腿。而且同时如果还盲目的追求自动化覆盖率的话，也将走向误区。那么基于效率来分析，可以从以下两个方面来做尝试：
-
基于风险
应该优先考虑测试核心、业务高频场景或者功能模块。例如：会影响核心流程的、在测试环节中BUG相对集中的功能点、影响服务级别协议 SLA、资损、用户高频使用的功能等。
-
基于ROI
基于BUG的修复成本，越早发现成本也就也低。越底层的自动化测试越能产生更高的价值。所以分层自动化测试的必要性不言而喻。
// 分层自动化测试内部有做分享从测试金字塔模型来分析，以及团队实际情况来考量，一般采用会建议优先引入接口/集成自动化测试(
依赖后端接口规范)。当然核心流程的 UI 自动化也很有必要(依赖前端的代码规范)。如果开发的单元测试能够引入效果会更佳。// 目前来看完全取决于开发的自觉性
-
当能够很好地平衡这些成本关系后，引入自动化测试才有可能产生真正的价值，并且需要长期持续构建有效的构建自动化。否则很容易变成面子工程，半路夭折，沦为测试人员的负担。
落地失败导致的原因有哪些？
在上述的问题。可以说在一定程度上问题基本都解决掉了。但是自动化测试仍然没能达到预期的效果。随之，新的问题又来了？你可能会开始吐槽：“自动化这么难搞,为什么我们还要趋之若鹜?”
虽然目前大多现状即便如此，还是得分析可能导致的原因在哪里：
-
人员问题
-
缺乏编程技术能力
国内软件测试起步比较晚，早期的测试工程师清一色地做着功能（手工）测试，不需要有编码能力，甚至觉得不用会编码是理所应当的。近些年开始随着敏捷测试的盛行，自动化测试逐渐成为行业趋势，才驱使一些测试人员去学习编程语言，但都仅仅局限于自动化工具层面，很少有能够深入学习的。
大部分可能接触的一些框架工具比如：RF、LR、selenium、appium、requests、unittest 等等。掌握这些常见的技能，这里会有一种情况就是你可能上手写一些自动化脚本，但是至于写的是否有效、合理、不得而知。
// 这里脚本的合理有效性起到决定性因素 -
测试用例设计覆盖目的性弱
随机性、低覆盖、无法真正的缩短执行效率。没有合理的规划用例的设计。比如：在手动执行测试用例时，为了缩短执行时间，避免某些操作的重复执行，通常会先设计执行场景，一个场景下，尽可能根据执行顺序，覆盖更多的测试用例。
// 而在编写自动化脚本的时候常常会忽略这一点 -
缺乏用例的有效验证
通过平时发现大部分的自动化测试用例验证只是断言状态或者简单响应的内容。然而一条严谨有效的测试用例。通常要对响应的结果做全面覆盖。考虑响应内容可能存在一些非幂等性的属性。
比如当前时间，目前提供的关键字中，灵活的支持过滤掉那些属性不校验的功能。需要避免在提升效率、稳定性的过程中，忽略质量的基本要求，如果是这样的话，那么就会显的有些本末倒置了。
// 有效验证是关键 -
用例稳定性
这又是一个让测试工程师很尴尬的事情，因为代码基础功底问题，在编写过程中自身的问题存在比较多，debug调试成本高，运行不稳定、断言不合理等问题导致测试结果可信度不高。
// 用例设计很重要对于这种情况，只能不断去强化你的代码能力，而且心态上有改变：不要觉得写代码的测试太难。自动化测试的本质其实还是在做功能测试。
// 仅仅是通过代码代替你的手动操作而已，很多人往往忽略了这一点。还有另外一点，就是当你在写代码的时候，应该像 RD 一样要求自己写的代码是易读、可维护的。在学习测试框架（
多阅读源码去理解作者设计的意图）的同时，还要关注数据结构、设计模式、数据库、中间件等。- 另外，在编写测试用例时，尽可能遵循FIRST原则：
- F——Fast：快速
- I——Isolated：隔离
- R——Repeatable：可重复
- S——Self-verifying：自我验证
- T——Timely：及时
- 另外，在编写测试用例时，尽可能遵循FIRST原则：
-
用例的维护性
在以上的问题都不太需要考虑的时候，并且大量的测试用例集成到CI/CD流程，不要以为这个时候就成功了，就能轻松的享受自动化来的收益了。
往往这才是第一步。因为随着产品模块、功能随着快速迭代的过程也随之发生频繁的变更，及时、有效的维护这些用例将会成为你的首要事项。
如果你最初的用例不规范、设计不合理、按照个人习惯编写，那么无效用例就会发生雪球效应，最后让你负担不起，大部分自动化测试无疾而终就是因为这个原因。所以有效及时的维护是首要任务。
// 用例设计是基础再次强调
-
-
工具问题
-
工具的使用体验
在多人协作的自动化项目过程中，因每个人的能力、习惯、经验或标准不规范，就可也可以引入能导致前期编写成本高、可读性差、后期维护成本高。针对这类似问题可以对自动化规范作出标准输出，定期分享和培训组员的基础能力。
也可以在技术引进的时候考虑是否有替代人工编写脚本的方案，节省人力的同时需要考虑维护成本。
-
自动化孤岛，缺乏持续性
初期引入到CI/CD持续集成中，出发点是好的，但是会发现过程中存在一些问题。比如流程节点或卡点增多，导致流程繁琐，又或者自动化测试用例执行失败率高、有效性差、环境因素等其他干扰因素。人员的工作量增加。可能引起排斥效果。
-
技术选型局限性
假设团队成员都已经具备初步的编码能力后，会面临下一个问题：怎么做自动化？或者说用那种自动化工具？
困惑于不知道选什么样的测试框架、工具，困惑于不知道从接口、Web、移动端哪一层入手。切入点无从下手。
-
框架选型
由于大部分测试人员学习编码是以自动化为出发点，比如selenium、appium等等。他们所具备的编码能力只局限于这些框架API。而编程的基本往往被忽视，基础不行。所以这样一来，可能就只有从熟悉的框架着手，而不能全盘考虑各类框架优劣势。
这样的话，就会存在很难根据自身实际业务来考量选择合适的工具框架，因为没得选。更别说根据开源工具来进行二次开发了。
-
分层策略
然后是测试分层，其实测试分层是个比较大的话题，单元、集成、接口、UI都可以介入入。至于测试分层自动化，上次分享专门分享过有兴趣的去翻下 PPT。大家可能都知道，问题越早发现，解决的成本也就越低。自动化能够下沉到越底层，那么ROI的收益会更高。
-
-
// 这里也存在可能技术选型的负责人没从团队整体情况去考虑也会导致工具选型的失败
-
过于"工具平台化”
这里在说一个常见的现象：平时可以发现大多测试社区、博客、群聊等等，讨论的测试框架、平台的功能实现。某某工具有支持某些强大的功能等等。
但是很少有人会聊自动化测试用例如何设计这才是最核心的东西。工具平台的功能支持再多，再强大。没有测试用例支撑，那都是工具开发人员的自嗨而已。
目前大部分测试开发的心态可能就是：他开发的工具框架厉害。功能多，代码能力强。测试框架、平台信手拈来，至于用例怎么写跟我没关系。殊不知，不管是手工测试还是自动化测试，其核心资产绝对是测试用例，而不是那些烂代码堆砌出来的框架平台。
// 工具平台建设最重要还是要考虑结合实际业务、团队成员的能力出发，不能为了工具而工具。为了追求平台而平台。 -
团队问题
-
过于关注覆盖率
一味追求需求覆盖率、接口覆盖率、代码行覆盖率，而实际问题是覆盖率只能保证你执行到了，但是它并不意味着它能发现有效的问题。过于关注覆盖率往往只会适得其反。在分层自动化分享的时候有专门的做过分析，覆盖率最合适有效的比例是在15%-25%之间。覆盖率的考量应该也是要取舍的。
-
优先级 VS 成本
质量范畴的各类工作如果用四象限法则来划分的话，自动化体系建设大概率会落到『重要不紧急』第四象限。自动化能带来那些价值都是不确定的，尤其是大部分公司手动测试占比依旧是主力，自动化的引入不一定能够解决质量、效率问题。
- 而且，如果你真的要全面推行自动化体系落地，短期成本还会明显增加：
- 人力成本：需要有编程能力的。
- 学习成本：手工测试到自动化测试的培训
- 流失成本：普通测试工程师学会了自动化测试能力，有了更高的薪酬期望，可能会跑路。
- 时间成本：测试分层的测试范围越大（多层累加），不一定会缩短测试周期。短期来看是投入大于产出。
- 而且，如果你真的要全面推行自动化体系落地，短期成本还会明显增加：
-
内部断层
能在部门或者公司层面推送自动化体系建设的本来就不多。一般都是在内部搞搞。而在网上能找到这种成功分享的经验却很少，即使去参加各种测试峰会的分享，所见识到的所谓成功经验，不一定能直接拿来用或者借鉴。大部分都是自研且根据自身业务的实际情况二次开发定制的。作业不好抄啊。
而自动化体系建设的测试开发人员，大多只关注框架和平台的实现，不关心后续的推动和落地。甚至是开发出来的工具平台是否能够满足业务线的期望他们是不关心的。
而执行层只关注简不简单，是否好上手。是否影响之前的习惯（因为没有人喜欢被改变）。这里就会存在意识断层。毕竟不在一个维度。各自都缺乏全局视角看待问题。
-
长期干扰因素多
自动化体系建设是一个长期沉淀的过程，贯穿整个产品研发的生命周期，是敏捷测试实践中不可或缺的一部分。
在自动化实践的过程中会遇到诸多的干扰因素，测试资源不足，项目周期压缩、提测质量、需求频繁变动、领导对自动化结果的质疑等等一系列问题，都会导致自动化测试会不得不爱。面对这些问题大多数情况只能接受并妥协，手动测试加速需求交付似乎就成了唯一。
-
对自动化测试的坚持
不同的组织架构，对待自动化的态度不一样。如果测试有独立的质量部门，有绝对的话语权，那么推行自动化体系建设才有底气。
// 这里感谢当初 @智哥 对自动化的坚持而如果是业务线形式开发测试融合到一起，通常业务负责人是产品或者开发，那么在这种组织架构下，Leader是不太关心过程是否用的是什么技术。他们更关注的是结果，是否能够高效率、高质量的完成需求交付即可。
甚至部分开发人员或测试人员本身都对自动化测试结果存在质疑的话，自动化体系的落地将更难实现。但是即使是这样或那样的诸多问题，也不要轻言放弃。
-
自动化测试演进
只有当我们正确认认识到自动化测试能给我们带来的预期收益、目标和规避了大部分误区之后，结合团队的具体情况，逐步的引入自动化测试，给予一定的时间，慢慢沉淀和发展，才有可能真正实现自动化测试的价值。
在不同的阶段，自动化的形态和预期也不一样。主要分以下几个阶段：
-
工具使用
在团队前期，基于 PostMan/jmeter 之类工具的简单接口调用，应当致力于一些基础规范的制定，比如让开发提交时效性高的接口文档，或者通过类似Swagger的插件来自动生成文档。
开发讨厌两件事：一、讨厌别人让自己写文档 二、讨厌别人不写文档。 -
引入测试框架
当下流行的测试框架也很多，如HttpRunner，Pytest，Junit5、AirTest等等。如果团队成员的代码能力更强些，开发的配合度更高些，也可以尝试一些左移的框架，如基于SpringBootTest 的注解进行dubbo服务接口测试或基于SOA的单元测试等或其他一些TDD/BDD相关的测试框架实践。
另外有了一定的基础之后，还可以通过优化框架来提供一些提升效率的功能，比如自动生成最基础的测试用例、数据等，或者能够解析接口文档，然后基于这些接口或者用例来补充和完善测试场景。
-
平台化
当团队实践自动化测试有一定的规模之后，再考虑做成平台化，推广到更多的团队当中去。大型的公司中都会有相关的工具。比如开源平台：meterSphere、HttpRunnerManagement等其他相关的。当然根据实际业务进行二次开发是很有必要的。
-
敏捷测试 DevOps
可以适当开始引入敏捷相关工具，CI/CD 流程管理， DevOps 平台也很多，都会带有一定的自动化测试工具，产品良莠不齐需要甄别。尝试摸索找到符合自身团队最佳的测试实践。
-
AI 智能测试
这类自动化测试在最前沿TOP一线互联网公司正在逐步的落地(有幸参加了一些技术峰会)，看似大势所趋，未来前景无限。但是个人觉得看看就好。
// 感谢 @毒蜂 大佬带我出去涨了见识
最后
自动化的概念的初衷是解决回归测试场景的应用。具有可重复性、稳定性等场景。主要是考虑功能的稳定性和投入成本，很显然前期项目功能变化频繁，需求变更的风险较高，同时交付周期较短。想做到高覆盖就需要大量的开发、维护成本。其中最主要的矛盾来自于“成本问题”，反过来想，如果实现自动化覆盖率的成本在不断降低，矛盾弱化，那么这个局限性可能将会不复存在。
只有当团队正确的认识到自动化测试能给我们带来的预期收益和目标后，结合团队的具体情况，避免对自动化测试有过高的预期，避开一些常见的误区，持续逐步的引入自动化测试，给予一定的时间，慢慢沉淀和发展，才有可能真正实现自动化测试的价值。
综上，真正要落地自动化测试体系建设，要综合考虑到人员能力、成本、项目、组织架构等因素，这是件昂贵的事情。也正因为昂贵，更应该踏踏实实迈好每一步，不要把事情浮于表面。
以上这么多废话都是这些年在自动化道路上中学习的无感所悟。中间有无奈、有茫然、当然更多的则是收获。欢迎对自动化测试感兴趣的同学 点赞+关注+回复 一起讨论。