槽神好，不敢称老师，以前在微博有关注过您。持续交付平台无论是开发、测试还是运维主导去做都没有问题，但 devops/持续交付体系里测试自动化本是核心要素，各种技术论坛却鲜有听到测试相关的声音，不免有些感慨。

梁大师有空也做些测试技术的分享，这个圈子需要你们这些前辈们的声音。

感慨下，相比起运维社区对持续交付/devops（这个名称容易让人忽略了测试的角色）的热烈讨论，大多数测试人员对此关注的还比较少，甚至有被边缘化的趋势，这是让我这个在测试行业侵淫了十多年的老兵比较焦虑的地方。

看项目使用的技术栈，是否满足所有接口的测试需求。从长远考虑，如果团队有代码基础。还是直接写接口测试代码比较灵活。

我还是比较赞同这个观点，web 化的测试平台很多时候会作茧自缚，无数的个性化需求很容易把它压垮，而且框架如何长时间维护也是一个大问题。既然对测试人员的基本要求都是能 coding 了，直接代码化编写不是更合适吗。

谢谢认可，欢迎交流

<sonar.java.binaries>${basedir}</sonar.java.binaries>

可以这样去配，从项目根目录开始查找，sonar 那个文章里有详细说明

移动 java 代码这个没必要吧破坏源代码结构了，如果只是想把 jacoco.exec 汇聚在一起，可以控制 jacoco.exec 的输出路径，或者运行完后把 jacoco.exec 文件收集在一起也行啊。

确实搭建平台和工具是一方面，推动团队理念的改变并接受去使用才是基础，这个事情光靠一个工具团队玩不转

期待有一款优秀的 APP 遍历工具

嗯，是这样的，能自动化的环节尽量都要自动化。

确实推动交付体系的改革需要从上而下的支持，光是一个团队一头热是难以达成的。针对 sonar 这块我的心得是把代码规则让开发的架构团队去定，毕竟他们对怎么写出好代码是最有话语权的，争取他们的支持非常重要。

问题数并不是一个好的代码检查指标，我们现在是根据公司的编码规范定义了代码问题等级，阻塞和严重是必须要解决的，其他等级的只做参考。

QTP 这种商业化测试工具 10 多年前很多人研究包括我。现在想来投入的精力并不值当。技术链最好是能与公司的技术体系能保持一致。

我是看了这篇文章才想到在这里留点文字的，目前测试这个圈子拿的出手的社区实在太少了甚至可以说没有。这也是这几年来测试这个职业变的越来越默默无闻的原因之一吧。

可以看下 sonar 新版本 webhook 的机制

能对大家提供些许帮助，正是后面继续写下去的最大动力

求科普底层 AI 实现框架和算法

总的来说已经越来越强大了 jenkins 社区后面的主要方向就是完善 pipeline 这块。

是 360 的代码安全检查产品吗

尽量完成哈，覆盖的东西比较多，有时间就总结点。

这不就是一个发布 pipeline 吗