蚂蚁不用阿里云效的么？

CI 实施的前提就是版本控制吧，你可以把 local build 当做 CI 检查？或者在 feature 分支上拉个人分支开发，然后走 MR？

如果一个 feature 分支做 merge request 到 master 分支操作时，通过 webhook, feature 分支可以在做 merge request 的时候有 CI。那研发日常 push 代码到这个 feature 分支会有 CI 吗？
--有，只要存在 feature 分支作为源分支的 mr，feature 每一次更新都会发送一个 mr 请求，都会触发 CI
能做到代码 merge 到 feature 分支前做 CI 检验吗？
--可以，我们用的 jenkins+gitlab 的方案，checkout 有一个 PreBuildMerge 参数，可以实现本地合并后再用合并代码做 CI，若有冲突直接失败，合并不会 push 到服务端，只做 CI。

用 tcpclient 模式，刚好总结过：

https://angrytester.github.io/2019/07/29/TCPClient%E6%A8%A1%E5%BC%8F%E8%BE%93%E5%87%BA%E7%B2%BE%E5%87%86%E6%B5%8B%E8%AF%95%E8%A6%86%E7%9B%96%E7%8E%87/

这个方案是针对 java 的，可以参考类似原理来做。

其实不算实时，做了操作之后需要执行一下 jenkins 的 job 才能生成最新的报告。

呃。。这个是针对功能测试覆盖率

个人建议即使是测试开发岗，工作前一两年还是建议以功能测试为主，一方面是扎实测试的相关理论，另一方面自己实际体会一下测试工作中的痛点，才能有的放矢地提出技术方案来支撑测试工作。

所以说只是辅助手段，比如如果代码都有遗漏，覆盖率 100% 也无意义，任何一种手段都是为了兜底，多种手段结合才有可能把产品的质量底线提升到可接受范围。

个人觉得覆盖率报告更关注的是没覆盖的部分，而不是已覆盖的部分。而且这些都只是辅助决策的，不能作为唯一参考。如果领导不认可这个的话，下面会做的很痛苦，因为统计覆盖率大都是找测试人员的茬（漏测）。