張永超，陶宏才

(西南交通大學 信息科學與技術學院，成都 610031)

在自動化測試執(zhí)行過程中，目前普遍采用多任務調度模型實現(xiàn)多個測試任務的并行執(zhí)行。傳統(tǒng)的多任務調度模型的核心思想是將任務和線程分離，抽象出實際工作的任務，并將它們映射到少量的線程上，這樣可以大大減少系統(tǒng)中運行線程的數(shù)目，從而降低線程切換開銷在整個系統(tǒng)資源消耗中所占比重[1]。不過，傳統(tǒng)多任務調度模型存在以下問題：

（1）由于每個測試腳本運行所需要的測試環(huán)境可能不一樣，因此腳本測試時不可避免地需要申請和釋放測試環(huán)境，從而帶來處于調度隊列不同位置而測試環(huán)境相同的測試腳本需要頻繁地申請和釋放測試環(huán)境，導致較大的環(huán)境切換開銷。

（2）傳統(tǒng)模型只實現(xiàn)了任務間的并發(fā)，不能完成任務內的并發(fā)，從而影響測試效率的提高。

為此，本文提出了一種新的多任務調度模型，旨在降低因執(zhí)行環(huán)境不同而帶來的線程切換開銷以及任務內測試腳本的并發(fā)執(zhí)行。實踐表明，新模型在支持大量并發(fā)任務場合具有較好的效果，極大地提高了自動化測試執(zhí)行效率。

1 新的多任務調度模型

1.1 傳統(tǒng)模型結構

傳統(tǒng)多任務調度模型的結構比較簡潔如圖1。主要涉及3個對象：任務對象、任務線程對象和任務調度線程對象。任務對象是對用戶提交運行任務的一種抽象，它包含要進行測試的測試腳本以及該任務運行所需的測試環(huán)境；任務線程對象則對應實際的線程，所有的任務由它負責執(zhí)行，每個任務線程對象都對應一個任務對象；任務調度線程對象負責管理所有的任務線程對象。在傳統(tǒng)的多任務調度模型中，任務調度線程對象會根據待執(zhí)行任務隊列是否為空來判斷是否需要進行調度。當待執(zhí)行任務隊列不為空時，任務調度線程對象就循環(huán)遍歷隊列中的每個任務線程對象，根據任務對象描述的測試環(huán)境進行測試環(huán)境的申請。如果申請成功，就運行該任務線程對象；如果申請不成功，就下移指針開始對下一個任務線程對象申請測試環(huán)境。當多個任務對象都申請環(huán)境成功，系統(tǒng)中就存在多個任務線程對象在同時運行，這樣就簡單實現(xiàn)了多個測試任務之間的并發(fā)執(zhí)行。但是在傳統(tǒng)的多任務調度模型中，每個提交運行的任務都被抽象成任務對象，并綁定到一個任務線程對象，每個任務線程對象都只對應一個測試環(huán)境，這樣就沒法實現(xiàn)任務內多個測試腳本之間的并發(fā)執(zhí)行。

圖1 傳統(tǒng)的多任務調度模型結構

1.2 新模型結構

為解決傳統(tǒng)模型的結構缺陷，本文提出了一種新的多任務調度模型，如圖2。

圖2 新的多任務調度模型結構

新的模型在原來結構的基礎上，引入了監(jiān)控線程對象和調度線程對象，并把實際的測試任務進一步抽象，根據測試任務中每個測試腳本所需測試環(huán)境的不同進行分組，抽象出作業(yè)線程對象，由它來負責運行具有相同測試環(huán)境的測試腳本，這樣就可以避免在運行測試環(huán)境不同的測試腳本時頻繁地申請和釋放測試環(huán)境，并可實現(xiàn)任務內不同測試腳本之間的并發(fā)執(zhí)行。監(jiān)控線程對象和調度線程對象的處理過程如下：

（1）每個任務都對應一個監(jiān)控線程對象。當用戶提交運行一個測試任務時，監(jiān)控線程對象就會掃描用戶提交的任務所包含的測試腳本，并根據其測試環(huán)境進行分組，一個測試環(huán)境對應一個或多個測試腳本。然后遍歷分過組的測試環(huán)境列表，申請對應的測試環(huán)境，如果申請成功，就根據該測試環(huán)境對應的測試腳本創(chuàng)建作業(yè)執(zhí)行片對象，然后通知調度線程對象準備創(chuàng)建新作業(yè)并調度執(zhí)行。如果沒有申請到環(huán)境，則移動到下一組測試環(huán)境進行環(huán)境申請。

