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

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

關鍵詞：TMap軟件測試管理方法；V模型；W模型；X模型；軟件測試

中圖分類號：TP311 文獻標識碼：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 背景

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

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

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

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

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

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

3 TMap測試管理模型的提出及應用

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

3.1 TMap的測試生命周期

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

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

3.1.1 計劃和控制階段

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

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

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

3.1.2 準備階段

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

3.1.3 說明階段

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

3.1.4 執(zhí)行階段

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

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

3.1.5 結束階段

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

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

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

3.2 TMap生命周期模型的好處

3.2.1 結構化測試方法

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

1）能夠針對被測軟件的質量風險提供深入認知和建議；

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

3）能夠預防缺陷；

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

5）能夠對測試產品（如測試腳本和測試用例）進行復用建立清晰的測試過程，能夠使時間、成本和質量的管理保持一致性和標準化，所有參與測試的人員將使用同樣的測試語言。

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

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

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

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

4 結束語

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

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

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

參考文獻：

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

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

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

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

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

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

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

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