• 2020,如果能完成自己的目标,就买个 Tesla,奖励自己。
    膜拜大佬。

  • 我的 2019 at December 30, 2019

    当初面试了四五家公司,只有一家公司可以提供相符的薪资。
    预计未来还会比较忙的。

  • 收到邮件了,问题我还没有复现(工作 ing)。
    希望把问题提到 issue 上去,这样比较方便追踪(gmail 国内上稍微费劲)。
    初步的直觉的判断,我觉得不太可能,因为纯粹是源生的 Jmeter 来驱动运行的,不太应该。但是你提到了吞吐率控制器,可能另有玄机。

  • 虽然没看代码,但是技术栈就很不错,赞。

  • 444104595@qq.com
    qq:97891996

  • 就用 Jmeter(+ant+jenkins)吧,水桶工具。

  • https 的能支持吗?

  • 我正在写自己的测试平台,但我之前没接触过 yapi,然后今天看到 yapi 的时候,我都惊呆了,难道我真的造了个轮子吗😱 😱 😱
    后面仔细看了下,还好还好,我的平台还好有自己的特色啊(比如集成了 Allure2 的测试报告吧,这需要我自己在代码中定制它,并不是直接使用 testNg 的集成之类的,而是相当于重新实现了一个集成依赖。当然这不是炫技,而是 Allure2 确实在测试报告领域,是未来,是趋势)。
    yapi 是一个成功的产品,很多经验值得借鉴呀(导入导出不说了,主要是 wiki(稍微单薄)和每个接口的备注,公共的环境配置,还有楼主写的这一段和 Jenkins 集成的方式,整体的格式和提示消息都非常棒)。
    yapi 也有一些不太好的地方,我就不说了。
    yapi 也有一些接口测试常用的,却没有支持的,我也就不说了,毕竟是我自己平台的特性……
    yapi 很成功,值得学习。

  • 年薪百万是测试负责人。好好看看职业描述吧。下面的小兵(高级工具人高潜)不是这个价位的。

  • 在社区与范式的 4 年 at October 24, 2019

    👍 👍 👍

  • 在社区与范式的 4 年 at October 23, 2019

    👍 👍
    大佬没提到管理技能,是疏漏了吗?
    我认为轮岗有利有弊吧,能详细分析一下轮岗这件事吗?我有点儿好奇。

  • 关于辛苦,简单说说我的理解吧。
    辛苦一般是几方面,时间上的和心理上的和身体上的。
    IT 行业,时间上和身体上的劳累就不多说了,其实最核心的就是心理上的辛苦。
    像华为这种高强度公司,或者阿里,头条这种,很多时候不是你自己不够努力,而是身边人比你更优秀,就把你比下去了,这种心理的劳累,高强度思考的劳累,高强度学习的节奏,不是 985 的出身是很难很难跟上的 (除了 985 就要证明自己高强的学习能力),去了也是被淘汰。
    再者辛苦也是有周期的,一般的 IT 工作,高强度的学习 3-5 年后,会进入一个平稳期或者过渡期或者是红利期,这段时间可以稍稍平稳,按照自己的节奏来工作学习,会比刚入职的时候舒服不少。不过阿里,头条,华为这种公司,不会让你轻易闲着,能力越强责任越大,占用你的时间越多。
    至于你说的兼顾家庭,这个因人而异,一句话吧,贫贱夫妻百事哀,很多很多时候,家庭琐事多,烦,是因为穷导致的(扎心抱歉)。

  • 确实,我测开也是兼职。

  • 可能你的心中早有决定,只不过希望我再给你确认一下了。
    手机的性能测试也是需要了解代码的,虽然你非科班出身,但是高通不累,相信 3-5 年后,在你高强度自学下,你可以成为这方面的专家。专家之后,管理岗位是自然而然的,即使高通不行,HOVM 应该也有你的一席之地,甚至互联网大厂也不是不可能。管理岗位是自然而然的,而你不能合理过渡到管理职能,只能有一个原因是你的能力还不够。
    华为是老本行,996,但是由于你是科班出身,不用高强度自学即可以快速上手工作。如果你的学业成绩扎实,工作勤快,情商高,相信可以快速过渡到职场人,快速拥有工作上的成就感,在华为立足,成为奋斗者,管理岗也是自然而然的。
    还有一些常识:

    1. 想赚钱,就会辛苦。不辛苦,还要多赚钱,那是你没看到人家的辛苦,或者家里有矿。
    2. 职场上,英雄不问出处。985211 有用,但没有决定性的作用。

    至于要去哪里入职,可以看看这两者的行业前景,先确定行业,再确定地方。具体可以问问老师,学长。

  • 先说说你投简历没音信吧:

    1. 年龄偏大。
    2. 年龄偏大没啥,看看公司如何,依你所述应该是个小公司,没啥名气,那么继续向下看。
    3. 学历如何,是不是 985,211,大专是肯定不行的了,至少二本大学网上看吧。
    4. 学历也不好,有没有好的作品,比如 github 等,博客等。
    5. 业务相关性如何,比如你是一直在 P2P 领域的公司的测试(跳槽的特别多),要转到人工智能的公司去,那业务没啥相关性就要够呛了。
    6. 薪资要求是多少,这和你技术水平有关系,如果啥都不是的,要的还多,或者要的薪资涨幅比较大(超过 5K),很难。
    7. 有没有管理岗的述求,没有管理岗位,适不适合你。

    可能看到这里,你的简历基本已经被 pass 了。(事实也是如此)
    再说说你的专家性:
    测试工作有两类专家:

    1. 测开的专家,专门开发各种测开工具,给测试同事使用。
    2. 测试的专家,所有测试同事遇到的测试问题,比如测试技术方案的问题,都要汇总到你这里,你要成为所有测试同事遇到的技术问题的终点。

    软实力要求:

    1. 测试的专家水分也不多,专家的 title 要得到开发的认可,就是所有和你接触的开发,对你的技术能力不能说不。
    2. 所有测试同事的技能把关,到专家这个程度,其它同事的技术成长,技术水平你都要心里有数,你的评价关系其它人的绩效奖金。
    3. 分享的能力,你的技术能不能广泛的传播出去,提升整个团队的技术门槛,甚至提升测试团队在整个公司,业内的技术影响力。
    4. 面试的把关,是不是阿猫阿狗都能进入公司。
    5. 管理能力,专家会带人了吧,P7 至少带的 P5,你需要带人来证明自己。(还有和各个领导的关系)
    6. 学习能力。不详细说了,现在的校招小朋友的实力,都很恐怖。

    再聊聊你的技术栈:
    很弱。实在不想怼吧。我见过校招的实习生,虽然是开发的实习生,应该比你高深。
    可能扎心了,举几个我问过的例子吧,如果你第一眼不用查百度,我收回我 “很弱” 的评价。
    回表。物化视图,MVVC,双向绑定,偏向锁,内存页的抖动,线程的生命周期。(这些都是校招题)
    不需要回答问题,如人饮水冷暖自知吧。

  • 其实你的源码我看过……api_automation_test 的源码我也看过。
    api_automation_test 不再维护了,我就多说几句好了……api_automation_test 的前端代码其实是比较烂的,同时我怀疑并不是一个人写的,更像是集大家之所长的作品,前端的风格我发现就有两种吧,具体表现是一会儿用 axios,一会儿换个界面就都是 ajax。相信你借鉴了也应该发现了。同时 api_automation_test 没有理解 vue 的组件化的思想,太多的前端代码都是重复的,怎么说呢,代码没有解耦。
    你的代码我就不在这里评价了。说一下你提的二次开发吧。
    在你这个平台上二次开发,我担心会不知不觉把 api_automation_test 已经实现的功能再自己实现了一遍。

  • 有个 bug 吧,项目中我更新了用例,但是项目的最后更新时间竟然没变。
    因为我看过原版的 automation_test 也是社区的开源项目吧,觉得你这个翻版的其实没超过原版的功能,或者还误删了几个原版很好的功能。
    比如:

    1. 同一个项目,不同的自动化测试用例,要复用同一个接口,原版是有接口选择界面的,或者选择到有的,或者新建接口。而你这里是只有新建接口,相当于抛弃了一个核心功能。
    2. 分组功能被你删掉了。分组功能是一个很棒的左树右表的功能,是项目下的又一个层级。简单说吧,如果你要去掉分组功能,那么你都不用做一个项目列表,还要有一个什么 “回首页” 的按钮,直接左边项目名称树,右边自动化用例列表就可以了。原版的项目名称跳转超链接就是为了分组设计的,很明显你没 get 到。
    3. 测试报告把 Echarts 图形也干掉了,但你也并没有拿出更好的方案。
    4. 项目全景也干掉了。

    当然你也增加了一下好的功能,可能主要是在断言的判断上吧。
    我并不是说你这个平台不好,而是希望把原版的好的基础上再做优化,而不是直接把一些成熟的东西不知道为啥的就全抛弃掉。

  • postman 接口测试 at September 09, 2019

    postman 确实是个成功的产品。

  • 这种思路很好,总的来说就是不要每次请求都要传数据,而是说 slave 先保存数据,测试结束之后走文件传输,例如 scp 把文件数据交给 master 整合。
    其实这种方式我尝试过:

    1. Jmeter 自带 diskstore 存储模式,就会将请求结果保存在本地文件。但是这种方式不行,文件保存路径是默认的在/tmp 下,文件名是随机的如 SerialisedSampleSender383066585222874452.ser 并没有地方能指定这个文件是哪个脚本文件的,这个文件名的前缀后缀是 Jmeter 定义的,但是中间的数字是 JDK 的方法 File.createTempFile("SerialisedSampleSender", ".ser"); 定义的。生成的 ser 文件,格式内容是 xml 的,文件比较大,同时默认是如果进程退出则文件删除,要不然也不会在 tmp 里,同时文件有分割,大概 113M 左右,就会被分割成一个子文件。
    2. 如果是自己实现,slave 存储 jtl 或者 csv 文件,来传输给 master 再拼在一起,这种我试过,在某些字段如 99%,90% 这些,和 Jmeter 实时传输汇总的得到的测试报告不同,也就是说自己拼装的 和 Jmeter 源生的方式,得到的测试报告不一样,而 Jmeter 源生的测试报告业界更承认。 当然这种误差很小,不敏感的可以接受。
  • 你这想的太多了,晋升的时候领导肯定都想到结局了,换句话说,领导早就放弃你了,你多虑了。
    你可以继续待着,不过要改变工作方式,改变大家对你的印象(很难很难很难)。

  • 直接改源码吧,改 maven 引用。

  • 我没看懂你的问题。

  • Mac 上的常用办公软件 at August 27, 2019

    打包 ios,玩 docker。
    除了这俩,远不如同价位 windows。
    个人意见。

  • 初识网络安全 at August 15, 2019

    写的真不错,已经收藏。向楼主学习。

  • 说一下我怎么给 Jmeter 改动代码的吧:

    1. 发现 Jmeter 解决不了我的问题。比如单进程内同时间生成多个测试报告。
    2. 查报错日志位置,对源码进行 debug,看源码问题出现的位置。
    3. 分析问题,大概了解了问题所在,如测试报告无法并发是因为公共变量的覆盖。
    4. 尝试修改,是否 Jmeter 自身的 public 方法已经支持改动。这个例子是没有。
    5. 一般我是拷贝 Jmeter 的源码出来,放到自己的环境里,然后改动,这个例子就是在最后生成测试报告在字节流的时候,才覆盖公共变量,而不是一开始就覆盖掉。
    6. 调试,验证 OK。