軟件測試中的自動化測試的風險點
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
今天和原來公司的老大聊了一會天，不禁讓我想起了，當年剛進入自動化測試領域，從一無所知到小有成就的點點滴滴。如今離開功能自動化測試領域差不多有一年多的時間了，我想有必要對過去兩年多的時光，在自動化測試領域學到的知識做一些總結。因為這個時候還能記得的東西，肯定是經過沉淀的東西。
自動化測試的引入成本都是相當巨大的。一般自動化測試工程師的薪水和程序員相當于甚至高于中高級程序員。而自動化測試從投入到產出整個周期也是比較長的。一般從測試工具引入，到初步測試用例可以使用(起到探路預研作用)，需要3個月的時間。而能形成比較完整的測試體系，能完成冒煙測試，集成回歸測試，測試報告產生，錯誤用例自動回放等功能需要一年的時間，所以投入一定要謹慎。這就需要引入的單位能清楚的知道自動化測試能解決什么問題，在引入過程中有哪些風險。合理的期望，才能引導測試人員開發出有價值的可以持續發展的自動化測試框架。
自動化測試能解決的問題在很多書上都有描述。即能解決相對固定，變化不大的功能模塊的測試，在這里我就不要詳細描述了。我想描述的是在實施過程中可能遇到的風險。
1.自動化測試離不開對業務的熟悉精通的測試人員。做測試的需要兩條腿走路，一條是測試技術，一條是對業務的熟悉，而任何測試用例它的靈魂都是業務。而自動化測試團隊往往是由技術出身的程序員組成的，所以往往不懂業務。要解決這個問題，有兩種方法，一個是引入一個超強的業務測試人員，對公司所有的模塊都比較熟悉，這對于ERP這樣的產品幾乎是不可能的。除非產品比較簡單，而比較簡單的產品也不需要自動化測試了。第二種方法，是由業務測試人員來寫測試用例，而這種測試用例是可以被自動化測試人員讀懂的。當然比較高的境界就是讓程序自動能夠讀懂。
通常最簡單的辦法就是由自動化測試人員編寫一個測試用例編寫工具，讓業務測試人員在上面編輯，程序自然有辦法轉換成自動化測試工具可以辨識的腳本語言。而實際上這種方法投入的成本很大，而對于業務測試人員也需要投入比較多的資源來學習這種編輯工具，個人認為不是一種很好的方法。
而實際上最有效的方法，是不改動原有的測試用例編寫方法，將它轉換為測試工具可以辨識的語言，這樣才能使業務測試人員的測試用例順利的向自動化測試用例轉換。
2.自動化測試工具的選擇
現在市面上比較流行有QTP,Rational Robot等琳瑯滿目的測試工具，那么選擇什么樣的測試工具來進行測試呢。其實在我看來商業的測試工具其實差別不大，所以成本往往是最主要的選擇原因。而開源的工具，目前我還不太提倡，因為開發投入成本實在太大，而且有太多不可控制的因素，不是很靠譜。需要強調的是測試工具起到的只是輔助功能，重要的是測試思想、自動測試框架、測試套件、測試用例的設計 ，在更多的時候還要測試工程師發揮他們的經驗和智慧實施有效的測試�，F在QTP和RationalRobot里邊幾乎都體現了以下兩個思想。
A.業務邏輯和測試數據分離。
業務邏輯和測試數據分離，這樣一套業務邏輯由于他的測試數據的千變萬化，就可以變出很多的測試用例出來。
B.測試組件概念的提出。測試功能模塊化，封裝化。
原本模塊和封裝是程序設計范疇的概念，而現在它在自動化測試領域也同樣適用。一個測試用例可以由不同的測試組件組成。如下圖將不同功能點的測試步驟封裝成組件
那么根據上面的組件我們就可以組成下面的測試用例
組件A->組件B->組件C
組件A->組件D->組件B-組件C
組件A->組件C->組件B
組件A->組件D
….
可見測試用例設計人員只要設計了四個測試組件，就可以完成豐富的測試用例組合。
這兩個測試思想是自動化測試對測試用例設計方法創新的最大貢獻。
3. 在自動化測試引入過程中，最容易被忽略的一個環節測試執行。由于測試執行是自動化測試各個環節中最晚一個環節，所以他往往是最容易被忽略的。然而實際上他和測試用例設計，測試腳本編寫一樣重要。它就如果足球比賽的臨門一腳，如果比賽過程中，前面的傳接配合做的很好，而臨門一腳不行，一切也都是白搭。測試執行，需要注意的問題。
A.需要考慮是否能夠夜間自動執行，這涉及到一些如計劃任務如何啟動等技術細節，只要花功夫還是可以解決的
B.需要考慮腳本版本和測試對象的匹配性。測試腳本也需要做嚴格的版本控制
C.需要考慮在各種操作系統上的兼容性測試問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
