X測試模型的改進與應用

熊 智， 劉 莉， 雷鈺鋒， 蔡偉鴻

(汕頭大學計算機系，廣東汕頭515063)

0 引 言

隨著軟件應用領域的擴張，軟件產品逐漸趨于大型化、復雜化，與此同時，軟件的質量控制卻越來越難以實施[1]。國內許多軟件公司的軟件開發管理能力相對薄弱，致使不少產品在開發完成之后無法正常投入使用，即使勉強上線，也往往因為出現過多難以解決的問題而最終宣布失敗，導致人力和物力的極大浪費。在這樣的背景下，軟件測試模型作為保證軟件測試工作效率和質量的結構框架，亟需通過強化和改進來適應不斷復雜化的軟件開發過程[2]。

軟件測試模型用于規范測試的進行過程，以保證軟件測試的效率和效果。隨著軟件開發與測試技術的進步，一般測試模型已較難適應當前軟件的開發測試過程[3]。文獻[4]提出的新軟件測試模型沒有針對具體的范圍表現出其應用優勢；文獻[5]提出的基于行為的軟件測試過程模型無法靈活處理中小型系統在測試過程中存在的問題；文獻[6]結合敏捷開發模式的改進X測試模型沒有考慮客戶對開發過程的影響和如何處理需求改變等問題。本文通過研究各類測試模型的特點，著重對目前應用最為廣泛的X測試模型進行了分析，結合其在實際開發測試中所暴露出的問題，對其進行了改進，并應用于數字版權運營平臺的二次開發測試中，取得了較好的效果。應用結果表明，改進的X測試模型很好地指導測試人員選擇合適的測試方法、制定合理的測試計劃，達到了節省軟件成本和提高軟件質量的目的。

1 傳統的X測試模型

軟件測試V模型把系統開發劃分成具有嚴格邊界的不同階段，測試是在開發完成之后對程序進行檢查的一個過程，但是 V測試模型在實際應用中的不足遭受到了不少批評和質疑。此后改進的 W 測試模型強調的是測試伴隨整個軟件開發周期，測試的對象包括需求、設計和代碼，然而W模型無法支持開發時發生的變更和迭代過程。X測試模型是在經典V模型的基礎上衍生來的一種基于實踐的測試模型，彌補了V測試模型的部分缺陷[7]。如圖1所示。

圖1 X測試模型

X測試模型針對單獨程序片段進行相互獨立的編碼和測試，此后將通過頻繁的交接成為可執行的程序，再對這些可執行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規模和范圍內集成的一部分。X測試模型還定位了探索性測試，該測試拋棄了繁雜的測試計劃和測試用例的編寫過程，往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤[8]。

目前，隨著X測試模型的廣泛應用，在具體項目的開發測試過程中也顯現出了一定的局限性，如結構過于松散和執行過程不夠嚴謹。具體表現如下：

(1)缺乏客戶的參與，沒有考慮到需求對軟件開發的影響，而大部分軟件的失敗都源于系統沒有滿足用戶的需求。

(2)缺少測試后的驗證過程，無法驗證經過修正的系統是否修復了原有的錯誤，以及在修改的過程中是否出現新的錯誤，系統的最終質量得不到有效保證。

(3)X測試模型雖然允許在開發過程中發生需求的改變，但在模型中卻沒有給出相關處理方案。

(4)過于注重對測試人員要求較高的探索性測試。在實際測試中，大部分測試人員對探索性測試的認識不夠，容易造成人力、物力和財力的浪費。

2 改進的X測試模型

本文的主要工作是在X測試模型的基礎上，結合實際項目的開發測試經驗，提出了改進的X測試模型。新模型對測試活動的開展順序做了調整，增加了迭代和回歸測試過程，并對各階段的測試工作進行了驗證，把測試人員和具體的測試工作關聯起來，提出測試需定義終止條件，以使改進的X測試模型盡可能多地適用各種具體情況下的項目測試過程[9]。

2.1 X測試模型的改進

針對傳統X測試模型過于松散化和不夠嚴謹的不足，本文對其進行了改進，改進的X測試模型大體框架：采用自底向上的測試方法，先對小模塊進行測試，再集成通過測試的模塊做集成測試；在每個模塊的測試執行前定義相應的準備工作，包括驗證需求、功能確認、設計測試計劃、選擇測試工具、編寫測試用例；開發測試過程以文檔為參考，但不完全依賴項目文檔，允許在開發過程的各個部分發生需求和計劃的變更；模型引入了回歸測試、探索性測試和驗收測試，當需求發生改變時，考慮采用迭代過程。改進的X測試模型解決了傳統X測試模型在開發測試過程中產生的一系列問題，更加適合實際應用。改進的X測試模型如圖2所示。

圖2 改進的X測試模型

改進的X測試模型仍保留原模型X字型的模型框架，左半部分表示n個單獨的模塊可以并行測試。模型右邊表示通過測試的小模塊不斷地交接，集成為小型系統并進行集成測試，再發布已通過集成測試的小型系統，然后集成新的模塊對其測試與再發布。改進的X測試模型中間兩條較短的X線條表示迭代的過程可追溯到開發周期的任一階段，測試過程與其相對應。新模型用右邊比左邊稍低來說明集成測試必須在至少2個模塊通過了單元測試后才能進行。

