已經開始實踐過一些selinum的自動測試，發現要維護好一個簡單的case消耗的精力遠遠大於獲得的回報。但是這個值得（技術能力）深入學，工具無好壞優劣之分，只有適合不適合。在網上看了很多關於自動化測試的文章，現摘錄一二：
以下內容引自：2014年自動化的個人感想
自動化技術的應用場所
1、功能回歸測試、冒煙測試。
2、數據精度要求高的測試，數據計算、比較、統計測試。
3、簡單重復的大批量測試，測試組合眾多，需要測試覆蓋。
4、疲勞測試。
5、接口、底層、代碼測試。
6、其他不便於進行手工的測試。
PPT解讀： 自動化測試 是個較大的范疇，所有不用手工進行操作通過程序驅動的測試都可以理解為自動化測試。從技術層面來講，但凡被技術實現的東西都可以被技術模擬和測試。在人們實踐的過程中，自動化技術應用的領域會越來越廣，測試也是一樣，自動化本身不會去約束方式和行為，自動化能夠做什么會超出我們的想象。
為什么需要測試框架
1、降低實現門檻。
2、統一技術風格。
3、量化測試成果。
4、底層前端分離。
PPT解讀： 沒有測試框架也可以實現自動化。每個測試人員技術背景不盡相同，擅長的語言、腳本、實施的技術水平參差不齊，沒有框架約束技術實現和風格，他人的維護難度會很大，不利於大家朝同一個技術方向進行分享和交流。 框架本身已經封裝了很多實際需要的接口和工具，測試人員不需要花費大量的精力再度開發，集中精力快速實現測試需求本身。統一的結構不僅多人可以同時維護一個項目，也便於測試結果的分析和匯總，眾多項目的批量運行。框架和項目的分離，使雙方各自影響的范圍得到有效控制，便於項目單點維護和遷移。開發需要框架，同樣測試開發作為一種開發活動也需要框架。
自動化效果體現
1、測試前置效果體現
2、測試范圍效果體現
3、Daily Test 和批量執行效果體現
4、其他指標
PPT解讀： 1、接口和單測可以通過BUG數量進行衡量。這個階段所發現的BUG含金量更高，修復的成本更低，更有價值。此外代碼行數、用例數量、代碼覆蓋率也可以很好的統計測試實際的效果。
2、自動化可以解決以往手工不能進行的測試，比如大數據量、中間件、隨機數據等測試，可以列舉由於引進自動化而增加的各種測試類型。
3、100個用例執行一次體現不了什么，但是100個用例在后續的兩個月里執行了100次，所替代的人工就是很可觀的。自動化項目堅持每日BUILD，一方面可以及時發現問題，維護更新用例。另一個方面每日測試的匯總數據也是自動化測試效果的展示。可以通過郵件、報告進行測試項目和用例的數據匯總，如果達到一定的量級還是很震撼的。
4、自動化還有代碼行數，編譯次數等指標。放在部署有平均部署時間，放在數據有平均一次生成數據量等。前端自動化不宜用BUG數量來衡量，因為主要選取的相對比較穩定的業務線和模塊。
以下內容引自：QA請勿忘初心
大部分QA或者tester，仍然以UI自動化為重心。之所以反對盲目的UI自動化測試，因為變化頻繁的UI設計，極低投入產生比，都應該讓我們重新思考下UI自動化的價值。
我們需要一個實施UI自動化正確的方式：
能不用UI自動化測試就不用，梳理業務主線，只保留用戶操作最頻繁，交互最多的場景。
根據面向對象設計的原則，構建適合項目的UI自動化框架，無論自己編寫框架，還是采用開源框架。
盡量采用獨立測試數據，確保運行測試不受影響。例如采用mock數據庫或者每次運行時還原測試數據庫。
作為一個QA，我們不僅要檢測項目中存在問題，也要改進團隊的實踐活動，更重要的是預防問題的發生。
每次bugbash或相應迭代完成后，要分析統計，找出產生缺陷的環節，並采取措施防止問題再現。例如每次release或者bug bash之后,我可以按照功能模塊與bug類型進行統計划分，分析統計bug的成因，例如某次迭代我們bug數量激增，經調查，發現我們對某些模塊的前端代碼進行了重構，但缺乏相應的單元測試與集成測試，造成了我們沒有及時發現bug。之后我們就對應的采取措施防止問題再現。
總結分析報告，及時反饋這些信息給團隊。總結分析是一個長期的任務，每次bug數量的變動，都會直接體現整個團隊上次迭代的開發質量，例如bug數量減少了，可以鼓勵成員再接再厲。或者某幾次迭代某些模塊bug成上升趨勢，那么就需要組織團隊一起討論問題根源，采取措施防止問題重現。
利用代碼質量分析工具幫助我們盡早預防問題的發生。例如sonar代碼質量管理平台，可以幫助我們從代碼復雜度，重復代碼，單元測試覆蓋率，編碼規范等緯度來分析我們代碼所存在的問題。當然也有其他的開源工具，像RubyCritic，/plato不同的語言都會有相應的工具。
在線監控，利用像newrelic，airbnb等監控工具對部署在本地或在雲中的web應用程序進行監控、故障修復、診斷、線程分析以及容量計划。這樣就算們產品環境有任何問題，我們都會及時響應，盡早修復，減低損失。
以下內容摘自：自動化測試總結
4.合適引入自動化
項目周期長，系統版本不斷，並且需求不會頻繁變更，此時是適合引入自動化測試的。
系統的測試對象基本可以正常識別，以及對無法識別的控件能否提供一個解決方案。
系統中不存在大量的不可識別第三方控件。
需要反復測試，如可靠性測試、回歸測試等需要進行上千次的系統測試。
5.不適合自動化
項目周期短，需求頻繁變更。即使是周期長的項目，如果經常需求變更，也不適合做自動化。
軟件版本還沒有穩定的情況下，主功能或大量功能有被重新更改的可能話，也不適合做自動化。
沒有明確的項目測試自動化計划，措施和管理。
多數對象無法識別，以及腳本維護頻繁與艱難，二者有其一，自動化必定失敗。
基於以上前人走過的路，目前我們單位自動化的需求（也可以說是我自己的，空余時間研究）包括：
1、當前生產發版的發版節奏由最初的一周一次變為20-30天一次，產品功能趨於穩定，測試人員2個，上線前回歸壓力大。如果可以自動回歸測試，將解放不少生產力，當然自己的技術能力也能進階。
2、自動化測試作為回歸的正向驗證切入運用場景，即自動化的驗證功能是對的。
3、后台涉及用戶使用頻率最高的兩個功能模塊：商品管理和營銷工具。