曾經做過很長一段時間的自動化測試‘積累了一些相關的東西。感覺自動化測試現在也是處于一個變化的階段，有很多東西只有問題，但是沒有答案。
1. 業務邏輯
在現在的應用中，復雜的業務邏輯會帶來大量的代碼量，同時如果業務邏輯進行改變，自動化測試的代碼修改也會成為項目的泥潭。對應的業務邏輯最好可以盡量分離出來，同時自動化測試的用例，最好是和手工測試的用例有所不同，自動化測試由于加入了編程的成分，那其測試用例最好成為可重用的。
2. 對頁面UI元素的識別
在web頁面相關自動化測試中，這些問題可能遇到的比較小，但是如果是測試應用程序的話，元素識別就是一個很大的問題，這依賴于你選擇的工具，以及開發團隊的配合，如果連UI元素都不能識別的話，那自動化測試就是扯淡。
3. 如何保證自動化測試的腳本代碼是正確的?
這算是一個悖論?用來檢查的代碼，你如何保證其是正確的。當檢查出一個fail出來，首先不去懷疑是程序本身的問題，而是去懷疑這是自動化測試腳本的問題。而如果你使用的自動化測試平臺是第三方的自動化測試工具的話，甚至還會懷疑到工具本身的問題。這樣在本身工作之外，卻又多了其他的check任務。這算是自動化引入的最大問題。當然，這還是由于自動化測試需要引入的測試代碼的復雜性引起的，一般現在也自動進行的unit test，也會有這樣的問題，但是由于其問題規模較小，代碼邏輯比較簡單，所以將這個問題覆蓋過去了。同時unit test由開發人員本身進行編寫，也使得這個問題不容易出現。
4. 自動化測試的結果分析
從測試數據的準備，業務邏輯的整合，測試腳本的編寫，到最后生成結果文件。但是如何分析這個結果文件，也是很麻煩的事情，這個也是和測試用例的編寫人員有關，測試用例編寫得越詳細，在腳本實現的時候就可以根據測試用例的描述來生成對應的結果描述，這樣對于單個的測試用例，至少這個結果是可以讓結果分析人員滿意的。
5. 如何重現某種錯誤
這個在手工測試中會發生，但是在自動化測試中產生的概率比手工測試要高得多。當你把測試腳本寫完，想著，OK，之后就是每天晚上讓它自己run，然后check一下結果就可以了。錯!你的麻煩才剛剛開始。當你第二天過來，看到半夜的時候，產生了一個錯誤，我們現在只有這個錯誤的截圖，以及測試結果文件中告訴你我測試工具一共做了哪些工作造成這些錯誤。然后你又針對這個用例單獨跑一遍，結果為pass。那恭喜你中獎了。一個很難復現的bug。從現象判斷不出是怎么產生的，偶然但不是必然會發生。這個很頭疼。首先你要確定它是個bug，一般都會讓你先check是不是腳本或其他問題。
6. 保證自動化測試不被濫用
有很多場合是不合適使用自動化測試的，在這些場合去使用自動化測試，就是給自己找麻煩。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