2.2 改進的X測試模型的優勢

本文通過對X測試模型做了一系列的改進從而彌補了原模型的一些不足，下面介紹了改進的X測試模型如何很好地解決原模型在實際應用中遇到的幾個問題，并就以下問題給出了具體解決方法。

(1)產品不符合客戶要求

改進的X測試模型讓客戶和用戶不同程度地參與到了測試過程中，并在測試的各個階段對其進行了分工協作，使其發揮監督軟件正確開發的作用。改進的X測試模型在測試前期加入了對需求的驗證和系統設計的確認，這樣保證了程序員編寫出來的代碼符合客戶的要求；在集成測試的最后階段加入了驗收測試這一過程，客戶和用戶一起參與到驗收測試中來以確定開發的系統是滿足客戶需要的。通過這些改進，避免了原X測試模型由于沒有考慮客戶需求而發生開發出來的系統偏離原意的嚴重錯誤。

(2)產品最終質量無法保證

模型左右兩邊都在測試后加入了回歸測試過程，用以識別上一輪測試發現的錯誤是否被改正以及改正后會否引入新的錯誤。回歸測試不能無限制進行，這樣過于浪費人力與財力。為了在質量和成本之間維持一個很好的平衡，改進的X測試模型引入了測試終止這一概念，不同項目組可以根據對系統質量的需求和開發成本制定合適的停止判別條件，這樣一來既控制了成本也最大限度地保證了軟件質量。

(3)客戶需求發生改變

改進的X測試模型在每個模塊測試和集成測試中加入了迭代的過程，這里的迭代包括兩種情況：當用戶需求發生變化時，程序要進行很大的改動，那么開發過程需要迭代，這時測試也跟隨著發生變化；客戶的性能測試需求發生了變化，或客戶對測試結果不滿意，那么迭代就有可能回溯到測試的各個階段。迭代的過程解決了如何處理客戶需求發生改變的情況，對原X模型的“容許需求改變”做了很好的補充。

(4)測試效率與成本問題

改進的X測試模型把還處于不成熟階段的探索性測試安插在測試過程中，由測試組長隨機執行。因為大部分測試人員對探索性測試還不太熟悉，而探索性測試對于測試人員的要求較高，要是過于注重該測試，不僅無法發揮其優勢，還可能造成人力物力的浪費。由經驗豐富的測試組長來執行探索性測試，既不影響測試的其它步驟，又有可能發現更多的錯誤。

3 改進的X測試模型的應用

數字版權運營平臺是一個具有數字版權的電子產品交易平臺，該平臺已完成了開發測試工作，但在運行中暴露了較多問題，并且由于客戶新增了功能和性能上的需求，模塊基本需要重寫，因此我們對其進行了二次開發。本文將原來的平臺稱為舊版本(V1.0)，二次開發的版本稱為新版本(V2.0)。在舊版本的開發測試過程中使用的是X測試模型，而新版本則采用了改進的X測試模型。

3.1 數字版權運營平臺框架

數字版權運營平臺通過對數字產品進行加密、添加水印、控制權限的方法來保護商品版權，整個交易過程在網站平臺上進行，并通過CA認證來管理注冊會員的個人信息。平臺的系統結構如圖3所示。

該運營平臺具有以下特點：系統結構復雜，模塊和開發人員眾多；客戶需求伴隨應用環境的變化時常改變；系統開發周期較短，開發完一部分功能后會進行小型發布與試用。上述特點導致使用傳統的X測試模型不能很好地適用于該平臺的開發測試，無法解決測試角色的配置、修復錯誤后出現的新BUG、產品偏離客戶要求和客戶需求變更等問題。

圖3 數字版權運營平臺系統結構

在平臺V1.0版本的開發測試工作中遇到了以下困難：①測試人員數量多、人員角色模糊，以至于各項測試工作不能具體分配到適當的人員身上，導致測試效率低下、測試進度緩慢；②開發人員在修改BUG的時候經常又引入了新的錯誤，而測試小組并沒有對修改后的系統及時進行測試，以致系統完成后問題不斷；③客戶認為發布的小型系統不是他們需要的，因此客戶和開發小組兩邊互相抱怨；④客戶需求不斷變更并經常提出新的要求，致使開發工作不能按計劃進行。以上問題導致軟件開發過程中發現的錯誤率(錯誤個數/測試用例個數)較低，而驗收階段卻出現了較多錯誤。

3.2 測試方法與步驟

本文把改進的X測試模型應用到數字版權運營平臺的二次開發測試中，項目經理在開發前依照客戶的需求做了總體設計，把整個開發工作按功能劃分成了多個子模塊，并把每個子模塊的實現工作分配給不同的程序員。整個平臺由項目經理負責整體設計和整合，開發過程的具體工作按結構圖的第二層劃分為4個小組，每個小組由組長負責下面模塊的分工和整合。測試工作在項目得到需求分析階段便開始了，具體步驟如下：

