序言：在部門做自動化有好一段時間了，經歷了自動化從無到有，然后到框架，到現在的平臺，以及持續集成，回顧發現由于自己之前經驗太淺，走過的彎路太多，現在也還在謹慎的前進著，上次又回顧了一遍”軟件測試經驗和教訓”里的自動化測試章節，發現早前很多懵懂的經驗，現在稍稍清晰，于是想著結合自己的歷程精簡出一些經驗吧。現在經驗還是尚淺，如果有更深認識的朋友，互相討論，謝謝
一、所謂自動化是為了軟件發布服務的，并不只是為了測試服務
來源：自動化測試目標建設
以前一直懷疑自動化測試的用處，我們之前花費大力氣開發了大量的基于關鍵字方式的腳本，用來提高測試的覆蓋率，每次測試耗費大量時間，但是發現的問題少之又少，雖然說，自動化測試不是用來發現問題的，是用來驗證軟件沒有問題，但是有一個矛盾在于我如果不做自動化測試，問題還是那么少，那么做自動化測試我們難道只是為了追求一個心理感受嗎？這個概率問題怎么平衡
后來，這個經驗是在與開發一起合作冒煙測試建設，到現在的持續集成建設，開始明白，自動化測試的好處是為了增強開發的靈活性和保證軟件開發流程的有序性
1）快速檢測新版本的不穩定變更，即冒煙測試，能夠快速驗證當前build版本是否可以繼續下一步或者提測，此處冒煙測試可以是單元測試、集成測試和基本功能覆蓋測試，常用的框架和工具：Junit、TestNG和接口測試框架（soapui、httpClient等）、界面測試框架用于基本的界面測試（QTP、RFT、selenium）。
2）盡可能的暴露回歸程序的錯誤，即例行回歸測試，測試部門在開發提測后，基于開發的測試單，手工重點測試變更內容，利用自動化有選擇性的覆蓋其他功能。此處更多的是到了系統測試層面。
3）驗收測試，在發布前應用自動化的各種手段進行一次基本功能驗收測試，通過率在多少以上才可以提交發布，而且此處環節還可以加入非功能測試。
所以說，我們做自動化測試的目標一切都是為了軟件發布服務，也可以理解為部署軟件生產流水線，在這里，推薦一本書，《持續交付-發布可靠軟件的系統方法》
二、不要事后去計算人工替代率，而是要參考自動化測試有效性
來源：自動化測試度量和ROI分析
之前在年底做自動化測試度量的時候，要求每個產品線將自動化測試執行次數和時間進行統計，這樣做的目的是為了統計自動化測試執行時間，然后要求測試人員算出每個模塊的人工耗時，然后進行換算，得到自動化替換人工的時間，后來算完后，發現這樣的數據其實是沒有意義的
1）測試的本質是不可以比較的，一次手工測試執行有可能比自動化測試執行也許是更有意義的。
2）大多數的人工耗時都是拍拍腦袋想出來的
3）運行只是表明自動化測試被執行，但不能證明這次執行是有效的，只有真正本來需要手工的測試被自動化執行時才有意義。
所以，在度量上，一定要保持維度一致，可以橫向比對，即不同模塊之間進行比對，有效性上可以從自動化測試模塊的應用場景和執行次數、執行頻率去評估，成本上，即是自動化測試開發和維護成本
三、度量一個自動化測試的可實施性可以從其可控制性或者可測試性上來考慮
來源：自動化測試可測性分析
有的人說單元做自動化比較好，有人說接口測試做自動化比較好，但奇怪的是也有人說他們做界面自動化比較成功，其實說接口測試和單元測試比較好的人，單元測試往往是開發來定義的，所以開發來控制可測性，接口測試的話，接口協議都是約定好的，所以可控制性和可測性有保證，而界面的話，有些產品的界面可測性控制比較好，例如都有唯一的debug id，或者界面變動性很小，那么也是考慮可以用界面自動化的。所以說，我們在推廣自動化測試過程中，不是人云亦云，而是要結合當時的環境，從可測性上去考慮自動化測試的開展。
四、試點推進自動化測試
來源：自動化測試推廣
自動化思路重要，但是做自動化本身也是具有一定機遇性的，其環境相關性很大，所以在開展自動化測試前，一定不要過度自信，鋪天蓋地的推廣，而是要找好試點項目。之前做過一個接口錄制工具給測試人員推廣使用，由于不是試點分析，每個組的測試人員拿著這個工具開發了一堆一堆的線性腳本，導致存積了大量的接口線性腳本，然后后來由于腳本的維護性和不穩定，慢慢的流于形式，甚是可惜。如果采用試點分析的方式，先在小范圍進行使用，并且跟蹤效果。
業內有一個分層測試的理念很好，可以基于IP和地域選擇性的發布新產品，根據使用效果，然后再根據情況逐步推向全國。
五、自動化測試框架的重要作用之一是為了職責分層
來源：自動化測試推廣和框架建設
所謂軟件框架功能，我覺得很重要的一點是能夠將每一層次的責任細分出來，數據驅動框架就是將數據單獨抽離，讓測試人員能更有效的管理數據，例如：可以構造重復的、組合的、隨機的或者大量的數據包；關鍵字測試框架就是將對象封裝、任務封裝、業務組裝分層，這樣，可以讓代碼能力稍強的人員面對對象和任務封裝，讓業務能力稍強的測試人員面對業務組裝，這樣可以通過框架將各個人員的職責細分，做自己所擅長的事。
關鍵字框架推薦robot framework，利用其可視化界面ride，其中還有一些拓展包，例如selenium2Lib可以應用在web測試。
六、可以的話，讓開發一起參與自動化測試
來源：自動化測試可測性分析
曾幾何時，我基于RFT和QTP都試點推行了公司的界面自動化，但是效果不佳，究其原因還是界面的變化太大，加上一些自定義控件或者一些自定義圖片展示的動態搜索無法查找，只能用存儲對象的方式，后來大力發展接口自動化，將界面自動化先擱置了一段時間，后來開發自己做了一部分自動化，說是效果甚佳，去學習才發現，他們有一些圖形和事件是基于xml配置定義文件描述的，這樣利用JDOM技術，解析出文件，然后根據QTP的腳本編寫規范，生成QTP腳本，而測試動作基本上涵蓋增刪改查。這種情況是我們測試之前無法知道的，因為開發流程原因，我們無法知道開發所采用的開發技術，所以說，我覺得可以和開發一起來評估自動化測試。
七、自動化測試是可以成為一種習慣的，盡早自動化
來源：自動化測試推廣
之前，和幾位華為的開發朋友聊天，問他們一個問題：你們自動化怎么樣，我原來以為開發是不太了解自動化的，沒想到他們給我的答案是，什么怎么樣，這是必須做的工作呀。原來他們華為的持續集成過程，開發自己寫測試腳本做冒煙測試，以前這是華為的規定，現在是他們開發人員的一種習慣。
所以，我覺得，推廣自動化不一定一開始就要大張旗鼓的，也不是所謂的等到一切時機成熟，自動化測試是一種輔助測試的方法，不同的情況可以采用不同的方式，幾行腳本，一個bat部署文件，一個數據統計，也是自動化的一種應用。用另外一種說法：不管黑貓、白貓，能抓到耗子的就是好貓。
八、自動化應該立即見效，見效后應該慎重評估
來源：自動化測試推廣
有時候如果我們對目的不夠清晰，不能抓好本質問題解決，就很容易走極端，有人說錄制不好，我們就反對錄制，有時候我們抓到一個錄制工具就以為遇到了神器，孰知后面是一個一個的大坑；而我覺得，錄制不是不好，而是如何將它用在合適的地方，錄制的好處是無需編程技能即可快速上，但是他的缺點是相對脆弱，一旦UI或者接口變化測試就會受到影響，分散的腳本不可重用且難以維護，而且系統在測試前必須可用（也就意味著無法使用A-TDD方法）。因此這種方法并不適合大型自動化測試。而關鍵字驅動，將數據與關鍵字結合來描述如何使用數據執行測試，這種方法是具備數據驅動的優勢，同時非編程人員也能建立新類型測試。所有測試由同一個框架來執行，無需不同的驅動腳本。然而初始成本很大，但是可以使用開源方案，因此非常適合大型項目。所以，我們剛開始的時候，選擇合適的項目，可以采用腳本錄制這種方式，讓自動化測試立即見效，小范圍推動項目進度，然后，就嚴格控制，開始設計框架，把握可測性。
九、不要指望用自動化測試平臺一下子解決所有的問題
來源：自動化測試平臺建設
當年在作自動化測試過程中，遇到瓶頸，就想當然的認為要開發業內所說的自動化測試平臺，即先弄出一個線，然后再想辦法去線上發展每個點，后來歷時幾個月，加班加點的，總算基于STAF開發出了一套分布式的自動化測試平臺，但是后來用著用著就不了了之了，分析出原因是問題本身和目的都沒有明確，單純的開發出了一個架子，然后再去找衣服強塞進去是不可行的，架子本身是為放衣服服務的，所以平臺本身是為讓自動化更有序的進行而服務的，之后我們大力發展點，而平臺是等點都滿足需求后，開始將點串起來，自然而然的形成了一條線，然后再加以修飾，就成為了平臺。所以說，不要舍本求末，追求花哨，而要踏踏實實的做好每一個點，以需求為導向，自然而然的才能把架子搭好。
在這里也推薦幾個用來搭建平臺的較好的工具和框架：STAF， Jenkins，selenium grid可以用來做分布式測試執行和測試節點管理，sonar可以用來做質量管理平臺，更多的是面向白盒測試分析。Toast也是一款不錯的自動化測試平臺，我覺得它的理念更多的像項目管理+jenkins。
十、將所有的測試資源都版本控制起來
來源：自動化測試配置管理
這個很重要，在我們的自動化建設過程中，因為我們是多產品線的，每個產品線的有些功能模塊是共用的，我們的方法是將每個模塊的功能抽象成關鍵字接口，所有產品線共用接口，只是實現上不一樣，而這種方式前期的問題是版本管理的問題，因為一個產品線開發出一個模塊后，各個產品線開始互相遷移，導致遷移混亂，還有一個問題是產品功能模塊也在不斷的更新，不同的產品版本要對應不同的測試腳本，所以后來，加入版本管理，而最終的測試腳本版本用V1.0.0進行跟蹤，第一位表示接口版本、第二位表示產品特性，第三位表示當前產品線的腳本維護。
版本控制中重要的兩個概念就是分支與合并，隨著開發的版本控制的不斷深入，測試的版本管理也需要跟上，常用的版本控制工具是svn、cvs以及分布式版本控制git，和基于流的版本控制系統Clearcase，個人覺得，前期可以用手工的方式定義好版本，等到開發協作強大到一定程度后，可以采用這些版本控制系統。
十一、時刻反省自動化測試過程
來源：自動化測試推廣
自動化測試是一個長期的過程，我們即要低頭走路，也要不時抬頭看路，也需要不時的休息一下，回顧自己走過的路程，整理之后才可繼續向前，所以需要我們每隔一個階段，就要好好反省自動化測試的開展和推廣過程，大家的時間都是很寶貴的，珍惜自己的時間，更要珍惜大家的時間。
總結；因為時間倉促和水平有限，有些經驗和教訓不一定很全面，或者還有朋友在推廣或者平時觀察到有更好的自動化測試實踐經驗和教訓，希望可以一起總結，總之，個人覺得，學習過程最有效的方式是理論和實踐相結合，知行合一，在實踐中發現問題，然后去推敲理論，解決問題，最終總結從而變成自己的東西。
版權聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641