• 是啊,运营得很不错,一直都有比较高质量的文章贡献出来。这些东西里就美团给我是全公司统一的输出渠道,阿里、百度、腾讯等各个大厂都是各个团队各个部门各搞各的,在不同的渠道发,乱

  • 我就理解成是对 shell 不熟悉吧。

    shell 是靠多用多查。常用命令其实不需要背,只需要熟悉并且在面对场景时快速反映出大概用什么方式去实现就行,这种东西去记忆也是浪费时间,手册一查全都有。

    另外,要知道常用的管道命令组合,很多典型的场景会有对应的命令组合去解决,这些需要一定的记忆和训练。

    我建议是上网找找常见的 shell 场景题,然后去自己写命令实现出来,训练量上来这个就差不多了。

  • 优惠券测试用例编写 at January 24, 2024

    一是去接入外部的自动审核服务要💰;
    二是自动审核但凡逃逸了一个问题也可能带来毁灭性的后果吧?

    我也不知道这些内部事务,我只是帮忙审核的志愿者。 😂

  • 优惠券测试用例编写 at January 24, 2024

    在审核队列里等了好多天,终于放出来让我审核通过了,舒服了。😁

  • 删除 at January 24, 2024

    楼主对自己的现状写得比较简单,所以不好评价。

    如果让我真诚来评价,仅仅只针对上面体现的这些,我的答案是会有难度。

    对 6 年工作经验的定位,首先不应该再是一线执行。分方向看:

    • 业务方向,要能胜任某个业务方向的质量负责人(负责人不等于 leader),整体负责这一块业务的全面质量建设(服务端 + 客户端)。业务大还是小就看面试表现和实际能力,能力越强给的业务范畴就越大,对应的问题就更复杂;
    • 技术方向,要能独立识别业务问题,转化出技术方案快速实现,推进落地协助业务拿到质量和效率的结果,解决过越难的问题越加分,对业界相关建设越熟悉越加分;

    一些自测点参考:

    1. 有无清晰的数据导向思维
    2. 有无某个方向完整的经历。假设是走业务方向,那接手一个业务后会怎么着手做质量建设,思路如何,说个一二三
    3. 能不能写明白半年规划
    4. 是否有了解过他人是怎么做,能不能总结出常见的建设套路

    【叠甲自保,我这也只是嘴炮,我自己来做估计也不太行】

  • 不仅字节是这样,其他大厂对外包的要求应该都类似。外包同学还是以业务测试为主(就是真正的点点点执行和业务场景分析),要求是业务理解力、基本技术基础(至少可以跟研发平等沟通)、良好沟通素质、抗压能力综合衡量。

    不是所有业务都有自动化,也不是所有自动化都是给外包维护,这些都要看情况,很多业务其实质量建设并不成熟,自动化等基本工作可能正式同学一样在做。

  • 我身边的外包同学,感觉超过 80% 以上是一点都写不了的,剩下的会写代码那部分,也有不少是来到之后被迫写起来,只是依葫芦画瓢的水平,变一下就不会了。
    正式同学肯定人人都能写,熟不熟悉快不快好不好就是另外一回事。

  • 你开头摆的数据对于我们这些外人来说没法理解,思路是先去拆分数据分析,可能你已经清楚怎么做了,为了回答完整我还是补一下:

    1. 先回捞数据,佐证是不是线上 Bug 是不是真的多(为什么别人感知到多?直觉是客诉反馈多而且有比较严重的级别)
    2. 假设就是客诉多给了别人线上 Bug 多的感觉,那逐个 Bug 分析归类,找出 Top 原因,常规操作吧
    3. Top 原因中,对应要什么改进就能解决这些问题。改进动作项对应的评价指标是啥?比如你前面说到【用例评审覆盖 100% 版本,技术方案评审覆盖 100% 版本】,那就得想办法去衡量好,怎么搞要看你们的研发系统是啥,支不支持这么干,或者有没有数据 api 给你们去拉数据。这里没法给你共苦或指标建议,工具依赖于你们的研发系统,指标依赖于你的改进事项
    4. 建设好持续的度量,同步好这个事情,定期放出数据让大家保持关注。

    这些思路我看你的回答都是有的,应该没什么问题。【上面想要我做的是先分析出问题,然后针对问题去考虑动作。直接做动作会被喷】这个是必然的,不然就是盲目在做事情。分析问题是为了能论证出你做的动作是能解决问题,而不是靠直觉或者拍脑袋

  • 那投入时间是肯定的了,没有什么问题不投入就会自己好,人越多的团队这种方式就越好使。

    有数据之后能自证问题,也能持续给老板反馈(现在怎么样,做了改进后怎么样,重点抓哪些地方改)。所以搞测试,本身也要把不少时间在质量运营上。

  • 对于这种问题,常用的做法是你建立一个数据看板,每日自动统计你关注的这个口径(至于需要多少开发量和工作量,得看你们内部系统是怎么样的)。目的是在周会或者什么会议上放出这个数据,表扬头部做得好的,批评尾部做得差的。这样运作一段时间平均水平就会逐渐上来。关键是背后得有老板支撑,老板也要偶尔关注到这个数据,否则也很难做好,因为大家都觉得无所谓。

  • 建议先明确自己的需求,然后再去市面看看有没有现成合适需求的东西上手就用,最后实在找不到合适的再考虑自己造。

    除非你真的什么事都没有,需要找点特别的事情来做做。

  • 可以啊,这种方式很不错。

    付费是一种门槛,门槛越高客源的质量也高(当然对应的受众人群也会越小)。以后等我没那么菜了,我也学学这样搞。

  • 经典一句话需求😅

  • 花菜】我的 2023 年终总结 at January 15, 2024

    最近我的小买卖也搞起来了,认识到一个不太稳定的尾货批发商,从里面低价入一些玩具再卖掉赚点差价,预期利润 10%~20%,唯一问题是投入成本没法扩大,规模太小,长期看一个月撑死赚个三四百。目前首月暂时赚了一百多一点点,也满足了。

    说到生蚝批发,看来楼主也是广东人哈哈哈哈

  • 和别人一起买了个一千多的极客 vip 账号,结果没看两章一年就过去了,然后到期,我是 fw 😭

  • 继续做测试还是考公呢 at January 08, 2024

    转开发难度高一些还是考公难度高一些?哪个更有把握就选哪个

  • 国产浏览器都是换皮的,内核八九不离十是 chromium,可以用 chromeDriver 试试

  • 不说国内顶级大学这么地图炮,普通的大学连专业课都很水,何况业指导课…… 实际里就用不了一点儿

  • 这种事情太常见的了,首先和领导理性探讨,判断这套方案是否真的适用于当前的业务现状,这个过程需要你有一些数据准备,包括有这个系统前和有这个系统后的测试工作量对比(占用了多少人天),解决完问题之后节省的工作量人天可不可以将历史付出掰回来。

    • 如果得出的结论是不可以,就不要碍于面子不把它撤掉。如果领导就是要坚持用,他愿意背锅,那倒无所谓,听话配合就好了。
    • 如果得出的结论是可以,那就去解决发现的问题。这个过程是系统性周期性的,需要长期投入人力,可以先把历史遇到的问题盘点出来做个简单分析(这里就体现出保留历史数据的重要性),找到 Top3 的问题一个一个解决。网络不行那就改善网络状态或者增加重试逻辑,开发改动就要看是开发随便改没规范还是测试没及时跟进维护好…… 解决完之后再看新的工作量再来一次分析循环……
  • 如上所说,这个需求的目标就是性能优化,所以我们只要验证优化前后性能有符合预期的提升就行,关键点:

    1. 优化前后,常规场景或目标场景下,有性能提升
    2. 优化前后,极端场景或非目标场景下,无性能劣化

    第一点好操作,第二点需要多判断一下。这个优化方式是加索引,加索引不一定万能,如高频写可能因为加了索引导致性能更差。

  • 我的 2023 年终总结 at January 02, 2024

    +1,是我对管理知识有个系统了解的启蒙书

  • 学多门语言不会串吗? at January 01, 2024

    会,一些语法细节经常会忘记,尤其是有个把月不写某种语言,一来写一些平时不怎么用的语法就只能靠搜索

  • 「功能人的 2023」 at December 29, 2023

    马上奔三的我都差点尿裤子了 😂 也在积极考虑副业,要想发展一门可持续的副业真不容易

  • 理解为这只是一种可能性的探索吧,当 gpt 去到足够强大的时候,这个方案就会从看起来很好笑成为真的很好用。好的新思路也经常是这种基础探索一点点发展出来的。

  • 这就是观念意识层面的问题了,质量本来就是共同的,如果研发和测试在这一块达不成共识,只能说爱莫能助。