和各位親交流一下我對自動化測試的想法，歡迎各位專家拍磚。我認為，成功的自動化測試工程的成功公式為：
成功（100%）=高效的自動化測試框架平臺（30%）+合理科學的自動化測試用例設計策略及實現（35%）+持續運營維護（25%）+其他（10%）
高效的自動化測試框架平臺（30%）：
咱們測試部門現在的自動化測試框架的水平，在全國絕對處于非常領先的地位。全國的IT企業里面，擁有和我們類似框架的沒有幾家。我們現在已經越過了河 流，游到了對岸，而大多數還在摸著石頭嘗試過河。我們的改變也是最近幾個月的事情，之前雖對自動化工具有所研究，但純粹靠編程來實現自動化測試，不適合我 們公司（測試用例稍有修改，就需要重新編譯打包，沒人喜歡；我們的業務測試人員的編碼水平也不足以完成大量用例的編寫）。
雖對取得的成績自豪，但是咱們的工具還沒到冰封代碼的時刻，我們還有很多想法需要花時間和精力去實現，也需要更多的人力……新的正能量的加入，是個很好 的開始。我也寫好了半年開發計劃，期待半年后，一個更完整，遵循簡單、高效理念的框架為大家所喜愛。這個30%，測試工具開發部門可以拿到滿分的 120%！
合理科學的自動化測試用例設計策略及實現（35%）：
自動化測試用例設計策略是個很大的話題，需要我們在實踐中不斷總結：
需要自動化的比例？
–》自動化測試屬于功能測試的一部分，自動化測試帶來效率改變的同時，也需要花費很多精力去創建及維護測試腳本，需在投入和產出之間找到平衡。把Testlink上面所有的功能用例都自動化—即使這是未來的規劃方向—這也是不現實的。那些最穩定、功能最重要的功能模塊才需要自動化。
自動化什么樣的用例？
–》軟件測試用 例的設計有橫向與縱向之分，工程學上以較長為縱、較短為橫，縱向指的完整的業務流程用例設計，橫向設計即切面設計，把功能模塊從大向小細分。 Testlink上面的用例大都屬于后者，事無巨細都考慮的很清楚。對于自動化測試，因投入成本問題，選取縱向設計的用例比較科學合理。建議：重新設計合 理的自動化測試用例，而不是簡單盲目選用testlink上面已有用例。你，如何認為呢？
相信自動化測試用例數目嗎？
–》打開testlink，咱們的“NGB系統端”和“SmartTV系統”的用例數在8000左右啊！！！8000個用例全都自動化實在沒有必要，也沒可能。大部分用例也是只有標題，沒有內容。還不如80個覆蓋重要功能的完整業務流程的縱向測試用例實在啊！
……
持續運營維護（25%）：
自動化測試不是一次性筷子工程，而是需要我們不斷的運營維護，我們運營維護的時間越長，從中受益也越大。運行后及時分析結果，反饋bug給開發或者完善測試腳本。產品升級之后，也需要更新測試腳本的。
其他（10%）：
其他影響因素，如果其他90%都做得很好，自動化項目還是失敗了，都可以歸于此。當項目組想告別刀耕火種的方式時，建議以實施自動化測試作為績效考核之一。審核機制，建議同時關注自動化測試的產量和質量，不要只相信數字，不要相信國內的免檢產品。
其他的其他……