本帖持续有效嗷!!!
是的是的,这个业务讲解,一般我会讲这么些内容:
以上时间大概 55 开,都很重要,但是不要陷入太多细节,要把主链路呈现清楚,不分散新人的注意力
目前待过 4 名新人(社招校招均有),简单分享我的经验。
上面这些点,作用最大的是首日业务讲解,细水长流靠的是定期 1v1 和适当的文档。
我接触的 UI 自动化还停留在传统的 PO 封装上,看完此文后不知道我下面的表述是否正确:
同样没了解过,尝试猜测一下。
首先大型游戏肯定都是模块化开发的,各个组件(物理、光照、)最开始肯定都是单独的测试,可能是单测、接口测试、宿主 demo 测试,个人感觉跟 sdk 的测试方法可能比较接近。
当模块化的组件确保没有问题,开始组合成场景(不同的场景由同样的组件集合来组装,就是等价类的概念),场景中插入一些任务,这里的 “任务” 概念我理解就是业务逻辑,这个时候相当于是集成测试环节。一个 3A 游戏虽然复杂(剧情、玩法、各种要素、各种场景等),但从游戏迭代的角度来说还是应该高度自动化的(游戏 bugfix 补丁也可以去跑)。而集成测试,可能会有部分专业的人做探索测试,更多工作可能是给到外包团队低成本铺人去点点点。
如楼上所说方案,我们目前也是用方案三,自己买主机挂载手机,同时连在办公网(wifi)下,而不是放在 idc 机房。
idc 机房可能会跟办公网隔离,不同公司规章制度不一样。
长见识了…… 真不知道还会有这种坑
按照线上页面的 PV、UV 排个序,首先最高的页面下几个最高的场景肯定是要做的,然后 QA、RD、PM 内部商讨,剩余长尾页面哪些要额外补充 UI 自动化
举个例子,比如说你的增量调用链最后是 B->C->D,你通过覆盖率拿到你测试后的调用链是 A->B->C->D->E->F ,这样不就能理解你的的测试已经覆盖了你的增量链路么? 也就是判断子集的操作
同楼上
问题一:直觉上就是发压机的配置跟不上,如果你是用 PC 机发压,这个可能就更大了。建议关注一下发压机的配置,以及发压机在发压时候的资源占用情况。
问题二:可以先盘点一下,部署在两台不同的机器上会有什么差异
问题三:具体要看业务逻辑实现,对于 “校验客户密码” 这种接口,应该是每次都要查询数据库,合理的代码实现不应该使用缓存
继续在这种地方呆着不走,除非你有什么难言之隐,不然就是对自己的未来不负责
我理解是一样的道理,算法在 monkey 上的作用就是决策下一步要点击哪个空间获得的 “收益” 更大,还是有可能直接给点 “返回按钮”。
我表达的意思是,这个手段在使用细节上还是有很多测试策略需要考虑的
我们内部有实现了一套差不多的玩意,我们管这叫 scheme 定向测试,只是说,可能定向过去的是一个原生页面、前端页面、内部其他技术制造的页面等。
其实有弊端:
不过还是有很多场景可以应用这种测试方式的,比如提高测试覆盖率、线下问题复现压测、某些特殊场景的定向测试。
如果要结合遍历测试来做,还需要预防跳转过去后,monkey 给你点到回退到其他页面了。
我觉得吧,能把大学那些数学课先捡起来(尤其是工作多年之后),就已经不是一件特别轻松的事情。
如果真的很轻松,要不就是天赋过人,要不就是基础确实稳扎稳打,要不就是学了点套路当调参侠自嗨
offer 中也有薪资开的比较高,越是工作年限比较久,越要知道下一份工作能得到什么,尤其在当下互联网环境,很难找到完美得工作,但是可以找到适合的自己工作.
表示这一点非常赞同,一定要看准赛道跳进去,跳进去之前又要充分考察这个公司、团队、岗位是否适合自己发挥。到这种时候 base 上差个两三 k 已经不是什么需要关注的问题了,主要还是考虑未来继续发展的空间。
对的,其实压测本来就是有两种目的,视不同场景:
压测我以前做过一个总结,可以看我的博客做个参考。
如果产品不明白,那还是得耐心解释给他们听,其实这也是你在研发和产品之间制造自己影响力的机会,让大家觉得你知道得很多决策经常正确,那是一件好事。
所谓的熟练掌握 python,一般只需要系统把 python 学一次就够了,要求就是一个普通的想法能用 python 这个工具正确实现表达出来即可。并不会强制你掌握那种 blingbling 的、很 pythonic 的、很奇技淫巧的实现方式。
其实不仅仅是 python,对所有的编程语言都是一样,它们都只是我们的编程工具,只是说你追究到库源码实现、编译器虚拟机实现层面上,在某些特定场景下能帮助你解决问题和优化代码。单纯从测试开发的岗位来说,除非个人爱好或者工作面试需求,不然也不是非得到那种深度。
当然,多看别人的代码,尤其是高效优美的代码(github 高 star 项目),对自己还是非常有帮助的。
mark,这个周末拉到家里的电脑认真阅读一下源码~ 看看能不能给找几个 bug hhhhhhh
申请开通专栏~ 感谢 @simple
曾经在企业里作为乙方对内部的网站系统搞过 4 个多月的渗透测试(或者叫安全测试更合理,因为不够专业),简单分享一下如何入门:
一个接口做不做压测,是应该测试人员自己判断 ,还是听开发说呢?
结论:产品、开发、测试共同判断。
如果这个接口有历史数据,可以基于历史数据来分析接口重要性,再判断是否要压测。
如果这个接口没有历史数据,是新增接口,最正确的方式都是产品、开发、测试三方一同判断。或者某方判断出结论后,正式地(会议、邮件均可,至少有书面记录性质的东西)跟其他方同步并征求意见最终确定下来(这样做的原因,是出问题一起背锅……)。
应该怎么判断一个接口做不做压测?
2 楼已经回答得很好,我补充一下个人的观点。从面试官的角度来问,其实本质上是考察你对整个业务的熟悉程度,面试官可能想从一个相对系统的视角来看看你有没有梳理过整个业务逻辑,所以才会问这种问题(我也偶尔会这样问,住)。
ok,知道面试官的目的,我觉得就可以针对性回答。
一些猥琐加分技巧:我们的目标是要让面试官能通过我们的口头描述,让他 “自认为” 理解了业务;同时为了让他听得开心,让他觉得自己的理解力好强,所以我们还要找重点去说,并围绕这个重点做深入。
综上,回答方式可以这样:
以上。
一些点:
Get ~