• Linux 操作之 - man 命令 at 2022年05月19日

    好像是本地缓存没有才联网,本地缓存有会直接读本地?

    我日常用,很少遇到要等待。

  • 平台的一些操作建议 at 2022年05月19日

    这个,有点众口难调。。。从我个人角度,反而不喜欢新开浏览器,还得手动点关闭,不如直接鼠标按住左键右滑这个手势操作直接返回方便。

    如果习惯新开选项卡,可以按住 ctrl 来点击,就会新开选项卡打开了。

  • 关于版本控制的一点疑惑 at 2022年05月18日

    没看懂,你这两个版本是两个分支的意思?

    近段时间发现测试环境内频发一些基础功能无法使用的问题(新增/运行等类型功能),而这些模块在近期是没有新增需求改动的。
    经与开发了解,发现是因多人多需求改动相同代码文件导致

    1、没有新增需求改动,为啥会有多人多需求改动相同代码?这个逻辑没看懂,建议再问清楚

    2、多人多需求改动相同代码文件,从版本管理角度最容易出现的问题就是代码冲突,以及某些情况下自动合并后的逻辑会错误。这个确实有可能导致质量很不稳定(以前别的项目也有遇到过,客户端并行需求,分支管理没弄好,两个需求共用一个分支,经常相互影响)。解决方法也很简单,既然需求是相互独立的,短期内可以拆分为两个分支,分别独立去测试,上线前再合并并回归一遍;长期来说大概率是架构有问题,存在某个超级类,啥逻辑都往里面怼,所以大部分需求都要改到这个类,需要想办法把这个类拆散,解决多需求会改到同一个文件这个问题。

  • Linux 操作之 - man 命令 at 2022年05月18日

    man 用的很少,自带文档实在太长太啰嗦了。

    相比 man,我更喜欢 tldr ,或者直接百度。

  • 会哭的孩子有奶吃。如果你觉得自己现在能力值得更高的薪资,且绩效也确实不错(这个很关键,绩效一般的话,说明你能力从公司评价角度,还没有超出预期,一般情况下不大可能争取到涨薪,涨薪肯定优先给到高绩效的员工),该提就提吧。

  • 图都挂了,楼主修复下?

  • 你这种应该是工资倒挂了,其实还挺常见的,内部涨薪不如跳槽涨得快。我第一家公司也有类似情况,涨得比行情慢很多,最后还是跳槽才涨上去的,直接涨了快一倍。

    现在既然已经提离职了,而且听起来你领导也不是特别想挽留你,你就不要思前想后了,破釜沉舟,全力去找工作吧。只要坚持,金子总会发光的。

    除了常规招聘网站,建议也可以留意下社区招聘板块的信息,里面也有不少好机会,而且发帖的一般是内部主管,相对来说机会大点(至少不会在招聘网站简历可能直接被筛掉)。

    加油!

  • 时间有点久,不大记得了。解决了就好~

  • 楼主有点冲动了,今年互联网行业这个大环境,找工作很难。

    并且听楼主描述,像是为了涨薪而离职找工作,但自己能力却又并没有超出自己目前薪资的表现,所以很难找。提几个建议:

    1、继续找,但短暂放弃涨薪这个要求,想办法进一个能让自己涨能力的公司或者团队。
    2、考虑跨城市,不同城市薪酬水平有差异,相同的能力换个城市可能薪资就上去了(当然生活成本也上去了,需要自己综合衡量)

    至于是否留在现在公司,建议还是以能力是否有可能提升作为一个核心衡量标准去考虑,从长远来说,薪酬还是和能力挂钩的。

  • 没太明白,这里的数据有效性指的是测试出来的性能结果有效性(背后涉及设计出来的性能测试模型是否和实际场景一致、测试环境模拟度是否足够等),还是啥的有效性?你说的这个数据库断言,我理解是功能的正确性(即服务端返回成功的话,数据库确定是写入成功的,不会是假的成功),不像是有效性。

    如果做数据库断言,理论上是会增大数据库的读压力的,但会影响多大这个不好评估,得看实际情况,比如这个查询复不复杂,是否命中索引、查询频率有多高等。

  • 那不清楚了,没怎么做过微信小程序的自动化,不大了解。

  • 受教了

    我们这边服务端服务 app 为主,大部分场景需要请求多接口的话,没有依赖关系的都是直接并行访问,不大会串行。所以很少特意关注这里提到的用户请求的并发模型。

  • 看了下,文章想说的应该是 LR 和 KylinPET 两者的录制能力差异吧,LR 录制后默认是串行,而 KylinPET 则是和浏览器的发送情况基本保持一致。确实从这个角度来说,LR 的录制能力不够 “拟真”

    不过有个疑问,一般什么场景下的性能测试,会要求并发模型和单个用户浏览器访问的时候保持一致呢?而且用这个评估最大在线用户数,也有点说不过去?

    “最大在线用户数” 这个概念本身就比较模糊,如果按 token 保持有效就算在线的话,那 token 最大存储个数本身就等价于最大在线用户数了。如果要加上服务处理性能,那得看这些用户在干嘛,用到哪部分接口,这个还得细分典型场景(大多数人用的场景)、特殊场景(预估压力会特别大但又真实存在的场景,比如大 V 直播啥的)啥的,很难一个 “最大在线用户数” 直接概括。

  • 从报错信息看,像是 customfield_10301 这个字段无法识别。

    确认过这个字段确实是这个 key 么?会不会写错了?

    有没有试过去掉这个字段?

  • 点个赞,细节都是魔鬼,能关注平台的体验细节,说明你是个很用心的人。

  • 从截图看,有多个 webview 。建议可以看看其他 webview 的内容有没有匹配的?

  • fastbot 官方好像有交流群的,你到项目主页看看?

    另外,如果是想在社区寻求帮助,除了一个报错信息,建议附上更详细的操作信息以及 fastbot 版本号等信息,像报 bug 一样完整阐述你的问题吧。

    光一个报错信息,除了肚子里货非常多的搜索引擎,作为个人实在很难解答。

  • 没太明白你想表达什么,如果是想协助解决问题,可以把你具体的操作步骤、报错信息等附上来?

  • 这个可能会有比较多难点。

    1、在控件内容(比如原来定位的 id)变了的情况下,怎么判断新的元素是用于替换旧元素的?这个我没想到什么比较固定的准则,实际项目里基本也是需要结合需求判断,有些不确定的需要找开发二次确认的。

    2、如果不只是改控件,而是连布局、交互都改了呢?这种情况下可能不存在原来的控件改成了什么新控件这种一对一关系,需要改动的其实不只是定位元素,甚至用例逻辑都得改。这时候可能需要的是会自动生成用例,而不仅仅是维护用例的工具了,现阶段除了智能遍历类外,暂时没见到这方面有比较成熟通用的工具。

    所以,如果界面元素持续变动很大的话,建议取消做 UI 自动化,或者考虑用录制之类的更便捷的方式生成用例。

  • 求回答 at 2022年05月16日

    偶现性问题的复现,我理解最有效的方式是:多试。

    然后试了之后,不要只记录步骤(因为相同的步骤不一定能复现),还需要记录现场的所有相关信息,包括相关日志、内存 dump 信息等。

  • 关于测试工作 at 2022年05月16日

    两个都需要。

  • OK

    这个是你额外引入的吗?我印象中我项目没有用到 Vue.locale = () => {} 这个。

  • 从用例上看,挺清晰的。提个小疑问,websocket 建立连接后,一般主要传送的应该是 message 内容,但我看到用例里每个都有 url 参数,这里的 url 实际对应的是 websocket 里传输过程中的什么内容?

  • 欢迎加入~

    话说,你的用户名是不是当时注册时设置有问题?我看到末尾带了一个挺长的 url ,有点奇怪。
    如果是注册时没设置好,可以在右上角的个人头像点击->个人资料设置->姓名 里进行调整。

  • 1.如何做一位合格优秀的业务测试?
    ——没太明白这里问的是合格还是优秀?个人理解优秀的业务测试,应该对业务和背后系统的熟悉程度,可以达到快速看出需求、技术方案里存在的问题以及怎么调整会更佳,并且这些意见能得到大家认可的。

    2.业务测试在一线城市有封顶薪资吗?
    ——封不封顶,取决于公司。理论上没有封顶,但能拿到高薪资难度会比较大,机会也相对少。

    3.业务测试如何去发展自身的特长,也就是职业发展?
    ——我觉得技术应该是测试岗的基础技能,但不一定非得变成自己的特长(技术真的是自己特长的,我估计大多都去做测开甚至开发了吧)。每个人的特长不一样(有的可能善于协调沟通,有的可能善于发现缺陷),根据自己的情况,找到自己在匹配职业发展方面的特长,并持续去发挥和发展自己的特长,让其变得比团队里大部分小伙伴更突出就好。

    4.如何让技术循循渐进的进步?
    ——个人觉得 2 个点很重要:
    a. 重复的东西聪明做,比如第二次做要比第一次更快更好,同时做好文字记录(很多时候第二次可能离第一次,时间上已经很远了,脑子回想起第一次怎么做已经很难了)。
    b. 遇到技术问题(包括但不限于被测物的缺陷、线上的故障、自己写的代码等)多寻根问底。解决只是暂时的终点,在解决的基础上了解清楚原因以及为何这个方式可以解决、是否有更佳的解决方案,才能让你记忆更深刻,下次变成预防而非只是解决。