基于數據驅動(dòng)的自動(dòng)化測試的研究和實(shí)現

現在常用的是基于數據驅動(dòng)的測試，它是以數據來(lái)控制自動(dòng)化測試的流程和動(dòng)作的測試，其中數據是獨立于測試用例腳本的，通常以文本文件形式、Excel文件形式、XML文件等形式存在。

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

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