一个健身经验超十年的胖子,喜欢看到自己的力量素质进步,也喜欢玩变形玩具并立志要拍玩具分享视频。生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。

热衷分享但货不太多,巭孬嫑浪。欢迎加微信 zingphoy(备注 TesterHome),聊技术/测试/人生/训练反正啥都行~

  • 2019 年底 ~ 现在:深圳字节跳动
  • 2017 年 ~ 2019 年底:深圳百度

个人博客,很长草了:https://zingphoy.github.io/

  • 每个人的工作都会有替代性的,如果以前做过的事情确实不复杂,那都是过去历史了没法改变,咱就不纠结这点。针对这个我给点建议:

    1. 是不是你做过的工作真的这么简单?还是你当时把它想的太过简单(言下之意是,试图讲视野上升,从老板视角去通盘考虑你的工作,你的工作在全局中属于哪一环,起到什么作用,上下游要有一些什么等等)?把这些全向一遍,虽然比不上做一遍,但至少让你在面试时有话可说。
    2. 是不是在做工作时,有些难题被你忽略了,比如遇到某个业务或者技术难题,为了快速做出来你选择了一个简单路线去绕过问题。这种也能捡回来思考一下,在面试时候说一说

    对于第二个问题。测试的日常工作就是质量把控和交付,常规迭代测试是工作中一半甚至更大部分,这些东西大家都懂,就不要浪费时间说太多,因为是本分工作。除非有特别的亮点,比如一些 bug 分析和问题排查比较出彩,一些突发事情处理比较合理严谨,一些业务决策比较逻辑清晰…… 这些细碎的闪光点很容易忘记,你要自己去想想有没有。

  • 面试官面试角度看,一般会把简历上体现的内容问一遍,先判断内容的真实性,再判断内容的包装度(做得有多深)。

    相比于找一个事事都干过,但都是简单实践级的选手,倒不如找一个某方向耕耘做成熟、踩坑多、有心得的选手。

    为什么会有这样的选择倾向?因为简单的实践不太需要脑力思考,只要解决过程中遇到的问题,进展就能一直推进,这些问题往往有直觉答案,不复杂,问题能定义清楚,解法能直接搜索到;而耕耘得深,遇到的问题越抽象,可能一个数据不好,要花很大力气去拆分不同数据再分析,为了达成一个指标要推导很多计划,铺垫很多事情,对人的锻炼效果是不一样的。

    所以,我的建议是你先把你自己认为做得最好的放在第一位展开说,即使你这个最好的其实也还不够好,但至少是你最能说的。其他比较简单的被问到就说,没问到就提一下过了。

    1. 先看其他公司公开的招聘中,你想要面试的岗位有哪些要求,收集下来
    2. 审视自己的技能是否达到要求,如果达不到要求就找办法迅速提高
  • AI 要怎么与测试结合? at 2024年02月20日

    在深圳 MTSC 2023 上有团队分享,把 gpt 结合到变更分析里头,让 gpt 分析变更代码的影响范围,并按照变更给出用例设计的参考思路。

    就上面这个案例当然我也觉得很鸡肋,但这肯定只是开端。

  • 春节玩帕鲁体验 at 2024年02月19日

    看完了,若有所思

  • 如果是在广东,那十分合理。好多人都不一定有

  • 可以考虑咸鱼卖我,我刚需要一个哈哈哈

  • 是啊,很多基本操作如果不规范,就像是地基不牢固,在上面继续发展就会越来越摇晃,牵一发动全身

  • 其实最关键的就是去砍手工用例,正如大家说,自动化用例执行本身就不会花费多少人力,所以砍自动化用例不痛不痒。跟手工用例关联的重点就是覆盖率录制,录制这个行为确实有成本,但是大体还是可控的,看业务情况可以不定期录制。

    1. 业务体量复杂,肯定是基于业务架构和业务链路来说的复杂,和用户量没有关系。
      典型如大厂里平台性质的业务,拿大家都知道的淘宝天猫来说,app 抽象起来就是一个平台,上面承载这五花八门各个团队的业务,而这些业务之间也不完全是互相独立的,常常是网状关系,技术和业务多少有关联。这种情况下就可以定义为业务体量复杂。
      假设现在就是一个数字计算器工具 app,即使成千上万的人在使用,它一样是一个很简单的技术实现,从代码量、调用链路、技术结构、开发人员等各个维度来说都不复杂。

    2. 【但是呢,重复的多少?没人愿意去重新搞搞清楚的可能也是有的?】我没有很理解在问哪一方面,是指回归用例是否存在重复吗?我猜测可能会有但是不多,因为回归用例要定期 review 保鲜,增加或删减回归用例是经常的事情。
      这个质疑出发点是好的,至于别人的业务是不是这样就不清楚了。

    3. 【为什么要全量回归用例】,首先这几万条用例本身并不是全量用例,它就是经过筛选的回归用例,很不可置信对吧😅 ,我也这么觉得。
      另外这是客户端形态的业务,回归测试是端到端的行为,也就是从客户端做测试执行,一并覆盖到业务视角的重点服务端链路。发版好像是三周或一个月一次。
      可能楼主对服务端更熟悉,下意识认为这个是服务端的回归。但往往 ToC 的业务,更重视客户端回归,因为面向用户的就是一个客户端或 app。服务端回归相对简单,想什么时候跑接口自动化就什么时候跑,只要保证环境隔离,不太需要绑定具体的时间节点或者外部配合。
      业务拆分就如上所说,一个平台类型的 app,不可能一个团队回归,比如淘宝直播有直播的团队回归,钱包优惠券有支付的同学回归……,所以这个几万条用例也可能不是一个团队的用例。

    4. 优先级概念的确很有用,但是优先级概念是业务视角出发的一种概念。精准测试是技术视角出发的概念,本质是面向任何变更,回归用例的精简只是它一个落地场景,它和按优先级砍用例在结果上有一定相似与重合,但是在过程上不是一回事。
      肯定不能说 “对于所有代码变更,我一律只跑 P0-P2 的用例,业务就没有质量问题” 对吧?同理,精准测试是一种门槛更高的补充手段。这里说的用例,都是指一个完整的测试执行和断言过程,精细到具体操作,这些基本概念我理解大家都是对齐的。

一个健身经验超十年的胖子,喜欢看到自己的力量素质进步,也喜欢玩变形玩具并立志要拍玩具分享视频。生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。

热衷分享但货不太多,巭孬嫑浪。欢迎加微信 zingphoy(备注 TesterHome),聊技术/测试/人生/训练反正啥都行~

  • 2019 年底 ~ 现在:深圳字节跳动
  • 2017 年 ~ 2019 年底:深圳百度

个人博客,很长草了:https://zingphoy.github.io/