我們都知道自動化測試是一種不錯的回歸測試的解決方案，我們一直想在自己負責的被測試產品/模組中引入自動化測試，但是，是不是應該大張旗鼓的在產品測試過程中引入自動化？
要知道回歸測試是有其專用目的的，主要是為了驗證原來好用的功能現在仍繼續好用，發現原來好用但現在不好用的功能。
要知道自動化測試指令碼的完全建立不是一蹴而就的，錄製了初始的指令碼之後，還要在被產品/模組發生變更後（並且在手工測試通過後）修繕或者補充指令碼。
要知道產品組或者專案組總是有進度和資源壓力的，不可能完全聽從測試團隊的意見和建議，測試團隊必須提出明確的證據，並能最終提供卓有成效的、令人信服的結果，這樣才能讓產品組負責人打消顧慮。
我認為我們需要做一些思考。
方案1：最直接的結果，就是在錄製完自動化指令碼後在第一次變更發布之前，通過回放指令碼，發現了眾多的嚴重程度比較高的缺陷，而且此類缺陷越多月好。研發管理者在對測試團隊提出表揚的同時，也會下更大的力氣在團隊中引入自動化測試。
還有，我們可以採集更多的資料，比方說用測試人員發現的缺陷和現場發現的缺陷之間的比例的走勢來論證自動化測試的必要性，但這需要現場團隊在反饋時，填寫發現問題的版本，就目前來看，這個任務是比較困難的。
總之，測試團隊（或者質量保證團隊）在目前的話語權仍然比較弱，我們所做的任何事情都要有證據，有實效。很辛苦，但很有意思。
關於自動化測試的一些思考。
我們都知道自動化測試是一種不錯的回歸測試的解決方案，我們一直想在自己負責的被測試產品 模組中引入自動化測試，但是，是不是應該大張旗鼓的在產品測試過程中引入自動化？要知道回歸測試是有其專用目的的，主要是為了驗證原來好用的功能現在仍繼續好用，發現原來好用但現在不好用的功能。要知道自動化測試指令碼的完全建...
關於自動化測試的一些思考（一）
時至今日，進專案組已經半年了，對自動化測試也有了更深刻的認識和理解。為什麼要進行自動化測試？要回答這個問題，先了解一下測試背景。我們專案所使用的軟體開發模型是agile，agile開發的scrum模型，整個大專案分成乙個個小team，每個team都有乙個scrum master。scrum mast...
關於自動化測試的一些思考（二）
之前有比較籠統的寫過關於自動化的一些思考 一 那時候剛做自動化不久，對很多問題的認識和感受不夠深刻，就現在而言，我依然是自動化測試的一枚新兵蛋子，還有很多的知識需要了解。回顧一下當時只是弄清楚了乙個問題 why，為什麼要進行自動化測試，自動化主要還是用於regression，對於測試new feat...