这种确实是非常依赖环境的支持程度，所以我觉得最好的方式只能是拥抱环境，寻找有机会在现有环境下推动和落地的方向。之所以建议从接口方面入口，主要还是考虑不管做哪方面的业务测试，接口测试都是需要接触和相对容易有成果的方向，当前可能有带有一些主观的推断，因为我差不多也是依靠这个方向去做的突破，什么 UI 自动化、性能、压测啥的方向也是一顿尝试，发现都无法落地之后，最后在接口方面实现一些价值突破，这也是为啥说有相同经历的原因。

相同经历路过，什么都学其实真不太行，逮着公司内最好落地的方向深耕。据我的理解的话，深耕接口这块是相对好出成果的，同时衔接自动化更平滑，对于中小公司来说，手工测试想要做出亮点的话。

很不错了，像我游测转软测都没人要

最怕遇到精神文明的面试题，问你对公司了解程度如何，不熟你就没了

工期已经这么紧张了，估计也没空搞自动化吧，建议谨慎自动化，除非有特别合适的空档期可以一下子搞起来，否则别碰，碰了就是技术债务。另外说的质量管理的观念，看着像是要左移呀，要测试提前介入或者协调分批提交，这个比较考验项目组人际关系

正经人谁写日报

有没有可能，公司招聘上面的全都要

emm,大概理解职能定位了，其实干的是细分的活，让业务部门专注业务。

没接触过，我所在的团队流程拉通、对接、流程提效的活都是自己团队内做的，所以才有此疑惑。不过看 1 楼大佬的解答，更像是把工作更细化了，业务部门主要精力放在业务上就行，至于部门协调、流程对接之类的活就交给专业去干的意思

可能本身在扁平化的团队待多了，感觉很难具象化职能，看大佬的描述看来更像是一个多职能部门桥接推动和项目流程提效的工作，个人理解可能有点偏颇

虽然人人都喊自动化，但是能卓有成效的寥寥，招聘都要自动化，进去可能连个脚手架都没有。还是要根据实际业务来发掘才行，不然没试手的环境，很难坚持学得下去

这不妥妥的流程问题么，都没提测，关测试什么事

自己搞个抓包代理就可以了吧，执行 ui 自动化的时候，让代理去进行返回校验

也不是不行，写个连接就行了 dog

不都这样吗，JD 都是 HR 拷贝过来的，并不是为了招人吧，纯纯为了刷曝光度

自动化这个东西如果是公司决策群体推动倒还算好了，流程拉通还算名正言顺，如果只是业务测试自己想做才叫原地升天，做自动化还不如做脚手架。

单纯只是测试战斗公式的话，逐步对公式内的参数进行组合模拟，然后验证比实际伤害值与预期是否一致其实就行了吧。

没 JD 的？

emm，差不多是类似的意思，假设权限对应的特权值只有 1、2，但是通过发包可以让后端写入一个不存在的 3，这个情况很多技术都会说这个情况不存在，操作不出来且无实际影响不用管，从当前的情况来看确实是没问题，但是如果产品后面又拓展个 3 出来，也就是我说的会给后续拓展带来风险了。但是通常意义上来讲，只能通过类似这种方向去推动修改或者丢给产品去 battle。

主要还是看是有存在越权或者潜在的业务风险吧，如果只是加了个特殊的权限值，但是是空权限，这种直接甩给策划呗，当然潜在的风险项就是后续的业务拓展可能会有坑。

如果不考研的话 建议就别选电子信息了

像订单这种时效性的数据应该不至于只存在缓存里面吧，毕竟服务器重启数据就没了，应该还是需要存数据库的。如果有存数据库的话这种事情就好验证了，重启服务器之后 redis 会重载数据库里面的数据，搞个测试服去调服务器的时间进行数据的跨日、周、月验证能不能重新获取这个编号或者数据有没有清理就好了

看起来跟 tcp 协议的处理倒是大差不差的

后端逻辑处理顺序的问题，先返还后删武将，然后就是 BUG，没有判断背包满的情况就直接重置了

游戏自动化看你是想搞接口自动化和 UI 自动化了，个人建议还是看公司岗位的情况，UI 自动化的成本是很高的，对于高敏捷的游戏项目并不怎么友好，个人维护很麻烦，当然这个是基于人力情况的考虑。接口自动化会更好上手一些，实施的成本相对 UI 来说会小很多，出成果也更快。