基于TMap的軟件測試模型的分析研究

張麗+趙衛(wèi)東+馮超男

摘要：針對傳統(tǒng)軟件測試模型不能滿足軟件開發(fā)過程需要的狀況，分析傳統(tǒng)軟件測試模型不夠靈活和完備的現(xiàn)狀，提出一種改進(jìn)的基于TMap的軟件測試模型。該結(jié)構(gòu)化的軟件測試模型改善了傳統(tǒng)測試模型的限制和不足，并能以一種可控制的方式，使軟件測試者對軟件系統(tǒng)的狀態(tài)和相關(guān)風(fēng)險有持續(xù)的認(rèn)識。

關(guān)鍵詞：TMap軟件測試管理方法；V模型；W模型；X模型；軟件測試

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2016）10-0113-03

Abstract： In view of the situation that the traditional model of software testing can not meet the health needs of the software development process， and traditional software testing model is not flexible enough and complete. So the article puts forward an improved TMAP software testing model. The structured software testing model improves the limitation and deficiency of the traditional test model， and it enables software testers on the state of the software system and the risks associated with a continued awareness.

Key words： TMap software test management method； V model； W model； X model； software testing life cycle

1 背景

近年來，以測試為驅(qū)動的軟件質(zhì)量保障技術(shù)在軟件開發(fā)中得到廣泛的應(yīng)用。測試是保證軟件產(chǎn)品正確性和提高軟件可靠性的最基本和最重要的手段之一，它已不僅僅是軟件產(chǎn)品開發(fā)成型之后的附加行為而是伴隨在整個軟件開發(fā)生命周期中的重要過程。軟件的失效可能造成巨大的經(jīng)濟(jì)損失。例如，1996年Ariane5運載火箭的發(fā)射失敗都是由軟件故障引起的[1-2]。

在測試中，如何更早地發(fā)現(xiàn)缺陷，用最小的成本、徹底的、有效地完成測試任務(wù)，以減少軟件發(fā)布后的成本支持，這就需要建立一個良好可靠的測試模型。于是各種軟件測試模型被提出，主要有V模型、X模型和W模型，這些傳統(tǒng)的測試模型都有自己的優(yōu)點但也存著著一些限制和不足，還不能完全滿足軟件測試的需要，為了彌補(bǔ)傳統(tǒng)測試模型的不足，TMap（Test Management Approach，軟件測試管理方法）應(yīng)運而生。目前，這個過程已被ISTQB（International Software Testing Qualification Board，國際軟件測試資本認(rèn)證委員會）所采用，成為了測試過程的標(biāo)準(zhǔn)。為了提供更加靈活的測試模型，本文對TMap軟件測試管理方法進(jìn)行歸納總結(jié)，抽象出適合當(dāng)今軟件開發(fā)需要的基于TMap的軟件測試模型。

2 傳統(tǒng)的軟件測試模型缺陷分析

軟件測試模型起到指導(dǎo)軟件測試過程框架的作用[3]。著名的V模型是20世紀(jì)80年代后期Paul Rook提出的著名的軟件測試模型，旨在改進(jìn)軟件開發(fā)的效率和效果[4]。它在傳統(tǒng)的瀑布模型軟件開發(fā)過程中增加了測試活動，并把它作為編碼之后的一個階段，但對測試的過程沒有進(jìn)一步描述。其主要針對瀑布模型對測試過程進(jìn)行了補(bǔ)充，它的價值就在于它非常明確的闡明了測試過程中所存在的不同級別，并且很清楚地描述了這些級別和開發(fā)過程中各個階段的一一對應(yīng)關(guān)系。但V模型也存在許多不足之處：容易導(dǎo)致在需求階段就存在的錯誤一直到最后測試時才被發(fā)現(xiàn)，無形中增加了軟件開發(fā)的成本；V模型沒有明確的指出測試的時機(jī)和規(guī)劃，越來越多的開發(fā)案例說明越早的進(jìn)行測試設(shè)計，就越能避免軟件開發(fā)初期的問題擴(kuò)散到整個系統(tǒng)當(dāng)中，V模型違背了越早發(fā)現(xiàn)錯誤越有利的原則[5]。

