迭代模式中基于可復(fù)用構(gòu)件的自動化測試框架研究

張燕華，賈永娜

（1.西藏民族學(xué)院信息工程學(xué)院，陜西 咸陽 712082；2.思特沃克軟件技術(shù)（北京）有限公司，北京 100007）

0 引 言

迭代開發(fā)模式相對于傳統(tǒng)的開放模式，具有可以控制項目風(fēng)險、允許需求變動、保證項目開放進度等優(yōu)點，使其在軟件項目開發(fā)，尤其是商業(yè)軟件項目開發(fā)中得到了廣泛的應(yīng)用[1]。目前雖然大規(guī)模的軟件項目開發(fā)都采用迭代的開發(fā)模式來降低項目風(fēng)險，但是還沒有形成一套完整的關(guān)于迭代開發(fā)模式下自動化測試的理論和方法。為打破這種軟件測試技術(shù)和理論落后于軟件開發(fā)的現(xiàn)狀，對迭代開發(fā)模式下的自動化測試技術(shù)的研究就非常有必要。

為降低測試腳本的維護開銷，使自動化測試在迭代開發(fā)模式下更加有效，把構(gòu)件復(fù)用技術(shù)、分離邏輯和實現(xiàn)等知識應(yīng)用到軟件的自動化測試框架設(shè)計之中，提出了迭代模式中基于可復(fù)用構(gòu)件的自動化測試框架（automation test framework based on reused component in iterative model，AFRI）。AFRI借鑒了現(xiàn)有測試框架的優(yōu)點，提出了更加適合迭代開發(fā)模式的測試流程和設(shè)計方法，吸收復(fù)用技術(shù)、分離邏輯和實現(xiàn)以及測試數(shù)據(jù)與測試腳本等思想，提高了測試框架的復(fù)用性、可維護性，降低了后期的開發(fā)和維護成本。

1 迭代模式中基于可復(fù)用構(gòu)件的自動化測試框架設(shè)計

在迭代開發(fā)模式中，往往把整個項目分解為多個階段性的小迭代。尤其是在需求變化快、工期緊的商業(yè)軟件開發(fā)環(huán)境中，每次迭代之后，都要進行全面的測試[2-4]。所以，測試工作成為迭代開發(fā)項目整體質(zhì)量和進度控制的關(guān)鍵點。測試工作的每個環(huán)節(jié)都要有很好的繼承性和可復(fù)用性，而復(fù)用技術(shù)按照可復(fù)用的抽象程度，可以分為代碼復(fù)用、設(shè)計的復(fù)用、分析的復(fù)用、測試信息的復(fù)用4個級別。

本文提出的可復(fù)用技術(shù)涉及測試過程中的許多環(huán)節(jié)，例如對測試用例和測試數(shù)據(jù)的復(fù)用，以及對自動化測試框架中測試腳本的復(fù)用，這都是為了與迭代開發(fā)模式的特性保持一致。

1.1 AFRI的系統(tǒng)結(jié)構(gòu)分析

迭代模式中基于可復(fù)用構(gòu)件的測試框架AFRI主要分為元素層、管理層、腳本層、集成層4層，其結(jié)構(gòu)示意如圖1所示。

圖1 AFRI系統(tǒng)結(jié)構(gòu)圖

1.1.1 元素層

該層的主要作用是建立測試腳本和待測程序中界面元素之間的聯(lián)系。通過把實際的界面元素抽象到元素層，可以使測試人員通過調(diào)用元素層中的對象，來操作待測程序中的界面元素，從而實現(xiàn)工作分工。如果開發(fā)和測試遵守統(tǒng)一的界面標準，則在每次迭代的過程中，軟件開發(fā)和界面元素的提取工作可以同時進行。當待測程序界面有所改動時，只要改動元素層中被改動的界面元素對象就可以很快地適應(yīng)新的需求。

1.1.2 管理層

管理層的作用是為元素層中的對象定義相應(yīng)的操作接口，例如：對dropdownlist的點擊，以及對其中item的選擇動作；對文本編輯框的輸入、粘貼、刪除、全選等編輯動作。管理層的接口與元素層對象相互對應(yīng)，每個元素都應(yīng)該有自己的操作管理集合，但不一定是一對一的關(guān)系，要根據(jù)具體情況對管理層的操作接口進行分類，權(quán)衡每個管理集合的操作范圍和種類。管理接口完成后，可在后期的測試工作中得到復(fù)用。由于每種界面元素的操作方式是一定的，即管理層提供的接口是固定的，腳本層中不同的測試腳本可能會操作同一個界面元素，這種重復(fù)的操作通過復(fù)用管理層中相應(yīng)的操作接口即可完成。