(1)項目經理、客戶和測試人員共同確認需求的正確性，之后被分配到模塊的程序員開始做模塊設計，模塊設計可以通過文檔或原型化模型來體現，由設計人員和測試人員驗證是否符合需求。

(2)模塊設計完成后，通過與客戶溝通交流來確定模塊的功能和界面滿足他們的要求，然后程序員開始編碼，測試人員設計測試計劃、編寫測試用例，各個模塊的工作同時進行。

(3)編碼完成后，測試人員按照測試用例執行測試，測試組長可以隨機地進行探索性測試，把測試結果以報告形式反饋給開發人員，然后再做回歸測試，驗證BUG已被修復和沒有出現新的BUG，回歸測試的次數由開發和測試時間進度來決定。

(4)開發過程中，客戶的需求發生變化或是開發出來的模塊不滿足客戶的要求時，便調出上階段做的測試驗證工作，找出問題出在哪階段，只在出問題的地方進行編碼和測試的迭代，而不需要從頭來做。

(5)通過測試的模塊被集成以后，測試人員對其進行集成測試，包括功能測試、性能測試、界面測試、安全測試等，經過客戶驗收以后，然后進行小型的發布。

(6)新開發的模塊經過以上的過程再不斷地集成進來，直至系統完成所有的功能模塊。

3.3 應用效果及分析

本文在對數字版權運營平臺的測試過程中，嚴格依照改進的X測試模型順利地完成了測試任務，并取得了較好的效果。在系統二次開發前先對測試人員與測試工作進行合理配置，通過開發早期的需求驗證和設計測試發現了不少錯誤并做了及時修正，回歸測試階段修復了新出現的BUG，運用迭代很好地處理了用戶需求的變更。通過與舊版本的開發測試中應用傳統X測試模型的結果進行比較，改進的X測試模型靈活地處理了前期遇到的問題。表1對數字版權運營平臺V1.0版本與V2.0版本的測試結果進行了比較。

從表1中可以看出，二次開發測試周期是以前的一半，而測試用例數量是以前的近1.4倍。系統V2.0版本在需求分析和系統設計階段進行了驗證，分別發現了11%和13%的錯誤；V2.0在開發階段發現的錯誤率是28%，后期錯誤率逐漸減小，V1.0在開發期間發現的錯誤率是17%；V2.0在驗收階段只有4%的錯誤率，而V1.0在驗收階段的出錯率達25%。實踐表明，改進的X模型能夠使缺陷和錯誤盡早地暴露出來，減少后期的維護工作，提高軟件質量。

表1 數字版權運營平臺V1.0與V2.0平臺測試結果對比

4 結束語

本文針對目前常用的X測試模型結構松散和不夠嚴謹的不足，提出了改進的X測試模型，該模型緊跟軟件工程技術的發展趨勢，在原模型基礎上增加了回歸測試和驗收測試過程，對測試人員與測試方法間的關聯進行了調整，強調客戶的參與和測試需終止，從而解決了產品不符合客戶要求、客戶需求改變、測試效率低等問題。將改進的X測試模型應用到數字版權運營平臺的開發測試過程中，應用結果表明，該模型能有效地指導測試資源的分配和測試活動的執行，使問題盡早暴露出來，減少開發成本，從而提高了開發測試效率和軟件質量。改進的X測試模型在大中型項目的開發測試過程中取得了較好的效果，接下來的工作將把該測試模型應用到更多的項目開發實踐中，并針對遇到的問題不斷進行完善，以增強模型的兼容性和適應性。

[1]Wongthongtham P,Chang E,Dillon T,et al.Development of a software engineering ontology for multisite software development[J].IEEE Transactions on Knowledge and Data Engineering,2009,8(21):1205-1217.

[2]Shari Lawrence Pfleeger,Joanne M Atlee.軟件工程[M].3 版.北京:人民郵電出版社,2009.

[3]柳永坡,鄒磊,金茂忠,等.軟件測試領域的知識管理及模型研究[J].計算機應用研究,2009,26(1):143-145.

[4]李神,陳嶷瑛.一種有效的軟件測試模型[J].計算機工程與應用,2004,40(10):114-115.

[5]陸永忠,宋駿禮,谷希謙.基于行為的軟件測試過程模型及其應用研究[J].計算機應用,2007,27(5):1238-1240.

[6]戴莉萍,熊小勇.基于敏捷開發的X測試模型的研究與改進[J].計算機工程與設計,2007,28(18):4342-4344.

[7]董曉霞.軟件測試工程化的研究與實現[J].計算機工程與設計,2006,27(11):2008-2010.

[8]Hovemeyer D,Pugh W.Finding bugs is easy[J].ACM Sigplan Notices,2004,39(12):92-106.

[9]Lammermann F,Wappler S.Benefits of software measures for evolutinary white-box testing[C].Proc of the Conference on Genetic and Evolutionary Computation,2005:1083-1084.