以下幾個方面嚴重影響著自動化測試的效率，如果處理不當，將會造成事倍功半甚至前功盡棄的后果，自動化測試也成了一副空架子。
一是測試的范圍：想要百分百的實現自動化測試是不現實的，而且從時間投入上也是不可行的；有選擇性的挑選應用程序的一些功能或區域模塊，采用自動化測試。
二是測試時間的準備工作：自動化測試腳本的開發時間必須考慮在內，一般來說，開發測試腳本的時間要比手工測試多出三分之二，因為現實里工具會在初始階段增加測試的范圍；因此，對自動化測試保持適度的期望值很重要：工具不能取代手工測試，更不能代替測試工程師。測試初始階段，投入會比較大，當自動化完成后，將會大大縮短后續的版本的測試時間。
三是投資的回報：自動化測試的準備工作如此漫長，據說自動化測試的效益只會出現在測試被執行三次以后的時間里。
四是何時獲得自動化測試的收益：定位合適的測試目標，并認真分析自動化測試的收益出現在何時、何處。如果測試程序頻繁進行大幅度變更或修改，還是放棄自動化測試吧�。銓馁M相當的時間去修改測試腳本，但收益是微乎其微的。（但是，如果應用程序頻繁變更的模塊彼此獨立，或者修改較小，或者只是特定區域的變更，那么仍然可以成功采用自動化測試。）另外，謹記只有當應用程序將近發布時，才可以進行完整的自動化測試；如果應用程序缺陷太多，功能點運行失敗，想要運行全面的測試套件程序是不太可能的。
五是變更的程度：自動化測試最適合用于回歸測試，將那些已經存在并相對完善的功能進行自動化測試；例如應用程序1.0版本的功能模塊已經穩定，沒有引入1.1版本的新功能，這種情況下，我們對其制訂自動化測試計劃并設計測試腳本，不至于因為簡單的GUI變更（例如某個控件改名或移動）而使腳本無效。我們也需要將修改腳本的時間考慮在內，例如，如果應用程序的版本升級造成很大的功能改變，那么也許要全部重新書寫測試腳本，這種情況是我們不愿意看到的。但是，如果只是某個相對獨立的功能模塊發生變更，或者變更較小，我們可以成功的實現在回歸測試里的自動化。
六是測試的完整性：我們如何度量一個測試是否通過或失敗呢？單單憑借工具返回的“pass”不足以證明測試本身通過無誤，例如，沒有錯誤的提示信息出現并不意味著腳本的下一步動作能夠成功進行。因此這一要點需要在規劃測試腳本的通過與否標準上考慮在內。
七是測試的獨立性：軟件測試的獨立性應該被考慮在內，從而不至于某一個測試用例的運行失敗引起全局影響，甚至阻止整個測試套件程序里其他腳本的運行；但是，在實踐中對該問題的把握并不容易，需要一定的努力達到此目標。
八是對測試腳本本身的調試和測試：必須花費一定的時間進行該工作，以檢驗測試本身的完整性。
九是錄制/回放：不要完全把工具的錄制/回放功能作為創建測試腳本的唯一方法，這個觀念是很重要的。測試者在后臺運行測試工具，再手工執行測試，工具將測試者的動作記錄下來，自動生成一個腳本，以便測試者可以重新運行測試動作，這雖然是個好想法，但對測試工作本身并無太大意義。
十是對測試腳本的維護：最后一點，對自動化測試腳本的維護是一個高投入的工作，腳本必須持續的更新，否則一旦應用程序有太多的變更而要修改測試腳本時，你會因為一下子需要上百個小時而考慮是否值得這樣做，從而最終放棄自動化測試。因此，測試腳本每次更新時，對其進行文檔化管理是必要的
延伸閱讀
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/