一个测试工程师走进酒吧，被开发工程师打了一顿

一个测试工程师走进一家酒吧，要了一杯啤酒；

一个测试工程师走进一家酒吧，要了一杯咖啡；

一个测试工程师走进一家酒吧，要了 0.7 杯啤酒；

一个测试工程师走进一家酒吧，要了 2^32 杯啤酒；

一个测试工程师走进一家酒吧，要了一杯洗脚水；

一个测试工程师走进一家酒吧，要了一份 asdfQwer@24dg!&*(@；

一个测试工程师走进一家酒吧，什么也没要；

一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；

一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；

一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；

一个测试工程师走进一家酒吧，要了 NaN 杯 Null；

一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；

测试工程师们满意地离开了酒吧。

一名顾客点了一份炒饭，酒吧炸了。

一位测试工程师被开发工程师打了一顿。

上面是网上流行的一个关于测试的笑话，其主要核心思想是——你永远无法把所有问题都充分测试。这样的背景下，持续集成的自动化测试似乎成了至关重要的部分。本文结合了自动化在笔者当前部门实践情况，介绍在自动化道路上不断探索的心路历程和各阶段的问题、优化与总结，沉淀下一些可供参考的经验与想法。

01、写在前面

早期在很多人的眼里，自动化测试具有巨大的潜力和优势，比如能减少失误率、提高准确性、节省时间和执行成本、提升测试覆盖度、做一些手工无法完成的测试，此外也可以提升质量反馈速度，甚至是提升测试团队的士气；然而到了现在，只要提到自动化内容，经常被提起的更多的人力成本、自动化收益、时间成本、设备成本、测试覆盖或执行效率等等。各个业务也经过从无到有，从有到无等多个阶段的反复，很多文章都分析出来了其优劣性，反复论证了其收益性，基本一致的观点就是不同业务需要不同对待，比如在增长期和稳定期区分对待，全力追求自动化测试价值曲线。

随着技术发展，自动化在各个领域和端也在不断演变、推陈出新，以更智能、更轻量、更敏捷的方式呈现着自己的优势。同时也细分了更加清晰的测试分层，比如从底层单元测试到框架测试，再到组件或者附件测试，到 API 测试，最后到端对端的自动化测试。此外很多测试团队在建设自动化初期，也得到了开发团队的支持，共同开发了相关框架 SDK，加速和提升这里的效率，还有很多团队引入了录制回收的机制来降低了用例覆盖的门槛，让更多人进来参与覆盖，这些都是非常优秀案例。

本文结合了自动化在当前部门实践情况，介绍在前端自动化道路不断探索的心路历程，以文档自动化为重点举例。从一开始雄心壮志到处处受挫，再到后面小心翼翼，再到最后用例共享，多人参与等和谐共处良性画面。面对不同阶段出现的各类问题和各类反馈，不断升级优化，反思与总结，坚持走好每一步，沉淀一些经验和想法，方便后续人继续在此基础之上不断优化和前进，将自动化真正用于加速落实在质量保障的道路上。

02、框架选择

工欲善其事必先利其器，这里花点篇幅介绍下 UI 自动化相关原理，虽然网上一搜，犹如洪水般涌入，内部 KM 介绍和讨论也从未停止一刻，此处还是简单介绍下，方便后人结合自己实际情况快速来抉择相关方案 。

1、业界框架：

• 桌面端：AutoIt、Selenium、Puppeteer、Mocha、Pywinauto、Sikuli；
• 移动端：UIAutoMator\ Instrumentation\ WDA \Appium \XCTest。

2、内部平台：

• QTA：集框架与平台于一身的自动化平台，内部使用较大的平台；
• 智研：测试堂有着更丰富的用例配置方案，类似 QTA 平台；
• Testone：包含了使用 Web 同源自动化测试框架 DWT 和基于录制回放的前端自动化测试框架 Rua；
• Wetest：主要提供终端设备和相关自动化测试方案。

3、其他方案：

• AirTest
• 自研 SDK
• ....

这里列的并不是所有自动化框架，包括新框架如 liteapp ，Flutter 均有对应自动化框架，这里仅列举使用和了解过的框架，每个框架各有特点，可以根据实际需求和技术背景选择合适的框架进行桌面端自动化测试，如果团队大力支持的话，可以自研框架，结合业务深度定制，这样可能比通用框架更加灵活方便，如果自动化初期，投入人力较少，则可以考虑下公司内通用平台，能够解决除自动化本身外其他配套问题，比如上报、集群、报告等等相关内容。如果是开发团队负责自动化内容，则可以使用业务同源代码相关框架，如果是测试团队编写的话，使用常用的三板斧如 Python，JS，Go 等；假如手工测试用例比较规范，如场景、步骤、校验点都是模版化，则可以参考一下相关 copilot 进行训练，朝着 AI 方向迈进，自动生成用例，公司内部也有一些尝试。但现实往往是什么都不会给你，那从内部实际业务出发，拿来主义也并不是一帆风顺，适配过程中也存在一些问题：

• 桌面端：

在项目初期时，参加了 Web 自动化 Oteam，桌面端直接使用了 QTA 平台，贡献了涉及 electron 里面嵌套 Web 相关内容。桌面运行初步运行还是比较顺利，基本把用例跑起来了，结合实际应用情况，在初期的时候存在不少问题，不过这些问题均为小问题，在铺量自动化过程中也逐一解决，详细解决方案可参考早期的关于自动化文档。经验证与调研，选择了 selenium 和 QTA 平台相互结合的方法，即在 UI 自动化方式使用 selenium 来编写，同时在子类中重写了相关函数，比如截图，废弃之前的 ImageGrab.grab 方式，直接采用 selenium 中 driver 的 get_screenshot_as_file 方法，也完善了 starStep 方法，将新子类产生的日志和截图上报到 QTA 平台，这样一来即满足了无头和执行效率的问题，同时也解决了报告归档管理、任务驱动等问题，无需建设相关自动化周边配套，只需关注自动化业务本身即可。

• 移动端：

文档在移动端主要以 Webview 方式呈现，anrdoid 通过 CDP（ Chrome devtools protocol）协议，通过 adb 方法调试 Android Webview 的方法，这是比较常见的方式。但是 iOS 比较痛苦了，都是一种常见的混合测试场景，由于流水线构建的都是 release 版本的包，不再提供 debug 版本的包，进行 H5 自动化测试时，无法开启 iOS Webview 调试进行 H5 自动化测试，这是摆在移动端上自动化的第一道难题。这里包括调研过越狱、图片匹配等各类方法，均不符合实际，后来无意间看到司内很多前端开发使用类似 whistle 等如 JS 注入或者增加调试代码的方案去提升开发效率，然后考虑到业务代码中增加调试代码，受限于测试人员的工作内容和调试组件对业务环境的安全性评估，需要测试、开发、安全等多方协商才能推进下去，稍有不慎就会引入测试代码引发功能问题，得不偿失。

但相比其他方式该方式是比较完美的方案，恰逢前端开始引入 freego 方式进行路由和管理环境，这让本不富裕的家庭看到了一线生机，即使用 freego 路由指定环境时，配置相关规则通过 append 方式引入一段注入的代码，从而避免与业务代码混在一起打包，该方案的局限性就是需要对每个环境配置一套 freego 规则，把所有涉及的 url 匹配规则都要填写进去，同时还有指定后台的 IP，产生的局面就是不同环境包括现网，每次运行前都需要切换 freego，此外后端IP变化后需要对应调整，存在的维护性，不过总的看来有方法比无法做强的多。

此外还需要额外部署一套提供注入 JS 的服务器，简称 chiiserver，开源代码地址 GitHub - liriliri/chii: Remote debugging tool，经过一系列的改造后，将前端用于调试页面的方式引入到自动化测试中，从而打开了 IOS 自动化测试 H5 大门，该原理不再赘述，主要是实现一套 CDP 协议方案，当然还有类似方式比如 vConsole、weinre 等就没有一一尝试了，其他内容如任务调度与平台报告，按照规定的格式都统一上报到 QTA 平台，统一了桌面端与移动端报告格式和内容。

03、开始尝试

框架搭建稳定后，开始按照优先级，结合业务侧整理出来的发布性用例，根据不同级别、是否可自动化等结合各类因素，不断开始覆盖场景，刚刚开始就像一批脱缰的野马，从简单基础的用例开始，开始去覆盖，在初期的时候，短期内开始覆盖了容易或基础的部分，同时应业务侧需求，需要将其发挥最大价值，从本地跑，到现网定期拨测，再到加入变更测试中。在早期的阶段，编写流程与执行流程都是简单而又朴素的，全是手工。

编写流程：

执行流程：

从上述流程不难可以看出，用例编写者或维护者占据了流程中大部分主导位置，即自动化的价值，完全是由他来决定，如果不及时分析问题、不及时修复用例、不及时更新场景，那自动化只能是自娱自乐，在很长一段时间内，各端的自动化发现的问题非常少，但是投入时间和人力都是持续的，但是在各个版本期间，几乎拿不来数据有多少 bug 是自动化发现的， 没有任何量化数据来佐证自动化的价值，相信这也是一些团队存在困扰的问题，假如开发、人工测试不去主动关注自动化情况，那必然是两条线，各自都是使用自己的方式来发现问题，有无自动化都对各自影响不大，归根结底可能还是自动化做的太差了。

也许在覆盖或者修复用例过程中，能发现一些异常场景，也是在群里反馈一下，反馈完后就默默去修复用例，没有规范流程，加上自动负责人可能负责十几个任务，根据没有精力去关注每次运行每个用例的情况，都是集中修复一波。此时自动化长期跑着，人力也是长期投入着，成功率也很高，但是发现的问题很少，有点麻木了，反观大家还是喜欢人工测试，虽然在人力成本较大的背景下，但是依然发现人工测试却是很香，其能动性、主动性、认知学习能力去发现问题，是自动化这种机械固化的校验是完全不比的，甚至写自动化的同学，也是非常渴望去人工测试，也不想去自动化，觉得自动化得不到任何反馈，得不到任何成长，盲目追求自动化测试覆盖百分比，把自动化脚本堆成“屎山”，大量充斥着类似 click、xpath 原始裸露的代码，除了写的人外，其他人基本看不懂，慢慢成为了别人眼中的二类代码，更别期望能理解报告结论，归根结底还是看不到自动化价值所在。

加上业务需求变更，新特性不断合入，需要自动化地方越来越多，很多人都期待自动化能发挥作用，让自动化来做一切人工不愿意做的事情，但出现的问题也越来越多。按照经典自动化测试策略，业务在增长型阶段，理应保证自动化轻量化，以便达到最大的效率，而现实中就是业务越增长，出现问题越多，就需要更多自动化任务来兜底，而自动化任务又需要更多人来维护，这是一种非常矛盾的境遇，归根结底还是自动化成本太高了。

那个阶段还出现了其他一些不可思议的情况：

• 谈 UI 自动化“色变”

UI 自动化任务，一个端或平台包括600个用例的任务失败了，假如成功率达到了80%，失败数100+，在发布变更时间只有十几分钟的时间内，谁都不敢鼓足勇气去看这些失败，更别提该还有其他端。

• 很多人都不知道有自动化

自动化任务流水线分散，启动方式千奇百怪，人员迭代快，知识都来不及传承，不清楚有没有自动化，怎么触发自动化，自动化能给我带来什么，能不能覆盖到新需求，只能看老需求稳定不稳定。

• 自动化完全是累赘

本来正常上线，只要测完新需求，确认覆盖率数据就可以上线，现在还要去确认自动化结果，即便铺看了也看不懂，根本无从下手，这让本不富裕的测试资源雪上加霜，麻绳专挑细处断。

上述介绍的场景是失败的持续集成，好端端的开局，结果一小心玩脱缰，搞的骑虎难下了，虽然过程也有一些优化，但犹如隔靴搔痒，各自为营，散兵游勇，在这里自动化的投入一直达不到平衡，而且自动化成本曲线跌宕起伏，甚至成本越来越大。

04、存在问题

上节笼统的汇总了一下自动化任务在持集成并没有发挥很大的作用，从表面来说，测试任务用例较多，运行完成之后的唯一出口落在脚本维护者上，而维护者他主要任务是维护成功率和尽快覆盖更多的用例，使用者与维护者没有任何交集，两者分别在两条平行线上运行，这样导致自动化的价值是需来使用者取得，说到这里又跟当初引入自动化的初衷背道而驰，个人认为这种价值观是有点歪的，理想而正确的价值观是谁使用谁来维护，自动化理应直接面对是业务，而不是面对着使用者，而要真正改变了这种的状态，才能良性发展，盲目去追求自动化测试用例覆盖百分比和稳定的成功率，只会在表面上让使用者感到更舒服，但不表明它是一种更有效或更高效的方法。

长期积累的自动化用例，体量庞大，维护艰难，有效性低，即便全部执行通过也无法安心发布，食之无味，弃之可惜，进退两难，人力成本丝毫没有变化，相反还要在自动化上面继续投入人力，属于亏损的情况。前端自动化的测试人这段时间是非常沮丧的。事已至此，要么继续浑浑噩噩，要么继续砥砺前行，回到当初做自动化初心上面，认真汇总一切阻碍自动化发展细枝末节，这里简单举几个例子一起来看看。

1、业务杂，用例多

按照测试金字塔的理论，端到端测试自动化处于金字塔的顶端的，理性用例应该越少越好，但是不容易发现问题，只能越写越深，越写越复杂。

• 测试类型：前端变更的发布环境测试、客户端版本的发布环境测试、特性需求的特性环境测试、daily 例行的现网拨测；
• 业务种类；
• 覆盖端：Windows, 、Mac、IOS 、Android、Web。

2、合流多，摧毁大

正常通过率96%，只要一次合流摧毁一半，甚至全部摧毁，一夜回到解放前，前期频繁合流，周期不固定，导致功能、布局、接口、启动等基本全受影响，别说自动化了，其他功能、专项、性能、安全等均需要重新测试。

3、效率低、成本高

这里涉及到效率低问题就太多了，无法一一列举，基本每个环节都要都存在效率低的问题，包括用例理解、用例编写、任务运行 、环境确认、执行效率、问题定位 、问题确认 、问题提单等，每个环境每个坑均踩一遍，这里篇幅有限针对每个环节仅列举一个痛点情况。

• 用例理解：

由于不是持续参与业务，无法完全理解业务全部特点，测试用例自然是用手动测试人员的语言编写的，其他人将其翻译成自动化脚本，需要理解成本，很多时候都没有完整属性描述，比如前置条件、步骤描述、预期结果等，也没有完全列完细化校验点。

• 用例情况：

路径-->打开文档，检查-->正确显示所有工具按钮。

• 实际情况：

工具栏显示方式有二种情况（简约、经典），按钮和布局均不同，工具栏以何种姿势才算是正确显示，经均需要二次转化后来编写自动化脚本。由于文档的频繁变更和新需求的增加，发布性用例复杂冗余，维护成本也很大，手工用例的编写无明显的规范，现在很多部门开始格式化用例，比如四段式用例、再比如Q手团队的用例层级清晰(epic：用例类型 feature：项目类型、scenario：用例名称、given：前提条件、when：用例步骤、then：预期结果)，从源头开始规范用例结果，方便用例自动生成，编写自然语言用例时，结合大模型辅助技术，即可生成稳定且代码脚本结构的化的用例，非常期待那个阶段的到来。

• 用例编写：

早期粗狂发育，用例编写非常随意，大量重复代码、无规范封装、硬编码，这让接手的人根本无从下手，维护非常高，如果元素调整的话，需要从万花中寻找对应地方进行替换，如果是前置步骤的话，则会需要替换多次。

加上移动端与桌面端分别有自身的框架，逻辑封装与用例编写的原则就是“丰俭由人”，有无校验点，有无有效的封装，均不可知，用例结构存在很大的问题，没有任何规范或者手段来指引或者指导逻辑或者功能封装，甚至相同辅助功能逻辑，移动端与桌面端分别需要设置一套。

很长时间内非常想去统计一人力的情况下用例覆盖速度是如何，很可惜得不到最终的答案。假如业务理解、数据充足、环境问题、框架封装完整、控件容易识别、校验点易发散的理想情况下，自动化用例编写条数平均可达到30条 case 上下，每个 case 可以覆盖一个或者多个手工用例场景，把相同场景或路径，融合在一个场景了，只是加上不同的校验点，假设一个 case 覆盖2个功能用例，即理想情况可覆盖60个手工测试用例；可现实情况就是不理想，存在各类问题和复杂的场景，就让人抓狂了，比如这个场景：A 创建文档，邀请 B 加入，设置 B 的权限为仅浏览，检查 B 打开文档，权限显示正常，B 邀请 C 进入文档，C 打开文档，权限显示正常。还有其他一些常见问题，比如不断言、过度 sleep 和硬编码问题就不细说了。

• 任务运行：

除了大量任务会在早高峰之前完成一次拨测，即6-7点期间全部跑完外，更多的应用场景就是在测试、灰度、个性环境运行发现问题，任务运行存在各种令人抓狂的事情。

• 触发方式：

初期运行方式人工 at 机器人或者直接驱动流水下跑任务，由于每个品类配置独立一条流水线，使用者需要收藏十几条地址，经常出现启动的任务不是想要的任务类型，也不知道这次变更内容，有没有对应测试任务，导致任务运行与变更单无关联，加上每个端完全时间不同，一次触发，消息推送到群，一天内20个人使用时，导致消息漫天纷飞，每个人都屏蔽了群消息，很多情况下，任务运行中断了，都无法感知，还在痴痴的等待。

• 无暇顾及：

现网运行想要达到目的是早于用户发现问题，而不是等到监控告警和反馈，如果基础场景或使用人数少的新功能失效时，需要及时上报，高优先级处理，而实际情况的任务太多，等到逐条来看，已经基本失去了意义。

• 环境确认：

理论上只要测试环境稳定，剩下就交给自动化运行即可，但是测试环境有个特点，同步更新成本低，修复 bug 或者自己新增代码，都可以反复更新镜像，会导致任务失败率高或者自动化跑在旧代码上，意义不大，均需要反复重跑和人工确认，加上业务特点，还需要验证离线包测试，不同环境加载的离线文件需不同，每个用例需要检测当前品类是否拉取资源包是否正确。

• 执行效率：

整体运行耗时过长，让人失去了等待的耐心，拉包、装包、登录、切换环境、用例初始化、Sleep 操作、用例重试、场景构造，再加上设备资源不足，在高峰阶段容易雪崩，运行时间和等待时间过长都延时每日更变上线操作的时间，让人处于无尽等待中。执行效率是非常重要的，随着不断铺量用例，用例来越多时，除了配置合理硬件测试资源时，执行策略、执行提速需要重点考虑，否则臃肿不堪。

比如：耗时9174s，这让操作变更单的人何其痛苦，如果接入了变更流程，更加上痛上加痛，痛不欲生，因为没有跑就不能下一步，时间太久又等睡着了，成功率太低也无法下一步。

• 问题定位：

大量的堆栈报错是语法报错，非编写成员基本看不懂，无法直接判断为是否为功能问题，即便是用例编写人，看到堆栈后，依然要回到 IDE 中反复对照上下文来定。不管使用何种方法生成自动化用例，最终都落在执行脚本或者机器码上面，因为不注入不嵌入的情况下，每个 App 都有一种配套的驱动 Api 与 App 本身进行交互，因此各端不同 driver 都有不同的语言实现版本，而每个语言又有本身语法和特性。软件理论提出，即便再完善的代码设计，依然无法完全避免所有情况下异常运行，自动化脚本运行场景，相当于是干扰第三方 APP 情况，发生异常情况概率非常大，发生异常后通常抛出了一堆堆栈信息。简单举几个例子：

案例1：AttributeError:"NoneType' object has no attribute 'text'

使用者与维护者矛盾往往非常容易在此处爆发，一方面是维护者尝尝抱怨使用者不去看报告，只关注成功率，另一方面使用者理解能力差异，导致无法完全理解，普遍存在发现了问题，由于看报告成本高，无法一眼能识别出是否是功能问题，导致了忽略问题带上现网，等到第二天现网维护者定位时才确认出来。因此很长一段时间盲目追求覆盖用例占比，沉迷于较为高的成功率时，反正忽略了如何更快的发现问题。

这里还有一个尴尬问题是由于历史原因，无法将存量的自动化运行结果与手工用例无法一一关联，一是无法得知目前自动化到底覆盖了哪些内容，覆盖占比如何，剩余未覆盖量大小，好评估人力；二是此时覆盖了哪些功能，有哪些功能是手工测试不需要再过了，如果能关联的话，那手工测试时，就无需关注是什么原因导致的失败，统称为失败，把成功的用例排除掉，只要是失败的用例，都重新过一遍验证一把，有问题的就提单；唯一受到影响的就是用例维护者，他不清楚那些用例要修复，哪些是问题，也是一股脑的修复，这样的一股脑对于两边来说都存在一定的成本，结果就是两败俱伤。

05、实践案例

在上一节详细列了自动化在当前业务应用的每个环节出现的问题，还不包括设备环境管理，比如执行节点系统崩溃和云测平台设备异常问题。此处呈现具体问题的目的也是说明自动化并不是想象中简单，希望能够引起自动化人群的共鸣。通篇文章整理下来基本还是传统自动化的成本的具体体现，只是落在每个业务上面具象化了而从影响了效率。虽然总结自动化成本的时候，我们总是刻意强调最昂贵的人力成本，其中人力成本包括了工具平台建设的支持、专业技能即编写和维护用例的成本，但是可能往往忽略了设备资源的成本，这也是非常大的一块成本。经过不断反思和汇总问题，汇总如下的解决分为三个方向的解决方案，致力把前端自动化测试重新建立起信心。

5.1 流程规划与结果优化

测试框架的灵活和整洁有助于维护自动化用例的提升，统一框架和规范是避免不同人员更迭时，按照自己的思路塞入更多的杂乱的代码，导致自动化脚本变成了“二类代码”，为何不妨在自动化代码不要作为脚本代码，而是作为常见"正规代码"，那首先就需要提高其整洁度。

• 横向与纵向统一

横向：各个业务在同一个平台的底层全部采用同一份代码，复用优化与，一处优化处处有效，降低基础维护成本，比如各类驱动的升级优化、客户端初始化操作，举个例子，邮箱、文档操作前，都需要登录，该登录过程完全是相同，减少底层框架和业务通用逻辑的维护。

纵向：相同品类在不同平台上面运行，只区分端 PC 和 APP 端，只需要一份自动化用例，以 doc 为例，需要跑在 Web 浏览器、企业微信 Win、Mac，修改用例下层的基类，调用不同的平台的基类自行适配，对特殊平台表现如系统文件选择器等，仅特殊处理即可，避免一个手工用例，仍需要写三套自动化脚本，放大工作量。

platform_type = config.Platform_Type
if platform_type == PLATFORM_WEB:
from wedoctest.wedocapp.web_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_WIN:
from wedoctest.wedocapp.win_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_MAC:
from wedoctest.wedocapp.mac_test_case import WeDocBaseTestCase


class LaunchWord(WeDocBaseTestCase):
"""
    word 各端自动化用例基类:兼容 mac、Windows、web端
    """

• 控件定位与操作

控件定位是 UI 操作的频繁的操作，也是影响自动化不稳定最大的因素，采取措施时优先控件属性定位，执行速度快，属性频繁变动改成使用图片模板匹配类似 AirTest，或者采用本地化的 OCR 策略，优化控件查找，逐步采用分级策略，业务功能热区进行使用更稳定的匹配方法，或者其他执行和获取属性方式。例如 Web 的 xpath 通常直接拷贝，生成完整的 xpath 路径，一是太长了，二是页面任何节点变化，都会有影响。目前需经过人工修正到最大匹配相对路径，尽大程度保证空间定位不随页面其他节点调整而变化；同时为了尽量减少控件操作，借用业务本身调试来实现，简化控件定位和操作。

1、常用控件的 XPATH 都会发生改变，采用模板匹配：

2、在 Web 形态的业务上，引入 JS 方法，获取控件属性通过产品本身的功能来获取，尽量减少为了校验而频繁操作控件。

为避免频繁升级和合流的导致全部摧毁自动化，文档每个品类的均汇总一些JS指令来辅助自动化操作，每当摧毁时只要及时汇总成 JS 变动，让研发来协助对应指令修正，即可快速的恢复成功率，甚至准备提测之前，以自动化任务运行结论为准，提升自测的质量，避免存在大量的功能问题，依然需要人工介入测试，降低测试人力成本。同时将移动端拼接指令的脚本改为桥接模式，和 PC 端共用一份命令文件，一次改动，各端受益。

3、在原生客户端的通过开发框架上面的调试能力，直接执行相关代码，实现相关页面操作和跳转，举个例子移动端自动化需要在各类环境上运行，是需要在已经准备好的离线包情况运行用例；导致频繁切换环境后，需要进入调试菜单点击清理离线包，然后下载离线包，该操作路径过长，经统计此路径一是耗时，二是步骤较多，容易出错，通过远程调试执行的 oc 代码采用命令解释器或者 adb 方式实现按钮点击能力，是实现 UI 层面上的操作（备注该功能仅在蓝盾测试包开启）。

而 Android 更为简单，则在注册广播和实现逻辑，然后直接可使用 adb 命令来实现相关功能。

val filter = IntentFilter()
filter.addAction("com.tencent.wetest")
WwUtil.APPLICATION_CONTEXT.registerReceiver(QMInstructionReceiver(), filter)

拉取更新

adb shell am broadcast -a com.tencent.xxx--es action "sync_server"

点击按钮

adb shell am broadcast -a com.tencent.xxx--es action "click_accept"

拒绝按钮

adb shell am broadcast -a com.tencent.xxx--es action "click_reject"

待定按钮

adb shell am broadcast -a com.tencent.xxx--es action "click_pending"

• 用例编写规范和提速

1、代码的封装：

1）测试用例的描述层

2）测试试用例的实现层

3）测试用例的接口层

2、用例特点：

1）用例之间必须独立；

2）运行结果必须稳定；

3）运行速度必须快。

3、 合格用例标准：

1）清晰的说明：用例优化步骤描述，每个控件操作自动调用截图，便于完善报告显示，这也是用例的描述层，用于人与人之间的沟通交流，让每个人都知道这个测试的目的与内容。

2）稳定的操作：用例的操作不仅包括前置场景构造、当前场景 UI 操作路径，它是将上面的描述层与程序脚本对应在一起的，是一种测试意图的体现，需要更加灵活去封装与业务操对象操作，举个例子：对于 Word 工具栏操作，我们将基础的操作（加粗、设置字体、设置背景颜色等等）进行简单的封装

在用例中使用时，可直接调用，当不同的用例编写者同时写用例时，不需要了解这些方法的实现过程，直接调用即可，而且这些基础方法的改变，也不会影响到已有用例执行逻辑。

self.startStep('设置加粗')
logic.set_bold()

3）完善的校验：在早期的时候，很多自动化用例都是逻辑自动化，即都是操作 UI 界面，并没有添加校验点，导致很多场景虽然覆盖了，但是没有得到有效的检测，及时页面弹出了提醒框，依然显示未成功的状态。为了避免自动化用例没有校验点，要求每个用例均要合适的校验点，在代码提交 git-hook 配置中，添加了检查规则，对着 testcase 文件夹的用例文件，新改变的行数，往上推导到用例名，判断当前用例是否包含 assert 相关校验，没有则进行相关提醒。考虑到很多不同场景下，很多最终的校验点是一样，同时覆盖的过程中又发现很多操作类似或者相同，因此分别统计各个子表（功能）下操作占比，针对占比比较高的模块，将操作步骤和校验点进行聚类，聚类的情况来指引那些高频场景和校验方式需要封装，方便覆盖其他用例时，快速使用，不要反复思考和重写。

4）引入代码辅助工具，旨在提供智能的代码补全和生成功能，得益于前面步骤的封装和规范，在后续新的场景补充时，只要先写入注释和意图，一定程度上生成一段推荐代码，加速脚本编写过程，复用已经生成好的逻辑。

5.2 流程规划与结果优化

除了将如何提升手工用例转化到自动化用例的速度和效率，降低编写与维护成本外，如何规范自动化任务关注和使用流程，同时让测试结果能够达到参考目的，让每个关注自动化的人能否理解执行结果，辅助自己进一步判断，解决测试结果可信度低、理解成本高的问题。

• 任务闭环

解决方案：订阅系统；

解决问题：任务未运行提醒、任务成功率低拉群上升、任务结果、问题广播、消息收敛。

自动化任务是跑的越频繁，其价值就是越高的，如果不跑的话，那就得不到关注，而得不到关注，就无法展示其价值，如果只自己关注，则无法扩大价值。同时关注必然带来大的成本，每天现网拨测任务，如果出现问题，则就是现网的问题，任务接入订阅系统，一方面提醒未运行的问题，第二方面就是及时提醒自己发现问题，从维护者角度去发现问题，及时关注与处理，避免了自动化任务持续的恶化，同时发现问题后，同步广播到相关订阅人，进行信息同步和共享，避免信息封闭阻塞，最后针对高敏感任务，通过率低于设定的阈值，则要求15分钟内分析出原因，否则拉群上升处理，该功能在文档融合初期，发现多起基础问题，此处是为了避免产生“破窗效应”。

• 运行规范

人员更迭，环境和任务多样，需要统一触发方式，前端自动化不同于单元测试或者协议测试，可以自动结合到研发流程中，比如同步部署、Commit 或者 MR 阶段，因为其运行效率问题、需要完备的运行环境和稳定的链路。对于未完备的文档变更运维流程而言，依然采用了简单朴素的方式，规范运行方式，解决了使用门槛，将变更信息与任务运行进行关联。

只需要指定变更单号，测试流程主动跟进上单品类和功能，拉取各个平台任务组装运行，四端运行完成后，整体推送汇总，尽量做到变更单测试任务时间通常控制在20分钟左右，腾出部分时间让操作变更单的人来分析报告并标记失败原因。

• 报告优化

自动化报告是在自动化尾端汇总结果，其易理解是给使用者带来极大的帮忙和兴趣，在易理解的基础上发现了问题，则对自动化任务认可有极大的助力；上节提到了使用者包括业务测试和研发同学，每个人熟悉领域不同，如业务测试熟悉手工用例，开发熟悉代码的语法等，在维护者与使用者不是同一人的前提下，让更多人有兴趣来查找问题，变得极为重要。

1）重新自定义报告：参考 QTA 报告平台，在已有显示结构基础上自定义一套自动化报告，该报告统一了移动端和桌面端形式，采用完全一套的风格，尤其避免了移动端需要访问 wetest 平台并结合下载 zip 包配合查看报告的极其复杂的报告流程。

用例描述完全采用了手工用例描述，容易理解。

采用各个维度排除干扰，缩小范围，如只看末次、排除现网、排除指定分类。

hover 错误信息，显示最终校验错误，快速发现问题。

2）报告错误自动分类：自动分类是在报错和堆栈信息非常明确的基础上，优化报告报错内容，例如早期完全看不懂的报告，变得简洁和方面验证，让每个不参与编写自动化的人，均可以看懂报错的内容，每个人都可以从报告中发现问题，另外相关错误自动聚类，可以集中快速找问题。

通过用例失败原因标记，可以达到两个目的，一是标记为用例问题的问题后，标记有效期内不会运行，同时及时汇总用例问题和分析推送给维护者及时进行关注，待确认和修复后，重新上线运行；二是加强手工测试与自动化维护者之间的互动交流，缩小关注问题，同时及时将发现暴露出来，统计当前这次测试任务的价值度量。

3）报告一目了然，更多详细完整操作步骤，前面历史对比

4）发现问题一键提单：发现问题及时提单闭环跟进，避免问题丢失和反复出现，提单信息包括用例信息、步骤、操作流视频、堆栈信息、预期前后截图、case 对应机器日志，账号、环境、版本等基础信息，解决发现问题后收尾一些复杂的工作。

5）评估整体覆盖情况：鉴于目手工用例的局限，没有上系统标准化，暂时无法改变，不过唯一能改变的就是我们自己。自动统计了每一次任务运行后，覆盖当前全部用例的情况和占比，大版本发布期间，可以跟进覆盖情况选择性手工覆盖其他模块，让自动化测试也成为辅助工具和手段。

• 运行效率

执行效率是每个自动化必须考虑的问题，随着用例量不断增大，如何在有效规定的时间内完成一定数量的自动化，即将成为一个考验。

1）用例分类：从功能角度、平台角度、端内端外角度，打算自动化用例，标记属于哪一种类别，上线变更时，跟进发布的内容选择对应标签下的用例组装用例，避免全量运行所有用例，当然也可以解决覆盖率的策略，选择仅有影响面的测试用例。

2）执行策略：在用例规范的基础上，依赖 API、调试、JS 等手段来提前构造场景和清理数据，提升用例执行速度。用例之间数据独立，互不影响，同时减少类似 sleep 等常见的等待方式。

举个例子：文档离线包策略神龙见首不见尾，启动程序后，正常情况会默认拉取资源，由于在变更环境，需要先切换环境，然后再拉取离线包，看似普通的逻辑，在测试之前需要多个调试彩蛋的组合，甚至有一些端，重启后，又把离线给删除了，这又让原本苦不堪言的自动化雪上加霜。经优化后，直接依赖调试接口，直接下载新的离线包的情况，缩短多、复杂、不稳定的辅助步骤。

3）设备资源：充分利用设备资源，针对 Window 客户端内自动化，尽快复用账号，避免客户端反复切换登录，同时运行多组 Web 端自动化用例，将紧张的 Window 资源充分利用起来。

5.3 团队协作与用例共享

1. 创建和维护自动化测试任务 ，共同确定自动化覆盖的目标和方向，优先针对共性问题多、高风险、有潜在问题或者容易被遗漏的进行重点建设。
2. 共享自动化用例，共同使用，可以创建属于自己模块专属任务；每个版本同步自动化建设目标和优化方向，同步分享提效方法，收集多方反馈意见。
3. 研发共同关注，借助调试框架提升测试效率。

06、阶段成果

自动化测试永远没有全部胜利的那一刻，即便有的话，也是阶段性的，只要你的业务继续发展，自动化任务就要跟着变化，否则沦为负担到最后又是放弃，经过几个月的梳理和优化后，在一定程序上改变了一些旧局面，提升了编写、维护、发现问题等各个环节的效率，但距离短期内将4w+用例转换为自动化用例的目标仍有一段要走，但是我们无法抛弃业务、脱离业务去建设框架，这样的框架最后应用到业务中也可能是水土不服，因此这里的改善后的成果仅是阶段性，这里做个简要的汇总：

1、 缓解手工测试压力

• 核心业务覆盖覆盖用例占比70%+以上

这里提一下我们的现在发布性用例依然还在散落在个各个在线文档中，用例编写风格千奇百怪，具有非常浓厚的个人色彩，每个任务运行结果后，拉取在线文档标记的用例进行统计，一是方便查看当前任务覆盖占比，二是让使用者针对性关注那些仍未覆盖的内容。

• 从万人嫌弃到逐渐认可，尤其是结合每天变更上线的自动化，成为前端单变更上线必不可少的重要环境之一，通过率基本可93%以上
• 流程和效率提升，更多人愿意使用

对报告结果形成互动，主动发现问题，研发侧也开始使用，改变仅测试团队关注任务结果，开发团队也关注前一天代码修改对新包的功能影响，提前发现问题达到及时修复，避免更多安装后发现无法使用，此外还前置到个性环境测试或者作为相关品类稳定性指标，作为提测的质量评估。

• 发现问题变多，提升团队自信心，告别前期版本发现问题贡献较少局面，尤其是临近发版，每天早上都能发现新包主场景问题，优先提出，避免卡主测试主流程，影响测试进度。

辅助一键提单能力，统计近1个月多数据：发现 BUG140+，严重问题60+，彻底解决了发现问题只能群里反馈，而无法闭环跟进的场景，同时也记录相关任务的价值量化数据，也方便后续对比现网反馈，分析自动化覆盖的质量和需要继续完善的地方。

• 所有自动化日均运行次数150+次(不排重)、用例库总数33+个代码地址库、主干分支上自动化用例总数6000+

降低维护自动化成本，让自动化工程师更加专注如何将手工用例转化成自动化用例，而不是花费太大的成本放在维护和寻找自动化价值所在的地方，通过完善各类流程的方式，让一个维护者能够负责更多更复杂的自动化任务，减少维护者的成本。

2、提升测试效率，降低维护修复成本

• 健康度的提升

提升变更测试环境中运行稳定性，提升了健康度，解决在用例大量失败的情况，无人关注的尴尬场景，核心任务现网要求的成功率为90%+，经过治理后，在无重大更新情况，变更环境也能到95%以上的成功率。

• 用例标准化（可读性、规范性）

1）规范化了自动化用例编写的流程和步骤，给出了相关操作的封装原则，解决业务频繁换框架、人员更迭，能够快速响应。

2）降低了阅读门槛，使用者不仅查看报告，也可以轻易打开对应自动脚本，辅助理解和提出意见。

3、借用自动化能力扩展专项

• 性能相关：耗时、流畅度、内存、CPU；
• 稳定性：Crash 检查；
• 其他：协同编辑丢数据检查、白屏、统计等。

4、自动化测试经验的沉淀

• 自动化测试用例运行次数越多，平均成本越低，收益就越大；
• 自动化测试用例之间应该尽可能相互独立，互不影响；
• 破除自动化测试用例的数量越少越好的尴尬局面 ；
• 不断探索提升效率方式，同时解决用例之外周围效率问题；
• 将已有的测试经验和框架平铺到新业务或者其他产品里；
• 如何放大自动化测试的收益。

07、总结展望

在内外网上可以找到成吨的关于自动化测试的内容，包括如何健康测试、测试类型、测试投资、测试策略和框架，但是具体到现实不同业务中，表现就千奇百怪。如业务需要质量保障，那需要进行测试，除非能保障开发出来一个问题都没有，面对千万人的产品业务，谁也不能保障没有问题出现，对交付频率的要求越高，希望前置周期越短，自动化测试就越为重要，道理都懂，但在实际内容中，可能出现在自动化上的投入的人力基本直接执行手工用例的人力不相上下，时常引发思考自动化尤其是客户端这类自动化到底有何意义，除了自动化方法我们还有其他方法来保证和兜住质量问题么 ？思考良久，如果非要给出一个答案的话，那就是人，人能做一切，既然自动的不行，那就人工上吧 。

文本开头繁琐介绍了各个团队的可能出现在自动化上的困境，接着不断列举出了自身业务中自动化各种不尽人意的表现，从而给出来看似有效的解决方法，但是这些并不是通用的方法，也不是最终的方法，只是在坚持与放弃之间的妥协之道；思来想去，真的解决方法还是需要结合业务不断探索不断优化的那个激情和使命，文章结尾也给了阶段的成果，深知自动化测试胜利的最终目标就是保障质量，同时降低人工成本，新需求开发完成，立马自动化跑起来然后直接发布，目前革命尚未成功，仍要继续努力奋斗，再累赘总结几点：

• 绝不能脱离业务：业务和框架都是不断更新迭代，任何在质量提效的工具和平台，决不能脱离了业务，不能抛下业务不管而独自研究框架，而先应用到业务里里，需求来源于业务。目前负责维护自动化人，在发版期间积极参与业务测试，包括专项测试、需求测试和发布性测试，深度理解产品和业务，同时也让自动化测试任务尽快多跑起来，多人使用起来，多人参与起来，发挥其最大的价值，用例维护者、任务使用者每个人都在工具和平台上找到属于自己的价值。
• 打开自动化思路：需要清楚当前自动化建设阶段和阶段的目标，在业务上产生效果，然后不断引入和探索新的自动化测试新方式。即便短期内无人力探索更高级更前进的快速自动生成，但仍不断优化和熟练技能，提升转化速度，优化执行效率、发现问题效率等，这些也是自动化建设重要一部分。假以时日，大模型更加成熟，等到用例格式更加规范，快速适配，也不用再经历一次多而无用，用而无效的场景，自动化测试目的是兜住和发现问题，并不是一味追求量多全覆盖，而是放在更容易出现的地方，频繁需求更变的场景，所以要打开思路，不要觉得自己的自动化工作很 low，如果能高效的发现问题，确实值得做下去，同时不断尝试新的方案，提升自己，不能自暴自弃。
• 重视自动化价值价值决定可持续化的发展，前期盲目覆盖却忽略统计这里的自动化数据，引发了是否放弃的大量探讨。有相关统计数据的度量，就可以衡量相关建设的质量和目标，有针对性有的放矢。此外建设好的自动化框架和测试业务的代码，同样也是拥有潜在价值的内容，不能以二类脚本的定义去描述它，更应该以正规的程序代码更高规范来要求它，更后续方便知识经验沉淀和不断发展。
• 健康管理自动化自动化测试是一个长期攻坚战，业务未停止，测试也不会停止。需要以积极和健康的心态去维护和管理自动化，阶段性指定目标和回顾目标，健康长期发现，罗马不是一日建成的，边建设边发现问题。

最后鉴于本文太过于繁琐，对能够一直坚持忍受并看到的文章最后的人表示感谢。同时对测试框架优化支持的研发表示由衷的感谢，自动化道路深且长，有你们的关注，会让这个夏天更加灿烂。

-End-

原创作者｜黄飞

你觉得实现自动化测试的意义在哪？欢迎评论留言。