一、為什么很多公司都說要組建一個自動化測試團隊，但極少能建立起來？
● 太過于相信自動化測試，且沒有經過嚴格的自動化測試流程和前期分析設計就草率的進行腳本的開發，最終的結果一定是失敗！
● 國內的公司很少有專屬的自動化測試團隊，往往都是信心十足最后確又虎頭蛇尾！這其中也分兩種情況：其一，缺乏真正可以做自動化測試的技術人員，每個成員都是在學習階段，那還談什么組建自動化測試團隊？這最多也就叫興趣小組？其二，的確有牛人在團隊中，但是我們都知道，國內很少有公司會專門組建一個專職做自動化測試的團隊，國內現在大多數情況是手動測試和自動化測試并用，那么，自動化測試的優先級肯定沒有手工測試那么高，而且項目的任務又多，久而久之，自動化測試的愿景又被擱置于一旁了。
● 其實自動化測試已經做的不錯了，但是領導看不到短期內有任何的回報，最后還是擱置了！這其中一方面牽扯到成本問題，另一方面則是領導對自動化測試從意識上就存在誤區，沒有真正認清什么才是自動化測試的真諦！
二、全職QTP自動化測試工程師的工作內容是什么？問幾個心中一直以來的疑問和困惑：
（1）QTP是針對功能測試的，主要是自動化地去做測試，那么它強大的地方在哪兒呢？是它能夠發現大量潛在的問題？（似乎沒感覺到），還是說可以做到無限重復的執行？我們公司用QTP只是重復運行，用來采集性能數據，所以并不能體會到QTP這款產品“贏”在哪方面。
（2）一個全職的QTP測試人員，每天的工作內容是什么呢？每天修改完善腳本、增加邏輯覆蓋率？假如一個成熟的產品有成熟的腳本，那么測試人員只要點一下QTP運行按鈕，然后直接拿測試結果？總體來說，還是感覺QTP要求很多，用起來很難且收獲也不大。
● 首先回答第一個問題：從這位同行的提問中，推斷他對QTP的認識一定停留在錄制階段，他把QTP當成了按鍵精靈。QTP的強大體現在它是解決自動化測試的最好的工具。其實提問的這位同行對自動化測試概念一定很模糊，他以為自動化測試只是簡單地重復工作而沒有考慮過驗證這個問題。做測試，手工測試是怎么做的？其實說白了，也就是用我們的眼睛來驗證，那么QTP就是那個能代替人類眼睛驗證的測試工具。就像機器人一樣，它不是智能的，它的智能是由人賦予的，所以它能做的操作都是人類事先已經知道的。QTP贏在它的一切，賣的真么貴、市場份兒那么高不是沒有道理的，如果去使用其他測試工具一段時間后再回來使用QTP，相信一定會感嘆，真實一個好工具啊！
● 接著回答第二個問題：一個全職的QTP人員他要做的事情和開發是一樣的，都是一脈相承的。他也要需求、也要框架、也要開發、也要維護等等，修改完善腳本不是每天要做的事情，而是每一個版本發布后要做的事情。如果有一個成熟的產品，用QTP寫出了成熟的腳本，那自動化測試的目的不是達到了嗎？我們的目的就是每天“點”一下，快速拿到測試結果從而解放人力并可以投入到其他項目的測試中去，這也就是自動化測試的目的和意義。另外，QTP基本上只能發現已知的缺陷，目的是為了保證在新增功能加進來以后老功能不受影響；同時也能夠回歸以前有問題的功能在修復后是否又重現了。QTP幾乎不可能發現新缺陷，那是手工測試階段做的事情。當然，QTP也真的不是萬能的，如它肯定不可能比開源的自動化測試工具更Open、擴展性強等，但是世界上不存在萬能的事物！
三、如何才能將QTP自動化測試從無到有地應用到項目中。怎么才能成功實施？有什么成功的要素嗎？
這個問題其實問得范圍非常廣，要回答好很不易，現在分享本人之前自動化測試的一些經驗。首先需要了解自動化測試的一個總體實施流程，當接到一個項目之后，需要了解影響自動化測試實施的一些需求，如項目的周期長短、需求變更的頻繁度、工具的選擇以及工具對測試對象的識別能力等。這樣做的目的就是為了確定項目是否適合做自動化測試，并不是每個項目都適合做自動化測試，失敗的例子實在是太多了，很大一部分原因就是前期根本沒有做充足的分析才會導致后期的被動局面，因此絕對不能忽視前期的這塊內容。當這些都確定完成之后，還需要完成一個簡單的Demo，用于驗證工具對項目中對象的識別能力，這些內容可以歸納在前期的可行性分析方案中。接著需要進行自動化測試設計階段，這個階段包括需求分析、自動化用例轉化為編寫，這里需要注意。不是所有手工測試用例都可以轉化為自動化測試用例，有些用例完全不適合做自動化測試，或者說不能用自動化測試完成，也或者需要投入很大的經歷才能完成。所以需要在設計階段就定義好這些可自動化的測試用例，并且還需要定義好公共的用例庫以及用例的復雜度。當以上內容都定義完畢后，就可以開始下一步核心工作了，也就是自動化測試框架的開發，其大致包含：創建一些公共的組件、公共函數庫、公共對象庫、測試用例調度機制、外部配置、錯誤處理、報表生成等功能，當然，如果不是經驗豐富的測試人員，在框架這塊處理上是不可能一步到位的，需要后期來適應項目并不斷進行改進。一段核心功能完成之后，可以說已經離成功又近了一大步了。最后的工作就是把用例全部完完整整地轉化為測試腳本，如果框架搭建的比較牛，這一步實現其實是比較輕松的。當然，一些特殊的難題令當別論，如小部分對象怎么識別不了，那只能通過專家組共同討論解決方案。
1、自動化測試的優勢
（1）回歸測試更方便、可靠
（2）可運行更多、更繁瑣的測試，且快速、高效
（3）可執行一些對于手工測試來說相當困難或根本做不到的測試
（4）更好地利用資源，使資源的使用更有價值
（5）具有一致性和可重復性的特點
（6）自動化測試腳本完全具有復用性
（7）使軟件更有信任度
（8）多環境下測試
2、自動化測試無法做到的事及其劣勢分析
（1）永遠不可能完全取代手工測試
（2）無法完全保證測試的正確性
（3）手工測試能發現的缺陷遠比自動化測試多（手工85%左右，自動化15%左右其中只有1%是新缺陷）
（4）對測試質量的依賴性極大
（5）測試自動化可能會制約軟件開發
（6）自動化測試工具是死的，它本身沒有任何想象能力
（7）成本投入過高，風險大
（8）自動化測試對測試人員的技術要求較高，對測試工具同樣有一定要求
3、何時適合引入自動化測試
（1）項目周期長，系統版本不斷
（2）需求變更不頻繁
（3）系統中的測試對象基本可以正常識別
（4）系統中不存在大批量第三方控件
（5）需要反復測試，如可靠性測試需要進行上千次的系統測試
4、何時避免展開自動化測試
（1）項目周期短，需求變更頻繁
（2）在軟件版本還沒有穩定的情況下
（3）沒有明確的項目測試自動化計劃、措施和管理
（4）領導不支持
（5）多數對象無法識別以及腳本維護頻繁與艱難，二者有其一，自動化測試注定失敗。
版權聲明：本文出自 跑跑跑跑 的51Testing軟件測試博客：http://www.51testing.com/?591690
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。