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