这个模式有利有弊：
3 年前，我们就是这种模式，每个测试是工作在开发组内的。 好处是对于这个技术层的纵深会有提高。你会经常接触到源码，框架。你需要设计特有的自动化来进行功能/性能甚至白盒测试。技术发展是突飞猛进。
不好的地方是话语权，如果领导认同质量管控，给与话语权， 那还好， 不认同那就是背锅工具人了。

测试人员是横跨所有技术层次的，前端/后端/数据/模型/抓取 等技术层， 除了全栈， 很少有人能了解/知晓全部的设计以及关联性。而且加上测试人员对于产品的需求理解。
这个时候测试人员非常适合作为团队内沟通的桥梁，这个是团队战略价值。

测试现在已经开始左移右移了， 左移可以防微杜渐，将问题扼杀在摇篮里。右移可以警钟长鸣，将经验教训带到下一个项目中。这都是价值所在啊。只不过不一定所有老大都有这个意识。

测试的尽头啊， 个人浅薄理解：
技术深入，做技术专家， 一个好的测试做起技术应该也是完全没有问题。 只是分工和侧重点不同而已。
深入产品和项目， 那就是产品专家/项目技术经理， 负责团队沟通以及项目进度。
半技术半管理， 那就是测试经理/负责人。

日志加了， 如果是和产线一套模板/服务， 也不怎么费开发。
日志留存个 1 天/周（ 根据你们测试场景），也没有很大开销， 按需测试也没那么多的流量。
好处就是， 容易朔源， 也方便定位问题。

监控的好处就不用说了，测试环境不加监控，挂了你都不知道。后面就各种项目来了临时救火修环境。
最简单就是把现有的自动化测试， 在测试环境每天跑一版，能定期回归，又能保证测试环境可用性。
利远大于弊

可以在服务器上搭一个 docker registry，本地 build 好镜像了就内网推上去，方便管理。

Excel 的话, 对于共享/分发/同步 可能不友好.
JIRA 类似的 bug 管理系统应该都能很好的解决这个问题. 搜索/反馈/统计/分类, 都可以在 JIRA 上很好的实施.

google doc，支持多表 query，缺点是要 ***

欢迎👏👏