不多，你才列了三个。我毕业第一年用了之后，再也没用过。

这个只能是实际情况实际分析了。你的业务模式跟技术实现方式很大程度上会导致结果的偏差。
从技术手段上来说如果你是网页端跟 APP 的话，区分前后端的 Bug 有个很直接的方法：自己 mock 一个正确的接口返回。（前端如果参数穿错的话应该是能够很直接的看出来）
从流程上来说，你发现的所有 Bug 第一优先提交给前端开发，如果不是直接对接人的问题是会自己转交给下游的。
从个人提升的角度上来说的话，我会劝你深入的了解前后端的技术实现逻辑，架构设计，数据流转等等。

是的吧。。。你们的开发测试比有时候就一定程度上代表了工作时间比例的评估了，因为人力配比是工作量长期动态平衡的结果。

charles 也是收费的。

核心用例长期维护（P0）；模块用例定期维护；版本用例看心情维护。
核心还是取决于用例的复用率有多高。虽然系统是长期维护，但是如果你的功能每次都是新的用例也基本等于是一次性的。

如果是历史业务的优化改动，基于自己对业务的熟悉程度评估。
如果是新的项目，毛估是按照开发与测试 2：1 的工时计算。如果有具体的技术实现方案评审，可以酌情加减时间。（假设开发测试处于同等技术水平下。）
题主所述的情况，建议就是解决带来问题的人是最好的解决方案，虽然看起来有点残忍。

开局一张图，剩下全靠猜？

哈哈哈。严谨如你。

取决于工作内容跟周围同行的水平。比如：某天开发突然说优化了一下代码，问为什么。开发说运维反馈 IO 太高，需要减少。那要如何测试呢？

常常说的理论基础。这就是理论基础跟常识。点赞。