W模型是Evolutif公司針對V模型的缺陷提出的一種改進(jìn)的測試模型。它強(qiáng)調(diào)測試過程和開發(fā)過程同時開始同時結(jié)束，并且開發(fā)和測試相互依賴。前期，測試過程更多的依賴開發(fā)過程，后期，開發(fā)過程更多的依賴測試過程。W模型，盡管已經(jīng)改善了V模型存在的一些不足，但不論是W模型還是V模型，都只適用于那些需求非常明確且已經(jīng)文檔化了的項目，測試人員需要根據(jù)嚴(yán)格定義好的需求和設(shè)計來進(jìn)行工作。但是在實際開發(fā)過程中，開發(fā)中因為需求變化等原因，開發(fā)人員實際上并沒有按照文檔的要求來工作，也就是說文檔沒有根據(jù)需求的變化及時更新，更或者有時候在一些開發(fā)流程不規(guī)范的公司，根本就沒有文檔。在上述情況下，V模型和W模型在實施起來都是很困難的。此外，這兩種模型都把軟件的開發(fā)過程看作計劃、設(shè)計、編碼、測試等一系列的串行活動。但事實上，大部分時間這些活動是互相獨立的，也就是說這些活動是可以并發(fā)進(jìn)行的。雖然軟件開發(fā)流程期望有清晰的設(shè)計和編碼等階段，但實際的軟件開發(fā)經(jīng)驗告訴我們，清晰的階段之分只是一種理想的狀況。

X模型也是一種對V模型的改進(jìn)方法，其缺陷在于：沒有明確指出在軟件測試的每個階段都應(yīng)該進(jìn)行測試；沒有像V模型那樣有明確的需求角色確認(rèn)；X模型并不要對每一段程序都進(jìn)行單元測試，也不像V模型那樣有很明確的固定的邊界，但是X模型沒能提供不進(jìn)行單元測試的判斷準(zhǔn)則；X模型過于關(guān)注低級別的即程序級別的行為，而沒有形成一個系統(tǒng)的模型。

3 TMap測試管理模型的提出及應(yīng)用

TMap測試管理模型，改善了傳統(tǒng)軟件測試模型的弊端，提出了一個完整的、一致的、靈活的方法?？梢愿鶕?jù)特定環(huán)境創(chuàng)建量身定制的測試方法，以及在不同的特定環(huán)境中可以采用的通用方法，從而適合于各種行業(yè)以及各種規(guī)模的組織。

3.1 TMap的測試生命周期

TMap描述的軟件測試生命周期共分為五個階段：計劃和控制階段、準(zhǔn)備階段、說明階段、執(zhí)行階段和完成階段。其生命周期模型如圖1所示。

圖1 TMap描述的生命周期模型

3.1.1 計劃和控制階段

計劃和控制階段涉及測試計劃的創(chuàng)建，定義了測試活動的相關(guān)內(nèi)容。計劃階段中的活動是建立易于管理和高質(zhì)量的測試過程的基礎(chǔ)。這是一個非常重要的測試階段，然而在實際測試過程中它的重要性卻總是被低估。在這個階段，需要根據(jù)風(fēng)險分析過程來制定測試策略、測試估算和策劃。接下來需要確定所使用的測試技術(shù)，以便選擇適當(dāng)?shù)臏y試覆蓋率并盡量使其達(dá)到最優(yōu)。然后，可以對測試組織人員和測試基礎(chǔ)設(shè)施進(jìn)行初始規(guī)劃。

通常一些測試過程很少能夠按照計劃被執(zhí)行。因此，必要時必須對測試計劃的執(zhí)行進(jìn)行監(jiān)控和調(diào)整。這就是控制階段的工作。在控制階段所有測試活動的目的是以最優(yōu)的方式控制和報告測試過程，以測試人員能夠?qū)y試過程的進(jìn)度和質(zhì)量以及測試對象的質(zhì)量有深入的了解和良好的控制。

軟件測試過程中測試人員需要對測試過程、基礎(chǔ)設(shè)施和測試產(chǎn)品進(jìn)行管理，并使用測試過程中收集到的數(shù)據(jù)進(jìn)行趨勢分析。同時，也要確保能夠及時獲得與測試相關(guān)的開發(fā)過程信息，如開發(fā)中的延遲、將要進(jìn)行的較大規(guī)模變更以及項目調(diào)整等。

3.1.2 準(zhǔn)備階段

