一个热爱锻炼的胖子,生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。

喜欢和人交流,如果你也爱唠嗑质量保障,加微信 zingphoy 一起吃瓜子~

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

个人小博客,就是有点长草:https://zingphoy.github.io/

  • 1、在做接口自动化的过程中,参数的数据应该从哪里来比较好。是写死(这种切换一下环境就不能用了,不太好对吧?),还是从数据库里提取?(那如果数据库里有脏数据,会造成测试接口返回信息不准确吧?)

    参数数据主要来源肯定就是你的用例设计,其他来源都是补充。补充来源可以是线上流量(access log 里面可以抽取)、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行,要加什么筛选标准,肯定不是随便一条数据就能拿来直接用,一方面有些数据涉及用户隐私安全,一方面有些数据不完整,一方面有些数据根本没权限拿,所以很多时候最关键的就是搞明白筛选标准和你的测试范围,不是万能的。
    【是写死(这种切换一下环境就不能用了,不太好对吧?)】没看懂你说的写死是什么意思,是人为确定的参数?为什么切一下环境就不能用呢?能不能按照不同环节做兼容?还是说你的环境本身就有问题?

    2、如果是动态数据,比如需要上一个接口查询商品,下一个接口添加购物车。如果上一个接口出问题,那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢?

    上个接口出问题用例应该直接报错结束吧,没什么特别的方法。上游你的控制不稳定,自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参,而是确定前置条件有无满足

    3、请问你们已经落地的接口自动化,是在测试环境跑还是预发布、生产环境呢?因为感觉做出来只在测试环境跑,发现不了线上的问题。整个接口自动化意义不大。

    全量用例是在测试环境跑,我们内部的预发布约等于生产环境,生产环境只跑很小一部分,而且都是读接口。在线上跑写接口就是给业务加脏数据污染,纯纯地坑研发,不仅可能发现不了线上问题,甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些,发现线上问题除了接口自动化(巡检)外还有很多,比如监控、用户反馈跟进,更牛逼一点可以是舆情监控等手段

    4、如果在线上跑接口自动化,涉及到钱的接口,要怎么去跑呢?

    基本原则是涉及到钱就别在线上去跑自动化,出问题就是事故,老老实实线下自动化或者线上手工验证,不差那么点工作量。一方面钱相关的一般是线下有 mock,自动化会比较安全倒还好,但是线上没有 mock,第三方支付也很少会给你在线上开这样的测试口子,所以就别去较劲,要是自动化把别人的接口打挂了还要担责;另一方面,如果线下测完了没问题,线上还出问题,我觉得可以想想为什么两者的结果不一致,再去尝试排除这些差异点,至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑

  • 这三角关系很乱,我没看懂为什么研发部门老大会问为什么不解决延期处理问题,ta 是在问产品还是在问测试?

    解决问题的到底是测试还是产品还是研发?

    研发老大跑来问测试为什么不解决延期处理问题,我怎么感觉他思路有点清奇。不知道是问题里写错了还是咋样

  • 看不懂问题

  • 仅楼主可见
  • 单纯拉个开源项目就是一顿看,效率很低,建议有目的性地看。
    比较实际的,testerhome 上不是有一些开源测试平台吗,这些咱也熟悉,你就看他们的代码,想了解哪个功能的实现就看哪个。
    这样很快就有感觉了,主要训练到一些全局搜索、调用关系猜测、常规模块实现思路等基本技能。
    看多了,有些操作就如同肌肉记忆一样,实现什么功能需要考虑什么细节。

      • 全局效率更优,专业的人做对口的事情,不容易被其他事情分心
      • 不同团队的职能更加单一更容易管理
      • 需求集中到工具部门,可以从全局决策集中投入人力搞,同时工具的收益更容易被量化
      • 破坏整体技术氛围,有综合诉求的人才会加速流失
      • 工具部门无法以同样优先级支持不同业务线的特殊需求,所以更倾向于选择通用需求或者核心部门的需求去做,一方面通用就是不好用,另一方面总有业务线的需求不受待见

    具体要看公司发展到什么阶段,要 case by case 分析。如果公司只是很早期的阶段,这样做无可厚非,因为人本来就少,业务线内部重复建设再浪费一些人力确实在 CTO 眼里是不合适的。如果是其他阶段,说法又不一样了。

  • 观感:内容写得很丰满,但是看不到重点,整体偏罗列没组织,给人的感觉是什么都做但是什么都做不深,是事情的参与者而非主导者,含金量打折。

    修改意见:

    1. 「内容做减法,一些常规的工作可以直接删掉,或者合并在一起」
      • 如 xx1 项目的 1、2、3、4 点,典型如【负责编写测试计划文档】,【负责编写测试结果分析总结文档】,这些都是测试同学最基本的工作,写和没写区别不大,建议删除 2、3、4 只留 1。要是真的不想删就合成一句话,如果最终合并成诸如【负责同测试团队共同构建测试各阶段质量规范标准的定义、编写测试计划文档、编写测试结果分析文档】,当我没说……
    2. 「项目经历中做好分类,每一个项目中突出一个重点」
      • 明确区分出 主导 和 参与 的区别,突出你主导的东西,如果全都是你主导的话,那这 3 年经验应该胜过不少 5 年的人。首先需要把事情分类,粗的类别可以是【业务测试】和【自动化】,细的类别可以是【流程规范】、【质量卡口】、【线上监控】、【xxx 自动化】等,这些就自行分类好了;然后突出主导的事项,项目中给出持续时间,肯定有些项目长有些项目短,到时候面试也重点引导面试官往你主导的比较熟悉的工作去问,对你也是有利的,不然问到不熟悉的一下子问死了。另外,技能列表也要做分类归纳。
    3. 「数据导向去阐述项目,做到心里有数」
      • 这个是加分项,对于 3 年的同学没有数据导向的思维也不意外。要呈现的感觉是:发现问题 -> 数据上阐述问题(如测试代码覆盖率很低,只有 xx%)-> 数据下钻细化,确定子任务的数据预期(如测试代码覆盖率低,可能拆分为缺失用例补充、冗余用例优化、手工用例自动化等不同提升方式)-> 每种方式贡献了多少数据,为什么会有这样的贡献 -> 最终收益结果。介绍的时候可以这么去介绍,简历上不需要写得这么详细,这个只能自己思考怎么去呈现了。
  • 字节的后端 golang 就是默认语言,不过后端测试对 golang 的掌握度也没有特别要求,毕竟实话实说还没去到帮研发改 bug 的程度 😂

  • 全世界的大厂都在搞 ChatGPT 竞品,但个个都是半成品,一两个月 rush 出来的东西怎么跟正版比😂

  • 云手机是指模拟器那种?下面就当是模拟器来回答。

    没大规模使用过,但是可以确定模拟器无法替代真机,因为模拟器在底层的接口支持和真机不一样,也就会导致部分模拟器上会出现的问题在真机上根本不存在,而真机会有的问题模拟器又测不出来。

    有部分场景可以考虑使用模拟器:

    1. 核心场景 UI 自动化、性能防劣化等,有明确固定的测试场景,重复一样的测试操作
    2. 和平台底层接口、显式样式等无关的功能验证
    3. 真的没钱买这么多真机,模拟器是在设备上去扩展部署的,成本低弹性高资源利用率高

一个热爱锻炼的胖子,生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。

喜欢和人交流,如果你也爱唠嗑质量保障,加微信 zingphoy 一起吃瓜子~

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

个人小博客,就是有点长草:https://zingphoy.github.io/