功能设计的挺好，这也是我一直想做但是没做的东西，之前也设计过这块，但是苦于一直没机会开发，我分享下我自己对数据工厂/造数工厂的一些功能的想法：
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 自动化过程中需要解决太多棘手的问题（测试数据，业务回滚冲正，验证码，短信等）。

开源么？

正常的测试都是手工 + 一点点自动化 + 一点点性能，我想没几个公司会有能力专门养几个工资比开发还高的测试测试去专门搞那些花里胡哨的东西吧。

如果一开始就有能力做开发我觉得没人会选择测试。
时间太长就算技术能力高了又会碍于累积的多年测试经验不想换赛道。
我建议技术能力可以，学习能力可以的人可以往高级开发，架构师方面发展。
除了一些大厂，中小厂里的测试真的没啥发展前途，开发和你同一天进去，人家涨薪的速度可能是你 2 倍以上。

这样返回没问题，正常框架都是这么做的；
严格点，开发需要对这种代码层面的 Exception 堆栈进一步封装成可阅读内容，可以提一个级别低的漏洞缺陷：
漏洞名称：异常信息泄漏
漏洞描述：未自定义统一错误返回导致信息泄漏，抛出异常信息泄漏，错误详情信息泄漏
漏洞风险：后端接口服务在出现异常报错时，没有进行合适的包装便将所有信息返回给前端，通过抓包工具或者 Chrome 开发者工具可以查看这些异常信息，可能包含例如表结构，代码包名，业务逻辑等敏感信息，极大可能被黑客所利用。
漏洞修复建议：Java 后台对所有异常出错进行包装，返回合适友好的提示信息，禁止将异常中所有信息返回给前台。

不管是偏业务测开还是偏工具测试真的如同楼主所说的需要料理这么多方向的事情？

这个薪资是说工作年限为 0 也有可能拿到 12K 嘛？