把界面交互、逻辑 和底层功能拆分开，按人拆分功能管理和页面管理

有考虑过，请问有好的工具或者是数据衡量指标么？
上面想要我做的是先分析出问题，然后针对问题去考虑动作。直接做动作会被喷。

这是对症下药啊~

P1 为核心业务出问题了
P2 为非核心业务功能
P3 为非核心业务界面、交互等

我们会分为是发布当季 BUG/历史 BUG
BUG 类型也有分需求设计问题，技术设计问题，功能遗漏，逻辑错误等等
总的问题会归在历史 - 逻辑错误的 BUG 上，情况会分为 2 中：
1.未做改动，发布很长时间后暴露的问题
2.修改后，被暴露出来的
原因：
1.功能现状看不清，都基于需求和个人对业务的掌握能力做事情
2.执行流程不规范（用例不进行评审）、开发不做技术方案

针对原因 1：要求测试按功能做用例沉淀（执行效果不理想，干完就存本地不上传不分类）
针对原因 2：用例评审覆盖 100% 版本，技术方案评审覆盖 100% 版本

执行一段时间后监管力度不够，又会变成原来状态，但是也不可能一直靠人来监管吧
有一些很小很小的版本也要做评审？

针对第五点回答下，本人刚好也正在历此劫。

5.对于小公司，接口自动化的效率如何体现？
1.首先你们公司是否有接口测试，如果没有接口测试，增加接口自动化是不能提升效率
2.如果你们有接口测试，你们做自动化的目的是什么？针对目的做自动化能更清楚自动化给你带来的收益
3.线上/测试出现多少因为接口测试不全的 BUG，拿数据来说话
4.和楼上说的一样可以做定期的回归（发布回归，开发分支合并回归）
5.监控线上业务接口（定时抽查接口，校验是否稳定）

查询权限，不是编辑权限，还能删库？