軟件測試自動化實踐

軟件測試自動化實踐

作者：chris

    首先爲什麼需要軟件測試自動化？通過我這幾年在微軟的工作，可以感覺到一點，應該說自動測試，可以定義軟件系統。從理論上來說應該是功能定義軟件系統，軟件系統是怎麼工作的是從功能規格上來看的。但是你要是沒有一套可以自動測試的測試程序存在，就沒有辦法驗證我這個軟件系統，就是修改了一點點，這個軟件系統是不是和前面的軟件系統一模一樣，你沒有辦法驗證，只有有一套自動系統，才能驗證軟件系統是不是還在原來的狀態上。我覺得自動測試是非常重要的一個東西，微軟一個軟件系統如果沒有跟着一套自動系統的話，這個軟件系統基本上沒有生命力，也沒有辦法進行更新，其他的各式各樣的服務也沒有辦法進行。
    代碼的複雜性也是不能小看的。現在測試一個代碼時，所有的覆蓋也是不可能的事情，每一個if…else…或switch語句就會把情況增加一倍，許多異常處理代碼正常使用中不會碰到。許多與時序，死鎖，資源衝突，多線程有關的錯誤很難捕捉到。除此之外，我們每一個版本又各自帶SP與QFE，每個SP進 行組合，可以得到一個天文數字，如果沒有一個自動測試系統的話，要測試整個產品，在所有不同的情況下進行工作的話，幾乎是一個不可能的事情。你要是有一套自動測試系統，對未來 會有一種事半功倍的效果。
    微軟內部有各種不同的測試，首先開發團隊有自己的DRT或者Check－in Suites。不需要重裝機器，要求速度快，對結果彙報要求簡單，100％通過就行，所以不需要很強的分析的能力。與開發團隊的關係近，在他們的源代碼控制系統中。測試團隊有測試的Lab BVT，所有的測試者都是在一起的，BVT的要求是需要重新安裝機器，可以排除其他老的因素在上面的干擾。要求速度快，只運行0級測試，BVT也是在每天的構建結束以後自動運行BVT，結果彙報要求也是比較簡單，一般來說需要100％，如果不是100％總是要找問題，前天的結果，大前天的結果應該都是100％。與測試團隊的關係近，在測試團隊的源代碼控制系統中，由每日產品編譯系統自動觸發，全自動運行。
    還有自己常規的Lab Pass也需要重裝機器，模擬最終用戶的使用形式。需要使用每日編譯結果，規模大，測試數多，環境要求也複雜，在這時候我們就會把整個剛纔我講的測試者引進來，一天可能需要測試不同版本，或者不同語言版等。對測試結果彙報與問題要求很高，因爲這時候所有測試必須百分之百的通過，可能前天有這麼一個問題，今天這個問題重新出現，是不是就可以忽略了呢？如果這個報告結果工具不能幹這個事，每天必須要重新做。由測試團隊根據需要產生。測試團隊的個人Private Pass，由測試個人根據需要產生，不一定需要重裝機器，對測試結果彙報要求很高，與測試團隊的關係近，在測試團隊的源代碼控制系統中。
    一個具體自動化測試系統分析。微軟內部有很多套自動化測試系統，比如OASys，是Office用的系統，還有Maddog，Bruce等等。這些系統演化到最後，總體結構大同小異。如果大家自主開發一套新的自動化測試系統，我估計大概十年以後結果就是這樣的。以OASys系統爲例，有Web服務器，是前臺的Web UI。SQL Server後臺服務器，有控制程序，客戶機程序，客戶程序就是在機器上裝一個小的程序，一些結果報告與分析的程序，有文件服務器，存放每天的構建的結果，每次結果的Log file等等，除此之外所有的測試都是在機器池中進行，一系列差不多一樣的機器，在一個測試裏隨時調用某一羣或者某一些，或者某一個機器進行使用。

   具體模塊的功能:
   文件服務器是存放每日的結果，存放每一個Run的logfile。比如你需要安裝什麼東西，需要什麼樣的後臺背景。
   SQL Server存放有關的Setup參數，存放所有與測試有關的參數，存放所有Client機器的情況，是什麼樣的機器，多少內存，系統時間是什麼，現在在幹什麼等等 ，所有機器的情況都存在這裏；還存放所有Run Pass的總體結果，運行數，通過率，運行機器名等……
    Web服務器是Web前臺，等於說是一個Web配置。測試團隊使用後臺服務器的入口，好處就是隻需要IE就可以運行，零安裝，易集中更新。可以查詢並修改所有存放在SQL Server中的參數，可以產生、查詢並觸發Lab Run，可以查詢Lab Run進展狀況，總體結果等。 還可以查詢並調整客戶機的狀態，所安裝的OS，程序等。
    機器池是幾十臺一樣或比較接近的輕型機器，擁有操作系統或文件系統的鏡像程序，可以進行自我更新。
    控制器程序，從SQL Server中讀取工作數據，產生工作腳本，並把工作按客戶機參數分配給客戶機運行，當運行結束時，從Client得到結果並更新SQL Server，分爲機房控制器與個人控制器等。Lab controller主要用於控制Lab裏的Machine Pool，Private controller主要用於控制Office裏的測試團隊成員個人的機器。控制器程序應具有動態分配任務的功能，控制器程序應具有Load Balance的功能，控制器程序應能根據Lab Run的優先級與機器資源最優化的分配工作。比如說你有一個自動測試，一個自動化測試每次在Run的時候並不是只有一個測試，同時進行的可能有三到四個同時進行，有的Lab Run會進展的很慢，有些優先級很高。動態分配的功能是非常重要的，根據你的Lab Run的優先級，決定給你分配多少資源進行運行，這是非常重要的系統。還需要多少時間也是一個比較重要的功能，如果你有以前的數據，比如上次Lab Run以後，就知道每一個測試需要Run多少時間，把總體時間加起來，可以看到在今天的構建上還剩下多少時間。
    客戶機程序。這個程序是一個非常小，非常輕型的程序，是運行在各個小的Client上面的，幾乎是零安裝，就是一個小程序，非常輕巧，因爲他幾乎不依靠於任何模塊，可在裸機上運行，在微軟裏所有的模塊都可能是需要測試的模塊，如果客戶機上運行的程序需要ADO這個東西，我們就需要測試這個ADO。可以用於完成控制器交給的任務並記錄全過程，非常穩定，不會死機，並能截取大部分的異常情況。可以截屏，TimeOut，所有的系統都是在Lab自動運行的，全部是一些機器，沒有人的。自動化運行系統很快，等於說一天24小時不停的進行。
    結果報告與分析程序，安裝於測試團隊成員的主機上。查詢數據庫並顯示所要Run的狀態，通過率，還需要時間等。進行簡單的運行操控，如重新運行，指定主機運行等。最主要的是自動分析運行的結果文件，比較不同之處，列出改進與惡化的Test Case。剛纔我講的每天可能有成千成萬的結果需要分析，成千成萬的結果可能有很大一塊早就已經分析過了，不想重新看這些結果，就要進行比較。各種各樣的情況都能讀出來，和存入的結果進行比較，得出新的需要分析的措施，你已經看過這些措施就不用管它了。這個程序分析完錯誤以後，可以輸入失敗錯誤的原因。提供結果文件的鏈接，Bug DataBase的鏈接，提供進一步分析結果的工具。記錄Test Case失敗的原因，並可直接輸入與跟蹤Bug號，當結果分析完畢，可記入爲基準結果，以便於未來運行結果的比較。
    我們是怎樣使用這一套系統的。首先一個測試經理得到一個測試的任務，比如說Windows 2000的任務，他可以把這個任務告訴一個人，這個人應該是測試團隊的成員(LRF)擔任，這個人乾的活每次根據這些東西產生一些Run，要知道這個Run進入什麼狀態，是不是很成功等等，協助整個Run能夠很平和的進行。這個人測試團隊也不是有很多人願意幹這個活，大家就輪流幹這個事情。LRF根據需求在Web UI用模板產生相應的Run，填入OS要求，語言要求，運行優先級，應完成時間等，把這些東西都輸入進去。這個Run被控制器程序得到，得到以後就根據優先級，完成時間，可用機房機器數，合乎要求的機器數，測試總量等來分配任務。機房客戶機得到任務，清理自己，安裝要求的程序與模塊，從文件服務器拷貝測試運行程序，執行測試並拷回結果。
    LRF通過Web UI跟蹤Lab Run進展，檢查有無重大問題，檢查運行進展能否按時完成並作及時的調整，當Lab Run接近尾聲，email測試團隊驗證各自結果。可以說測試者本身一般不會監測Lab Run進行。測試團隊成員收到email打開我們剛纔講的結果報告與分析程序，最主要是新的錯誤，新的錯誤比如說是Bug，產生一個很小的Code，重現這個錯誤。
    測試程序的問題，測試程序本身Code上的問題，你要修改你的測試程序等等。如果是對於客戶機安裝的問題，一天整個系統每臺不同的機器都是一個問題，比如今天XP統統都通過了，比較簡單。最後測試經理對所有的結果彙總，也是在結果報告程序進行的，大家把成果分析完以後，測試經理自動產生一張總報表，會通過這個數據決定我們這個產品怎麼辦，不光是在最後彙總的時候用。
    做一個很快的回顧，對於一套測試自動化系統來說，對一個成熟的測試團隊來說是非常重要的東西。如果一個測試團隊如果沒有一個完整的測試系統來說，沒有辦法進行一個測試。一個新開發的測試自動化系統，儘量通用化。我們的測試系統，什麼都能做，可以看他系統設計的模塊，並不是爲了測試什麼東西而設計，可以測試任何東西，所以Office這麼大一個產品，裏面任何東西都是在測試系統上測試，測試系統需求非常簡單。對自動化測試本身來說，是非常簡單的一個東西，什麼都不知道，只知道產生一個結果，運行結果拷回去就完了。還有一些控制，控制我剛纔講的動態分配資源的問題。如果你要是機器數不夠，這就是自動化測試控制，但是要測試什麼東西，完全是由測試人員自己決定，所有自動的腳本都是自己編的，你就是存到文件服務器上就行了。每個測試自動化系統每一板塊各有側重，不必大而全。從測試自動化系統整個來說，一開始的前期投入可能大一些，大家可以看到，你要建立整套測試自動化系統，每個系統想方設法自動化、模塊化，剛開始投入非常多，長遠來說是很有利的。如果手工測試的話，後臺那麼多不同的應用程序，有各種不同XP的情況，不同語言的情況下，如果都用手工來做幾乎不可以想象。如果有測試自動化系統，只要開發一次自動化以後，所有其他的機器都是自動運行的，不用再管他了。所以他對鼓舞整個團隊的士氣是非常重要的。一個測試者一天的工作，對測試結果來說非常簡單，只要看一下每天的新的情況就完了，其他的事情都不用管。自動化測試對後期軟件維護來說也是非常重要的。自動測試系統是什麼都能測試，不管幹什麼都可以測試，針對你產品所有的測試自動化起來，如果只有一個版本可能是不行的，微軟所有的產品Office已經有十二個版本了，這麼多的版本程序來說，如果沒有自動測試是難以想象的。如果有自動測試就可以同步測試使用，這樣就可以達到事半功倍的效果，很快可以驗證，可以避免重複勞動。自動測試定義軟件系統，如果一個軟件系統沒有自動測試的話，後期維護，下一版本的發行都是難以想象的一件事情。