1.1.3 腳本層

腳本層的作用是根據(jù)前期設(shè)計好的測試用例，完成對被測軟件的功能和業(yè)務(wù)邏輯的驗證。腳本層包括測試數(shù)據(jù)、場景測試腳本和測試結(jié)果驗證腳本3部分。測試數(shù)據(jù)集合不但要提供測試腳本需要的輸入數(shù)據(jù)，同時也要提供測試結(jié)果校驗數(shù)據(jù)。一個場景測試腳本只是完成一個特定的測試場景。整個過程中，測試腳本從測試數(shù)據(jù)文件內(nèi)，讀取測試數(shù)據(jù)，然后調(diào)用管理層中操作相關(guān)界面元素的管理接口，完成測試用例所描述的操作序列，最后通過測試結(jié)果校驗?zāi)_本對測試結(jié)果進行校驗。

1.1.4 集成層

集成層的主要功能是根據(jù)不同測試階段的測試目的集成不同的測試腳本。例如：冒煙測試，只需要從宏觀上驗證被測程序的基本功能，其對應(yīng)的測試腳本集合相對較小，可設(shè)為{a1，a2，a3，a4，…，ak}；而集成測試需要驗證被測程序各個功能模塊集成后的功能和性能，其測試腳本集合除了要包含每個模塊的功能測試腳本外，還要包含驗證各個模塊之間接口的功能測試腳本，可以設(shè)為{a4，a5，a6，…ak，…an}，且有 n＞k，但同時，這兩個測試集合都有共同的測試腳本集合{a4，a5，a6，…ak}，所以不需要重復(fù)的開發(fā)測試腳本{a4，a5，a6，…ak}，只需要根據(jù)不同的測試目的，從腳本層中選擇需要的測試腳本組成測試腳本集合。由此可見，腳本層在后期的測試工作中也得到了復(fù)用。

1.2 AFRI的測試流程

測試的實施過程要從需求說明書開始[5]。根據(jù)需求說明書設(shè)計軟件功能說明，然后制定測試計劃、設(shè)計測試用例、開發(fā)測試腳本，最后進行集中測試和缺陷管理。在迭代開發(fā)模式中，測試工作也是迭代進行的。基于AFRI系統(tǒng)進行測試的流程如圖2所示。

圖2 基于AFRI的測試流程圖

1.3 迭代中測試用例的生成算法

迭代開發(fā)過程中，軟件的功能說明和用戶需求，隨著每次的迭代而逐漸完善和增加，而在迭代比較頻繁的開發(fā)中，需求的變動也是經(jīng)常的；所以，測試用例的可復(fù)用性也至關(guān)重要[6-7]。本文針對迭代開發(fā)中以功能界面為基礎(chǔ)的特點，提出了以被測軟件界面元素為基本單位，基于UML順序圖模型的測試用例生成方法。該方法不但能夠在每次的迭代中復(fù)用前期迭代中產(chǎn)生的界面組件，還可以復(fù)用該界面組件對應(yīng)的測試數(shù)據(jù)。

在順序圖中，場景被定義為在相互交互的對象間傳遞的一個消息序列[8]，每個消息序列代表用例的一個可能的事件流。在順序圖中可以詳細地說明前置條件和后置條件，以及一個消息序列涉及到的參數(shù)，如界面元素，而這些參數(shù)序列又可以產(chǎn)生一個或多個描述測試場景的有向無環(huán)圖。例如，一個成績錄入系統(tǒng)中，老師登陸系統(tǒng)，并更改某個學(xué)生成績的操作序列，可以用如圖3所示的UML順序圖表示。

圖3 更改成績操作順序圖

基于UML順序圖生成測試用例的過程包括：按照功能說明畫出完整的順序圖（包括前置條件、后置條件、約束條件、消息序列，以及參數(shù)等信息），根據(jù)順序圖中的信息得到所有測試場景有向無環(huán)圖（尤其是每個消息序列中，每個參數(shù)所對應(yīng)的測試數(shù)據(jù)），采用兩因素組合覆蓋的方式遍歷整個測試場景有向無環(huán)圖，最后生成測試用例。由圖3的部分操作信息所生成的測試場景有向無環(huán)圖如圖4所示。

