人家说的不是业务测试,而是产品经理以及产品面向的业务用户甚至是内部客户~
我觉得有必要啥时候再写一篇文章来讨论一下这个问题,社区里这种话题太多了
话说我都 4、5 年没写文章了吧,唉……
只要薪资给到位,接受转行干环卫!
只要薪资给得够,接受每天跪着走!
只要薪资给得爽,接受马尿喝二两!
只要薪资给的足,接受当众表演撸!
看到这段,我不由得要祝福楼主:加油,因为所有的大公司的中高层在你看起来可能都在勾心斗角,而你居然如此 care……
项目忙要离职,项目组清闲也要离职……为了思考如何适应你的度,老板头发都白了~
但是 8 月份我辞职了,因为这家公司勾心斗角,中层之间为了各自的利益互相整人,当然受害的就是我们这群手下,还有个最重要的辞职原因,我们公司三个项目组,一个测试负责一个组,我这个项目组超级忙,每周四都要迭代更新,我就不停的加班加点测试,其他两个项目组的很清闲,老大都不安排他们帮我,反而安排他们学习,我看着他们学习,讨论着新知识,我什么都不知道,只有埋头干,又一次忍不住开玩笑似的给老大说了,老大还是无动于衷,那时候心里真的又气愤又难过。
贵 “鄙公司” CTO 亲自来请教了吗
有数据表明,每 1 万日活对应 1 位测试比较合适,哈哈哈哈哈哈哈哈~
多机并行足以,还并发……有什么必须要性能说明一下吗
一般都是两台或更多 HAProxy 服务配合 keepalived 一起分发,keepalived 负责 High Availability,HAProxy 负责 Loadbalance,但是实际工作的 HAProxy 服务只有一台,的确是单点,需要带宽和性能非常高
所以,最后的解决方案是啥?HAProxy 服务硬件扩容?HAProxy 服务前面加请求队列管理?
没有
双十一的时候我 2C 8G 5M 带宽的 2070/3 年,还返现了 320,相当于 1750 三年,比双十二划算太多了
白盒为上……发请求其次,下下策是狂点 10 万次,请参考:
https://coolshell.cn/articles/8593.html
没见你测试中奖概率的正确性?
最开始用 Jenkins 是做自动化测试,一开始就是 slave 资源池(预先算好容量)分组模式,master 上不允许跑任何 job:
group-label1:QTP
group-label2:selenium
group-label3:UT & sonarqube & Fortify
……分组插件是测开的小哥哥小姐姐们写的~当时害我查了好多文档没找到这个功能~
那时候容器还不火,现在真心是技术进步太多了,骚操作一波接一波的~
cache:缓存低速 IO 设备上的内容,供频繁读,用于提高 IO 效率
buffer:缓存程序所需交换的数据,供合并写入,用于减少内存和 CPU 操作次数,某些情况下也是为了提高 IO 效率
大平台的甲方工资低才有意义
for this:
一直以来都觉得自己得不到最好的是因为自己太弱,怪不得别人
所以,如果有机会,我一定会变成自己最讨厌的人——有钱人!
我就是众多电视剧中的终极大反派的典范:起初最善良,最后最邪恶,我不否认,哈哈哈
这个观点我表达过了
我不代表社区,我跟社区以及黄老板毫无瓜葛,纯粹的第三方吃瓜群众言论而已,我不会心虚的
我想表达的是,喷子说你水、作假,我觉得很大成分上可能是真的(通过你专栏另一篇文章的通篇辞令分析出来的),但是不值得去喷,喷显得忒没水平,要求做生意赚钱坚守道德底线是不礼貌的行为,就是说我知不知道详情都可以表达这个意思,懂了吧?
写的烂不烂不重要,虽然我特别歧视楼主用 excel 组织测试的框架设计,但是还是比较赞开源精神
在开源工具上做生意,大家都有自己的法子,不要把小生意跟道德挂钩,能跟道德挂钩的都是大生意
所以:
1、我不知道楼主的行为具体咋样,果真如按照喷子的描述估计我是鄙视的;
2、如 1 成立,我可以容忍楼主短期内那么做,但是长期来看还是要改进,但是喷子如果拿不出更优秀的东西出来还是停止喷吧,我还看不惯 XXXX 呢……
3、楼主对社区有很大误解,也别说什么你们内部咋运作不知道这种话,社区从来没以自己官方的名义说过啥名企定向合作的事情,既然你如此认定……那你是把社区当成你的竞争对手了,跑竞争对手这里发帖子有点下作,还是不要了,要么你收回你不知道你们内部咋运作这句话
试试
.mian-content {
backgroud-color: #FFFFFF30;
}
既保留背景的朦胧美,又不至于让人看着太恶心
分布式主要考虑两大点:
1、failover 接管
2、同步的延迟是否满足请求频次的需求
还有就是他这个 remote cache 的容量能否跟得上这个集群所有需要同步的 cache 的量,最简单的办法就是持续加压。
remote cache 听起来就像抓娃里面的 violate,保证各个节点都从主存(remote cache)中读数据,但 violate 并不能保证线程安全,同理这个 remote cache 应该也不能,所以楼主说的业务代码需要主动加锁保证一致性是很有必要的。
港真,分布式的设计本身就需要考虑测试方案,可测试实施起来可比代码写起来难多了,我被 ehcache 坑过一回,自己做的 cache 方案自己写代码、自己测试,都快测哭了,后来换 redis 单点主从热备方案了,连集群都没敢上,业务性能需求需要的强一致性导致项目组不再信任集群间同步的效率,尤其是有限流的云服务器上……半吊子看法,讲错勿怪~
element-ui 的最大毛病,就是就算模块化按需引入,打包出来的 vendor.js 还是暴大
你这首页慢的哟,推测你的服务器带宽 1Mbps 以下,哈哈
我双十一买的是 5M 带宽的,很大一部分原因是为了解决 vue+element-ui 这个鬼问题
1、线上质量监控
2、缺陷根因分析(测试 + 线上)
3、过程数据侧面度量——各种数据的绝对值、比重、比例(密度)以及趋势发展动态
看了几个实名的大佬的回帖,感叹一下:
1、大佬越来越大佬,随着经验增长,大家都快认知趋同了
2、匿名抱怨的一直在通过表面现象恶意揣测,选择性忽略一些重要的其他要素来以偏概全,不针对这个帖子,很多匿名吐槽都这样~
3、匿名君可能还是会坚持认为大佬们这么说只是屁股决定脑袋,不知道大佬们年轻的时候是不是也曾有过这样的心路历程,抑或是正因为大佬们一直坚持深入思考才成了大佬~