比如你的平台用例就是一个 python 脚本，一个 js 脚本，一个 go 脚本。https://testerhome.com/topics/27297

一样的，你平台支持调度执行你做的脚本就行。本质上平台只是为了方便数据统计和过往回归结果统计。

羡慕，副业真难想 hhh

1. 系统是 jwt 设计的话，拿到 screct 自己就可以搞，去掉 expire 即可。

2. 如果非 jwt 的单点登录的话，在开始 ui js 脚本前，手写 request 前置登录即可。

嗯，后端数据逻辑本来就更适合做在接口测试里面，没必要跟 UI 测试耦合在一起。

所有 UI 所需的数据，都内置 mock 做处理。

而且虽然脚本是录制的，但是其实不是只能录制，本质上只是个 js 脚本的 string 类型，所以很多处理可以根据业务自己用 js 去适配写些功能，后面这块准备抽出来单独做个业务的数据工厂和业务的函数工厂。

反手就是一个怒赞 hhh

也感谢大佬的日常技术交流分享和鼎力支持 hhh

现在后端写什么鸭 hhh

大佬面前不敢当 hhh

你可以的 hhh 加油鸭 hhh

还是萌新 hhh

所以现在在做哪行

前排沙发打 call !

一起加油鸭 hhh

好滴鸭 hhh

申请开通专栏~

回放对比的时候，回放路径的所有中间件和数据库肯定要保持一致性，所以如果是修改适配中间件保持其一致性，成本有点高，还是做规则校验和 interface 层面的 fake 与 mock 更解耦一点。

是啊，落实下来工程量还是很大的

写接口是不能直接回放的，会涉及到很多数据操作和脏数据的问题。

如果要回放，需要代码入口处封装一层 fakeDB，然后实现 fakeSqlQuery，然后所有符合某种规则的 sql 都 mock 返回一致的数据。

1. 大部分人不会用自动化，所以这个就是平台做出来就是为了给不会代码的人用的，因为只需要在点点点的时候开启录制即可。

2. 业务简单的 点点点更高效，是点点点更快，但是回归呢？自动化本身意义是回归。

3. UI到底关注什么 首先是功能吧，我的业务需求其实是更关注埋点，当然功能也关注。

4. 我不提倡大家都一股脑去做什么平台，先仔细想想自己公司需求是什么，你怎么做能提高效率，这个你说的对，所以我这篇文章的核心其实是 从业务测试需求痛点到自动化测试平台设计开发，出发点要对，不然就是盲目开发，你应该详细看看文章。

5. 建议在工作中 找到提高效率的本质方法 万变不离其宗。当需求足够时 引入或者自建 改造 适用于自己的才是最好的。 对的，核心就是为了提高回归效率和测埋点的效率，所以这个平台就是自建开发适用于我们业务测试的平台。

分享出来的目的主要是两点：

1. 我是如何从业务测试痛点里面去找可以提高效率的点

2. 除了传统的 python/java + selenium/appium，我们还能怎么样做 UI 自动化平台

首先，登录问题可以用万能 token 做处理，对于所需的业务数据，其实用 mock 做处理直接返回，不需要真正请求到后端，然后只校验 UI 的正常显示，关于数据逻辑校验的还是放到接口测试来做。

断言的话，不用写在脚本里面，在用例里面配，不过确实要自己定位加，比如这样。

第一，自动化代码能够做到 修改一两处就能维护好这些受影响的用例，我感觉其实更花精力，还必须得项目很稳定。
第二， 修改一两处就能维护好这些受影响的用例，这种情况太理想了，更多时候 UI 是全部大改的，代码基本要重写。而且你要应用的项目不止一个，有 N 个项目都在迭代更新，真的能有这么多份写好的自动化代码吗？
第三，本身手工测试，就是要点点点，只不过这次，在 dev 环境点完了，开了录制，接下来就可以在 test / staging / release 上快速回归，不需要投入会写代码的人力物力。
第四，如果真的能够定位到 修改一两处就能维护好这些受影响的用例，其实对于录制来说，真的不用重新录，把某些改动的地方匹配替换一下就行了。

不用维护，哪些 UI 改了就重录替代用例，快录快用。目的是没改的快速回归，以及很多第三方的置入功能，比如 mock 比如 埋点监听 等等。

愿闻其详