共计 8022 个字符，预计需要花费 21 分钟才能阅读完成。
本文作者：程胜聪 – CODING 测试域产品总监
在业内热火朝天的 DevOps 转型过程中，自动化测试始终是热点之一，毕竟提供疾速品质反馈是达成 DevOps 指标的要害。于是，作为测试畛域的“皇冠”，自动化测试的落地施行始终为人们所关注。然而落地当中产生了种种问题甚至是争执，经久不衰，无形中给自动化测试体系建设蒙上了层层迷雾，让人纳闷。上面咱们就一些踩过的“坑”进行探讨，冀望这些教训分享可能有助于揭开迷雾、看清方向。
要不要做自动化测试？
在软件工程实践当中，测试绝对开发来说是个“辅助”的角色，而软件交付的产物也不用包含测试的产出。随着软件研发过程的复杂度晋升，尽管还是辅助角色，而且其价值依然难以独自掂量，然而测试对品质保障的作用曾经深入人心，以至于从 10 多年前开始，曾经没有人会挑战测试作为研发体系中根本角色的存在了。
然而相似的，作为“辅助的辅助”，测试畛域中的自动化测试又开始面临着同样的质疑：自动化测试到底有没有价值？这个问题在 10 多年前开始被频繁提出，而且难以答复。作为处于辅助位置的投入，人们必定会亲密关注其老本大小以及跟收益的比照。自动化测试最开始呈现，是为了代替重复性的手工操作，从而节约回归测试的人力老本，于是要获取正向收益的前提是执行的次数够多：
自动化收益 = 迭代次数 x（手工执行老本 – 用例保护老本）- 用例编写老本
所以，在 DevOps 时代的频繁公布测试场景下，自动化测试的价值失去了充沛展示。要不要做自动化测试的问题现在曾经不会造成困扰，因为当下业内曾经造成了统一的意识： 自动化测试是继续测试的根底，是 DevOps 时代中不可或缺的实际。 此外，因为自动化测试的执行效率很高，体现进去的工夫老本劣势更是显著，甚至比老本劣势更能戳中这个疾速公布时代的痛点：因为不这样做的话，咱们会越来越难以应答短周期公布所须要的疾速无效验证。
有策略地发展自动化测试
测试体系建设须要分层策略指引、接口测试往往最优先
罗马不是一天建成的，为了达成自动化的指标，进行自动化测试体系的建设是须要投入资源和人力的。因此在具体落地过程中，咱们须要充分考虑 ROI，来设计符合实际状况的指标达成门路。自动化测试的确有很大价值，但不代表咱们应该无节制地投入到各种类型的自动化测试当中：自动化测试是为了验证既定逻辑是否合乎预期，在需要变更频繁的场景下，自动化代码的保护老本不可小觑。所以咱们须要适合的策略，来指引自动化测试的施行——金字塔模型。
不少人对金字塔模型的第一印象，是其给出在 3 种测试上的投入占比倡议：单元测试最多、接口测试居中、UI 测试起码，比方 70%、20%、10%。但更为重要的是，Mike Cohn 提出了对测试进行分层的理念，以及给出了每个层级的测试优缺点：越靠近用户应用界面的高层次测试，粒度越粗，效率越低，写的测试应该越少；反之越靠近底层代码的测试，粒度越细，效率越高，应该写的更多，也应该执行得更频繁。
而在实际当中，每个企业面临的场景不同，投入状况也不一样。比方现实情况可能并不是金字塔而是纺锤形状的，两头的接口测试占比最高。种种实际表明： 在自动化测试建设的初期，接口测试往往是团队发展自动化测试的首选。 这是因为接口测试兼备执行效率和体现业务价值两方面的长处，在这个畛域进行资源投入较为容易被技术团队和业务团队独特承受。而且因为接口定义的稳定性也较高，其保护老本也是可控的。所以绝对单元测试和 UI 测试来说，接口测试的投入产出比能够说是最高的。
接口测试以接口定义治理为根底，契约变更的同步揭示和 Mock 是要害
接口测试通过调用接口来达成测试验证的指标，既包含零碎与零碎之间的接口，又包含同一零碎外部各个子模块之间的接口。接口测试的重点是查看零碎 / 模块之间的逻辑依赖关系，以及进行交互的数据传递的准确性。接口测试是黑盒测试的一种，却是最靠近白盒测试的黑盒测试，故而在较早发现缺点和执行效率上也靠近于单元测试，往往被称为“灰盒测试”。
接口测试的用例个别包含单接口用例和基于业务场景把不同接口集成到一起的多接口用例。单接口用例是根底，而且也是开发调试过程所需。业内比拟风行的是用 Swagger 进行接口文档治理，Swagger 预约义了支流编程语言相干的代码注解，能够在接口实现代码变动之后获取接口文档的更新， 主动反映接口变更的性能对自动化用例的保护来说十分重要。
多接口用例则是测试人员依据对需要性能的了解所设计进去的，这部分用例就充沛展现了自动化测试的业务价值。因为这部分用例绝对简单，团队会须要为之筹备根底框架，甚至打造脚手架来进步编写效率。在实现上个别会包含接口标准定义、接口间调用的代码治理、测试数据的存储管理、执行调度平台、结构化统计报告这几个局部的能力。于是在业内也呈现了不少在这个畛域的效率工具，比方 Postman、ReadyAPI！、Robot Framework，以及“低代码”的平台 apifox、Eolinker 等。
有了接口的契约定义，就能够对未上线的接口实现 Mock（测试替身或者挡板），这样就能够不必依赖于具体的开发实现而构建场景测试用例，有利于测试开发之间或者不同开发者之间的并行合作。当初搭建 Mock 解决曾经有很成熟的框架，比方 Mockito、EasyMock 等，或者平台型工具 postman、apifox 都可能很不便的搭建 Mock Server。
总的来说，有了能够遵循的接口定义标准、加上接口变更的信息同步、以及提供对接口的 Mock 服务，在团队中就能够基于 API-first 的形式实现并行开发、调试和测试了。
高效编写自动化用例有没有“捷径”可走？
现今零碎的性能越来越弱小，也越来越简单，写好自动化测试用例不是简略的事件，这一块也是不可漠视的投入。于是在自动化建设的实际中，咱们自然而然会谋求更高效的办法。谋求高效之路没有问题，只是如何能力防止走歪呢？上面咱们对一些常见的“提效工具”进行探讨，冀望能够对事实的实际起到借鉴作用。
编码方式向左，低代码平台向右？
现今零碎的接口往往盘根错节，要做好接口测试，既须要对业务层面的零碎 / 模块之间的逻辑关系有深刻理解，又须要把握好技术层面的各种测试框架和相干编码技术。能够说，接口测试自动化的建设依然面临着较大挑战，人们天然会寻求高效的形式进行施行，相应的就呈现了对自动化用例低代码平台的需要。于是出于“对测试同学技术能力的事实思考”，研发 Leader 往往会“以负责任的态度”，寻求“入坑”去谋求低代码平台。低代码的概念在近两年如此之火，更是导致这个话题重复被提起。那么咱们在写自动化测试用例的时候，到底应该是遵循老老实实写代码的形式，还是应该大胆采纳低代码平台去疾速晋升覆盖率呢？
低代码平台的劣势是什么——那就是通过升高自动化编写的技术门槛，让编码能力较弱的人员也能参加进来，从而较快地从 0 开始晋升自动化覆盖率。个别低代码平台都是基于接口测试自动化的数据和代码拆散的准则而进行设计的：先把罕用的接口操作方法形象进去，并且封装好（在 Robot Framework 中称为关键字），而后通过在界面上拖拽组件组合成一个逻辑流程，再加上数据传递驱动造成一个残缺的业务场景。所以应用低代码平台给人的体验，就是通过表格表单的操作实现自动化用例，感觉上“不须要编程能力”。
然而，在实践中应用低代码平台进行简单业务测试时，对数据字典、操作的形象（关键字）、设计能力的要求还是很高的，不然碰到绝对底层逻辑的变更，那就须要改变茫茫多的用例。从不少团队的实际来看，低代码平台在中长期保护上面对多变业务场景会显得难以为继：不足技术抽象思维的、非工程背景的业务（或者业务测试）成员很难继续“重构”现有的用例。而为了保障用例的准确性和整体运行效率，对自动化用例的重构是不可避免的。面对着一系列的“表格局”文档，工程师普遍认为这种形式是软弱和低效的，从而不违心接手。
所以， 是否应用低代码平台取决于咱们对业务倒退的预期： 对于非核心业务，如果预期模块是绝对固化而不须要演进的，那么无妨大胆利用低代码平台发展疾速笼罩的自动化测试，低代码平台的确缓解了团队管理者的“自动化建设焦虑”，帮忙团队迈出自动化测试的第一步；而对于外围业务、注定要跟随着业务倒退而进行技术演进的模块，那么就须要充分考虑中长期达到晋升自动化编写效率的目标。原则上咱们该当抵赖， 自动化测试用例的编写，事实上存在着“工程门槛”，也的确是须要“工程门槛”的。 哪怕应用低代码平台，也须要领有“工程师思维”，思考“关键字”和数据结构的封装和保护。总的来说，应该通过减少可视化、缩小重复性工作的形式，让工程师更加高效地编写自动化用例；而不是“无限度的升高门槛”，以冀望未经训练就能够写出强壮的、高质量的自动化测试用例。
流量录制回放形式能够取代手工写自动化用例吗？
对于接口测试，事实中还存在一种状况：那就是对现有零碎缺失的接口测试进行“补锅”，须要对已存在的泛滥接口场景进行测试用例的补充笼罩。如果采纳传统的测试形式，是从接口定义开始，手动梳理零碎接口文档、对照着录入测试用例、写好逻辑断言，而后还要在深刻了解接口后，结构相应的测试数据，这是惯例的形式，也是正确的形式，然而毫无疑问是个慢工细活。当咱们须要在较短时间内实现一轮补充的话，这个形式显然做不到。于是一种新的解决方案呈现：主动采集实在的流量并造成接口测试用例。
流量“录制”指的是对线上的流量申请和返回进行拦挡录制，而后记录下来造成测试用例；而“回放”指的是把线上录制下来的申请和返回，复制到一个准生产环境服务中，测试新性能和服务是否满足要求。实在（数据）和高效，是流量录制回放形式的两大长处，而其次要的利用场景包含：
- 呈现线上故障时，录制的实在流量能够回放到开发 / 测试环境来进行调试剖析，这是用到“实在”的场景，也是流量录制回放性能的根底价值；
- 对录制好的实在流量进行复制放大、利用到预公布环境中作为压测用例，这也是用到“实在”的场景，实在流量对压测来说的确是个很好的补充；
- 如上文提及，批量造成第一次的回归自动化用例汇合，这是用到“高效”的场景。
实现流量引流录制的支流形式包含：Nginx 的镜像复制、GoReplay 间接监听网络接口捕捉 Http 流量、基于日志解析，以及针对利用业务自研复制引流性能。业内最为风行的工具当属 GoReplay 和 TCPCopy，其中 GoReplay 尤其简略易用，而且无代码入侵，对线上利用的影响能够忽略不计。
那么是不是有了流量录制回放的性能，就不再须要手工写自动化用例了呢？必定不是的，咱们还须要踏踏实实写自动化用例。首先， 流量录制回放是后置的“补锅行为”，没有人心愿等到接口上线之后才去测试， 所以往往是一次性的工作；其次，流量录制也是须要较长时间能力达到较高的用例笼罩，对于十分用的边界，然而重要的场景咱们依然须要人工去设计；再次，对于构建简单的多接口组合的场景用例来说，流量录制的形式还难以做到：对录制下来的流量进行二次加工，可能还不如动一下脑筋去人工实现。
UI 测试用例的录制形式靠不靠谱？
UI 测试的形式十分直观，也很容易看到业务价值，然而 UI 界面的疾速迭代特色导致测试用例的无效生命周期很短，保护老本极高。所以，相比起单元测试和接口测试而言，软弱、简单、以及投入产出比低下的 UI 自动化测试，不应该成为咱们的次要投入畛域，个别用于笼罩要害并且 UI 处于稳固情况的业务。
UI 自动化用例还能够通过录制形式来疾速生成，现今比拟风行的提供录制形式的自动化测试工具包含：面向桌面程序的 QTP、Ranorex、面向 Web 页面的 Selenium IDE、Chrome DevTools-Recorder、阿里的 UI Recorder、面向挪动端程序的星海“鲸鸿”、WeTest UITrace 等。
当初业内存在一个乏味的景象，那就是只管录制失去的 UI 自动化用例基本上不具备可维护性，然而不少人还是会心愿采纳录制形式实现自动化。究其基本，是大家对 UI 测试的期望值跟个别自动化测试不一样：抵赖 UI 界面的易变性导致自动化用例保护老本很高的事实，从而罗唆当作“短暂”的、“用完即弃“的回归测试用例—— 只有录制足够简略疾速，大不了过一段时间（下一版本）就废除从新录制。
出于“物尽其用”的观点，做这样的抉择看上去无可非议，然而也要关注团队成员对这种形式的接受度。毕竟反反复复去做一些注定了要放弃、从头再来的事件，对人的士气打击也是不言而喻的。从久远来看，咱们还是更心愿从绝对稳固的层级，比方组件级别去笼罩 UI 的测试，也就是说前移到单元测试环节。毕竟当初前端框架曾经很成熟，齐全能够基于框架对 UI 进行细粒度的单元测试。而对于端到端的 UI 测试，还是应该审慎投入。
“聪慧”的执行自动化用例
以下自动化测试代指的是集成级别测试，不包含单元测试
写好用例代码是自动化测试重要的第一步，然而只有执行了能力让其价值失去展现。如同自动化收益公式所表述的那样，自动化测试用例执行次数越多越好。而在实际当中，当咱们不能每次执行全量回归用例集时，就须要思考测试范畴和效率之间的均衡，有策略地执行自动化用例。上面两点是对于自动化价值的外围准则，须要在自动化测试体系建设中牢记：
准则 1：自动化测试价值的本源在于业务，应该基于业务驱动自动化测试，始终关注优先级最高的需要所对应的测试。
准则 2：自动化测试价值的放大器是测试执行频率，只有跑的次数多了，才可能赚回老本；而只有单轮次执行的够快，能力保障较高的执行频率。
CI/CD 中跑自动化测试会遇到什么“坑”？
从瀑布模式时代开始，传统的自动化测试执行形式是 nightly-run：设置工作在每天上班后跑全量回归用例，而后第二天拿到后果后再去解决执行失败的 case。而之所以做不到实时跑自动化测试，就是因为自动化用例累积到肯定数量之后，须要好几个小时能力执行完一轮。然而在 DevOps 时代并不会有如此“拮据”的工夫留给回归测试，会冀望把自动化测试嵌入到 CI/CD 流水线之中，提供及时的品质反馈，例如上面几种状况：
- 自动化测试嵌入 CI 中，也就是每次把新个性的代码合并（Merge Request）到骨干分支之后，除了须要跑一次全量单元测试外，往往会跑一次冒烟测试用例集；
- 自动化测试嵌入 CD 中，在每次执行生产环境部署动作之前，确认在预公布环境上跑一次全量回归测试用例集；部署实现后还会在生产环节跑一次冒烟测试用例集；
- 在团队可能实现迭代内及时编写好自动化用例的状况下，CI 过程中还须要执行已实现个性所对应的用例，确保代码变更之间的互相兼容；
- 甚至在迭代内，团队中的成员能够自在创立 CI 来执行任意一个选定的自动化用例集。
一般来说，CI/CD 对运行工夫是十分敏感的，所以在流水线中的集成测试局部不能耗时过长。如果不加管制地扩充测试用例集范畴集成进来，那么运行时长必然不受管制。
构想一下，随着代码写的越来越多，每次跑自动化用例所破费的工夫越来越长，最初只能升高执行自动化测试的频率……这就比拟无语了，明明曾经写好了这么多代码，却施展不了价值，那咱们还须要致力写更多自动化用例吗？这样的“坑”置信很多人都碰到过。自动化测试本来性能很弱小，但当初被解放在笼子外面，这样的窘境该如何破解呢？既然每次循序渐进执行大量测试用例的形式不可取，那就须要找到更优的办法，来实现“更聪慧”地执行自动化用例。
要执行得更快，第一个想到的解决方案天然是并行执行，把用例散发到分布式的机器环境中。而要做到这点，则须要设定规定保障用例之间的独立，并且做好测试数据的治理，让每次用例执行改变后的数据都能还原。只是这样做会让复杂度大大增加，而且问题呈现后也难以排查。除此之外还有一个很重要的问题：每次跑的都是全量，两头夹杂着大量有效执行的用例，那么因而失去的抽象的通过率又可能阐明什么问题呢？除非设定简略的规范，就是要全副通过，然而事实中因为网络抖动导致的延时、简单的数据更新等等起因，都会导致零零星星的失败。所以，并行执行还不能齐全解决问题，咱们还须要另辟蹊径：如果跑自动化测试用例时，能够依据变更来确定用例范畴，而不是每次执行都笼罩全量用例，是不是就能够管制测试执行的工夫呢？答案就是精准测试—— 通过建设变更和测试的对应关系，从而更无效的验证变更，缩小不必要的全局回归。 精准测试从实现上大抵上包含两种：基于代码变更确定用例集，和基于需要变更确定用例集。
基于代码变更来主动确定用例集，是将测试用例与程序代码之间的逻辑映射关系建设起来，反映的是代码的测试覆盖率。这个指标十分雄伟，只是目前业内的计划还不成熟，还须要搭配大量的人工查看核查。而基于需要变更来确定用例集，则是建设测试用例与业务需要之间的映射关系，反映的是需要的测试覆盖率。这个办法在技术上听起来不是那么高大上，只是通过治理上的束缚来实现，然而曾经能很好达到咱们的目标。CODING 就是基于这样的逻辑打造了自动化用例库，指标是让 1）和 2）的实际失去顺畅落地，乃至实现 3）和 4）的自在执行某个自动化用例集。
CODING 助力实现“业务驱动自动化测试”
CODING 测试产品推崇的是“业务驱动测试”：所有从业务需要登程，通过建设自动化跟业务需要的关联，能够让自动化对症下药的扩充覆盖率，而不是凭空随便去写测试代码，产生反复的有效测试。
同时，CODING 自动化用例库通过对自动化测试代码进行解析，把失去的函数列表匹配到相应的性能用例，基于已有性能用例与需要的关系，造成自动化用例与需要性能的映射关系：
基于这样的关联关系，咱们就能够顺藤摸瓜，依据某个自动化函数运行失败，找到对应哪个需要有问题，而后依据需要的优先级或者影响范畴决定是否持续下一步，是打回修复问题还是决定持续公布上线。
首先，建设自动化代码和性能用例的匹配关系，自动化覆盖率“高深莫测”。
CODING 提供示例代码导入，帮忙用户通过在代码中依照规定在注解 / 正文中填写性能用例 ID，或者人工判断，让解析进去的自动化代码函数跟已有的性能用例进行匹配，逐渐晋升性能用例的自动化覆盖率（也为精准测试打下基础）：
而后，在迭代进行当中，可能选择性执行特定的自动化用例集。
在一般测试计划中，能够圈选局部性能用例来执行对应的自动化用例；而在迭代测试计划中，圈选特定需要后，对应的性能用例列表也就产生了，从而实现业务驱动自动化用例的执行。CODING 会继续增强灵便执行自动化测试方面的能力，提供更加顺畅的“聪慧”执行的场景计划。
总结
自动化测试体系的建设是个系统工程，波及到人、技术、流程等方方面面，咱们尤其须要全局思维、权衡利弊，“没有最好的、只有最合适的形式”。
首先，应该在团队层面对齐自动化测试的指标。因为品质保障是有老本的，不能无限度的投入，没有清晰的品质预期就无从着手去制订施行门路。不论是团队成员的能力建设，还是自动化测试技术框架选型，整体工作流程的设计都必须以此为基准。
其次，技术框架 / 工具的选型应该要适配现有或者指标工作流程。对于心愿打造研发一体化工作模式的中大型团队，在工具选用和流程制订上就须要体现跨职能的协作性，而且要向业务对齐，并且要充分考虑团队的继续效率。比方让自动化测试成为 DevOps 继续集成 / 继续部署的一环，自动化测试要体现业务价值（保障对业务需要的笼罩），而后关注测试脚手架的可维护性，造成对自动化用例 / 测试数据的重构，测试执行效率及时调优的制度标准。
最初是对人的倒退，业务的变动带来技术和流程改革的要求，最终的落脚点还是要依附人的成长。咱们在制订指标、设计流程、选用工具的时候，会思考到团队的适配度。团队成员也会随之产生职责变动甚至技能降级要求，须要关注集体体验，并对其进行疏导和造就，实现“有温度”的转型。 已经风风火火的“去测试化”风潮的回落，正阐明了测试的角色不会隐没，测试开发最终还是测试，只是让测试角色“回归”到工程师的根源。
点击开启高效云端研发工作流
