軟件測試模型的應(yīng)用研究及改進

摘要：介紹了軟件測試的幾種模型，包括V模型、W模型、H模型、X模型，這些模型定義了測試活動的流程和方法，為測試管理工作提供了指導，并且指出了上述測試模型的長處和局限性。針對傳統(tǒng)的模塊任務(wù)分配方式的不足，對模塊分配進行細化并結(jié)合X測試模型，根據(jù)實際開發(fā)情況對X測試模型進行了相應(yīng)的調(diào)整和改進。

關(guān)鍵詞：軟件測試；測試模型；模塊分配細化；軟件工程

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)31-1005-03

Research and Improvement of Software Testing Models

SUN Wen-ting

(Tongji University， Shanghai 201208， China)

Abstract: This paper introduces several models of software testing， including the V model， The W model， H model， X model， these models definition of the activities of the test procedures and methods for the management of the testing provide guidance. And it notes the length and limitation of these models. Based on the disadvantage of the traditional methods of modules allocation， the modules allocation is detailed and combined with the X testing model， The X testing model is improved according to the actual software development practice.

Key words: software testing; test model; modules allocation detailing; software engineering

1 引言

從保證軟件質(zhì)量的角度來說，軟件測試是軟件質(zhì)量保證工程的一個重要組成部分，也是最重要的質(zhì)量保證手段。有研究表明：越早發(fā)現(xiàn)軟件中存在的問題，開發(fā)費用越低，軟件質(zhì)量越高，軟件發(fā)布后的維護費用越低。為了保證所要提交的軟件產(chǎn)品能夠滿足客戶的需求，以及在使用中的可靠性，就必須對所開發(fā)的軟件產(chǎn)品進行系統(tǒng)而全面的測試。

2 軟件測試過程概述

軟件測試過程是一種抽象的模型，用于定義軟件測試的流程和方法。眾所周知，開發(fā)過程的質(zhì)量決定了軟件的質(zhì)量，同樣的，測試過程的質(zhì)量將直接影響測試結(jié)果的準確性和有效性。軟件測試過程和軟件開發(fā)過程一樣，都遵循軟件工程原理和管理學原理。

隨著測試過程管理的發(fā)展，軟件測試人員通過實踐總結(jié)出了很多的測試過程模型。這些模型將測試活動進行了抽象，并與開發(fā)活動進行了有機的結(jié)合，是測試過程管理的重要參考依據(jù)。

3 傳統(tǒng)的軟件測試過程模型

3.1 V模型

V模型最早是由Paul Rook在20世紀80年代后期提出的，旨在改進軟件開發(fā)的效率和效果。V模型反映出了測試活動與分析設(shè)計活動的關(guān)系，如圖1所示。圖1描述了基本的開發(fā)過程和測試行為，非常明確地標注了測試過程中存在的不同類型的測試以及這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。

V模型指出，單元和集成測試應(yīng)檢測程序執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達到系統(tǒng)要求的指標；驗收測試應(yīng)確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統(tǒng)設(shè)計等活動的驗證和確認的功能。

3.2 W模型

W模型由Evolutif公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進行的驗證和確認活動，如圖2所示。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，明確表示出了測試與開發(fā)的并行關(guān)系。

W模型強調(diào)測試伴隨整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計等同樣需要測試，也就是說，測試與開發(fā)是同步進行的。W模型有利于盡早、全面地發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與對需求的驗證和確認活動，盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快項目進度。

但W模型也存在局限性。在W模型中，需求、設(shè)計、編碼等活動被視為串行， 同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段結(jié)束后才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當前軟件開發(fā)復雜多變的情況，W模型并不能解除測試管理面臨的困惑。

3.3 H模型

V模型和w模型均存在一些不妥之處。如前所述，它們把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動，而事實上，這些活動在大部分時間內(nèi)是可以交叉進行的，所以，相應(yīng)的測試之間也不存在嚴格的次序關(guān)系。同時，各層次的測試(單元測試、集成測試、系統(tǒng)測試等)也存在反復觸發(fā)、迭代的關(guān)系。

