• 嗯嗯,所以要结合团队情况看。

    写配置的其实也是有办法做成复用的,最常见的方案就是关键字驱动(比如 robot framework),可以用写用例的方式写函数封装。不过会有点感觉像是四不像,简单程度上比纯数据驱动会复杂一些,毕竟可以有控制语句了(if/else/while 等),灵活程度上又没有代码灵活,没有适合的 ide 配套写起来非常难受。

    我是觉得,如果编程水平实在不行的,那就直接弄录制回放,甚至考虑下此时是否适合引入自动化。因为先不论自动化脚本编写难度如何,实际自动化总会遇到一些问题需要排查,而排查解决没有一定的编程基础,是搞不定的,容易直接卡住。这种情况下,要不有专门自动化团队有能力协助搞定这些问题,要不就通过培训 + 淘汰,提高团队这方面能力。

  • 可以考虑让运维给你临时开几台虚拟主机,直接把压测工具和脚本放到 git 仓库,然后 clone 到机房主机。跑完后把报告数据拉到本地分析生成图表。也可以考虑直接部署个 meterphere 上去,直接 web 平台操作,不用拉来拉去。

    公司内网到机房的带宽是有限的,而且如果中间有 CDN 之类的挡一下,你基本压不倒实际服务。

  • 以下仅代表个人观点:
    1、写 yml 配置形式。好处是实现简单,上手也简单,容易统一。缺点是灵活性容易受限,对于相对复杂的用例,写和调试相对麻烦,不好复用(不是复制粘贴,特指调用已有的某些步骤)。
    2、直接写代码。好处是非常灵活,缺点也是过于灵活,没有好的规范容易乱。同时上手也相对难一些,需要有一些编程基础。

    具体选哪个,核心看你们目前团队的编程水平。会编程的人多,第二种会更好,因为灵活性足够高,因此用例怎么多也不至于太乱。如果大部分不会编程,选第一种,甚至直接选录制回放生成脚本的可能更合适。

  • 做的项目全部没有效果数据,看不出掌握程度和项目难度。比如自动化多少用例,通过率百分之多少,突破过什么难点,都没提。体现不出水平,默认认为水平不高,也看出总结归纳能力不强,有需要当一些项目负责人或小组长,会有点悬

    见过一些 1-2 年的简历,写得也差不多,属于都会不精。3 年最好有一个精一点的,详细写下,突出深度。

  • web 前端性能如何测 at August 20, 2021

    建议你看看 chrome 开发者工具里的 lighthouse 和 performance ,注意不是直接看界面(这个东西还没简单到直接看界面就无师自通),而是去找相关的使用文档先了解下。这两个就是做前端性能检测相关的事情的。

    另外,浏览器提示卡死这个现象,本身就基本上可以排除服务端原因。因为服务端再怎么慢,也只会导致请求超时(请求都是后台异步的,本质就是持续的等待),不会导致资源耗光引起浏览器认为卡住(个人理解应该是 UI 主线程卡住,没法响应任何用户操作事件)。同时也通过看浏览器 network 里面这个服务端请求的返回耗时,看是先返回,还是先卡住。

  • 你们改 header 的目的是什么,只有改 header 这条路可以走吗?

    如果是,改 header 这个,我理解也可以直接在 wifi 路由器里,或者弄个 http proxy ,来篡改请求数据?

  • 这个问题有点伸手了,先搜索引擎搜索下?

  • 可能你说的距离和我理解的不大一样。你说的看起来像是楼层高度,我说的是楼层间隔,即中间隔了几层。1 楼和 2 楼间隔是 1(2-1=1),2 楼和 3 楼间隔也是 1(3-2=1)。

    有楼层高度是会更精确,但实际上楼层高度差异很大(某楼层高度是其它楼层的 2 倍甚至更多)的楼毕竟是少数,而且差异 0.5 米按照电梯的速度,时间差异也基本在 1-2 秒内,从等电梯的人角度看,这个差异几乎可以忽略不计?对于电梯公司来说,少数几套通用算法走天下,成本比每个大楼还得根据楼层高度来调整算法要低不少吧。

  • 公司给不到技术支持,可以多上来社区提问哈。社区有专门问答区的,大家都会看到,得到答复也快而准。

    提问方式可以参照下那些回答数比较多的是怎么提的,仿照着来。社区毕竟不像同事,可以立即互动,所以尽量把问题描述清楚,这样才能更好的得到最佳答案。

  • 想先确认下,楼主对于 “好走” 的定义是啥?这个用词不大准确,每个人都有每个人的理解。

    其次,按照目前情况来看,一线大厂的薪酬,和二三线的银行,差距会挺大的(差 2-3 倍甚至更大),天花版差异也大。一般除想得特别透彻(赚够钱,不再关注钱方面的事情),或者迫于无奈(比如加不动班了),否则一般情况下,应该没有人会愿意放弃丰厚的薪酬和前途,回去二三线做个没啥发展空间的测试的。

    不过现在二三线发展也挺快,大厂也逐渐有二三线的分部,我看到更多的同学选择是在大厂内部转岗去二三线分部,拿着一线大厂的薪酬,在二三线消费相对低的城市里相对优雅地生活。

    总结:先去大厂总归没错,有这段经历,以后选择也比别人多。至于是否选择二三线银行,这个到了那个时候再去考虑把。

  • 我提的这个方案算可以么?几乎完全不知道 是指其他楼层吧,如果电梯是在 1F 或者 B1F,按照题目里的条件,只要一开门就知道了。

  • 现在这家公司没有涉及到自动化,我自己后面是想往自动化靠近,就自己不能实践到工作中,这样效率就比较低

    这里想确认下,公司没有涉及自动化,和你自己不能把自动化实践到工作中,关联是什么?公司没有涉及自动化,你也可以本地自己搭,自己用的。我自己平时也会做些便利自己的小脚本。

  • 赠送的蓝钻可用户参与此游戏 这句话怎么看起来怪怪的?

    这类游戏玩法我们也有类似的。前端一般需要保障
    1、操作没问题。比如下注是对的,不会点一下变成 +2 之类的卡顿
    2、展示没问题。底部角色记录、倒计时、钻石使用数这些,都要正确。开奖动画和开奖结果要正确。特别是倒计时,要保障大家都同步开奖(我们这边是这样,不知道你们有没有差别),所以倒计时准确度需要在 1 秒内。

    不过最核心的,不是这些界面,而是背后的开奖逻辑。最低要求,是要保证这个游戏的庄家(就是公司)是能盈利的。所以这个开奖规则本身设计就要很严谨,实现也必须保障和设计保持一致。所以测试重点是在这个开奖规则的实现是否准确,以及在调整各种配置后(微调概率啥的)也是能正确按照新配置来开奖的。

  • 从你给的信息看,你现在是一个困境,你想学点东西来跳槽,但你发现不跳槽自己学不好东西。结果就是东西没学好,槽也跳不了
    突破的关键,是提高自己的自学能力(比如去培训班,有监督),尽快学到能跳槽的水平。

    同时也需要明确,自己自学,碰壁是必然的,要有耐心坚持下去。我自己试用过很多新的东西,基本没有一帆风顺的,都是有各种坑或者文档未提及的点,需要自行解决,问题多的可能 1 周都跑不起来个完整 demo。而打破这些壁的关键就在于搜索和沟通。先搜索尝试解决,解决不了可以在社区或者其他地方进行提问沟通。踩坑填坑多了,经验就会积累起来,然后再做好总结梳理,形成思维框架,就会逐步成为你的核心能力。

  • 过来人经验,自学没有合适方法的话,容易效率很低且产出基本拿去面试没啥用。

    建议你选一个方向自学下基础,然后找机会换一个能让你更容易接触到你说的这些东西的公司,在里面通过工作实践来上手吧。尽量选一些规模稍微大一点(研发团队 200 人以上)的公司,并在面试时明确了解公司内部是否有开展你说的这些测试类型。毕业生前 2-3 年,找对平台很重要,否则就浪费了学习精力最旺盛的这几年了。

  • 好的,大概理解了。你这个感觉和之前接触过的流式处理 flink 的比较接近,要求重启后要恢复到上次消费消息的状态,然后继续往后走,保障消息处理不重不漏。

    event sourcing 模式搜了下,是 Martin Flower 大神设计的微服务架构模式,通过统一的事件流来触发各个子系统的操作。但你这个好像又有点不一样。event sourcing 的核心点在于 event store ,以及聚合资源库。聚合资源库就是提供应用了最新事件后的最新数据状态,供外部查询使用。我看的是这个:https://zhuanlan.zhihu.com/p/38968012 ,如果有理解不正确的欢迎指正。

    回到你这个功能,个人理解核心点应该还是保障重启后消息处理的不重不漏,即重启后可回到重启前状态。你这里的场景一、场景二应该可以满足正向场景的要求。但有几个实际使用中会出现的场景可能需要考虑下:

    1. 事件是一个动态的存储内容,系统怎么知道回放到哪个事件,刚好等价于重启前的那个事件?此处如果有一些存储机制,也需要测试一下它的可靠性
    2. 你这里提到正常运行时,内存和数据库基本延迟在 5 秒内,但你的快照定时是按小时/事件数来的,应该远超过 5 秒。那为何不考虑直接把数据库内容加载到内存,而是要从快照 + 事件来呢?这个点可以了解下,可能背后包含某些取舍。
    3. 重启除了单纯的重启服务,还可能存在修改事件处理逻辑后重启(比如上线发布)。此时可能会出现修改逻辑后,事件处理结果和原来的不一致,把快照到重启前那一刻的事件都处理完,也不一定内存就回到当时状态。这种情况应该怎么处理才正确,我觉得可能也是需要去考虑的点。因为在根本设计上,你实际就是通过重复消费来恢复状态的,那就有可能出现逻辑改动引起数据处理结果不一致的情况。
  • 面试官表示对于 “距离优先” 这个条件,有办法通过计算来覆盖到。

    距离优先的入参是电梯离目标楼层的距离。如果按照题目说的除了电梯在 1F 和 B1F 开门外,都不知道电梯在哪,那只能基于电梯在这两个楼层来测试这个特性了。

    我在想,他说的是不是这样的测试方法?
    1、先想办法让电梯 B 停在 1F(找人协助啥的)
    2、把电梯 A 停在 B1F
    3、在 1F 按按钮,确认是电梯 B 开门,而不是 A 开门

    但实际场景,可不仅仅是考虑距离优先的,还要考虑方向是否对等(比如 A 在 3 楼,但正在下;B 在 B1 楼。此时 1 楼按个下,应该让 A 过来,而不是 B 过来)。同时也没告知除了从 1F、B1F 的电梯外部按按钮外,还有什么控制手段,感觉好多东西没有交代,需要去确认。

  • 覆盖率 0,那没有评估的必要,说明压根没测。。。

  • 想确认下,楼主是在独立的自动化团队(专门写自动化脚本),还是在业务团队兼顾写自动化脚本?

    如果是后者,价值体现应该比较容易,节省自己的工作量就是价值了。
    如果是前者,光靠自动化体现价值比较难。还是要基于自动化扩展下更多的事情。单纯自动化价值实在有限。

  • 我们之前用覆盖率,不会这么硬性指定必须达到 xx%。我们关注的是没覆盖的部分,是否能给出合理的说明(比如这个只是一个捕获异常后的日志记录,对业务不那么重要),保障不会有明显漏测即可。

  • 好奇问下,那你们后面是怎么解决这个问题的?怎么去设计测试用例避免被带偏或者遗漏?

  • 哦哦,我明白你意思了。
    我是基于需求先写用例,然后根据设计文档进行补充调整(有一些实现细节通过,设计文档会更清晰,也更容易拆分和针对性测试)。你是直接基于设计文档写用例,确实容易走偏。

  • 额,基于设计文档来调整用例我也挺常做的,P9 大佬是说有啥问题?

  • 大概理解你意思了。这个功能核心是保障重启前后内存状态保持一致,实现上采用了定时全量(快照)+ 实时增量(事件)结合的方式。

    这里面有几个细节点,你没有提到,想确认下:
    1、内存和数据库的关系是强一致(写内存同时就写库,失败时同时删除),还是弱一致(数据库总落后于内存,定期同步保障一致)?
    2、系统内这个内存具体是怎么存储的,一个全局变量,还是多个局部变量?是否有方法直接获取值(如通过外部接口 get)?
    3、你的方案二有提到 "手动指定从某中间快照回放" ,感觉你这里的快照还可以进行回放,有点奇怪。能否介绍下快照实际存储的内容是什么?是类似 git 一样的所有增量集合,还是一个没有任何历史的全量记录?

  • 打开 chrome 的开发者工具,通过 network 看看是哪里有问题?

    没有样式一般就是 css 加载出问题了。