測試依據(jù)的可測試性評審是在準(zhǔn)備階段中完成的。這一階段的目標(biāo)是使測試依據(jù)的質(zhì)量能夠滿足測試設(shè)計的要求。此外，在項目早期對測試依據(jù)進(jìn)行可測性評審能夠提高質(zhì)量，并減少后期發(fā)現(xiàn)缺陷而付出的高額代價。因為，開發(fā)人員要基于系統(tǒng)文檔（測試依據(jù)的一部分）進(jìn)行系統(tǒng)開發(fā)，而這些系統(tǒng)文檔可能會存在一些錯誤，如果這些錯誤沒有被及時發(fā)現(xiàn)的話，將會導(dǎo)致大量修正工作（通常需要付出高額代價）。在開發(fā)過程中，錯誤越早被發(fā)現(xiàn)，修復(fù)的工作越容易（代價越小）。

3.1.3 說明階段

說明階段涉及定義測試用例和構(gòu)建基礎(chǔ)設(shè)施。這樣做的目的是盡可能的多做準(zhǔn)備，從而當(dāng)開發(fā)團(tuán)隊提供測試對象后，可以盡可能快地執(zhí)行測試。一旦測試依據(jù)的可測試性評審結(jié)束后，這階段的活動便可以開始進(jìn)行。測試說明活動可以與軟件的實現(xiàn)同時進(jìn)行或者在差不多的時間段內(nèi)進(jìn)行。

3.1.4 執(zhí)行階段

執(zhí)行階段的目的是通過執(zhí)行已商定的測試用例來深入了解測試對象的質(zhì)量。真正的測試執(zhí)行是在測試對象交付到測試團(tuán)隊的時間點開始的。首先要對測試對象的完整性進(jìn)行檢查。然后，將測試對象安裝在測試環(huán)境中來評估其功能是否滿足需求。

上述的活動通?？梢杂傻谝惠啘y試進(jìn)行確認(rèn)，即所謂的預(yù)測試。預(yù)測試是結(jié)合測試基礎(chǔ)架構(gòu)，對被測對象進(jìn)行的一個整體檢查，以確認(rèn)被測對象的質(zhì)量是否達(dá)到進(jìn)行深入測試的要求。進(jìn)行預(yù)測試之前要滿足主測試前置條件，接下來可以依據(jù)在設(shè)計階段建立的測試腳本來執(zhí)行測試，并且本測試活動執(zhí)行之前需要滿足執(zhí)行測試腳本所需的前置條件。測試執(zhí)行階段還包括對測試結(jié)果的驗證，通常以缺陷報告的形式記錄預(yù)期結(jié)果和實際結(jié)果之間的差異。

3.1.5 結(jié)束階段

在重復(fù)進(jìn)行的過程中應(yīng)用TMap結(jié)構(gòu)化測試方法可以帶來許多好處。它可以促進(jìn)測試成果物在后續(xù)測試過程中的復(fù)用以及加速一些測試活動。測試產(chǎn)品可以是有形的東西——測試件，如測試用例或測試環(huán)境，也可以無形的東西——過程評估，如對經(jīng)驗的總結(jié)。

當(dāng)保存測試件時，需要從大量測試件中選擇適合的內(nèi)容進(jìn)行保存。測試件主要包括測試用例、 測試腳本和測試基礎(chǔ)架構(gòu)說明等。在測試過程中，要保證測試用例與測試依據(jù)、測試對象保持一致。如果不能做到上述的要求，可規(guī)劃測試件的保存優(yōu)先順序，通常測試用例的優(yōu)先級最高。

測試過程的評估也是在這一階段中進(jìn)行。這樣做的目的是學(xué)習(xí)經(jīng)驗，并將這些經(jīng)驗教訓(xùn)應(yīng)用在新的測試中。測試過程的評估還可以作為測試主管編制最終報告的輸入項（最終報告的編制屬于控制階段的活動）。

3.2 TMap生命周期模型的好處

3.2.1 結(jié)構(gòu)化測試方法

在傳統(tǒng)的非結(jié)構(gòu)化的軟件測試過程中，可能會經(jīng)常出現(xiàn)一些問題：兩個及以上的數(shù)據(jù)集單獨評估時會產(chǎn)生一個結(jié)果，而聯(lián)合起來進(jìn)行評估時會產(chǎn)生一個相反的結(jié)果[6]。當(dāng)測試人員使用測試生命周期模型對測試過程保持整體認(rèn)識時，這種現(xiàn)象就很少會發(fā)生。而作為一個好的結(jié)構(gòu)化測試方法，TMap可以帶來如下好處：

1）能夠針對被測軟件的質(zhì)量風(fēng)險提供深入認(rèn)知和建議；

2）能夠在早期發(fā)現(xiàn)缺陷；

3）能夠預(yù)防缺陷；