（2）每個任務都對應一個調度線程對象。當調度線程對象收到監(jiān)控線程對象發(fā)送的創(chuàng)建新作業(yè)通知時，就會根據監(jiān)控線程對象創(chuàng)建的作業(yè)執(zhí)行片對象創(chuàng)建相應的作業(yè)線程對象，并將其與相應的作業(yè)對象進行綁定，之后把該作業(yè)對象添加到作業(yè)管理對象的作業(yè)對象列表中。調度線程對象會根據設定的時間間隔定期去查詢作業(yè)管理對象中是否有待執(zhí)行作業(yè)，如果有就開始調度執(zhí)行相應的待執(zhí)行作業(yè)線程。

2 新模型的實現(xiàn)

2.1 模型的實現(xiàn)類圖

新的多任務調度模型的實現(xiàn)類圖如圖3。

圖3 新模型的實現(xiàn)類圖

圖3 中，類SchedulerDetectorThread、SchedulerSchedulerThread和類JobThread都繼承自線程類Thread，分別對應圖2中的監(jiān)控線程、調度線程和作業(yè)線程。調度線程在新建作業(yè)對象時就把自身作為監(jiān)聽對象和作業(yè)對象關聯(lián)起來。當作業(yè)執(zhí)行完成或執(zhí)行異常時，作業(yè)對象就可以通過監(jiān)聽對象通知調度線程來做相應的處理。

2.2 任務間和任務內的并行實現(xiàn)

新模型繼承了傳統(tǒng)模型多個測試任務之間并行執(zhí)行的優(yōu)點，只要提交的測試任務對應的測試腳本有可以運行的測試環(huán)境，就可以運行任務。同時，新模型支持單個測試任務內多個作業(yè)線程的并行執(zhí)行，如圖4，因此能最大程度地利用測試環(huán)境，提高測試執(zhí)行效率，降低頻繁申請/釋放環(huán)境所帶來的系統(tǒng)開銷。

圖4 任務內的并行執(zhí)行

2.3 作業(yè)線程執(zhí)行結果的處理

新模型通過設置狀態(tài)碼的形式來告知調度線程對作業(yè)線程的執(zhí)行結果進行處理。作業(yè)線程執(zhí)行結果包括：JOB_COMPLETE_CODE（作業(yè)線程成功執(zhí)行完畢）、JOB_ERROR_CODE（作業(yè)線程執(zhí)行出錯，網絡、測試環(huán)境異?；蜃鳂I(yè)線程重新執(zhí)行次數(shù)超過最大值）、JOB_RETRY_CODE（作業(yè)線程執(zhí)行完畢，但其中存在測試失敗的用例，需要重新執(zhí)行失敗的用例）。調度線程對象會根據作業(yè)線程返回的結果狀態(tài)做如下處理：

（1）JOB_COMPLETE_CODE：通知監(jiān)控線程釋放相應的測試環(huán)境。

（2）JOB_ERROR_CODE：通知監(jiān)控線程釋放測試環(huán)境，并把測試環(huán)境標識為不可用。

（3）JOB_RETRY_CODE：通知監(jiān)控線程把剛才執(zhí)行失敗的測試腳本新建一個分組添加到待測試隊列中，等待調度執(zhí)行，如圖4的分組7。

當然，實際應用中，可以根據具體情況在模型中添加其它類型的狀態(tài)碼，來標識作業(yè)線程的執(zhí)行結果，并通知調度線程做相應的處理。

3 新模型的應用

下面以一個自動化測試工廠為例來說明該模型的應用。采用本模型的自動化測試工廠的主要工作是自動調度運行測試用戶提交的測試任務，根據測試腳本運行環(huán)境的不同申請對應的測試環(huán)境，把測試腳本發(fā)送給相應的測試環(huán)境執(zhí)行。測試腳本執(zhí)行完成后，工廠自動保存測試腳本的執(zhí)行結果，并將任務的運行結果通過郵件的方法反饋給測試用戶。

