小菜鸡我说下自己的想法～落地一般是为了解决问题，我这边项目是用来做开发提测的卡点，做了 UI 自动化验证提测的包是否主流程通过。
建议先评估目前已有的问题，是否确定能够通过 UI 自动化去解决/有无其他方式/产品的迭代是否稳定，评估可以使用 UI 自动化后先梳理下整个流程。如果期望代替部分手工回归功能，那要先制定好 UI 自动化覆盖的场景、触发自动化的路径、框架选型等，就当写需求文档一样先把你期望的方案写一下～

1. 写方案（场景、路径）
2. 评审方案【个人觉得前期评审方案非常重要，不然你可能好不容易干完了结果大佬评估你这个流程有问题要重构，评审整体流程以及 UI 自动化的场景】
3. 执行方案（技术选型，分 APP/web/PC 桌面端/小程度）如果你是自动化小白，选好技术框架后可以先从框架教程走起
4. 看效果，持续跟进

自动化框架现在行业内挺多的，我这边是 appium，用 PO 模式。这些跟着 appium 教程学一学应该都大同小异

1）先算好 roi 自动化脚本的编写和维护成本 与人工覆盖的差值 高于的话 再考虑 2）看楼主的选型是在做 web 的自动化 那么对多浏览器多版本的支持也需要考虑过进来 3）对线上问题进行分析归类 看看大部分问题是在接口层还是 ui 层发现的。如果是业务逻辑为主，那么优先落地 api 自动化会比 ui 自动化的价值更高

先找几条冒烟 case 试试水

按照你们项目的实际业务特点和技术栈选项进行，首先是需要把基础用例写好，然后提取部分可以自动化的，进行自动化测试回归。

技术框架，我说下我的粗浅的认识，供参考。

• 如果是 APP，用 Appium+Python
• 如果是 WEB，使用 Selenium+Python
• 如果是小程序，使用 Airtest 或者 Minium
• 如果是接口，使用 Pytest+Allure

设计模式大部分都是 PO，你也可以自己思考符合你的方法，这个没有标准的。

接口的比较好弄的，UI 的太麻烦了
先统计一下要回归的流程，再进行技术选型，框架编写，用例编写

楼上大佬们都说的很全面了

上来直接搞 UI 落地效果难以保证，建议先搞接口。

好巧，最近我也有这样的疑问。我一直想不明白的点是，我为什么要做这个 UI 自动化，我做了这个自动化对项目来说有什么帮助吗？明明测试步骤我都已经写在文档上了，但是就是每次要使用代码编写用例的时候，这个键盘就像是长了针尖一样，怎么都敲不下去

好的，谢谢大佬指点

好嘞，感谢

目前是打算先准备一些基础的功能模块来试一下

好的

主要还是为了提高效率，每次一到版本迭代，都要花很长时间来手工回归，太浪费时间，打算通关自动化来完成回归，把节省下来的时间花费在新功能的测试上，这样效率就能提高

ui 自动化测试落地，还是应该多思考你需要自动化测试给你带来什么样的效果，然后再思考 ui 自动化测试能不能达到你想要的效果，如果可以达到，就去按照你的想法实现，实现过程中再慢慢优化就好了。
只有你自己真正的试过之后，才能找到适合你的，方法、框架都大同小异。

UI 自动化的落地，任重而道远

首先还是得看你自动化的目的吧。如果仅仅是为了跑主流程，在我看来没有多大意思，顶多是代替手工跑一个常规流程冒烟（这里我想问一句，如果自动化只回归个 P0 主流程用例，你们敢人工不再介入主流程就上线吗）。我现在自动化设立的目标是能跑大部分回归用例（尽可能多的覆盖所有用例场景），自动化执行以后测试人员不用再去仔细回归所有用例，从而达成提效的目的。框架什么其实随意，重要的是实现目的。接口自动化比 ui 自动化要容易推进的多，建议从简单的开始，想好了再做，不然重构麻烦的一逼

所有用例场景就是包括口单功能和业务流程用例吗（正向反向的相对数据），最近有在考虑先从接口入手，但是校验问题可能需要用到数据库，数据库开发那边不给，要协商

建议可以简单点，先别关注太多框架层面的东西，先把最核心的 1 个流程的自动化用例写出来、跑起来用先吧。

框架、方案、流程什么的都是正式立项时的事情了，而立项涉及到领导以及其他团队成员，有比较多不可控因素。所以我觉得，从实际落地角度，其实自己一个人先写起来、用起来是最简单可控的。有一定成果后再去立项，比从零立项，要容易得多。

调研后，看看适不适合使用自动化，考虑投入产出比去节约成本，这样推行也有利于自动化的落地

“目前因为版本功能需求的持续增加，每次版本迭代都需要手工回归一些功能，感觉效率非常慢，想通过 ui 自动化来提升这一块的效率”，据楼主的问题，建议：
1、理清要解决的问题，如：是需求不断增加，带来原有可能受影响的功能没时间测试，于是考虑自动化吗？如果是，则建议对原有功能设计自动化测试用例，但需一步一步地分析、改进，直到回答预期。
2、当某一模块的需求不断变化时，此模块的 UI 可能仍在变化，此时考虑自动化不太合适，因为修改脚本的 ROI 低。
3、自动化的实施，例如：如果仅是把原有用例脚本化，然后执行，很可能达不到目的。为了快速的试水，建议无需拘泥于用例，可自动化手工常需操作的功能、流程，然后人工分析自动化跑出来的记录，进而不断优化自动化的范围与方法，真正对项目发挥价值

测试也得从需求出发, UI 自动化是为了解决什么问题, 是不是只能通过 UI 自动化解决, 然后再去想方案设计比较好...
从我的角度看, 现在做模拟手动的 UI 自动化成本还是过大, 并且工具自身的成功率也不是很好保证...如果只用在核心的回归场景的话, 维护成本是下来了, 但是真的能发现问题吗, 有没有现成的只能用 UI 自动化的 case 支撑...别最后技术方案一顿输出, 落地大半年一个 bug 没发现还全是误报, 毕竟工具终究是为了价值服务的...

感觉前期不用想那么多，自己可以本地先干起来，实现那么一部分的用例，如果真的取得了不错的效果，节省了人力且团队也信任自动化用例的结果，再去考虑扩大用例范围，和团队成员一起，做大做强；