4）能夠使測試過程盡量短的占據(jù)整個開發(fā)過程的關(guān)鍵路徑，從而縮短了軟件開發(fā)的交付時間；

5）能夠?qū)y試產(chǎn)品（如測試腳本和測試用例）進(jìn)行復(fù)用建立清晰的測試過程，能夠使時間、成本和質(zhì)量的管理保持一致性和標(biāo)準(zhǔn)化，所有參與測試的人員將使用同樣的測試語言。

3.2.2 不必嚴(yán)格按照時序方式執(zhí)行各個測試階段

TMap軟件測試模型只有執(zhí)行階段占據(jù)項目的關(guān)鍵路徑，其他階段的所有活動都可以避開關(guān)鍵路徑執(zhí)行。并且當(dāng)計劃、準(zhǔn)備和設(shè)計階段的工作越充分時，測試執(zhí)行階段所需要的時間越少。生命周期模型的形狀（平行四邊形）意味著測試的各個階段不必以嚴(yán)格的時序方式執(zhí)行，不同測試階段可以出現(xiàn)時間重疊或同步進(jìn)行的情況。

3.2.3 TMap測試模型可以與開發(fā)生命周期配合使用

軟件產(chǎn)品從形成概念開始，經(jīng)過開發(fā)、使用和維護(hù)，直到最后退役的全過程是軟件的生命周期[7]。TMap測試生命周期與軟件開發(fā)生命周期之間的關(guān)系取決于所應(yīng)用的軟件開發(fā)方法和相關(guān)測試級別。然而，有兩個“固定”時間點有助于確定測試生命周期和開發(fā)生命周期的關(guān)系。一個是準(zhǔn)備階段的開始時間點與獲得測試依據(jù)的時間點的對應(yīng)關(guān)系；另一個是執(zhí)行階段的開始時間點與獲得測試對象的時間點的關(guān)系。因此，TMap測試模型可以與軟件的開發(fā)生命周期配合使用，使測試更加靈活。

4 結(jié)束語

基于模型的軟件測試在學(xué)術(shù)界和軟件工業(yè)界都得到了重視，并得到越來越廣泛的應(yīng)用。軟件測試模型是對軟件行為和軟件結(jié)構(gòu)的抽象描述，可以用于生成測試用例，進(jìn)行測試失效辨識，從而有效提高測試效率，并有利于測試結(jié)果評價。基于TMap的軟件測試模型還需要要在以下幾個方面進(jìn)行深入研究：

1）對基于TMap的軟件測試模型本身的研究一方面要針對專用TMap測試模型進(jìn)行抽象獲取通用模型，另一方面也要對不同類型軟件開發(fā)專用的TMap測試模型。模型的研究包括理論和應(yīng)用兩方面，在理論方面要加強(qiáng)形式化描述的準(zhǔn)確性和統(tǒng)一性，在應(yīng)用方面應(yīng)該尋找能建立更加完備的基于TMap的測試用例的方法，提高測試的準(zhǔn)確性。

2）測試的自動化，基于TMap的軟件測試模型不能自動生成測試用例。這與TMap軟件測試生命周期的靈活性相關(guān)，在未來要完善這種軟件測試模型的結(jié)構(gòu)性從而可以自動生成測試用例。

參考文獻(xiàn)：

[1] 齊志昌， 譚慶平， 寧洪. 軟件工程[M]. 北京： 高等教育出版社， 2001.

[2] 周濤. 航天型號軟件測試[M]. 北京： 宇航出版社， 1999.

[3] 余久久， 張佑生. 軟件測試改進(jìn)模型研究進(jìn)展[J]. 計算機(jī)應(yīng)用與軟件， 2012（11）.

[4] 朱少民. 軟件測試方法和技術(shù)[M]. 2版.北京： 清華大學(xué)出版社， 2010： 66-70.

[5] Roger S Presma. 軟件工程實踐者的研究方法[M]. 4版. 北京：機(jī)械工業(yè)出版社，2000：312-356.

[6] 王艷軍， 張海軍， 于慧媛. 淺談軟件質(zhì)量評估中的辛普森悖論現(xiàn)象[J]. 科技視界， 2014（11）.

[7] 劉湖平， 增紹軍， 王欣. 基于安全軟件開發(fā)生命周期的軟件工程[J]. 中國管理信息化， 2013（7）.

[8] 孟祥豐. 軟件測試模型及其改進(jìn)方案[J]. 電子設(shè)計工程， 2012（23）.