為了解決以上問題，有專家提出了H模型。它將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執(zhí)行活動清晰地體現(xiàn)出來，如圖3所示。

圖3僅僅演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖3中標注的其他流程可以是任意的開發(fā)流程。例如，設(shè)計流程或編碼流程。H模型揭示了一個原理：軟件測試是一個獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備，盡早執(zhí)行。不同的測試活動可以按照某個次序先后進行，也可能是反復的，只要某個測試達到準備關(guān)鍵點，測試執(zhí)行活動就可以開展。

4 X測試過程模型及其改進

4.1 X測試過程模型

X測試模型的目標是彌補V測試模型的一些缺陷，如圖4所示。X測試模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執(zhí)行的程序(右上半部分)，這些可執(zhí)行程序還需要進行測試。已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。

在圖4中，X模型還定位了探索性測試(右下方)。這是不進行事先計劃的特殊類型的測試。這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤，X模型包含了測試設(shè)計的步驟，就像使用不同的測試工具所要包含的步驟一樣；X模型并不要求在進行作為創(chuàng)建可執(zhí)行程序(圖中右上方)的一個組成部分的集成測試之前，對每一個程序片段都進行單元測試(圖中左側(cè)的行為)。但X模型沒能提供是否要跳過單元測試的判斷準則。

4.2 X測試過程模型的改進

軟件開發(fā)過程中的變化性因素，包括需求變化、開發(fā)人員流動和技術(shù)更新等，一直是影響軟件質(zhì)量、開發(fā)進度和成本的主要因素之一。在傳統(tǒng)的軟件開發(fā)方法中，總希望前期調(diào)研分析工作做細、做完整，以減少在后期由于需求變動而帶來的開發(fā)成本增加，即盡可能把變化排除在開發(fā)進程之外。但在實際開發(fā)中，這只是一種理想狀態(tài)，需求變化是不可避免的。

傳統(tǒng)的軟件開發(fā)是獲取全部的系統(tǒng)需求之后，開始整個系統(tǒng)的模塊設(shè)計。而傳統(tǒng)的軟件系統(tǒng)結(jié)構(gòu)的總體設(shè)計是基于功能層次結(jié)構(gòu)建立系統(tǒng)：采用某種設(shè)計方法，將系統(tǒng)按功能劃分成模塊的層次結(jié)構(gòu)；確定每個模塊的功能；建立與已確定的軟件需求的對應(yīng)關(guān)系；確定模塊間的調(diào)用關(guān)系；確定模塊間的接口即模塊間傳遞的信息；評估模塊劃分的質(zhì)量及導出模塊結(jié)構(gòu)的規(guī)則。經(jīng)常采用自頂向下的方式。然后為每個模塊確定相應(yīng)的數(shù)據(jù)結(jié)構(gòu)、算法等，最后為程序員分配這些模塊，以一個醫(yī)藥管理信息系統(tǒng)為例，說明該傳統(tǒng)的模塊任務(wù)分配方式，如圖5所示。

這樣的分配就存在了一些不足之處。如只有等所有的模塊都設(shè)計完畢后，才能開始代碼實現(xiàn)，等待時間過長，容易使得開發(fā)人員和用戶感到疲倦和不耐煩；如果在這里總體模塊的劃分和設(shè)計存在不當?shù)脑挘瑒t會使得整個系統(tǒng)存在潛在不足，而這種潛在不足將會一直持續(xù)到系統(tǒng)完成的那個時刻，從而無法保證系統(tǒng)的正確性。我們可以發(fā)現(xiàn)，在一般的任務(wù)的分配上，每個開發(fā)成員都對應(yīng)到不同的模塊，負責自己模塊的詳細設(shè)計與實現(xiàn)，這樣一來，每個人都很獨立，只知曉自己負責的內(nèi)容，而對系統(tǒng)整體性了解不夠，對于將來系統(tǒng)的維護帶來了很多限制。

