要知道迴歸測試是有其專用目的的，主要是為了驗證原來好用的功能現在仍繼續好用，發現原來好用但現在不好用的功能。
要知道自動化測試指令碼的完全建立不是一蹴而就的，錄製了初始的指令碼之後，還要在被產品/模組發生變更後（並且在手工測試通過後）修繕或者補充指令碼。
要知道產品組或者專案組總是有進度和資源壓力的，不可能完全聽從測試團隊的意見和建議，測試團隊必須提出明確的證據，並能最終提供卓有成效的、令人信服的結果，這樣才能讓產品組負責人打消顧慮。

我認為我們需要做一些思考。
方案1：最直接的結果，就是在錄製完自動化指令碼後在第一次變更釋出之前，通過回放指令碼，發現了眾多的嚴重程度比較高的缺陷，而且此類缺陷越多月好。研發管理者在對測試團隊提出表揚的同時，也會下更大的力氣在團隊中引入自動化測試。

如果對方案1沒有絕對的信心，那麼我們應該縮小範圍，在哪個模組中先引入自動化？以前的想法是，選擇最核心的業務模組，這樣的做法不無道理，核心業務萬一發生了問題，其影響會很大。但是選擇核心業務模組建立自動化的前提是，大家對自動化測試的重要性和必要性已經能夠理解和接受了。因為所有人對核心業務模組都會格外的盡心，開發人員的開發除錯會不由自主的增加，測試人員的測試頻度和測試設計也會盡可能的傾斜，在這種情況下（特別是運行了很長時間的核心業務模組發生了變更後）在釋出之前仍然有問題的可能性相對較少。 試想一下，如果一個核心的業務模型，在變更後執行指令碼，卻始終不能發現幾個嚴重程度高的bug，專案負責人肯定會說：幹嗎還要那麼辛苦的去維護指令碼？反正產品那麼完善了，反正不能發現幾個bug，更新指令碼的任務先暫停吧。。。
反之，我們需要研究的是哪個業務模組在釋出後發現的bug是比較多的，並且調研哪些bug是由於沒有進行迴歸測試而導致的。針對這樣的資料建立其來的自動化測試，執行結果必然會引發更多人的關注。在這種基礎上，再向其他模組推廣，那麼效果自然比盲目的去引入要好得多。

還有，我們可以採集更多的資料，比方說用測試人員發現的缺陷和現場發現的缺陷之間的比例的走勢來論證自動化測試的必要性，但這需要現場團隊在反饋時，填寫發現問題的版本，就目前來看，這個任務是比較困難的。

總之，測試團隊（或者質量保證團隊）在目前的話語權仍然比較弱，我們所做的任何事情都要有證據，有實效。很辛苦，但很有意思。