一个产品对应的开发有多个层面的，前端、后端、类 openstack 后端开发，去年版本频率正常的时候是有项目周会一起沟通的，也有些许成效。现在人员少了，版本频率相比增加了，缺少了之前的沟通，只是工位就近的开发去聊一下。作为测试确实也有自己身上的过错，工作做的狭隘了，没有做好产品 QA 的工作，在此也反思一下。

测试人员是提供自测用例的，加上时间排期紧，测试监控开发自测这方面做的不到位

简历之外的内容也可以关注，比如 github、论坛贡献之类的

上述测试开发技能图中，一个人会的越多当然越好，实际往往是工作中能接触到的、用到的会越来越精通，其他的只能自己在业余时间去摸索自己感兴趣的。每个分支都很深入的话，很难，也没有太大的精力，就算是学了，长时间不用也会慢慢生疏。测试是一个团队，不是单打独斗，在这个团队中需要的是某方面精通，能扛起单方面大旗的人，而不是希望整个团队中都是多面手，就像是海贼王里的草帽路飞一伙儿，各有各的长处。

这个问题向负责的项目组反馈了好几天了，还是没有变。按我的理解，这部分应该灵活可配置的，数据库里就可以将模板改掉，还是存在这个问题，要么开发设计有问题，要么制度有问题，要么对产品来说这不是问题或无所谓（最低优先级处理） 。
哎，上面的三个要么，每个都是潜在的可能会暴雷的问题。

建议收下了，当下先想办法推起来，大家都用起来了才能知道哪还需要优化，这时一点一点的细化才合大家的想法。

功能刚做出来没多久，第一部分 CICD 模块做完后也推过，没什么效果，主要是测试还是以业务测试为主，自动化率不高，我也是在业务不忙的时候去搞一下平台，只能一步一步来。整体流程也是在摸索中前进。不过平台上验收测试这个模块倒是使用率 100% 了，毕竟是平台最开始的功能。

完全用 Jenkins 也可行，不过上文也说了，公司目前没有对 Jenkins 特别精通的人，也没有人专门负责，对于 Jenkins 的操作权限也完全在开发那边，Jenkins 对于运维，公司还没有走到一步 。Jenkinsfile 也是开发的那边管控的，放在项目代码目录里，基本上配置好后就极少去动了，为了项目并行，可能一个项目组测试环境就有多套，总不能让开发经常去改 Jenkinsfile。另外一个初衷就是统一记录，后续方便测试分析。

技术要求越高的越是紧缺资源，对于门槛比较低的业务测试，永远不会紧缺，以后更是会有被淘汰的趋势