假設測試用戶通過自動化工廠客戶端創(chuàng)建提交了一個包含100個測試腳本的測試任務，每個測試腳本都對應一個測試環(huán)境文件，并在測試實驗室中存在相應的測試環(huán)境。那么自動化工廠引入該模型后對該任務的處理流程如下：

（1）系統(tǒng)通過單件模式生成一個任務管理對象（SchedulerTaskManager），負責統(tǒng)一管理系統(tǒng)中所有的監(jiān)控線程和調度線程。

（2） 任務管理對象根據任務的唯一標識創(chuàng)建一個測試任務對象（SchedulerTask）。同時，該測試任務對象會創(chuàng)建調度線程對象（Scheduler-SchedulerThread）和監(jiān)控線程對象（Scheduler-DetectorThread）。

（3）任務管理對象啟動監(jiān)控線程和調度線程，監(jiān)控線程啟動后開始掃描測試任務相關的測試腳本并按照其測試環(huán)境進行分組，創(chuàng)建待測試分組隊列，掃描隊列中的每個分組，為每個分組申請測試環(huán)境。如果申請成功，則創(chuàng)建JobExcutePiece類的一個作業(yè)執(zhí)行片對象，并通知調度線程準備創(chuàng)建新作業(yè)；如果申請失敗，則下移隊列指針，對下一個分組申請測試環(huán)境。調度線程啟動后執(zhí)行步驟（5）。

（4）調度線程在收到監(jiān)控線程發(fā)送的準備創(chuàng)建新作業(yè)消息后，首先創(chuàng)建作業(yè)管理對象，該對象用于保存所有運行的作業(yè)對象。然后，根據申請到環(huán)境的作業(yè)執(zhí)行片創(chuàng)建作業(yè)線程對象（Job-Thread），并綁定到作業(yè)對象（Job）。最后，調度線程把作業(yè)對象添加到作業(yè)管理對象中。

（5）調度線程開始檢查作業(yè)管理對象中是否有待執(zhí)行作業(yè)。如果沒有，則循環(huán)等待直到作業(yè)管理容器中有待執(zhí)行作業(yè)對象；如果作業(yè)管理對象中有待執(zhí)行作業(yè)，則調度線程開始啟動作業(yè)線程執(zhí)行測試。

（6）作業(yè)線程執(zhí)行完或執(zhí)行過程中出現(xiàn)異?；蝈e誤，作業(yè)對象通過監(jiān)聽接口通知調度線程。

（7）監(jiān)控線程在收到調度線程發(fā)送的作業(yè)執(zhí)行情況消息后，根據作業(yè)的執(zhí)行情況做出相應的處理。

（8）循環(huán)以上步驟，直至所有作業(yè)線程都執(zhí)行完畢。

（9）所有作業(yè)執(zhí)行完畢后，自動化工廠通過郵件方式把任務的執(zhí)行結果發(fā)送給測試人員。

4 結束語

本文提出的自動化測試的多任務調度模型，本質上就是一個面向應用的用戶級的線程庫，因此繼承了用戶級線程庫低開銷的優(yōu)點。調度模型以減少系統(tǒng)申請釋放測試環(huán)境額外開銷和實現(xiàn)任務內測試腳本并行執(zhí)行為出發(fā)點，對傳統(tǒng)的多任務調度模型進行了改進，使其適用于自動化測試環(huán)境，是一種比較實用的多任務調度模型。作為一種抽象的軟件結構模型，它在需要同時開啟大量任務的自動化測試場合具有很強的實用性。

[1]胡 寧，張德運，史宏鋒. 一種低開銷的多任務調度模型[J]. 微電子學與計算機，2005.

[2]崔啟亮，胡一鳴. 國際化軟件測試[M]. 北京：電子工業(yè)出版社，2006.

[3]K. Mustafa, R. A. Khan. 軟件測試：概念與實踐[M]. 北京：科學出版社，2009.

[4]趙 斌. 軟件測試技術經典教程[M]. 北京：科學出版社，2007.

[5]Srinivasan Desikan, Gopalaswamy Ramesh. 軟件測試原理與實踐[M]. 北京：機械工業(yè)出版社，2009.

[6]陳汶濱，朱小梅，任冬梅. 軟件測試技術基礎[M]. 北京：清華大學出版社，2008.