这是正常讨论又不是吐槽,匿名的底层逻辑是啥?顶层设计又是啥?如何保证闭环?如何赋能社区?
这是正常讨论又不是吐槽,匿名的底层逻辑是啥?顶层设计又是啥?如何保证闭环?如何赋能社区?
案例 1:我刚毕业那会,A 公司狂招人,然后入职没多久公司就卖给另一个公司 B 了
案例 2:一个同事应聘某公司旗下互联网公司开发部门总监,入职之前通知公司解散了
哪里拷过来的,既没有排版,也看不到图片,更看不到出处说明
做多了应该手熟,开始做 10 件错 1 件,后来做 100 件错 2 件,再后来做 1000 件错 3 件,最后做 10000 件还是错 3 件……这样的话只要领导不是 SB 都知道咋回事
但是如果做 10 件错 1 件,做 100 件错 10 件,做 1000 件错 100 件,那就别做了,这种情况下不做就是对团队对公司的贡献,极大的贡献
如果交付一个服务给你,你需要花 3 个小时才能发布更新完成,甚至中间会造成长时间服务中断,你觉得这个算不算交付件的质量有问题呢?我觉得必须是……
openjdk 了解一下?
有些明确的 Exception,如果可以 trace 到 file,然后就可以追踪到 MR,直接给到代码负责人就行了,通知还是要的
死锁也能洗,佩服佩服……
所以,短期内,测试的价值靠测试工程师支撑、体现,长期看,测试工程师最好是没价值,不管你乐意不乐意,这一天终归会到来。
nodejs、java、c、go、rust 先后表示封禁中国企业,你咋办
那仓颉造字干啥,人类一边说一边比划多好啊,有了文字就有了妨碍啊
这几个词本身就不是什么高大上的黑话,只是一种思想或者行为的抽象称呼而已,如果你觉得自己能用其他的简短的话语来表述那大可以说出来,没准出于对 ALI、HW 的反感,大家更愿意用你的说法呢?毕竟我也讨厌赋能这俩字被大厂用成了垃圾~如果造词有罪,那我还鄙视 “全链路压测” 呢……
说实话,我当初看到 “质量内建” 这四个字(十几年前),就像中学读到 “落霞与孤鹜齐飞,秋水共长天一色” 一样感觉很惊艳,聊聊几个字就可以把本来很抽象的东西具象化~
的确是误解
楼上那些如此排斥的、觉得恶心的,请问你们了解过吗?
就拿质量内建这事来说,到底哪里让你不爽了呢?莫非开发提交一堆垃圾代码跑也跑不通你就很开心,可以奋起提 bug 刷 KPI 了,还是被 block 干不了活了可以开心的划水?再或者开发提交一堆看似能跑过但是像屎一样的三角形代码,加一个逻辑你就要回归所有的分支,重构一个方法你就要测一周这样才开心?
stage ('SonarScan') {
echo "codeAnalyze started!"
withSonarQubeEnv() {
sh """cppcheck -j 4 src/ -itest --enable=all --xml --xml-version=2 ./* 2> ${WORKSPACE}/cppcheck-result.xml"""
sh """sonar-scanner \
-Dsonar.projectKey=${JOB_NAME} \
-Dsonar.projectName=${JOB_NAME} \
-Dsonar.sources=${WORKSPACE} \
-Dsonar.host.url=http://jenkins.urcompany.com \
-Dsonar.language=c,c++ \
-Dsonar.exclusions=**/*.py,**/*.java,**/*.go,**/*.js,**/*.ts,**/*.css \
-Dsonar.inclusions=example1/**/*,example2/**/* """
}
echo "codeAnalyze Completed!"
script {
timeout(10) {
def qg = waitForQualityGate('caffe_quality_gate')
if (qg.status != 'OK') {
error "未通过Sonarqube的代码质量阈检查,请及时修改!failure: ${qg.status}"
}
}
}
}
必然是长相气质佳了,老总面子上过得去,为了男票牺牲了原本更好(大约 3141592654 倍)的上升通道着实有点可惜,不过既然在意家人的感受,选择去做技术也是可以的,只可惜测试还是有点累的
其他大部分项目管理类工具都是基于自己的项目管理思想来建立的,不见得可以很自由地设定工作流,有时候甚至要反过来团队的工作流去适应系统。
往往自研这些工具主要就是为了固化和沉淀一些组织级的流程或者规范,当然 JIRA 通过 ScriptRunner 这些插件配合起来也可以实现。
JIRA 有个不好的地方就是,大家都知道可以变流程,就各种提需求、争吵,最后通过很多项目就会搞出一堆乱七八糟的东西出来,做度量和组织级改进的时候非常操蛋。
自研优势就是告诉项目组,这是组织级流程的固化,不符合流程规范的进行不下去,可以避免很多失误和口水战,比外来的和尚念经有时候效果还要好一些。
我理解,恒捷大佬是通过抱娃,练出了腹肌和胸肌,所以大家赶紧造娃啊,娃喂的越胖效果越显著啊
楼上那几位,你们为什么会觉得楼主没有写过脚本、不是通过脚本去优化的框架?
内部公共包/二方库这些,需要使用 nexus 之类的内部 maven 仓库来管理,基础模块预先发布好,业务模块才可以编译、发布
TO 楼主:不要妄图自动化一切,除非你们的 cmdb 做到了高度实时有效,即便是这样,也要花费很多精力:维护组件目录映射关系,通过变更文件清单找到所属组件,从 cmdb 查找、解析所涉组件所有的依赖组件……并且递归查找到 root,然后自上而下去发布基础组件,最后再发布你当前变更所涉及到的组件~
首先你的登录服务必须是一个独立的仓库,或者是一个大 project 里面的一个独立的 module,以 spring 为例,可以参考https://www.cnblogs.com/toutou/p/project_module.html
maven build 的时候可以这样做:https://www.cnblogs.com/wenbozhou123/p/7885905.html
都是一个百度就能解决的问题
我们抛开开发自己背不背锅的问题,只说测试工程师,归根结底这是个卷不卷自己的问题
如果对自己、对自己的职业有所要求,那么一切 “Bug 藏的太深”、“测试环境无法复现” 的理由都不是借口,因为如果你愿意卷一下自己和自己所从事的这个职业,你一定会想到、找到办法规避这个问题,不然那些单测、静态分析、渗透攻击、埋点、监控、生产流量导入乃至混沌工程之类的解决方案要来干吗的?—— 如果愿意承认这个世界上有至少一种手段来规避这种漏测问题,那这个锅就背的心安理得了。
如果说将自己和测试这个职业定义为仅仅是点一下、看一下、验一下的角色,那么遇到比较复杂难以测到的问题,出现漏测自然觉得无所谓,因为我能力有限啊,发现不了还能怎么办?要么你牛逼你来?再说你也不看看我拿几毛钱工资?凡此种种,肯定不会觉得自己应该背这个锅的。
当然,那种用户一眼就能看出来的问题,无论你对自己是什么要求,只要没测出来,那就认了锅吧,不然就真的不要脸了。
卤煮的观点高度赞同,速成也速失,或者经不起推敲、拷问,做完事情自己的能力没有得到多大提高
酒吧不好,来我们玉兰四期吧,我请客
好吧,实话说,我前面回复的时候说『预设了很多背景条件』,然后想说就像某些沙雕面试官的出题套路一样,结果觉得太那啥了,又憋回去了,不成想还真是……
信用卡额度这么明显的因素不用考虑吗
另外,也赞成拒绝这种垃圾需求,连用户场景都没交代……大约是预设了很多背景条件,但是都没说出来,觉得所有人都默认明白