因此，可以利用場景分析技術(shù)對用戶故事進行獲取和分割，采用迭代周期實現(xiàn)，集中所有的人力去完成每個場景。例如，上文的醫(yī)藥管理信息系統(tǒng)中的基礎(chǔ)信息管理場景被分割成4個子場景，分別分配給不同的程序員，這樣即使每個人對應(yīng)的具體場景是不一樣的，實現(xiàn)的內(nèi)容并非完全相同，但由于都是關(guān)于基礎(chǔ)信息管理的功能實現(xiàn)，因此在彼此的任務(wù)理解上并沒有什么障礙，而且由于功能分配的細化，更加貼近實際需要；并且由于每個人都參與了系統(tǒng)的各個部分，對于系統(tǒng)的整體了解性更強了，便于將來系統(tǒng)的維護和擴充。圖6是細化模塊任務(wù)分配方式。

通過上述的分析可以看出，X測試模型具有測試的先行性，集成的頻繁持續(xù)性，變更的存在性等特征。但在具體的應(yīng)用中，由于模塊任務(wù)分配的細化，該X模型顯得過于粗略，存在一些不足之處。如未能反映出軟件測試中迭代特性；未能很好地體現(xiàn)出對變更的適應(yīng)性；未能表現(xiàn)軟件人員和客戶的互動合作性。因此，在X測試模型基礎(chǔ)上，本文提出了一些對X模型的改進來適應(yīng)模塊任務(wù)分配的細化，如圖7所示。

改進型的X測試模型把原模型的下半部分結(jié)合到上半部分，并作了相應(yīng)的變化。模塊劃分的原理仍大致遵循傳統(tǒng)的軟件工程方法，但在模塊任務(wù)的分配上則有所細化，即分配上突出模塊的相似性或相通性，因此該改進型測試模型中的程序片斷也具有這樣的特性。左邊各項工作如測試計劃、工具配置、測試執(zhí)行、代碼編寫都是由軟件人員采用結(jié)對開發(fā)的方式來完成，其中根據(jù)實際情況，結(jié)對的一方可由客戶來組成。集成后由軟件人員補充測試設(shè)計，由用戶編寫驗收測試，然后由雙方共同模擬相應(yīng)的運行環(huán)境來執(zhí)行測試。整個測試過程也是由多個迭代組成，直至發(fā)布。圖7中虛線表示變更及為適應(yīng)變更而作的改動。

5 結(jié)束語

本文介紹了幾種軟件測試模型，并進行了比較研究，總結(jié)了它們的長處和局限性。并且針對傳統(tǒng)的模塊任務(wù)分配方式的不足，細化模塊分配并結(jié)合X模型，提出了一種新的軟件測試模型，將在大量的測試應(yīng)用中，逐漸完善成為使用有效的模型。

參考文獻：

[1] 張海藩．軟件工程導論[M]. 北京：清華大學出版社， 2003.

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

[3] 軟件測試過程管理實踐介紹[EB/OL].[2008-07-02].http://www.cppblog.tom/mzty/archive/2006/05/19/7402.html.

[4] Myers G. The Art of Software Testing [M]. Newyork:Wiley，1979.

[5] Ian Sommerville．軟件工程[M]. 北京：機械工業(yè)出版社，2005.

[6] William E. Perry. 軟件測試的有效方法[M]. 2004.

[7] 李緯，陳嶷瑛．一種有效的軟件測試模型[J]. 計算機工程與應(yīng)用2004(10):114-115.

[8] Cem KanerJack Falk．計算機軟件測試[M].2版.北京：機械工業(yè)出版社，2004.

[9] MCGREOR JD， SYKES DA.面向?qū)ο蟮能浖y[M]. 楊文宏， 李新輝 譯. 北京: 機械工業(yè)出版社， 2002:30-43.