人力成本降低 90%，那我想问，开去的另外 9 个人的工资都给你朋友了吗？如果没有，那他这么做的意义何在？

直接去数据库查询，一两条 SQL 不就搞定么？

我大概明白楼主的意思 ，大概就是开发那边没有专门的需求分析人员，开发人员不想自己看需求文档开发，所以就直接对照测试的用例来开发了，等于你们测试给开发做了前期的需求分析工作呗。

我觉得 8/9 楼这个说的很正确，怎么降低上手门槛，让不同类型的测试人员，包括开发人员都能够去使用它，比如功能测试人员可能技术能力较弱，人家可能会先从数据库查询一批数据，然后通过文件导入这种方式，自动化测试人员可能会使用 SQL 语句去查询，性能测试人员可能会使用模板造数（因为需要大量数据），开发人员可能就直接写 jar 包或者写脚本了。所以在构造数据这块，要提供尽可能多的方式以对应不同类型的使用者。这样对平台的推广比较重要。
另外就是与功能测试，自动化测试，性能测试，开发调试要更加无缝的集成使用，无需其他繁琐的操作就能享受造数工厂提供的能力，比如自动化脚本不管是平台化还是没有平台化，都能通过简单的方式接入造数工厂，开发在自己的单元用例中，是否可以通过引入你们提供的 SDK 快速接入造数工厂，这块都可以研究下。

这个逻辑方面我确实没有考虑到，可能但是更多的是希望在脚本里面对数据进行精细的处理，其他类似数据库查询，接口查询等只是抓取数据的方式，最后加工出来的数据是符合数据池数据结构的还是想依靠脚本去处理的。

功能设计的挺好，这也是我一直想做但是没做的东西，之前也设计过这块，但是苦于一直没机会开发，我分享下我自己对数据工厂/造数工厂的一些功能的想法：
1、可以新建不同的数据池（主要用于不同的测试场景，包括功能测试业务场景，自动化测试集，性能测试等），定义自己需要的字段，支持 string,file 类型,这个有点类似数据库的表；
2、针对这个数据池，配置池中数据的造数规则/策略，比如：池中数据量的最大最小值，满足何种条件时自动触发数据生成，定时触发生成策略以及池数据扫描的时间间隔等；
3、针对这个池子，可配置不同的测试环境，每个环境中的造数详细规则不相同（主要用于同个业务测试会在不同环境下执行）；
4、创建造数步骤，支持生成，还原，销毁，预处理这些类型的步骤，每种类型的步骤适用的场景不同，根据字面意思能够理解，比如生成就是生成测试数据，预处理就是数据提供给别人之前的处理操作；
5、针对不同类型的造数步骤，编写详细的步骤操作，提供尽可能多的方式来方便用户去处理数据（这里的处理包括生成，还原，销毁，预处理等操作），比如 groory 脚本执行器，MOCKJS，数据库 SQL 执行器，HTTP 请求器，JSON 提取器等，用户也可以自己上传 jar 包来编写造数策略；
6、除了上面自动化的造数策略，也支持手动新增，excel 上传等操作来增加池中的数据，支持批量下载导出不同格式的文件用于支持自动化测试（properties），性能测试 (csv)，开发测试 (json) 等，也可以手动触发生成，还原，销毁等策略；
7、与其他自动化模块以及第三方系统的集成使用，在本系统内部，应该可以方便在其他模块快速引用池中数据，自动化测试执行时，自动向数据池索要数据，数据池自行根据策略来判断是否需要触发造数规则；针对第三方系统也要提供方便快捷的接口以供调用；
8、支持给功能测试提供页面也快速查询到自己测试业务要使用到的数据，支持给性能测试提供大批量造数，以及导出能力；

是不是没写好，都没法用！

uiautomation

问题已解决:
新版的 sshd 服务，配置文件中，退出 ssh 后，默认配置会杀死当前控制组里面的所有子进程，修改策略即可,退出 ssh 的杀死程序（KillMode）
有如下策略：
1、control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
2、process：只杀主进程
3、mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
4、none：没有进程会被杀掉，只是执行服务的 stop 命令。

查看/lib/systemd/system/sshd@.service 文件，保证内容与下面的一致，尤其是 KillMode=process，如果没有这一行，请自行追加
[Unit]
Description=OpenSSH per-connection server daemon
Documentation=man:sshd(8) man:sshd_config(5)
Wants=sshd-keygen.service
After=sshd-keygen.service

[Service]
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=-/usr/sbin/sshd -i $OPTIONS
KillMode=process # 追加这个配置
StandardInput=socket
重新加载配置并重启 sshd 服务
systemctl daemon-reload
service sshd restart

最大线程数应该由基准测试（单并发能达到的最大 TPS）的结果来定。

大佬才有年度总结。我一年每天做一样的事情，没法总结。

应届生都这么卷了，8 年老油条感受到了强烈的危机感了。

突然发现，我就随便吐槽了几句也能上榜，醉了！！！

命题高大上，实际落地效果并没有想象中的好。

什么开发 一天就写 200 行代码？

普通的测试人员有几个会用到前沿技术啊？
尤其是点点点，业务才是重点。
而且就自动化测试目前来说，也做的并不够好。

AI 测试？那让点工都失业？

什么都比开发强，干的被开发多，拿的比开发少，图啥啊！

建议你们直接去 211,985 校招。

一般 UI 自动化不会做全量的业务吧。
我们公司一般是接口全量，UI 自动化只做关键业务和 TOP 业务。

如果确实用例多，除了增加执行机器外，还可以优化下框架代码，脚本代码，比如减少初始化操作时长，提前处理测试数据等等

这不完全是开发的问题吗？你们既然可以测到问题，那么由此产生问题的原因难道就没有推着去解决呢？还能反复因为代码合并的问题导致缺陷不断？

出去多面试吧，领导要是觉得你值得留，就会给你涨到外面差不多的工资，如果不留你，你就直接去外面看看吧。

换不起~

实际上，公司层面不管是领导还是开发都觉得既然你要做自动化就应该自己解决所有自动化过程中中遇到的问题，比如验证码识别，双因素登陆校验，文件上传下载。尤其是自动化需要运行在生产环境中的时候，执行 UI 自动化过程中需要解决太多棘手的问题（测试数据，业务回滚冲正，验证码，短信等）。

开源么？