如果重视这个发布的质量，就要抓测试覆盖率和回归测试覆盖率（鉴于你说的改动引起其他功能）；
要抓回归测试，就要看测试资源和测试时间；
要做成常规的回归测试，就要做自动化测试。
所以对我来说，做自动化是必然需要的；至于担心资源不够，看你怎么规划和协调了。

你确定是接口没问题 UI 有问题？这种项目一般都比较垃圾，内部系统 UI 还要处理数据？
我觉着如果是上面这种情况，你应该考虑下给研发提改进需求

大量回归得做，自动化也得搞。
你是测试，质量自然是优先考虑的内容。态度强硬点，和业务商量回归测试的重要性。
既然要回归，可能会给业务方延期，经常延期的话业务方那边也不好交差。所以后续自动化也得做（不能因为麻烦就不做），按照现在的情况来看，做自动化对大家都有好处。

我们部门处境和你公司很像，上周因为线上 bug 导致没绩效。现在我们的做法是 和业务讨论回归 case，然后有空的时候做自动化

其实我觉得测试项目有 bug 是很正常的情况，和你用什么方式测试没什么关系，重点还是看你们项目的测试策略，评估项目的侧重点，是不是为了项目进度就是可以牺牲掉一点已知的模块质量。但是如果是确实是验证了但是漏测，这个就比较难受了

测试时间已经不够了，你还要去搞自动化，UI 频繁变动的话维护自动化脚本花费的时间比你手工点一遍都长。我觉得短期内还是提高对需求影响范围的分析，增加回归测试的颗粒度和范围更出效果。自动化的开展需要详细分析是否具备可行性以及投入的决心，否则短期看不到产出，容易使领导降低信任，很容易放弃的。

都漏测了，是考虑不全了，前提搞错了

1. 先得评估出影响范围，哪些老功能模块被影响了，自己要适当看看代码；（也需要研发给出反馈）
2. 根据此次更改，圈定测试用例，和研发达成共识
3. 执行到位

自动化有空了或者双休日加两天班，突击掉。但是其实一般自动化都覆盖主链路，而故障一般都是一些异常场景。还是挺难的。

一样的随时随地的活从天上来 测试没流程 炸裂

七楼八楼答得非常好了。总结一下就是：

1. 先做好测试评估，思路是先拉研发一起看达成测试范围共识（评估的过程中要抛出时间限制，以及明确出质量问题要供共同承担的意思），有余力再做测试覆盖率的验证。
2. 建立好基本的研发提测流程，约束研发提测的自由度，明确你下班前半小时提测，我就是无法测试完成上线。记录好研发开发工时和测试工时，逐渐平衡出一个相对合理的研发测试工时占比，没理由每次都是研发改 10 分钟，你就要测半小时。
3. 线上漏测 bug 重点分析原因，如果明确是新需求改老代码导致老功能出问题，很大一部分是可以评估出来然后做回归的；如果是评估不出来的问题，要不就是研发对代码不够了解（在只有一个测试的情况下，更别说让测试能评估出来），要不就是边界 case。以上都不是你做自动化能解决的问题。
4. 前端自动化没必要做，尤其是这类内部系统，一方面变更成本低，另一方面大家对这个系统不够敬畏重视，做前端自动化大概率是负 ROI 的事情。

楼上说的没错，我理解楼主其实想通过自动化测试解决自己时间不够的问题，这样多一点时间用来回归测试？想法是好的，但你这种情况，做自动化测试很难有正向的 ROI。找领导好好沟通下，协调人力

UI 自动化，对变动频繁的项目没有用，用例需要不断的调整以适应项目的变化，ROI 太低，我们是一周一发版，最后都放弃 UI 自动化；
对于变动频繁的系统，自动化的收益都不高，优先保证已经不会变动的核心流程，使用接口自动化结合覆盖率工具一起去保证测试质量
如果是 go 语言我记得有框架，可以输出，每次调整影响的返回，可以根据这个确定回归范围
《最近几周线上经常发现漏测的 BUG，是不是该搞自动化了》
和开发明确测试范围，范围之外的 BUG，你不需要负责，先明确责任范围

先搞接口，后面再搞 UI

我现在这家公司线上经常有 BUG，而且这里对线上 BUG 不重视，出现了就解决，就没有然后了。。。
质量跟屎一样，整个脑壳疼

对不合理的需求说不，对不合理的排期说不，对不能在计划内完成全部功能的测试的情况及时反馈给领导， 预警！
以我之拙见， 功能测试都完不成， 自动化测试也要花时间去写脚本嘛， 哪有时间来搞。