单测这块确实是开发同学自己 cover 的，QA 同学除了维护测试工具还会 cover 3 端的 UI 自动化测试。

多端联合的场景确实是比较少的（由于多端互相影响导致的问题也比较少），比如文档 web 端编辑和移动端同时编辑 和 在 web 端开两个 tab 同时编辑，其实对于服务端的验证其实是一致的
另外 3 端测试涉及多个测试服务的逻辑编排和执行复杂度会很高
从这两方面考虑不会投入过多（如有必要会通过手工验证一下去保障）

至于灰度，我觉得是兜底的保障手段，我们是有内部灰度，外部的灰度肯定也有，常规流程，不至于依赖灰度去佛系发现问题。

确实不够好，我们目前重点就是高品质的产品体验，还需要一段时间的执行落地，有进展会进一步分享~

1. 统计的是研发团队的总人数，包括各功能模块开发（包括 TL）、2-3 个运维。本质上是减少了大量信息获取、各角色的协作沟通的时间，解放 QA 生产力 同时研发能便捷获取测试反馈无需找 QA 沟通问题细节。
2. 暂时没有更多数据可以提供，对线上的缺陷是有抑制作用的，但目前仍未达到理想水平。业务质量影响因素是多维的，仅仅靠研发质量体系是不够的，比如产品设计是否合理、性能体验等等，外部质量是我们当前努力的新方向。

确实，目前的质量状况还是不乐观的。不过相较以前已经有一些明显的提升了，至少在研发侧的体感还是比较明显的。
我们目前重点就是高品质的产品体验，还需要一段时间的执行落地，有进展会进一步分享。

目前我们的 case 还是工程化的，基于 mocha，通过 CI 调度机器执行（移动端和 web 端），桌面端是通过本地搭建的一套 macmini 机器执行的

会能本能，欢迎一起交流学习