束 進
(中海網(wǎng)絡科技股份有限公司,上海200135)
隨著我國高速公路建設的不斷開展,高速公路收費系統(tǒng)已經(jīng)遍布全國各地,在我國交通運輸事業(yè)的發(fā)展進程中扮演著重要的角色。其中,高速公路收費系統(tǒng)軟件的測試是保證高速公路收費系統(tǒng)軟件質量的關鍵過程之一,對確保高速公路收費系統(tǒng)正常運行具有十分重要的作用。
隨著各省高速公路規(guī)模的日益擴大,以及區(qū)域聯(lián)網(wǎng)的開展,高速公路收費系統(tǒng)軟件的規(guī)模也隨之不斷擴大,邏輯性不斷加強,功能不斷被拓展。因此,這些軟件產(chǎn)品的系統(tǒng)測試變得越來越困難和復雜,傳統(tǒng)的人工測試的局限性也越來越明顯。自動化軟件測試技術正是在這樣的背景下受到了密切的關注,成了近年來軟件測試的重要研究方向,被越來越多的應用在了軟件測試的各個階段。研究面向高速公路收費系統(tǒng)的自動化測試技術,目的是為了節(jié)省測試成本、提高產(chǎn)品的測試效率、縮短研發(fā)周期,從而滿足客戶對高速公路收費系統(tǒng)的需求。因此,設計并實現(xiàn)一種適合高速公路收費系統(tǒng)的自動測試框架具有重要的意義。
所有能夠有效組織和管理自動化測試中所必需的各個組件、能夠有計劃地執(zhí)行自動化測試并且支持測試結果分析和測試過程改進的結構實例或文件實例都可以稱作自動測試框架。
目前普遍存在的自動測試框架有以下幾種:
1.數(shù)據(jù)驅動框架:當測試對象流程固定不變(僅僅數(shù)據(jù)發(fā)生變化)時,可以使用這種測試框架。測試數(shù)據(jù)是由外部提供的,如Excel表、XML等。
2.關鍵字驅動框架:這種自動測試框架提供了一些通用的關鍵字,這些關鍵字適用于各種類型的系統(tǒng)。此外,其還為自動化測試工具和被測系統(tǒng)提供了抽象性。例如,它可以使用相同的測試用例來測試類似的Web和Windows系統(tǒng)。關鍵字驅動的測試框架因為使用了外部的數(shù)據(jù)源(比如Excel數(shù)據(jù)表)讀取腳本中的關鍵字和測試過程,所以較難調試。
3.混合型框架:這種自動測試框架同時具有數(shù)據(jù)驅動型框架和關鍵字驅動型框架的優(yōu)點,不僅有通用的關鍵字,還有基于被測系統(tǒng)業(yè)務邏輯的關鍵字。
以上幾種框架各有優(yōu)缺點,對于較為復雜的軟件,單獨依靠數(shù)據(jù)驅動或關鍵字驅動無法完全滿足軟件的測試需求,一般會采用混合型自動測試框架。
近些年,為了滿足市場和客戶的需求,公司高速公路收費軟件的版本升級的頻率越來越頻繁,測試周期不斷被壓縮。讓手工測試人員在有限的時間內去驗證成百上千的測試用例,基本上成為了不可能實現(xiàn)的任務。由于傳統(tǒng)的手工測試已經(jīng)無法滿足企業(yè)進行有效的軟件測試,自動化測試技術應運而生,但是目前的自動化測試技術卻很難在企業(yè)中得到實際應用。
1.軟件變更引發(fā)的自動化測試程序的變更維護量超出了手工測試的工作量,使得自動化測試技術成為了一個“美麗的謊言”。
2.企業(yè)內大部分測試人員精通測試業(yè)務,但是不熟悉自動化技術;新招聘的自動化測試人員熟悉測試技術,而又不了解測試業(yè)務。二者資源無法在短時間內融合,使得企業(yè)無法接受需要投入的成本。
隨著企業(yè)對自動化的期望越來越高,各類自動化測試工具逐漸熱銷。運用這些工具,基本上可通過錄制技術快速地形成測試腳本進行一些參數(shù)化或檢查點設置的腳本修正工作,而后點擊回放按鈕,就可以很“輕松”地完成一次軟件測試。但是,后期大量的自動化測試腳本維護工作使得企業(yè)投入成為了一個無底洞。運用該方法不僅僅沒有真正解決軟件測試問題,反而造成“高投入、低產(chǎn)出”問題凸現(xiàn),這使得很多企業(yè)不得不再重新回歸到手工測試模式。
自動測試化框架就是為了組織在測試過程中被拆解細化的各個測試組件而存在的,能夠有效組織和管理自動化測試過程中的活動,能夠解決自動化測試中出現(xiàn)的問題。
一些成熟的自動測試框架已經(jīng)廣泛應用于軟件開發(fā)項目中。其中,XUnit是基于測試驅動開發(fā)的測試框架,適用于單元測試,JUnit和Cpp Unit都屬于XUnit;Apache JMeter是Web應用程序的性能測試框架,用于分析重負載情況下整個服務器的性能;Seleniu m是Thought Wor ks專門為Web應用軟件設計的驗收測試框架。然而,很難找到一個適合高速公路收費軟件的自動測試框架,而這一框架就是所需要研究的方向。
QTP(Quick Test Professional)提供符合主要應用軟件環(huán)境的功能測試和回歸測試的自動化,采用關鍵字驅動的理念以簡化測試用例的創(chuàng)建和維護。
然而,只使用QTP的錄制回放功能得到的測試腳本去測試高速公路收費軟件是有缺陷的。因為這些測試腳本是隨機創(chuàng)建的,測試數(shù)據(jù)和軟件操作混合在了一起,即使測出軟件缺陷也很難進行追蹤和重現(xiàn),而且維護成本也是非常高的。
為此,設計了基于QTP的高速公路收費軟件自動測試框架,由于高速公路收費軟件涉及多個層級,較為復雜,采用混合型自動測試框架進行設計。該框架定義好了一組自動化測試的規(guī)范、測試腳本的基礎代碼,以及測試用例的集合。通過使用該框架,可以減少冗余測試代碼,提高試代碼生產(chǎn)率、可重用性和可維護性。此外,通過將該框架復用到很多類型相同或相近的項目中,還可大大節(jié)省測試成本。
圖1 基于QTP的高速公路收費軟件自動測試框架架構
基于QTP的高速公路收費軟件自動測試框架架構見圖1,分為以下幾個部分:
3.1.1 測試數(shù)據(jù)層
測試數(shù)據(jù)層包括測試用例庫和測試數(shù)據(jù)庫。
(1)測試用例庫包括對象庫、業(yè)務組件庫和函數(shù)庫。測試用例是一系列測試步驟的集合,與手工測試中的一個或多個業(yè)務流程相對應??梢詮臏y試用例中讀取測試數(shù)據(jù)、設置檢查點、生成日志文件、調用業(yè)務組件和公共函數(shù)。
被測應用程序所有對象被錄制后都會被保存到一起,形成對象庫。
業(yè)務組件是一些重用性比較強的測試腳本,通過調用業(yè)務組件,可以提高測試腳本的開發(fā)效率,降低測試腳本的維護成本。
函數(shù)庫包含擴展函數(shù)和常規(guī)函數(shù)兩大類,它們之間的區(qū)別在于是否跟被測應用程序控件有交互。
(2)測試數(shù)據(jù)是自動化測試的一個重要組成部分,包括輸入數(shù)據(jù)、輸出數(shù)據(jù)和檢查點數(shù)據(jù)。所有測試數(shù)據(jù)都將按統(tǒng)一的規(guī)范管理,任何測試數(shù)據(jù)都不能被某個QTP腳本私有。
3.1.2 測試邏輯層
測試邏輯層包括批量執(zhí)行列表和批量執(zhí)行驅動器。
(1)批量執(zhí)行列表包括了所有的測試用例。為了方便管理,通過設置測試用例的屬性來決定是否執(zhí)行該測試用例,以及在哪個環(huán)境中執(zhí)行。
(2)批量執(zhí)行驅動器是整個框架的核心,其主要工作包括控制測試用例的執(zhí)行和生成測試報告。如果被測應用程序出現(xiàn)異常,驅動器將強行關閉應用程序及相關服務。
3.1.3 測試展示層
測試展示層主要是指測試報告。
批量執(zhí)行驅動器將執(zhí)行成功和執(zhí)行失敗的測試用例的個數(shù),以及完成整個測試任務所用的時間記錄下來,通過測試報告可以查詢和打印測試的結果。
該自動化框架應具有以下特點:
(1)實現(xiàn)測試數(shù)據(jù)的統(tǒng)一管理,將測試數(shù)據(jù)從測試腳本中抽離出來;
(2)實現(xiàn)空間對象的統(tǒng)一管理,所有的控件對象都是獨立于測試腳本的;
(3)實現(xiàn)測試腳本的模塊化和封裝性,提高測試腳本的可維護性;
(4)測試腳本可以批量執(zhí)行,并且生成集成的測試報告;
(5)方便實施,不會因為引入自動化框架而增加額外的工作量。
使用該框架可以在無人監(jiān)管的情況下實現(xiàn)多個測試用例連續(xù)執(zhí)行,自動化腳本的運行過程為:
(1)測試人員通過啟動驅動器執(zhí)行自動化測試;
(2)驅動器從批量執(zhí)行列表中讀取第一個測試用例的ID,開始執(zhí)行第一個測試用例;
(3)測試用例根據(jù)ID將相應的測試數(shù)據(jù)加載到QTP的Global Table中,并在指定的測試報告中記錄每一步的測試結果;
(4)當?shù)谝粋€測試用例執(zhí)行完畢后,驅動器再次回到批處理Excel文件中讀取第二個測試用例的ID,如此循環(huán)下去,直到所有的測試用例執(zhí)行完成;
(5)驅動器在測試報告中記錄執(zhí)行成功和執(zhí)行失敗的測試用例的個數(shù),以及完成整個測試任務所用的時間。
3.2.1 測試數(shù)據(jù)
框架采用SQL SERVER數(shù)據(jù)庫管理測試數(shù)據(jù),所有測試都集中在該數(shù)據(jù)庫里(每個項目對應一個測試數(shù)據(jù)庫)。所有的測試數(shù)據(jù)使用完畢后都會被備份保存,下次測試類似項目時可以借用。
當執(zhí)行到某一測試用例時,初始化函數(shù)會將其對應的測試數(shù)據(jù)加載到r unti me Data Table中去。當測試用例執(zhí)行結束時,r unti me Data Table會被自動清空,并準備加載下一個測試用例的測試數(shù)據(jù)。
每組測試數(shù)據(jù)占用數(shù)據(jù)庫的一個表,并按照測試腳本的ID進行命名和排序。每個表的每一行測試數(shù)據(jù)代表一次循環(huán)。一張表格內的測試數(shù)據(jù)不得重復,否則QTP無法正常讀取數(shù)據(jù)(不同表間的測試數(shù)據(jù)沒有限制)。
3.2.2 對象庫
該自動化測式框架中的對象庫被所有的測試用例和業(yè)務組件庫共同擁有,被測試的應用程序的所有對象都會被錄制并保存在對象庫中,否則QTP腳本將無法正常運行。另外,為了便于維護對象庫,任何對象都不能歸某個QTP腳本私有。
3.2.3 函數(shù)庫
該自動化測式框架中的函數(shù)庫主要包含兩大類函數(shù):擴展函數(shù)和常規(guī)函數(shù)。它們之間的區(qū)別在于是否與被測應用程序控件有交互。
擴展函數(shù)中的活動與被測應用程序控件是有交互的,例如直接操作控件、對控件發(fā)出請求、或接受控件返回的信息。與QTP的函數(shù)相比,我們設計的擴展函數(shù)與被測應用程序的關系更加緊密,在測試腳本中的可用性也比較強,既能操作控件,又能察覺錯誤并進行糾正。
擴展函數(shù)為應用程序和QTP提供了一個中間層。有了這個中間層,自動化測試腳本對QTP的依賴就會減弱。即使是使用更新版本的QTP,自動化測試腳本也無需進行重大的改變,只需要調整擴展函數(shù)即可。
3.2.4 業(yè)務組件庫
不同的測試用例間可能會有很多相同的測試步驟,如果將這些測試步驟組織成可以重用的業(yè)務組件,那么只需要調用業(yè)務組件就可以達到相同的測試目的。因此,框架采用了基于業(yè)務組件的腳本模型,可以實現(xiàn)測試腳本的模塊化和封裝性,提高測試腳本的編寫效率和可維護性。
在該框架中,業(yè)務組件與函數(shù)的不同在于,函數(shù)實現(xiàn)了獨立于應用程序業(yè)務邏輯的功能,例如系統(tǒng)變量設置和異常處理等。而業(yè)務組件實現(xiàn)的是與應用程序業(yè)務邏輯相關的測試活動,如登錄、注冊和退出應用程序等。函數(shù)庫可以被不同的項目開發(fā)團隊共享,業(yè)務組件卻做不到這一點,被測應用程序不同,業(yè)務組件可能大相徑庭。
實施自動化測試的一項重要工作就是執(zhí)行自動化測試腳本。通常情況下,測試人員都是使用QTP中的運行命令來執(zhí)行單個測試腳本。如果在執(zhí)行過程中出現(xiàn)了問題,測試人員往往會直接中止運行,立即分析出錯原因。用這種方法執(zhí)行自動化測試時,測試人員在腳本運行期間必須一直在一旁觀察,無法做其他事情,因此,在框架中建立了批量執(zhí)行驅動器和批量執(zhí)行列表。在批量執(zhí)行多個QTP腳本時,能夠實現(xiàn):
(1)在無人監(jiān)管的情況下批量執(zhí)行;
(2)中間一個測試腳本出了問題,后面的測試腳本不會受到影響;
(3)測試數(shù)據(jù)互不干擾;
(4)生成集成的測試結果。
測試人員只需要事先在配置文件中將待執(zhí)行腳本的運行狀態(tài)改為TRUE,然后直接運行驅動器即可。驅動器首先會加載配置文件,然后創(chuàng)建記錄測試結果所需的Excel文件;接著,讀取配置文件中第一個腳本的名稱,開始執(zhí)行測試用例;如此循環(huán),直到所有的測試執(zhí)行完成;最后,驅動器計算出執(zhí)行成功和執(zhí)行失敗的測試用例的個數(shù),分別記錄在測試報告的相應字段。
QTP自帶的測試報告雖然方便易懂,但不適合在自動測試框架中使用,因為測試人員從中提煉出想要的信息往往要花很長時間。在自動化框架中,提供了測試報告生成功能,只須通過統(tǒng)一調用該功能,即可達到自動生成測試報告的目的。在測試用例執(zhí)行的過程中,該功能可以將測試中產(chǎn)生的錯誤信息、日志信息、測試結果及其所屬的測試步驟集成到Excel文件中。
測試人員可以點擊測試腳本鏈接看到測試腳本每一步運行的詳細結果,包括測試步驟簡要描述、期望測試結果、實際測試結果等信息。測試人員通過詳細結果部分,可以很容易地分析出測試執(zhí)行失敗的原因。
自動測試框架中提供接口,測試人員只需提供QC的登錄信息和QTP工作目錄的絕對路徑,即可自動將多個QTP測試腳本連續(xù)上傳到QC,無須進行監(jiān)控。
高速公路收費軟件一般由車道收費、票據(jù)管理、卡管理、財務管理、圖片管理、參數(shù)管理、車道監(jiān)視管理、運行管理、稽查稽核管理、數(shù)據(jù)傳輸管理、清分結算管理和費率管理等模塊組成。
依據(jù)這些業(yè)務功能對其中可以執(zhí)行自動化測試的子模塊構建業(yè)務組件庫;針對每個子模塊識別對象庫,建立公用函數(shù)庫;依據(jù)業(yè)務流程建立對應的測試腳本,形成批量執(zhí)行列表;通過基于QTP的自動測試框架執(zhí)行自動化測試。
在實際使用了該框架進行項目測試后,發(fā)現(xiàn)這種框架設計非常有效。
1)減少了30%~50%甚至更多的腳本編寫工作量;系統(tǒng)越大,優(yōu)點越明顯。
2)后期維護難度和工作量在統(tǒng)一管理下大幅度下降。
3)減輕了測試管理服務器的壓力。針對所購買的QTP License較少的情況,通過框架的統(tǒng)一協(xié)調運行和管理,在很大程度上緩解了由于License有限帶來的時效性不高的問題。
圖2 業(yè)務功能的測試腳本結構
經(jīng)過對高速公路收費軟件的實際測試應用證明,基于QTP的智能交通軟件自動測試框架具有測試周期短、測試質量高等特點,有效地提高了軟件自動化測試中測試代碼的可重用性和可維護性。
[1] 黃文高.QTP自動化測試與框架模型設計[M].北京:機械工業(yè)出版社,2008.
[2] 陳能技.QTP自動化測試進階[M].北京:電子工業(yè)出版社,2010.