摘要：本文介紹了基于數據驅動的自動化測試以及其實現方法，包括軟件是否適合自動化測試的可行性分析；開發測試前的需求分析；基于數據驅動的測試框架的實現以及其維護和擴充。自動化測試是一個比較新的研究領域，也是近來很具爭議性的研究話題，對于自動化測試引入之后的利弊，眾說紛紜。當然自動化測試也在爭議中顯現出了強大的生命力，其測試效率高、重用性好等優點得到了廣泛的認同。本文中所介紹的自動化測試框架結構在很多大型的軟件系統中得到了應用，取得了良好的效果。
0 引言
隨著社會的不斷發展和信息化的不斷普及，各種軟件越來越多，在日常生活中也起著越來越重要的作用，再加上客觀系統的復雜性，無論經驗多豐富的開發人員、無論采用哪種開發模型開發出來的軟件，每個階段的技術復審也不可能毫不遺漏地查出和糾正所有的錯誤，因此如何才能把新的軟件做得更穩定、錯誤更少呢?測試!統計表明，在典型的軟件開發項目中，軟件測試工作量往往占軟件開發總工作量的40％以上。
測試是軟件能否通向市場的最后也是最重要的一關。傳統的測試方法是手工測試，目前大部分都是采用此方法，其特點就是簡單，但是它存在的問題非常多。手工測試可能引入人為的輸入錯誤，尤其在數據量大的情況下；另外大量重復性的手工測試可能成本較高，如果考慮軟件發生改動而需要重復手工測試的情況，這個成本還會更高；沒有辦法對組件進行隔離的測試，從而導致發現問題和解決問題的成本都太高。在很多項目中，測試人員的所有任務實際上都是手動處理的，而實際上有很大一部分重復性強的測試工作是可以獨立出來自動實現的。
針對手工測試的缺點，自動化測試應運而生。相比手工測試，自動化測試的優勢很多；規范測試流程，提高測試效率、測試覆蓋率等。很多人對自動化測試存在誤區，把其理解為找到一種自動化測試工具，把它應用到軟件工程項目中，自動化測試工具只是被看作是一種錄制和回放的工具。事實上自動化測試遠不止這么簡單，錄制和回放僅是自動化測試中的最低級別。目前常把自動化測試分為5個級別，如圖1所示。
現在常用的是基于數據驅動的測試，它是以數據來控制自動化測試的流程和動作的測試，其中數據是獨立于測試用例腳本的，通常以文本文件形式、Excel文件形式、XML文件等形式存在。
1 基于數據驅動自動化測試的實施
1．1 可行性分析
基于對自動化測試優點的分析，很多人對自動化測試存在另一個誤區，認為對于所有的軟件都適合引入自動化測試，且只要引入自動化測試，就會提高測試的效率，降低測試的成本。實際上并非如此，自動化測試也需要開發和搭建測試框架，創建測試用例，這也就意味著成本的投入。對于一個項目周期很緊的測試項目，按測試方案進行手工測試的效率可能要比自動化測試工具錄制腳本再測試的效率好得多。那么自動化測試工具的價值在什么地方?
對于一個一次性開發、沒有后續版本更新的軟件而言，自動化測試是毫無意義的。但是現在很多軟件都會不斷推出新的版本，在推出新版本的過程中，每次除了測試新加或修改過的模塊，相關聯的舊模塊同樣需要測試，才能保證產品的質量，這樣就需要做大量的重復工作，自動化測試此時就可以創建測試中的可重用模塊，同時還可以覆蓋大部分的功能測試，這樣可以使測試人員從回歸測試中解脫出來，專注于新模塊的測試。所以可以說自動化測試的最大價值在于回歸測試。
因此，對于一個軟件或其中某些模塊是否適合自動化測試必須要先進行可行性分析，以證明你所選的測試方法的正確性，通常可進行自動化測試的軟件需要滿足以下幾點：
(1)手工測試復雜度高：
(2)所選測試用例，實現自動測試的難度低；
(3)軟件用于自動化測試的模塊界面變化相對不大；
(4)軟件生命周期長，經常推出新的版本；
(5)軟件開發已基本完成，主要用于測試升級版本；
(6)所選自動化測試框架必須對所測軟件應用界面有有效的支持，且維護管理成本較低。
另外自動化測試前期需要投入時間和一定的成本投入，故不要一開始就期望有高的回報，其效應會在不斷完善積累中顯現。而且不要期待自動化測試可以發現每個版本中的大部分錯誤，因為自動化測試主要用于回歸測試，而且產品中每個新版本的大部分bug會在新模塊中出現，所以自動化測試在于長期效應，能保證每個版本產品質量的穩定。
1．2 需求分析
正如開發軟件需要有需求分析一樣，基于數據驅動的自動化測試本質上也是開發，所以在制定測試方案之前也需要收集測試需求，這樣才能保證自動化測試的成功。
隨著IT技術的發展，傳統的開發人員兼任測試人員的模式已經不能滿足需求，目前大多數較正規的軟件公司均已采用獨立的測試人員來對軟件進行測試，所以形成了開發人員、開發管理者、測試人員、測試管理者的模式。如圖2示。
規范的測試過程需要上述人員的通力配合，因此在做自動化測試之前應該有一份規范的文檔，用來描述測試內容、人員安排、測試流程、缺陷管理等。其中開發管理人員和測試管理人員分別作為開發團隊和測試團隊的接口，協調兩個團隊的工作，一般來說開發人員需要在每次對軟件更新后提供詳細的功能文檔，開發人員還需要提供自動化測試所需要的數據等相關資源，測試人員根據功能文檔創建適合做自動化的測試用例，并建立基于數據驅動的自動化測試工程。
1．3 數據驅動的自動化測試框架結構以及實現
基于數據驅動的自動化測試不是簡單的錄制回放，而且通過編程的形式來實現每個測試用例，其中數據文件獨立于測試用例，這樣數據的更新對整個測試工程的維護會降低到最小。因此創建自動化測試框架需要有一定的編程基礎。
本文自動化測試中采取的是三層框架結構，如圖3所示。
其中最底層為UI Driver層，主要負責定義基本的通用元素庫，如按鈕、下拉框、文本框等在每個軟件中都會出現的基本元素；對這些元素的基本操作以及通用操作(如等待某段時間的函數等)。這一層和測試的軟件沒有關系，因此通用性很強，既可以自己開發也可以用前人開發好的底層自動化Driver。
第二層為代理(Agent)層，這一層是建立在被測軟件上，對被測軟件的每一界面(UI)均建立相關的類和對象，方便最上層調用，這一層需根據軟件的不斷更新而更改。
最上層為測試用例層(TEST Cases)，這一層建立在代理層上，代理層建立好之后，可以提供給測試用例層所需的界面元素，使測試用例可以通過對界面元素的操作完成自動化測試過程。這一層是測試用例的實現層，如果有了比較完善、結構合理的底層以及代理層，此層實現起來就會非常簡單。
其中測試數據以及軟件中元素的ID信息是存放在獨立的XML文件中，測試用例層或者代理層需要用數據時，可以通過統一的接口讀取。這樣的方式不僅可以使整個測試工程結果清晰，最重要的是可以降低整個測試系統的維護費用，這樣才能確保自動化測試的投入回報不斷提升。
1．4 自動化測試的維護和擴充
自動化測試工程會由于軟件的不斷擴充而必須加以維護和擴充。其中維護是指由于新版本的升級導致的舊的測試用例無法通過，必須加以維護才能正常運行。而擴充則是指由于版本的不斷升級，某些功能已經非常穩定，適合于自動化測試，需要新添加一些測試用例來覆蓋這些功能。
擴充和維護是一個長期的過程，其中需特別注意的是每次自動運行測試用例，必須有個詳細的結果日志來記錄測試用例的通過情況，對于運行失敗的用例，記錄失敗的原因，這樣有利于測試人員通過結果來判斷產品的bug。這里需要特別注意的是，有的測試用例表面上是通過了，但是實際上卻執行失敗了，并且結果日志上記錄的是通過，如果出現這樣的情況，而測試人員卻毫無察覺，這就是失敗的自動化，所以對于每次自動化測試的結果，最好能夠建立起核查機制，以確保結果的可靠性。
2 總結
自動化測試是一個比較新的研究領域，也是近來很具爭議性的研究話題，對于自動化測試引入之后的利弊，眾說紛紜。當然自動化測試也在爭議中顯現出了強大的生命力，其測試效率高、重用性好等優點得到了廣泛的認同。本文中所介紹的自動化測試框架結構在很多大型的軟件系統中得到了應用，取得了良好的效果。
