如果这是一个业务场景，那是不是回归测试的时候可以覆盖到

开题立意：我不赞同楼上的观点，回归可以更全面，但是不能冗余
首先，我们确定下这个问题的性质：这是一个误操作事件，是开发人员工作失误导致的问题，与我们本次需求更改无任何关联关系 (这点待楼主确定，我只是说个场景)
然后，我认为此类问题无法拦截、也不该由测试去负责擦屁股，至少职责上是的。（）

楼上的回归测试方法是大部分人在面对此类结果 (非源头) 时的第一反应，可是我认为回归测试不该是如此的。中小系统或者具备自动化回归的情况下，我们可以这么去做，那大型产品呢？较频繁的版本迭代呢？难道我们每次都要 all in 吗？
回归测试核心是针对需求变更对其需求流程、需求关联功能、流程周边功能，这个范围已经足以达标性的保证本次需求的质量管控范围，如果本次存在范围外的需求外变更，我认为测试是不需要为其进行额外负担的。

当然我们测试人都是很有责任感的，所以也就有了本帖的存在，也就有了同行们对解决所有问题的热忱，但是如果真的线上出现了此类原因导致的问题，我同样不想各位因此背锅因此自疑。注：楼主的举例问题是否可以监控到 excel 的变更情况，有的化可以在转测时对照需求比对下表格的改动是否有出入，没有监控的化那。。

看着像是配置数据, 那么都可以通过文件对比来检查改动
excel 可以直接对比, 其他文件可以用 beyond compare 等软件对比

这种问题我们一般会在上线评审时看出来，上线评审会对比本次上线和之前的变更内容，包括且不限于所有的配置、文件、包等，以避免这种误修改。

经常能避免什么全局替换，复制粘贴少了个符号之类的问题，挺有效的。（前提是大家都认真对待）

@Henry @ 今晚打老虎 excel 直接对比会是一个方法，但估计需要流程定义，如增加检查此 Excel 表的 checklist 确认，因为靠人经常忘。
@Ouroboros 上线前评审也是一种好方法，但有个问题，如果评审的文件是二进制，有变化时变了什么不好判断。

你要是有代码权限，研发的每次 push，你都可以看一下。嫌累，那就写个脚本每天自动拉代码，记录下这个 excel 的文件信息，判定是否修改，改了钉钉群发个警告，完事。

@Lambda 这个方法应可以，要以改进为只要 excel 有变化，则自动推送变化的内容。相当于自动监测，也是
@ 今晚打老虎 提到的监测方法。