圖4主要描述了圖3中的login和search事件所生成的測試場景的有向無環(huán)圖，主要驗證login和search的功能點。對于change和browse事件的測試場景生成方法是完全相同的。圖中節(jié)點分為4類：1，0，-1，-2，分別對應(yīng)該層界面元素可以選取的 4種測試數(shù)據(jù)集合，其中只有1代表有效的測試數(shù)據(jù)。樹的每一層都描述了一個界面元素所對應(yīng)的測試數(shù)據(jù)，而對于按鈕節(jié)點，只有在前面的輸入信息組件中輸入有效的數(shù)據(jù)才可以通過，其他無效的輸入都不會通過按鈕節(jié)點到達下一層。例如，對于password層，只有有效數(shù)據(jù)1連接到下一層，而無效數(shù)據(jù)-1和空值0都不可能成功登陸，所以沒有一條連到下層的線段。這樣，就可以過濾掉無效輸入數(shù)據(jù)所產(chǎn)生的組合序列，從而大大減少測試用例集合中有效測試用例的數(shù)量。

圖4 相應(yīng)測試場景的有向無環(huán)圖

2 基于AFRI進行測試的收益分析

以某軟件公司的軟件M為測試對象，驗證了AFRI的可行性。采用Douglas Hoffman所提出的自動化收益分析方法，充分考慮到了除了測試工作之外的其他額外花銷。

式中：ΔBa——自動化測試相對于手工測試的額外回報。

ΔCa——自動化測試相對于手工測試的額外支出。

使用AFRI系統(tǒng)進行自動化測試的收益情況，可以通過圖5直觀地表示。

從圖5中可以看出，使用AFRI系統(tǒng)進行自動化測試在第一次發(fā)布時，收益為0.7712，入不敷出，還沒有收益；但在后面的迭代過程中，自動化測試表現(xiàn)出了較好的效益，而且隨著自動化測試復(fù)用次數(shù)的增加，效益逐漸增加，并趨于平緩。這說明使用AFRI系統(tǒng)進行自動化測試，可以在后期的迭代中得到更高的收益，尤其是測試構(gòu)件復(fù)用率高、功能需求變動較少的情況。但在測試腳本變的龐大時，收益的增長幅度就變小了，這是由后期的測試腳本維護量變大、自動化測試固定支出增多等原因造成的。框架設(shè)計開發(fā)活動是一個迭代的、逐步遞增的過程，好的框架一般是多次迭代及辛苦努力的結(jié)晶。要得到更好的收益，需要根據(jù)具體的測試環(huán)境進行多次的迭代開發(fā)和改進。

圖5 基于AFRI的自動化測試收益分析圖

3 結(jié)束語

AFRI為自動化測試提供了一個有效框架，尤其是對迭代開發(fā)模式中的自動化測試工作具有較強的理論價值和實際意義。通過測試過程中得到的實際測試數(shù)據(jù)，使用目前成熟的自動化測試收益分析方法，證明了迭代開發(fā)模式中AFRI系統(tǒng)進行自動化測試收到了很好的效益，可以達到一次開發(fā)、長期收益的效果。

[1]Paul C J.軟件測試[M].北京：機械工業(yè)出版社，2003.

[2]朱菊，王志堅，楊雪.基于數(shù)據(jù)驅(qū)動的軟件自動化測試框架[J].計算機技術(shù)與發(fā)展，2006，16（5）：68-70.

[3]古樂，史九林.軟件測試技術(shù)概論[M].北京：清華大學(xué)出版社，2004：216-217.

[4]Chen J J， Subramaniam S， GUI A.Environment to manipulate FSMs for testing GUI-based applications in java [C]∥Proceedings of the 34th Hawaii International Conference on System Sciences，2001：1-10.

[5]Burnstein I，Suwanasart T，Carlson C.Developing a testing maturity model：Part I[J].Journal of Defense Software Engineering，1996，9（8）：21-24.

[6]Kuhn D R，Reilly M J.An investigation of the applicability of design of experiments to software testing[C]∥Proceedings of the 27th Annual NASA Goddard/IEEE Software Engineering Workshop，2003：4-6.

[7]黃雨田，聶麗琴，段富，等.用例需求分析技術(shù)的應(yīng)用[J].太原理工大學(xué)學(xué)報，2005，36（2）：224-227.

[8]飛思科技產(chǎn)品研發(fā)中心.實用軟件測試方法與應(yīng)用[M].北京：電子工業(yè)出版社，2003.