哪里拷过来的，既没有排版，也看不到图片，更看不到出处说明

做多了应该手熟，开始做 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 干不了活了可以开心的划水？再或者开发提交一堆看似能跑过但是像屎一样的三角形代码，加一个逻辑你就要回归所有的分支，重构一个方法你就要测一周这样才开心？

• 如果 workspace 每次清理的话，可以用在 pipeline 取到 merge request 或者 push 中的 commits，commits 里面有 files，gitlab 和 svn 都有接口，如果是 gitlab 的，webhook 里面的 trigger 也可以（信息在 trigger 的 request body 里面）；如果不清理的话，变更会更容易在 runner 本地获取变更集，参考stackoverflow或者博客园
• 把 files 放到这个参数里面：-Dsonar.inclusions=example1/**/*,example2/**/*
• 1 分钟这点时间实在算不了什么，每次做全量有个好处就是代码质量趋势看得比较清楚，作用不单单在于卡准入，对存量的质量管理也有作用。

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 藏的太深”、“测试环境无法复现” 的理由都不是借口，因为如果你愿意卷一下自己和自己所从事的这个职业，你一定会想到、找到办法规避这个问题，不然那些单测、静态分析、渗透攻击、埋点、监控、生产流量导入乃至混沌工程之类的解决方案要来干吗的？—— 如果愿意承认这个世界上有至少一种手段来规避这种漏测问题，那这个锅就背的心安理得了。

• 如果说将自己和测试这个职业定义为仅仅是点一下、看一下、验一下的角色，那么遇到比较复杂难以测到的问题，出现漏测自然觉得无所谓，因为我能力有限啊，发现不了还能怎么办？要么你牛逼你来？再说你也不看看我拿几毛钱工资？凡此种种，肯定不会觉得自己应该背这个锅的。

当然，那种用户一眼就能看出来的问题，无论你对自己是什么要求，只要没测出来，那就认了锅吧，不然就真的不要脸了。

卤煮的观点高度赞同，速成也速失，或者经不起推敲、拷问，做完事情自己的能力没有得到多大提高

酒吧不好，来我们玉兰四期吧，我请客

好吧，实话说，我前面回复的时候说『预设了很多背景条件』，然后想说就像某些沙雕面试官的出题套路一样，结果觉得太那啥了，又憋回去了，不成想还真是……

信用卡额度这么明显的因素不用考虑吗
另外，也赞成拒绝这种垃圾需求，连用户场景都没交代……大约是预设了很多背景条件，但是都没说出来，觉得所有人都默认明白

你发到活动区，应该就不会有人跟你较这个芝麻真了

想当然了吧，工业 App 范围太大了，有些可能涉及自动控制的，不重视测试？
反正我不信，不然每年因为这个要死多少一线工人呢

记得：广度是深度的副产品，如果你觉得你自动化测试做得很好了，但是只会自动化测试等很容易被替代，说明你的深度根本不够，没找到解决问题的核心方法套路。
举个例子：做 GUI 的自动化测试，面临分布式、兼容性问题的时候你要解决的就会有测试实验室/云测服务的构建，市面上的现有解决方案无论多优秀，在你具体的场景落地的时候都会有这样那样的问题，你要解决下去就势必需要掌握这些周遭的技能，比如自己加特性、改 BUG，了解开源协议背后的知识，学习采购和设备管理，保不准还要掌握 docker、k8s、openstf 等等之类的技能，然后保不齐又要辐射出 dockerhub、helm 等等等等……所以你所说的广度这就已经很可观了，关键是：你真的做到了追求深度了吗？