首先在我看來，自動化是必定會提升工作效率的。之前其實我也認為自動化是沒有用的，現在想想，只是無知限制了我的思路

總結下我經常遇到的場景吧~

1.重復工作較多

.之前和同事工作中扯淡，他在做一個功能測試，但是僅僅是因為加了一個功能點卻要回歸下之前不少測試用例，回歸可能還好說，但是測試流程比較復雜，然後就聊到了自動化實現，這樣重復工作很多，我和他聊到和自動化可以實現，作為業務測試的他對自動化可能不是很清楚，他說不是很清楚是否能實現。其實我想表達的是團隊的磨合，如果真的日常工作重復工作很多，我覺得有必要和測試負責人聊下，看是否能解決，這是單方面，測試經理也應該經常和組員聊下日常工作遇到的問題，答疑解惑。若這樣的重復工作太多，沒人去解決問題。需求經常延期，我覺得因為這個原因加班並非需求多，而是因為管理層能力不足而加班的。

2.錄制性自動化繁瑣

通過錄制做自動化其實我是接觸不多的，在我剛幹測試時團隊就是直接寫腳本實現關鍵字驅動,這樣只要按照測試模板填寫關鍵字即可的，今年碰到了現有公司用的是selenium自帶的錄制工作，但是看了他們的實現方式，得先錄制再概改腳本這樣實現，不是很靈活，如果用腳本封裝selenium庫只要填參數，對比下，方便很多又省事了一些，所以這點我覺得是公司在這個領域還是稍有寫薄落，導致功能測試人員寫自動化用例繁瑣了一些，那麽怎麽還能讓功能測試依賴這套東西提高效率呢？

3.管理層不註重自動化

這個點其實沒什麽好說的，靠的是測試負責人的個人魅力和說服力，以及能夠利用自動化提高效率，這樣有產出，管理層正常對高效率和質量保證還是比較看重的，如果拿出產出，管理層還是不支持，那麽對技術有所追求的我覺得在該公司個人能力到達瓶頸後，有必要重新找個管理方面還算可以的公司。

扯了不少，現在我以我的認知設計了自動化怎麽嵌入到測試流程提高效率吧~~

1.自動化屬於測試策略的一種，是否要開展自動化決定於公司是否存在自動化需求，比如：

這樣，業務上存在了自動化的需求了，測試開發人員直接寫腳本嗎？？？還不至於，腳本是給所有業務測試包括自己使用的，應該更讓別人知道怎麽實現或者邏輯怎麽竄通的，這個需要和當時人(業務測試人員)討論的，例如：

1.框架選擇，首先目前還是開源框架用的比較多，單元測試框架: python的unittest\pytest或者java的juint\testng GUI開源工具 robot都可以根據現有團隊的認知選擇

2.用例模板設計，目前我的實現還是通過excel去實現關鍵字驅動的，這個可以和業務測試人員定義一下關鍵字命名和傳參

3.收集場景關鍵字，如果腳本開發的測試只在測試某個系統，但是公司業務系統較多，這樣業務測試可以和說下負責的系統有什麽特殊的控件（其實就是，點擊，輸入，js彈窗，懸浮。iframe的切換，下拉框，時間控件不可輸入等）以及每個系統用的什麽數據庫mysql,oracle.mongodb這樣腳本開發人員可以提前寫好這些方法，這樣就減少了後期遇到再修改腳本的可能性，

4.定義建議至少兩位腳本開發的人員，這樣至少在遇到問題可以討論以及在前期解決業務測試人員不可避免遇到的一些問題，這樣業務測試會明確出了問題可以找誰

基本腳本設計需求已經定義好了，這樣腳本可以開發了

當腳本寫完後，需要定義自動化如何潛入到測試流程，提高效率

1.首先自動化用例的編寫必然會占用工作，排期必須要讓出時間，前期會占時間比較多，其實前期工作量只是在補現有功能之前一直沒有做的東西，往後自動化用例會少了很多，占排期也會越來越少

2.依賴自動化成為工作的一部分，例如這周一到周四測的功能，把一輪測試完的功能自動化用例寫起來，一輪測完，開發必然會改bug再發個版本，無bug也沒關系，不影響流程，這時候，執行寫好的自動化測試用例回歸二輪，二輪無bug，待發生產即可，既然說了把自動化當作工作的一部分，那麽過程必然磕磕絆絆會有些問題，自己定義一個解決問題的時間，10分子或5分鐘未解決，找腳本開發人員解決，這一個過程其實就是不停的提升腳本的健壯性，時間越長，健壯性越強，這樣在後面的工作中，有了前期的鋪墊，後面有相應的功能就可以省了不少時間

3.還有個問題是前端元素會經常改動，這個確實是個問題，先說下兩個解決方式吧，第一個是在編寫測試用例的時候，不同的用例前期必然會出現重復步驟的，這樣單獨寫個用例出來，讓主要的業務邏輯的用例繼承這個重復步驟的用例，這樣目的可以減少用例的修改數，還有一個是定期維護，在下次版本編寫用例時維護好報錯的用例，註意這個定義維護只放在下次用例編寫自動化用例的排期中，定義時間是因為這次版本是運行沒問題的，那麽投產後驗證也沒有問題，之後測試環境新增功能迫害了元素，不用管，雖然失敗但是流程不能亂，放在下次自動化用例編寫還有個原因是之前已經做了自動化鋪墊，那麽這次版本必然會少工作量，加上維護失敗的用例，這樣工作量飽和了，當然我覺得元素改動沒那麽誇張到大批量都死掉，這只能說明元素定位方式需要改進，不增加開發很多工作量的情況下或與開發配合

4. 還有一點，前期自最好不要讓加班寫自動化用例，這樣會給測試某種程度帶來負面情緒，前期還得給出排期，不給排期做自動化，我覺得測試很難把自動化當做工作的一部分，

自動化就像一個投資，雖然有風險但是收益是客觀的，當然是在理智的前提投資，自動化流程的設計就是一個理智的分析再投入實踐。

5.再插一點吧，有些公司測試是各幹各的情況，就是一個人負責某個系統，那麽功能和自動化都是這個人負責，自己的工作量自己想辦法解決還是不錯的，效果好，其他測試必然效仿，這種方式我覺得還是不錯的，但是現況普遍有崗位是穩定單幹某個系統的吧 所以還是得全局考慮...

不知不覺扯到現在，算是接觸了一年自動化的一些感受吧

論自動化如何提高測試工作效率