• 在游测这些年(2009-2012) at 2021年10月08日

    原来大猫这么早就来广州啦

  • 感觉还是没看出,到底何时适合进行自动化测试?与其说那么多概念,不如来个实际的例子,会更清晰易懂?

  • 但是远程启动所有压力机完成后,样本数却少于并发数

    样本数具体是多少,少了多少?你这里信息不完整。

    另外,同步计时器原理上是通过阻塞进程来一次性发出压力的,只能阻塞单个 jvm 里面的线程。你这里用了多个压力机,jmeter 自带的 master/slave 通讯机制,是无法保障跨压力机情况下的同步计时器线程累计数的。

    比如你脚本里同步计时器设置了 200,那实际上是每个 slave 自己分别去累积 200 个并发一起发,而不是全部 slave 一起累积 200*9 个并发一起发。具体可以参考下

    https://zhuanlan.zhihu.com/p/72945182
    https://stackoverflow.com/questions/54228259/how-to-synchronize-request-send-time-across-different-nodes-in-jmeter

  • 性能指标波动分析 at 2021年10月08日

    你这个是啥?缓存命中率?

    我只是猜测而已哈,具体你得看接口逻辑才知道为啥前期性能比较差,不一定就是缓存的问题。

  • 对分页接口,断言的疑惑 at 2021年10月06日

    不知道你背后系统实现是什么,如果用的是 mybatis + pagehelp ,那实际 size、pages、total、current 都是 pagehelp 自动加的分页用字段。

    这类建议直接手工测试一下即可,除非分页逻辑有调整,否则个人觉得没太大必要去校验分页参数。以前分页各种 bug 是因为都是手写分页逻辑导致的,现在都用框架配置,用不对问题会非常明显,所以个人觉得没太大必要自动化去校验。

    records 倒是关键,这个和分页逻辑没有关系。比如搜索的话,看搜索结果是否符合要求来判断搜索逻辑的 sql 是否有写错。这部分一般都得手写 mybatis mapper xml 的配置,会比较容易写错写漏。如果有权限看代码,直接看代码会更直接便捷。

  • 你这个问题得问平台开发人员吧,每个平台的设计和实现都不一样,我们不知道你这个内部平台的实现,所以你问 “大家有遇到吗” ,我只能说没遇到过,毕竟我没办法用这个平台。

    然后平台不能 os.system ,可能和平台本身设计有关,毕竟 os.system 是权限非常高且危险的(rm -rf /* 这类危险的命令都可以跑),限制不给使用也算情理之中。

  • 个人习惯按风险挑。简单的说就是如果这个用例对应功能真出问题了,问题会多大。把会出大问题的都过一遍。

    不过也看实际情况,如果对质量要求高,全过也没啥问题。

  • 性能指标波动分析 at 2021年09月30日

    瞎猜,像是前期都没命中缓存,所以性能消耗非常大也慢;后期都命中缓存,就稳定多了。

    不知道你具体的脚本和报错,没法给更多推论了。

  • 不合适,这样就有很大的分叉了,我没有足够精力维护这样一个新的分叉。

    而且我这个 pr 其实没包含前端的部分,以及和现有 agiletc 实时同步的兼容测试,在我内部二次开发过的平台是一个成品,但在 agiletc 上还是个半成品,需要前端配合以及做好兼容方面的测试。

  • 查询后把内容变为实体类对象,这个就是 mybatis 做的事情了。你可以试试引入 Mybatis ?实体类自动生成这些 我前面说的这个工具都有。

    另外,不知道你这里的查询条件有多少,我们以前接口测试查数据,可能更倾向于直接写 sql ,通过 where 条件限定内容,比较灵活。如果查出来的结果有比较多需要校验的,那就通过外部表格等方式来记录,甚至进一步通过自动写入表格来自动生成断言。

  • 可以把你公司或团队里面,这种问题的具体情况分享下不,以及你们尝试过的方案?你的描述里从来没提到 “我们” 或者 “我”,全是第三人称甚至没有人称 ,总感觉你不是在说自己的问题,而是说别人的问题,或者 yy 出来的问题。

    然后你的回复相比感谢和理解并变成后续行动这种认可(比如:感谢分享,确实我们复盘没有找到你提到的根因,后续我们再内部讨论一下,继续深挖为何需求这么混乱),更像是内容点评。我们回复的目的是想帮助你解决你的问题,而不是给你做这些点评的,这些点评我主观感受上,会感觉很怪。

  • 额,收到这个点评感觉有点怪怪的。

    想先问下,这个是你团队实际存在的问题,想了解下大家有什么解决方案可以参考呢,还是什么?大家是冲着协助解决问题来的,这样的点评回复,搞不清楚到底对你有没有用。大部分都是类似 “你说的对” ,没有真正有意义的反馈交流,感觉好奇怪。

  • jdbc 里面默认 bigint 就会转 Long ,官方文档:
    https://docs.oracle.com/cd/E19830-01/819-4721/beajw/index.html

    PS:如果你用的是 spring ,强烈推荐用 https://github.com/davidfantasy/mybatis-plus-generator-ui 来自动生成所有数据库表的实体类 + 增删改查接口逻辑。省力且避免手写代码出错,比你这么手写要简便高效很多。

  • 嗯嗯,这个认同。

  • 这个和私单还不大一样。我以前遇到过好几次需求评审完,都确认下来后,产品周会开完,这个需求需要承载更多的业务目标,那需求又产生调整的(嗯嗯,拥抱变化)。所以光靠需求评审卡严,其实很难,总会有我们想象不到的地方产生变化。

    既然本质问题是业务节奏快,产品没法把需求想得面面俱到再开干,那我们的解决方案,就是围绕着更深度了解需求,便于按照一致的出发点补足细节来。比如:
    1、建立需求初审制度,技术也一起参与了解需求的出发点。需求文档初稿出来后各个技术、测试组长先审,快速明确需求价值、技术可行性。
    2、正式需求评审通过后,每天早会产品必须一起参加并同步是否有调整,同步后现场评估技术成本。调整成本超过 1 天影响排期的,一律走需求变更流程,变更排期。
    3、需求描述不明或者前后矛盾导致的 bug,测试也会记录并把类型设置为 需求问题 ,让产品澄清。测试报告里会体现这类型问题的数量及严重程度,并在复盘时一起沟通,看大家有什么好招减少或者避免这类问题产生。

    不同的组织结构、不同的问题根因,会产生不同的解决方案。所以我前面说复盘只是找到了需求质量差,但没找准根本原因(一般根本原因都和人员能力或者组织结构有关),需求混乱直接就加强需求评审,卡得更严,真的不一定能解决问题,甚至可能激发矛盾。

  • 考虑到答复里有同学回复了不错的内容,所以这个帖子暂时先不屏蔽。

    也请 @ 捉虫子的小强 后续发帖前,先看看精华帖或者其它问答帖是怎么讨论的。分享观点就应该正文里写观点,提问就应该正文里写清楚上下文和想寻求帮助。现在这种正文一堆没有上下文的问题,自己的回复一味抛外部链接,帮助不了解决问题,反而阅读体验非常差。

    社区不想随便屏蔽任何人花时间发出的帖子,但也希望大家讨论时保持好一种诚心学习交流的气氛。请大家一起维护好这个气氛。

  • 如果发帖目的是想解决实际问题,建议分享下你的实践经验和思考吧,这样才能真的帮助的大家。

    只是发各种不同文章的链接,也没有你自己的思考(比如你觉得里面哪部分说得有道理,哪部分觉得没啥道理),对于帮助解决实际问题,真的帮助不大。而且你已经连续好几天发同类型文章了,如果有诚意想分享经验,请看看别的分享文章怎么写的,调整下你的写法把。

  • 是 bug,这个是业务规则漏洞。前后端应该要保持一致。

    没出问题 != 没有问题,不知道你这里具体业务场景是啥,但既然不允许删除订单,那应该是业务规则是基于此时订单无法删除来设计的。那如果此时实际出现了订单删除,我理解你其它业务逻辑也可能会跟着一起出错,甚至连整个帐一起出错,到时候修起来就非常累了。

    当然一步到位全部发现全部改好很难,可以按安全风险一批一批检查和修改,但这个风险要明确暴露出来,让项目团队明确知道,并进行评估决策。

  • 前面帖子正文里的复盘,是不是可以进行更深入的根因分析?

    需求问题应该已经是问了几个 why 后得到的了,但我理解还可以再继续深入下?需求质量不高,就直接加强需求评审,有点担心会治标不治本。

  • QA 能干多久,要么转岗? at 2021年09月27日

    不知道你现在心情怎样,如果还比较平静,那可以像我前面说的,写一下年度总结,总结下最近一年做了什么,然后把你脑子里印象最深的得到快感最明显的 2-3 件事也列出来。两个比较一下,找到落差在哪里,然后想办法填平这个落差。

    一般迷茫来自于没有成就感,没有成就感来自于事情太碎或者太重复,没有挑战,所以印象不深,感觉好像没干啥,也没啥进步。所以需要你自己额外花时间去总结下你到底做了啥,为何没有成就感,以前做的有成就感的事情是怎样的,是否适合后面再继续做。

    如果你已经比较焦虑,一想这问题就脑壳疼,那先找点别的事情做,减缓下焦虑感吧。刚好接近国庆假期,可以去做些自己喜欢做的事情(比如我自己会喜欢通过打羽毛球、骑单车走走远路来解压),转换下心情,平静下来,再去做前面的分析。

  • ...我自己都忘了当时这句话是怎么想出来的,大伙就不要关注这个点了。

  • 没留意到用户名不一样,误会了。。。不好意思

  • QA 能干多久,要么转岗? at 2021年09月27日

    hmm,不知道你是准备怎么度过这段迷茫期呢?

  • 建议你先想好你到底对商城业务线到底是不是真的喜欢,里面是否真的有自己的发挥空间,再决定是否去认怂问机会吧。你前面这番迷之操作,估计会让你的领导心里留下一个疙瘩,得花一些经历去消除。如果你去了又发现实际不是自己喜欢的,最后也是得跳槽,而且还顺带让你领导留下你不负责任的印象。。。

    今天说完,后天就得正式接手的那种

    下次遇到这类突发且对你影响很大,你一时间也想不清楚的,你说你需要慎重考虑下,给你 1-2 天时间再答复就好了。然后这个时间里认真做思考,有必要就多问问你领导一些新业务的规划细节,有助于你做决定。这种事情会慌乱很正常,凡是都有第一次,吸取教训,下次改善就好了。

    尝试一下跳槽,自己是自信但又不自信的人,面试又会怯场,学历硬伤,工作经验也才 3 年多,怕出去后找到的比原来的还差。。。

    这个问题倒是你要花心思去解决的,以后一定会遇到跳槽要出去面试的,不能总是心里留着这个疙瘩,怕这个怕那个然后就不敢出去面,继续留。可以去练一练,不管有没有面过,这个经历都会给你不同于你目前公司的收获的,所以个人还是比较建议你出去面一下,哪怕 1 家都好,看看外面的世界。

  • QA 能干多久,要么转岗? at 2021年09月27日

    可以试着写一下年度总结,总结下最近一年做了什么,然后把你脑子里印象最深的得到快感最明显的 2-3 件事也列出来。两个比较一下,应该就可以找到原因了。

    没找到原因前,不要轻易行动,要不到时候骑虎难下更痛苦。