Mark
规则上确实有很大的优化空间

使用 DBNPP 插件：DBNPP 是一个 Notepad++ 插件，它提供了与多种数据库（如 MySQL、Oracle、SQL Server 等）进行交互的功能。您可以在 Notepad++ 的插件管理器中搜索并安装 DBNPP 插件，然后按照插件的说明进行配置和使用。

使用 SQL 语句执行工具：Notepad++ 内置了一个名为"Run"的功能，可以用于执行外部程序。您可以编写 SQL 语句，并使用适当的命令行工具（如 mysql.exe、sqlplus 等）来执行这些语句。然后，您可以将结果输出到 Notepad++ 中进行查看和编辑。

拿 exe 包试一试，还不行的话方便把 har 文件发我下吗，云盘还是 wx 都可以
不确定是不是 py 版本问题

选择是根据自身情况来定的，也不要让未知的风险影响当下的选择，不同地域不同公司不同岗位不同人这都是影响因子，思考好自己的能力，然后去选择就好了，有时不需要想的太多

你永远都有选择的权利，只要你愿意为之奋斗

你够不上后端的门槛，就意味着你本身的能力和自律程度不足，直白点就是混了个毕业证的程度，如果非要在这两个里面选的话我还是推荐测试

注意嗓子

怎么好使怎么来

前两天有人问带专和本科的区别有多大
今天我来问问渣本和 92 本的区别有多大
明天我再来问问 OD 和正式的区别有多大

三四线城市测试达到 25，真是吾辈之楷模
.....
看到你原来的帖子才发现，深圳/广州原来是三四线城市啊

你可以换个头像，昵称改成历史人物

第一，是否方便说下贵地的瓶颈是多少
第二，我在羡慕一线大厂大米的同时也看到了压力和风险

我看西安的市场还是可以的啊

不要轻易的否认自己，也不要轻易被别人改变自己。这是我昨天看的故事书里写的，也送给你
不要轻易的踏上一条不熟悉的道路，也许那只是一条独木桥

所以优先级是拿来干嘛的？你有空的话可以把全部功能过三遍，没空的话让你过一遍你都过不了

02:24 还在操作帖子，老前辈要注意休息啊

你自己看看你写的，除了你们组的谁能看懂实际代表的概念
线上 bug 多少算少：0 肯定算，但是很难做到
线上 bug 多少很难只用数字来计算，如果你出现了最高级别的 bug，那 1 个也是多的；如果你都是非功能性 bug，那一年几十个也不算多
给个比较宽泛的参考就是无重大问题出现，功能性问题小于 10，非功能性问题不重要
ps：这里的问题严重程度也要充分考虑对客户的影响程度

你真是全凭 GPT 来回答啊

图不错

着啥急，问开发啊，找 ETL 啊
不能动数据还不能复制下啦，联系要下 UAT 的数据

没必要，跨度太大而且给公司带来无收益的成本
你可以拿现有的开源产品逐步升级，先让领导看到效果，才能有后续

我的建议是：步子迈大了容易扯着 D

1.平台》框架》脚本集》脚本

你可以选择一步到位，也可以选择期望的逐步降级，先实现再升级

2.怎么校验？

曾经也做过一小段时间的银行业务测试，最大的感慨就是 “SQL 是真 TM 的长！”
当时也有想过自动化校验该怎么实现？
既然是校验数据，那数据必然是经过了一系列的处理，或者数据清洗
那脚本是不是要比对着该业务处理逻辑来对入参同样做处理，最后以脚本结果为期望去比对业务结果

那该怎么保证你的处理逻辑没有 bug 呢？

又该怎么能保证你的逻辑实现能力是强于 ETL 的呢？

如果不能保证，那期望就失去了价值，比对也失去了意义，做的一切也就是无用功

3.你的业务是否真的适合做自动化？

自动化的核心是 “重复”，而你描述的业务给我的印象是：漫长、复杂
这点我认为你可以实际的去梳理下业务线，确定下是不是真的适合脚本化，确定下脚本的维护成本和性价比

最后给你个建议：

遇事不决，可问 5W2H

市场越冷 差距越大！

是 PC 端软件的 UI 自动化吗？

总结：转行试水和买房入坑

内容如何不予评论，界面设计的优化空间很大，至少我是不太想用这个样式，记得之前有个开源的 Rabbit 平台设计的前端就很棒