• 问题 1:像这种入参非常多的接口,测试用例一般怎么设计,覆盖到什么程度比较合适?

    我的经验是有几个思路

    1. 从代码覆盖率上去看,你的用例是否达到一定水平的覆盖率,比如 80% 以上;是否覆盖了关键业务路径,如果对代码熟悉可自行判断,不行的话可以拉开发一起过一下
    2. 和开发一起评估对齐出哪些优先覆盖,哪些可以不覆盖那么全,其实就是用例评审的时候强调好测试的取舍
    3. 其实这类参数校验,开发的代码一般就是一个 validator 定义好校验逻辑,或者开发框架上有提供对应的校验功能,基本是可复用的,直接白盒看代码去确定自己有没有必要搞这么多用例。如果参数校验很完整,其实可以适当删减无效用例

    问题 2:工具生成用例

    很多公司都有实践,如果要自己做也不难,大体思路是定义好不同参数类型的取值集合,如 int 就对应整型最大最小值、0、正负数、不同形式的整数写法等,预定义好一些取值,这些预定义的取值去替换测试用的 json 数据。再实现一个 json 解析替换的功能就可以是一个简单版工具了。最后的目标就是通过输入一个 json 范例,或一个 json scheme,自动生成不同的 json 数据供测试输入。开源工具不了解,我自己没有找过

  • 谈一谈今年的 TesterHome at 2022年11月30日

    可能大家最近确实忙,我自己本身这几个月也经历了一波团队变动。

    分享的想法没变,不过时间少了,一些想法需要时间丰满一下才会分享出来,那时间变少了只能拉长单次分享的时间间隔了。

    说到招聘,这一块很有感触,一方面是外头的公司资深和 leader 岗位一直招不到合适的人,一方面市场上又很多领了大礼包的人。有个迷幻的感觉是,裁员是公司的决定,招人是团队的决定,这两个是有些相互矛盾的。我在的团队也在招人,招聘帖子见:https://testerhome.com/topics/34978

  • 上面是官方的招聘信息,细节想了解可以评论(勾上,仅楼主可见),或者直接加我微信 zingphoy 私聊细节 😁 ~

    目前还有 HC,主要缺口是有七八年经验的同学,当然小几年经验的同学同样欢迎。

  • 我的建议:面向问题去寻找解决方案,如果资源不允许,优先找现成可用能短时间看到效果的方案,你就会发现在应用的过程中,越是万金油的方案,就越是不好用,逐渐就会有你的想法,在里面加入越来越多的公司和项目特色了。

    我其实想表达的点是:不要什么都想着自己亲自造轮子,解决一堆技术难题什么的,因为拿不到收益看不到结果,事情往往都活不下去……敲黑板的重点是,做什么事情都要面向问题,哪个选择明显效率更高成本更低,就是小学加减法了。

  • 一般是给固定涨幅,现在大环境不好,供大于求,肯定会压涨幅,我自己没试过,猜测是 10-30%。
    没有说值多少绝对数的薪酬,寥寥数语也不清楚楼主是什么定位和具体什么深度广度。如果本来就很低,大概率跳完之后也不会很高;如果本来就很高,再跳就是更高(废话文学)。

  • 测试环境被攻击有更多信息么?

    测试环境是否对外?
    测试环境攻击的是什么,危害大不大?
    测试环境被攻击那线上会不会有机会受到同样攻击?

    你问要不要增加安全测试,当然回答是要增加,这不是肯定的么?前提是你有没有人再说

  • 理由要说就真的太多,postman 只是一个执行工具,它没办法低成本铺开大家添砖加瓦,没办法结合到公司的研发流程,也没办法度量相关数据,更没办法向上汇报质量。

    当然不能说它不好,如果目标是追求快速完成接口自动化,把这个事情执行好,postman 应该是首选工具。

  • 小白刚学测试 at 2022年11月18日

    建议很简单:尽量往技术侧靠拢(做测试也尽量找技术性的岗位)。
    为什么:主要是因为技术方向的工资能更高天花板也更高,有技术能解决更多问题,有技术影响力也更大。

  • 或许也可以想想,培训是不是真的有意义,是不是真的帮到大家或者解决大家的问题?

    能力提升确实是个人的事情,但是如果想团队持续发展,大家更优归属感更忠诚,管理者如果能帮大家更快地提升个人能力,也是管理者的能力体现。

  • 多数情况都是学习氛围的问题,而要解决这个问题,可能需要关注一下这些因素:

    1. 是不是所有人都没有学习的意愿,还是缺少一个带头学习的人把大家带起来【我觉得这个是最重要,团队里没一个特别热爱的人,做什么都是假的】
    2. 有没有机制来保障大家的学习有效有输出有沉淀,如定期分享会,学习课题池,对应的奖励机制
    3. 基础条件是否提供到位,如有没有团队经费为购买书籍服务
    4. 学习到的东西是否有真正的工作价值,如以工作中某些话题去开展学习,最后应用到工作上
  • 新的芯片多多少少会有坑,但普通使用估计也没多少机会能遇上,原则上买新不买旧

  • 瞎回答一下:会不会是 jmeter 这个显示就只代表本机的数据,我记得好像是在压测结束后,slave 才会把数据统一返回和 master 去做分析。试想一下,作为 master 自己既要压测干活,还要在压测的时候接受 slave 的数据信息去处理,其实是干不过来的。

  • Keep 不是一个专业的运动工具 app,而是做成了运动社区,这些数据我认为仅供娱乐(For 社交),认真就输😅
    不过这里说的是数据覆盖的问题,也确实恼人

  • 僅樓主可見
  • 删除 at 2022年11月07日

    综合看起来简历是属于业务骨干,不适合 leader,也许有机会做储备 leader。

    从互联网大厂的要求来看,这个年纪的要求是做一个子方向的 owner,带几个同学一起去负责把这个方向做起来(也会要极少数的岗位是技术专家的角色,攻坚问题管事不管人),看的是胜任力。对比楼主的简历,一定要说不合适的话,要不就是业务领域不匹配,要不就是做的深度不足够(有时候所谓深度,前提是先有业务体量才会出现深度)。

    不需要妄自菲薄,至少在核心技能上应该没问题,建议后续多花些时间做系统的思考,留意落地上遇到的问题,除了传统的各类自动化外,看看其他地方的质效建设,如灰度线上、研发期间等,把体系知识呈现出来,同时了解一些管理方法论,就能继续平稳进步。

  • 我注意到的点可能比较奇怪,为什么这个小伙伴可以摆烂 3 个月,才和他一对一沟通了解问题。
    从老板角度去想,是不是意味着少着一个人也没有什么影响,然后就顺理成章地优化掉😅(无恶意),可能楼主也要想想在日常沟通上是不是要定期开展来及时了解小伙伴们的想法。

  • 一开始选择 apscheduler 就是想轻量快速,搞着搞着我们发现不适合有坑,就只能回去大家都用的 celery 上,目前还没出现问题😅

  • yes,apscheduler 没提供有分布式多实例环境下的解法(至少我完整看了官网文档,也翻过源码,确实没发现),现在我们还是选择逐渐迁移到 celery 上去了

    • 现象:服务上线,出现多个 apscheduler object,每个 object 都会执行它的定时任务 —— 简单来说就是一个定时任务被执行多次,本质原因是存在多个 apscheduler 库的 object。
    • 原因:我们服务有多机房实例,而且上线时会有小流量灰度发布的流程,先在单机房部署一个服务实例,此时该实例产生一套定时任务;后面在其他机房部署服务实例,就又产生一套定时任务了。
    • 解法(不严谨不保险):redis 做个简单的分布式锁,生成 apscheduler object 时判断一下是否其他机房已经生成过,从而保证全局只有一套定时任务。但是存在分布式锁超时失效的问题,这样还是会存在多套定时任务。
  • 好像直接用 apscheduler 这个库还方便点,我也有在用,本身库封装得很好,拿过来就直接用了。

    不过我遇到另一个问题,是多服务实例下的会出现多套定时任务,apscheduler 好像没有提供分布式下的解决方案,当时我自己解决就用了个分布式锁去做,但感觉不够保险。

  • 大厂回连日记 at 2022年10月31日

    在和别人聊天时,时常会聊出到一种 “从一线退回二三线城市,就是认输” 的感觉。

    而我认为,当一个人决定了从一线城市退出那一刻,也说明了 ta 知道什么生活才是自己想要的,是更成熟的表现。

    2020 年时在看一本鸡汤书《优秀到不能被忽视》时有一句话很触动我,赠予大家:不要把自己变成一个脾气暴躁的工作受虐狂,把休息视为失败,将同行的成就视为自己的悲剧

  • 初探前端质量保障体系 at 2022年10月26日

    点到具体的 pdf 文件里,稍稍右上角的地方,有个下载按钮可以直接下载

  • 初探前端质量保障体系 at 2022年10月26日

    在 Testerhome 网页编辑太卡了,可能因为本身文本比较多,操作起来有点痛苦。而且很多图片呈现格式上不太好看,所以就没贴完。(是我没贴图,不是 Testerhome 没展示图😅

  • 校招面试有感 at 2022年10月23日

    感同身受,我前后大概面试了近 300 个校招/实习同学(集中在 20~21 年),22 年降本增效嘛,就没怎么面了……刚好分享一下我的感想

    对于校招面试,有几个主要印象:

    1. 校招面试绝对是一个体力活,体现在校招同学的经历高度相似,如项目经验,面试形式大多数只能从项目展开再去到八股文,要追求高效面试没有其他办法
    2. 选择测试和测开岗位,确实就是研发岗自我感觉达不到要求,退而求其次的选择(这很正常,岗位要求差异是客观原因,同时对于没实习过的同学,本来就很难理解岗位之间的真实差异)
    3. 测试和测开,很多电子通信专业的同学会投过来(本质上是和计算机有交集但不深入的专业,科班出身倾向于投研发)

    我在面试时的偏好:

    1. 代码题上,【逻辑明确的工程题】要比【奇技淫巧的算法题】更优先。算法题讲究个临场发挥,需要专门训练,而工程能力是在日常编码中积累,和学校经历更贴切
    2. 面试表现聪明机敏优先,校招生看的终究是潜力和意愿,如果各方面发挥没有达到不及格的地步,人比较聪明我也是会通过
    3. 以挖掘亮点为主,而不是刻意去寻找同学的缺点去证明他无法通过
    4. 对于后期参与面试的同学,因为已经经历过很多轮其他公司面试的洗礼,在交流沟通的要求上我会稍稍提高一点点
    5. 有真正思考过的同学,对于某个技术点,能表现出触类旁通,能沉淀出知识脉络,会使用工具去提高效率(如看书后会梳理脑图),我是很喜欢的

    印象比较深刻的,就是遇到一个本硕都是化学专业的同学,在研二开始刻苦自学计算机,白天在实验室做化学项目,晚上在宿主自学理论知识和实践项目,最后拿了我们的测开 offer。

  • 如果有这种问题,建议关注 Testerhome 官方微信视频号,上面有以前的大厂分享录播,可以看看别人家遇到什么问题,是怎么去解决的。还有历届 MTSC 大会的 PPT,拿点思路。

    楼主应该是平时很少主动去了解业界,多去看看就知道了。