正经人谁写日报
有没有可能,公司招聘上面的全都要
emm,大概理解职能定位了,其实干的是细分的活,让业务部门专注业务。
没接触过,我所在的团队流程拉通、对接、流程提效的活都是自己团队内做的,所以才有此疑惑。不过看 1 楼大佬的解答,更像是把工作更细化了,业务部门主要精力放在业务上就行,至于部门协调、流程对接之类的活就交给专业去干的意思
可能本身在扁平化的团队待多了,感觉很难具象化职能,看大佬的描述看来更像是一个多职能部门桥接推动和项目流程提效的工作,个人理解可能有点偏颇
虽然人人都喊自动化,但是能卓有成效的寥寥,招聘都要自动化,进去可能连个脚手架都没有。还是要根据实际业务来发掘才行,不然没试手的环境,很难坚持学得下去
这不妥妥的流程问题么,都没提测,关测试什么事
自己搞个抓包代理就可以了吧,执行 ui 自动化的时候,让代理去进行返回校验
也不是不行,写个连接就行了 dog
不都这样吗,JD 都是 HR 拷贝过来的,并不是为了招人吧,纯纯为了刷曝光度
自动化这个东西如果是公司决策群体推动倒还算好了,流程拉通还算名正言顺,如果只是业务测试自己想做才叫原地升天,做自动化还不如做脚手架。
单纯只是测试战斗公式的话,逐步对公式内的参数进行组合模拟,然后验证比实际伤害值与预期是否一致其实就行了吧。
没 JD 的?
emm,差不多是类似的意思,假设权限对应的特权值只有 1、2,但是通过发包可以让后端写入一个不存在的 3,这个情况很多技术都会说这个情况不存在,操作不出来且无实际影响不用管,从当前的情况来看确实是没问题,但是如果产品后面又拓展个 3 出来,也就是我说的会给后续拓展带来风险了。但是通常意义上来讲,只能通过类似这种方向去推动修改或者丢给产品去 battle。
主要还是看是有存在越权或者潜在的业务风险吧,如果只是加了个特殊的权限值,但是是空权限,这种直接甩给策划呗,当然潜在的风险项就是后续的业务拓展可能会有坑。
如果不考研的话 建议就别选电子信息了
像订单这种时效性的数据应该不至于只存在缓存里面吧,毕竟服务器重启数据就没了,应该还是需要存数据库的。如果有存数据库的话这种事情就好验证了,重启服务器之后 redis 会重载数据库里面的数据,搞个测试服去调服务器的时间进行数据的跨日、周、月验证能不能重新获取这个编号或者数据有没有清理就好了
看起来跟 tcp 协议的处理倒是大差不差的
后端逻辑处理顺序的问题,先返还后删武将,然后就是 BUG,没有判断背包满的情况就直接重置了
游戏自动化看你是想搞接口自动化和 UI 自动化了,个人建议还是看公司岗位的情况,UI 自动化的成本是很高的,对于高敏捷的游戏项目并不怎么友好,个人维护很麻烦,当然这个是基于人力情况的考虑。接口自动化会更好上手一些,实施的成本相对 UI 来说会小很多,出成果也更快。
接口自动化本身定位就偏向用于回归测试吧,功能测试过程中单接口测试才是重点,在开发环境通过接口自动化来验收本身就是一个成本不低的做法,个人看法。
测试需要有独立的测试环境,跟开发共用很明显的一个问题就是资源竞争,这是个很明显且项目经理能很容易感知到问题,测试需要测试时,开发需要占用,直接降低了双方的效率呀,这个理由还不够么
用例定制哪里可以直接搞解析器把协议数据解析成可视化结构就好了,就不用对着 wireshark 去一条条转结构了
返回的条数在于你需要验证哪些数据吧,在解析器增加协议筛选就好了,根据用例获取用例指定的协议数据做校验
同楼上,我多开一个线程专用于发心跳包,相当于同时存在两个线程:一个用来发测试协议 一个专用发心跳 但是会存在一个情况就是如果测试协议大量在发送的情况下,心跳包很难抢到时机发送,会出现无法定时发送心跳,这种情况怎么解决?还是说在有协议通信的前提下,心跳包可有可无?