的确是误解
楼上那些如此排斥的、觉得恶心的，请问你们了解过吗？
就拿质量内建这事来说，到底哪里让你不爽了呢？莫非开发提交一堆垃圾代码跑也跑不通你就很开心，可以奋起提 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 等等等等……所以你所说的广度这就已经很可观了，关键是：你真的做到了追求深度了吗？

懂了，核心问题是 url 拼接没有用 rootUrl，用了 current location

给艾总新书做的硬广而已，怎么就变成了 bug？

你为什么认为你的『预期结果』是对的呢？
在我看来目前的跳转没啥问题，右侧的版主展示是框架性的内容，不会因为你在哪个节点而跳转目标不同

换个问法：开发能自测又能自己设计很科学的 case，关键是有问题随手就改好了，Geek……还要测试干吗呢？
显然开发的长处是写 bug 和改 bug，指望开发设计 case 就很容易陷入开发者典型的固定思维套路，造成大面积测试遗漏，你是测试大拿，你这时候还不上去体现自己价值更待何时……还问~

@ 一枚老男孩 其实是可以用的，默认都是无样式的，你们试着改一下字体或者字号，『复制样式』、『清除样式』就可以点了
但是『粘贴样式』是有 bug 的，只是样式上一直是 disable 的，但其实也是可以点的，试一下就知道了，找一下样式控制那个文件改一下代码就 OK 了：

go、c/c++、oc 的覆盖率呢，不比 Java 用的少啊

为什么连这种话题都要匿名，上瘾吗

没有好不好，只有在自己的能力范围内能胜任的最好职业，我也想去做上市公司做高薪高管，然而实力不允许啊

我 30 开始兼职 CRUD，到现在（37）还是 CRUD，只不过变成了需求、架构、设计、建模、前后端都能自己搞定的 CRUD，佩服楼主的魄力，这么大年纪……