自動化測試基本策略(2)

　　簡而言之，是否值得使用自動化測試，就要看它是否具有自動化測試的特點和高的投資回報率。

　　2.2 開始自動化測試的時機

　　如果是新的自動化測試工具的開發或研究，最好預留一個比較充裕的時間，時間太趕很難設計出精品。如果想在功能測試階段使用自動化測試，那么自動化測試架構的設計最好能夠與代碼實現同步，否則如果等代碼實現提交測試之后再做自動化測試工具的開發或研究，在功能測試或回歸測試的過程中就被動了很多。

　　關于在項目的什么階段開始自動化測試，由項目決定，對于需求相對穩定并且是基于成熟的架構上開發的系統，自動化測試腳本最好在功能測試開始之前編寫，在功能測試階段就可以使用已經編寫好的腳本做功能測試了。

　　但我們平時遇到的項目，有很多是需求變化比較大的，或者是一些不夠成熟的系統，這樣的系統如果在功能測試之前編寫好的腳本，很有可能不能在系統上正確運行，大多還是需要手工執行才可以測試，甚至會在功能測試完后系統跟功能測試之前的系統會有非常大的區別。對于這樣的項目，自動化測試開始得越早項目的成本就越大，最好在系統的架構或需求相對穩定后再做自動化測試。

　　對于一些需要錄制GUI界面的功能的自動化測試，在頁面的功能相對穩定之后再做自動化測試性價比會比較高，因為頁面是最容易變動的部分，而且任何一個控件的修改都會導致自動化工具不能識別控件，導致很多自動化測試腳本會跟著做大量的修改，增加了維護的成本。當然，因為頁面變化而引起的腳本的改動的大小，也跟自動化測試的架構和寫腳本的功力有密切的關系。

　　對于一些協議或接口相關的功能測試(比如：XML或socket接口等)，是較為容易實現自動化測試的，封裝好底層的協議提供給自動化測試腳本調用，即使是協議會有變化，改動起來還是很簡單的，維護的成本相對較低。

　　總的來說，在軟件功能達到相對的穩定，沒有嚴重錯誤和邏輯錯誤后開始自動化測試，性價比是比較高的。

　　2.3 自動化測試的覆蓋率

　　自動化測試的覆蓋率是很多管理層所關心的，很多項目或產品的自動化測試目標之一就是自動化測試的覆蓋率。從管理的角度來說，100% 的自動化目標只是一個從理論上可能達到的，但是實際上達到 100% 的自動化的代價是十分昂貴的。自動化測試覆蓋率越高，測試腳本的維護成本也就越大。由于對每一個構建版本的需求變化的復雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。

　　自動化測試的覆蓋率的大小與自動化測試的成本有著很大的聯系。自動化測試的覆蓋率為多少比較恰當，也要看被測試系統的性質和測試的階段。

　　在自動化測試設計的階段，可以考慮先實現冒煙測試的測試用例自動化，冒煙測試的功能一般是系統的主要功能，是自動化測試設計必須首先實現的，而且通過實現這些功能，也可以檢驗自動化測試的架構是否合理。

　　在功能測試的前期，自動化測試腳本的覆蓋率最好只是一些關鍵的并且是相對穩定的功能的測試自動化，用于冒煙測試或關鍵功能測試。

　　系統穩定后，如果系統是一個生命周期很長的系統，且測試的功能很容易實現自動化測試，這樣的系統的自動化測試覆蓋率可以考慮在80%以上。

　　但如果是一些時間很趕的項目，或者是一些比較難實現自動化測試的功能，也就沒有追求高的自動化測試的覆蓋率的必要。隨著測試案例的增加，維護的成本也會相應增加，特別是一些GUI的測試，自動化比率越高，維護腳本的成本也就越高。

　　不要追求在很短的時間實現自動化測試，也不要追求100%的自動化測試覆蓋率，積累經驗循序漸進的自動化測試，效果會更好。

　　第3章 自動化測試實現基本策略

　　自動化測試與軟件開發本質上是一樣的，利用自動化測試工具，經過測試需求分析，設計出自動化測試用例，從而搭建自動化測試的框架，設計與編寫自動化腳本，驗證測試腳本的正確性，最終完成自動化測試測試腳本(即主要功能為測試的應用軟件)。

　　3.1 測試系統需求分析

　　任何測試的基礎都是被測系統的功能，不管是手工的功能測試還是自動化測試或者是性能測試，都是基于系統的功能展開的。當測試項目滿足了自動化的前提條件，并確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應的測試用例、測試數據，并形成詳細的文檔，以便于自動化測試框架的建立。

原文轉自：http://www.uml.org.cn/Test/201005042.asp