近段時間，一部分工作在進行自動化測試開發，一部分工作在于資源整合，一部分工作在自動化測試推廣，而感觸最深的就是推廣了，自動化測試難點一在于應用，難點二則在于應用推廣，再好的技術底蘊，再好的形式，沒有一個好的推廣過程，則也是不行的，根據這段時間和過去的一些教訓，在此總結一下，希望不對的大家能指出。
一、現象分析
做過自動化測試推廣的人員應該都會遇到這么幾個現象：剛開始推廣自動化測試時，測試人員都很好奇，都會積極的參與配合，但是測試人員的熱情在一段時間之后會被自動化測試人員的不斷變動性所打敗，所以，作為一個測試人員，你應該把測試人員的信任值和熱情度牢牢把握。
1、自動化測試人員總是不斷的更新框架，從而導致測試腳本不斷變更，造成測試人員不斷去定位測試腳本和維護測試腳本，造成測試人員對自動化測試信任度降低。
2、測試腳本在還未規模化應用的時候，則去強行的開發大型的測試平臺，這樣帶來的問題就是后期的變動性造成了平臺架構的變動，從而導致測試腳本和測試平臺的兼容性差。
3、測試開發人員犯的一個很大的錯誤就是不斷推出一系列不成熟的工具，即只想著去開發一個工具，而把測試人員還是當成了“測試人員”，而不是用戶，從而造成了測試人員對測試工具的使用的畏懼性。
4、不夠雙贏；很多時候，測試人員做的工作往往被忽略，例如：測試開發人員開發的腳本數量是一個績效，造成對開發出的腳本質量往往不負責任，但是測試人員對別人開發的腳本和環境的維護則沒法進行量化統計，這樣測試人員還不如手工測試來的績效高，這樣，則造成了測試人員對自動化測試的積極性不高。
二、對現象的思考和實踐分析
1、腳本的穩定性應該是放在第一位的，不管剛開始的設計和想法多么宏大，你也必須克制自己，不管線性腳本，不管封裝也好，從最基礎開始，讓測試人員首先感覺到腳本的運行順暢性，而不是頻繁的維護。這也是一個前期自動化測試的一個先鋒部對，不求一下攻克，只求快速獲得情報和前線支持，為后面的大軍進發做準備。
2、決定開發了一個框架的話，那么就要先考慮到可拓展架構，或者快速做一個原型，采取功能迭代增加的方式，一定記住的時，能抽像到底層的一定要抽象，千萬不要把特性的東西寫死在底層，而是要分離。不然你會發現：前期寫死一個變量，也許會讓你在后期的某一個拓展中造成你的所有腳本癱瘓。
3、測試平臺、持續集成平臺之類的都是架子，個人覺得，要保證的是：測試平臺和測試腳本是分開的，即測試腳本可以脫離平臺單獨執行，而不是腳本需要依賴于平臺執行，因為有時候移植工作其實是一個很大的工作量，你不能保證你的平臺永遠沒有變化，平臺好變，大量的腳本不好變。
4、預期開發一堆的全面化的復雜的測試工具，還不如在一個點上把一個工具做精了，讓測試人員真正覺得好用，那么你的自動化測試才能慢慢被他們接受，從而配合你的工作。其實這種策略很常見：很多平臺化的公司做大前都是從一個點開始，把一個點做精了，這樣就可以以此為入口，從而建立起一個產品體系。少做即是多做，這真是真理啊。
5、分享一個我推廣自動化測試的例子：在部門內部，以一個自動化測試活動為一個項目，測試人員做為項目負責人，我則可以作為項目協助人參與。例如：一個關鍵字測試驅動用例項目，測試人員來設計測試驅動設計文檔，包括劃分的關鍵字點、環境、參數等。由另外的手工測試執行人員來測試執行過程中，組裝關鍵字，最終形成測試腳本用例。關鍵字、文檔以及腳本便作為整個項目的輸出，以項目為活動顆粒的好處是職責容易細分，進度容易把握，并且最重要的是能夠讓測試人員主動性更強。所以，在推廣過程中，要采用各種策略讓測試人員的能力提升和職業發展相結合，讓他們的成果突出，這樣你給他負責，他才對你負責。
總結：其實推廣過程中，最大的經驗就是一定要站在不同的角度上思考問題；學會以輔助的角度去做人做事；學會珍惜別人的時間和勞動成果，學會將別人的成果最大化，學會雙贏；有時候學會自己寧愿多做點，不要告訴比人；也許，這樣，你得到的將是你意想不到的。