蚂蚁不用阿里云效的么？

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% 也无意义，任何一种手段都是为了兜底，多种手段结合才有可能把产品的质量底线提升到可接受范围。

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

实时染色还是基于 jacoco 实现的吗？效率如何？

你可以用 fiddler 拦截请求 一个请求一个请求放 另外对这种不是每次必出现的 loading 得做个判断看元素是否存在再去做 waituntil 否则 rf 执行会有问题 之前遇到过

有个问题 如果 graphwalker 一次无法遍历所有节点 工具是否会报错？

为啥获取不到元素定位？因为太快？

每次部署都需要更新所有服务？如果是这样 可能要考量一下服务设计是否合理了 依赖过多？

嗯 是的

感觉这种方式还是传统虚拟机的玩法啊..为啥还要依赖 war 这个中间产物呢 直接输出镜像不好么 纯探讨哈

有点忘了当时装的时候遇到啥问题了 后面直接就上 docker 了

这种方案是不是不能排除注释和空行这种非逻辑变更？

感谢！

顺便 片子有下载吗

转型的难点可能主要在于工作习惯的改变 光 kanban 里的限制在制品这一条 感觉我们做了半年多了都还有团队成员觉得别扭

docker 虽然是一种虚拟化技术 但是一般不叫虚拟机 再说我们的做法 镜像的原则是尽可能层数少 也就是尽量只包含必要的东西 所以一般都不会以一个完整 ubuntu 作为基底去打镜像（不完全排除有这种需求）建议常见的一些应用镜像 例如 mysql redis 等 最好参考官方镜像的 dockerfile 去做

diffy？

https://github.com/AngryTester/jacoco
工具改造了一个，平台还在建设中，后面做好了会开源。