要知道回归测试是有其专用目的的，主要是为了验证原来好用的功能现在仍继续好用，发现原来好用但现在不好用的功能。
要知道自动化测试脚本的完全建立不是一蹴而就的，录制了初始的脚本之后，还要在被产品/模块发生变更后（并且在手工测试通过后）修缮或者补充脚本。
要知道产品组或者项目组总是有进度和资源压力的，不可能完全听从测试团队的意见和建议，测试团队必须提出明确的证据，并能最终提供卓有成效的、令人信服的结果，这样才能让产品组负责人打消顾虑。

我认为我们需要做一些思考。
方案1：最直接的结果，就是在录制完自动化脚本后在第一次变更发布之前，通过回放脚本，发现了众多的严重程度比较高的缺陷，而且此类缺陷越多月好。研发管理者在对测试团队提出表扬的同时，也会下更大的力气在团队中引入自动化测试。

如果对方案1没有绝对的信心，那么我们应该缩小范围，在哪个模块中先引入自动化？以前的想法是，选择最核心的业务模块，这样的做法不无道理，核心业务万一发生了问题，其影响会很大。但是选择核心业务模块建立自动化的前提是，大家对自动化测试的重要性和必要性已经能够理解和接受了。因为所有人对核心业务模块都会格外的尽心，开发人员的开发调试会不由自主的增加，测试人员的测试频度和测试设计也会尽可能的倾斜，在这种情况下（特别是运行了很长时间的核心业务模块发生了变更后）在发布之前仍然有问题的可能性相对较少。 试想一下，如果一个核心的业务模型，在变更后运行脚本，却始终不能发现几个严重程度高的bug，项目负责人肯定会说：干吗还要那么辛苦的去维护脚本？反正产品那么完善了，反正不能发现几个bug，更新脚本的任务先暂停吧。。。
反之，我们需要研究的是哪个业务模块在发布后发现的bug是比较多的，并且调研哪些bug是由于没有进行回归测试而导致的。针对这样的数据建立其来的自动化测试，运行结果必然会引发更多人的关注。在这种基础上，再向其他模块推广，那么效果自然比盲目的去引入要好得多。

还有，我们可以采集更多的数据，比方说用测试人员发现的缺陷和现场发现的缺陷之间的比例的走势来论证自动化测试的必要性，但这需要现场团队在反馈时，填写发现问题的版本，就目前来看，这个任务是比较困难的。

总之，测试团队（或者质量保证团队）在目前的话语权仍然比较弱，我们所做的任何事情都要有证据，有实效。很辛苦，但很有意思。