基于數(shù)據(jù)驅(qū)動的自動化測試的研究和實現(xiàn)

現(xiàn)在常用的是基于數(shù)據(jù)驅(qū)動的測試，它是以數(shù)據(jù)來控制自動化測試的流程和動作的測試，其中數(shù)據(jù)是獨立于測試用例腳本的，通常以文本文件形式、Excel文件形式、XML文件等形式存在。

1 基于數(shù)據(jù)驅(qū)動自動化測試的實施
1．1 可行性分析
基于對自動化測試優(yōu)點的分析，很多人對自動化測試存在另一個誤區(qū)，認(rèn)為對于所有的軟件都適合引入自動化測試，且只要引入自動化測試，就會提高測試的效率，降低測試的成本。實際上并非如此，自動化測試也需要開發(fā)和搭建測試框架，創(chuàng)建測試用例，這也就意味著成本的投入。對于一個項目周期很緊的測試項目，按測試方案進行手工測試的效率可能要比自動化測試工具錄制腳本再測試的效率好得多。那么自動化測試工具的價值在什么地方?
對于一個一次性開發(fā)、沒有后續(xù)版本更新的軟件而言，自動化測試是毫無意義的。但是現(xiàn)在很多軟件都會不斷推出新的版本，在推出新版本的過程中，每次除了測試新加或修改過的模塊，相關(guān)聯(lián)的舊模塊同樣需要測試，才能保證產(chǎn)品的質(zhì)量，這樣就需要做大量的重復(fù)工作，自動化測試此時就可以創(chuàng)建測試中的可重用模塊，同時還可以覆蓋大部分的功能測試，這樣可以使測試人員從回歸測試中解脫出來，專注于新模塊的測試。所以可以說自動化測試的最大價值在于回歸測試。
因此，對于一個軟件或其中某些模塊是否適合自動化測試必須要先進行可行性分析，以證明你所選的測試方法的正確性，通常可進行自動化測試的軟件需要滿足以下幾點：
(1)手工測試復(fù)雜度高：
(2)所選測試用例，實現(xiàn)自動測試的難度低；
(3)軟件用于自動化測試的模塊界面變化相對不大；
(4)軟件生命周期長，經(jīng)常推出新的版本；
(5)軟件開發(fā)已基本完成，主要用于測試升級版本；
(6)所選自動化測試框架必須對所測軟件應(yīng)用界面有有效的支持，且維護管理成本較低。
另外自動化測試前期需要投入時間和一定的成本投入，故不要一開始就期望有高的回報，其效應(yīng)會在不斷完善積累中顯現(xiàn)。而且不要期待自動化測試可以發(fā)現(xiàn)每個版本中的大部分錯誤，因為自動化測試主要用于回歸測試，而且產(chǎn)品中每個新版本的大部分bug會在新模塊中出現(xiàn)，所以自動化測試在于長期效應(yīng)，能保證每個版本產(chǎn)品質(zhì)量的穩(wěn)定。
1．2 需求分析
正如開發(fā)軟件需要有需求分析一樣，基于數(shù)據(jù)驅(qū)動的自動化測試本質(zhì)上也是開發(fā)，所以在制定測試方案之前也需要收集測試需求，這樣才能保證自動化測試的成功。
隨著IT技術(shù)的發(fā)展，傳統(tǒng)的開發(fā)人員兼任測試人員的模式已經(jīng)不能滿足需求，目前大多數(shù)較正規(guī)的軟件公司均已采用獨立的測試人員來對軟件進行測試，所以形成了開發(fā)人員、開發(fā)管理者、測試人員、測試管理者的模式。如圖2示。

規(guī)范的測試過程需要上述人員的通力配合，因此在做自動化測試之前應(yīng)該有一份規(guī)范的文檔，用來描述測試內(nèi)容、人員安排、測試流程、缺陷管理等。其中開發(fā)管理人員和測試管理人員分別作為開發(fā)團隊和測試團隊的接口，協(xié)調(diào)兩個團隊的工作，一般來說開發(fā)人員需要在每次對軟件更新后提供詳細(xì)的功能文檔，開發(fā)人員還需要提供自動化測試所需要的數(shù)據(jù)等相關(guān)資源，測試人員根據(jù)功能文檔創(chuàng)建適合做自動化的測試用例，并建立基于數(shù)據(jù)驅(qū)動的自動化測試工程。