第三条和我司（同为魔都三姐妹的友商）去年招聘的一样，今年已经扭转过来了。讲真，4 门语言测试开发成型的很少，很容易出现一种情况，是人少没办法的路数。米哈游测试开发那么多完全没必要啊，比如原神就 10 个。

加精理由是 pykka 的应用和 actor 模式，这块在测试上属于相对跨学科，建议都可以学习下。并且是个系列作品，期待后续。

service mesh 本身是有网络开销。多用户跑设置集合点跑了吗？

websocket 默认是 text，但是可以设置为发二进制。

加油加油

脱离前端框架的方式，UI 前端访问微信，拦截一层拿到这个变量存持久层比如 Redis(内存也行，取决语言)，试试这个。
如果可以的话就用变量继续做接口测试。

我来说下感受，如果只是看个热闹还是比较伤感的。行业车轮是在进步，稍微学习下起码不会落下太多。
测试也不要绝对的划分，测试就是不需要有太多开发实力的，测试是一门职业，也是服务质量的最重要的担当者，职业发展需要众人拾薪，空等着行业发展，是挺难的。
至于工具/框架/平台从 0-1 比较简单，是否从 1 做到 5，需要考虑推广和持续开发。
1.0 工具是一种辅助方式，2.0 平台后更多的是抽象统一化的工具变成平台，楼也是一点点盖高的，高屋建瓴也是碎片时间一点点盖高的，毕竟内部业务很少是靠 PPT 画个饼就给招一批人的。

内容还是挺有意思的，会和同事一起开发，不是就一个人孤军奋战。而且那边还在开发很多常见质量品类之外的。快点联系发帖人吧。

觉得能解决问题就是好东西啊，这块可以在宣传和讲解这个平台产品上多下功夫，好比一个项目立项也不是一番风顺的。
我个人觉得可以不要灰心继续投入。因为很多内部工具是否成为"高需求和爆款"更多不是一开始就很明确了作用，而是越改和越开发越好。
抱璞守真，跳出测试工具只有接口，自动化，压测这 3 个内容。

有些工具和框架本身作用就是为了检查测试用例不足，从而补充测试用例，比如覆盖率就是。
测试交付，交付效能提升，交付减少往返开销是不一样的啊。。

1.最简单的思路是完成开发提的需求。
2.冒烟测试 跑完标记出哪些跑了哪些没跑，一开始需要验证是否是自动化问题，做了一定累积和自动化返回数据定义后。
就可以慢慢信任。
3.挂钩子提交后，多条分支版本是否可以拉起来，到哪里是通的（用例上体现）。
有时候推广和维护都是心血投入，不是只是开发完就算了。

之前在 3 月份时发现这个技术栈，练手一部分后就一直放草稿箱里面，完成是 11/9 号

反向传播后，梯度下降。不过现在有个问题是，如果数据量不够的情况下，一些模型用不了...造数填充是不行的。

大公司有一堆干活的，应届生是用于另外一条路线。

要问你进去做啥。。

汉字方式不太推荐会有大坑，汉字等于理解为支持自然语言和模板的一种开发模式，互联网业务被验证，BDD 也只有一小部分可行。
游戏不太好搞。可以了解下命令设计模式。

我回头开个帖子写，你说用什么语言的。。

是啊是啊。

自动化不是很推荐用覆盖安装。。

老师告诉你，有事别找老师，要自己自学。老师不能授给你鱼，会害了你，桃李满天下很花时间，学成龙大哥说的一样，年轻人，我看好你喔。

1.配置表下面还有一部分是说把配置表把接口测试，需要使用部分存储数据库。
2.美术相关的，可以看官方引擎推荐，加油。还有多余资源检查等，只要正则和提取数据能力。

挺好的，使用文档解析协议也是一种思路。收发器层是一种应答式的，会不会把线性写压测 case 进入收发器变成同步处理了（全局设置是异步到收发器需要等待还是可以变成同步的）。另外反射从描述文件那边取会不会有点不是很快。

做得挺好的，我在学 Python 时也受过朋友帮助，尤其是煎饼,下面列 3 个可以完全用 Python 开发的浅见。

一.图片资源检查（长期项目）：
作用：比对图片资源二个版本（包）更新差异，这个基础上先查出 2 次图片修改新增差异，后面配合其他的比如性能恶化，再去查图片素材导致花屏，性能影响点更合适；有 IP 公司可以用于，IPQA 审核图片用。
美术素材的纹理文件类型检查，比如开发了软解功能，在部分区域的美术素材纹理是有固定检查标准，或者是升级了 etc 压缩格式等级，也是有固定检查标准的。
核心思想为 unity 和虚幻之外的，用 unzip 解包来做，比对 2 个包的素材位置的 md5，如果素材有加密，需要用加密之前的包。
虚幻不了解，Untiy Assetbundle 后无法看，所以要拿 2 次工程里面的图片打个压缩包来做。
残留资源检查：
读取 lua 中引用图片的地方，去抓取出来放到列表里，然后去遍历整个工程，就可以找到残留图片资源，这个优点是减少包体大小。

二.自动化前置组件（1-4）
最佳实践，不使用一个文件去驱动整个自动化，使用 jenkins 流水线调起根目录的各 python 文件（把自动化行为拆分为前置和中间部分，后置）可以一个功能一个文件，所以前置会有多个文件，去年我做了，最后可能也没时间去解释为为啥分文件，没用起来。
自动化流程前置（按顺序）：
1.取包 包管理区域（比如挂载盘，jenkins，软件管理软件等等）获取包
2.解包扫描 代码自动备份包，解包为备份包。检查包内区域文本的敏感信息和文字信息是否可读，协议描述文件位置（protobuff）是否解开可读，资源如果是加密的是否后缀和前缀可识别等，这里如果有安全组件还可以添加这里，我司无。
3.图片资源检查 上面的，把信息记录下来。
4.安装手机处理弹框
5.启动应用，应用启动后标记 对应手机模拟器信息。如果这里有客户端埋单检查组件当然也可以加进去（比如畅游埋点就是客户端服务端都有，然后二则匹配。）

三.增强配置表检查工具 检查点（长期项目）：
这个的确你自己也列过了，但是所说是一个增强部分。
公司方面是看你服务需要服务一个项目还是多个项目，多个项目就是要考虑用代理模式。项目组--->代理--->rule，从 rule 那边抽离共性给项目组用。上百个规则时，用这个可以让代码清爽。
如果是一个项目，可以考虑在检查规则时，顺带把策划配置表用代码把接口要的参数抽成几张表，导入数据库内（！需要每个版本都要导入）。可以服务辅助接口测试，接口测试细的来说，需要验证参数结果是否对（比如 3 个任务一共获得了多少资源，当前资源记录下，资源数检查点来源就是从数据库里面取导入的策划配置的数据）。

测试开发风景很大，有些需要开发到后面和接入更多项目会找到不足。主要来回复，游戏压测其实还是测试团队做比较好，工作这些年也看到过很多各种不同经历的 “风景”，目前来看开发自己做还是比较大问题的。

macaron 并不是一个小众的 web 服务，所以也是有学习意义的。
比如 ctx macaron.Context , ctx.Req.Request 等同 http.Request，ctx.Req 下面包装了不少服务方法来方便开发。