杜以團,趙 林,楊小娟
(中國電子科技集團公司第三十研究所,四川 成都 610041)
隨著軟件質量越來越為大家所重視,軟件測試逐步發展為一個獨立于軟件開發的一系列活動,就每一個軟件測試的細節而言,都有一個獨立的操作流程. 軟件測試模型是指軟件測試活動全部的過程、活動和任務的結構框架. 軟件測試模型是對軟件測試活動的抽象,它來源于軟件測試實踐,同時用于指導軟件測試活動的開展和過程控制管理,同軟件開發模型一樣,都遵循軟件工程和管理學原理[1]. 軟件測試模型對指導測試工作開展具有十分重要的意義,軟件測試根據不同的測試對象、測試背景、被測對象質量要求、項目進度要求等,可以采用不同的測試模型實施測試活動,指導軟件測試活動安排.
傳統軍工科研院所項目大多采用瀑布式的開發模型,開發測試基本按照V模型和W模型開展. 在軍工科研院所轉制、軍民融合發展的背景下,軍品項目競標常態化、軍轉民項目逐步落地,傳統的開發測試模型無法滿足部分項目開發測試周期和市場競爭要求. 近年來,敏捷開發已成為主流的開發方式,軍工科研院所一方面多數項目采用重量級的軟件工程化的開發方式; 一方面部分項目為了適應市場形式的變化和滿足快速的產品交付要求,積極開展輕量級的敏捷開發實踐. 同時,傳統的測試模型無法有效指導敏捷測試項目或項目局部敏捷測試工作的開展,而且敏捷開發方式目前也沒有建立一個行之有效的測試模型,這就使得測試人員在開展測試工作時面臨諸多困惑.
自20世紀80年代后期由Paul Rook提出最具代表性的軟件測試模型之一V模型[2]后,國外軟件測試模型研究先后經歷了W模型、X模型、H模型、前置測試模型等發展演變[3],這幾種測試模型也發展成為世界上主流測試模型. 國內軟件工程化和測試技術基本引進學習國外主流技術、經驗,對軟件開發測試基礎技術研究不夠且起步較晚,對軟件測試模型的研究大多是基于主流測試模型如V模型、X模型的項目應用實踐和主流模型的適應性改進. 2000年以來,國內研究學者也提出了一些測試模型,但由于缺乏鮮明的特色、不具備普適性和國內基礎技術研究環境等各方面因素,沒有形成具備一定行業知名度和影響力的測試模型.
隨著近幾年敏捷開發模式已成為主流開發模式,國內除遵循軍工質量管理體系標準的企業主要采用V模型、W模型外,其他多數企業轉向敏捷開發模式. 在敏捷開發模式中,開發和測試高度融合,不存在傳統測試模型中單元測試、集成測試、系統測試等明確的測試階段劃分,強調測試驅動開發,對測試人員和整個項目團隊都提出了更高的要求. 然而,基于敏捷開發模式的測試尚未形成一個主流的測試模型.
目前,主流傳統測試模型有V模型、W模型、X模型、H模型、前置測試模型,下面對這5種測試模型原理、優勢和局限性進行對比介紹,如表 1 所示.

表 1 軟件測試模型對比Tab.1 Comparison of software test models
V模型清楚地表明了軟件開發中的各個測試階段,但沒有明確應對軟件的需求、設計進行測試. W模型對此進行了補充,并明確提前開展測試計劃、測試設計,但同樣是重過程、重文檔的開發模式,每一個階段工作都對上一個階段工作有嚴格的要求. V模型和W模型清晰地體現了開發和測試的線性關系,對嚴格遵守軍工質量管理體系標準(如GJB5000A、GJB/Z 141等)要求的項目具有很強的指導性. H模型主要體現軟件測試的獨立性,對具體測試過程活動指導意義不大. X模型體現了編碼和單元測試、集成測試的頻繁交互關系,并定義了探索性測試. 前置測試模型將測試和開發緊密結合,將技術測試和驗收測試獨立開來,驗收測試不再是完成技術測試之后的過程活動.
傳統軟件測試模型各有其價值和優勢,總體來說,體現了軟件測試的一些基本原則: 軟件測試要盡早進行; 軟件測試不僅是對代碼的測試,還包括需求、設計等技術文檔; 軟件測試要進行測試計劃和測試設計,測試設計要有較強的復用性.
敏捷測試一般將其理解為遵循敏捷核心思想和敏捷宣言的測試實踐活動[8],敏捷宣言強調敏捷開發的4個核心價值觀: 個體與交互高于流程和工具; 可用的軟件高于詳盡的文檔; 客戶協作高于合同談判; 響應變化高于遵循計劃.
傳統軟件測試模型不適合快速迭代的敏捷開發模式,不能適應頻繁的需求變更[9]. 當項目需求頻繁變更、項目周期緊迫的情況下,傳統測試模型無法有效應對項目交付周期風險; 采用迭代的開發測試模式,能夠降低增量開支,降低產品無法按既定進度進入市場的風險,更容易適應需求的變化. 前置測試模型是開發和測試的緊密結合,敏捷測試則是開發和測試的融合.
在敏捷測試中,測試人員不再依賴設計文檔,不存在明顯的測試階段劃分,測試用例作用減弱,測試人員與開發人員保持緊密溝通,更多采用思維導圖、探索性測試,強調自由度,測試設計和測試執行同時進行,邊設計邊測試,根據測試結果不斷調整測試計劃.
傳統的測試模型有明確的測試階段劃分、測試準入條件和測試回歸、測試判定準則,而在敏捷測試中這些都不再有明確的標準,頻繁的軟件狀態變化和版本交付發布已成為常態,因此,習慣于傳統測試模式的測試人員在參與敏捷項目時會面臨諸多困惑: 應該在什么時機介入開展測試?在測試執行過程中開發已經迭代一個版本甚至多個版本怎么辦?當前版本未測試完成對已修復的缺陷要不要先進行回歸測試?在敏捷測試中如何判定版本是否達到交付要求?
為了解決在敏捷開發項目中測試人員存在的困惑,能夠順利的開展軟件測試活動,本文結合敏捷開發理念和項目實踐經驗,設計了一種適用于敏捷開發模式的軟件測試模型——階梯模型,如圖 1 所示.
在階梯測試模型中,不再像傳統測試模型有單元測試、集成測試、系統測試等明確的階段區分; 吸收H模型中的指導思想,一旦測試就緒,具備測試條件就立即開展測試; 盡早開展測試,同開發需求分析和設計同步開展測試需求分析和測試設計,并根據需求變化隨時調整測試需求和測試設計; 對版本進行小規模快速增量迭代,直到達到版本發布要求,然后進入下一個發布版本的增量迭代過程; 吸收前置測試模型中技術測試和驗收測試相對獨立的思想,達到發布要求的版本提交用戶進行驗收測試,同時進入下一個版本的技術測試.
階梯模型的核心思想體現在版本的增量迭代過程,在某個版本測試過程中,可以隨時響應下一個版本的迭代,體現了擁抱變化的敏捷開發理念,使得軟件需求和技術狀態的變化不再是測試執行過程讓人“懼怕”的因素. 因小版本的快速增量迭代過程像階梯般的推進,故該模型命名為“階梯模型”.

圖 1 階梯模型Fig.1 Ladder model
下面對階梯模型具體工作內容要求和流程準則等進行詳細闡述.
在項目需求階段,由產品經理、項目經理等角色同用戶溝通,清晰地了解用戶需求,并和客戶協商確定版本發布迭代規模及用戶需求優先級. 團隊內部對用戶需求開展討論,在技術決策范疇內,開發人員和測試人員協商決定發布周期內的小版本迭代規模.
在參與項目需求討論的同時,測試人員分析并確定測試需求,根據測試需求開展測試方案、用例等設計,并確定測試用例執行優先級. 團隊內部保持緊密溝通,一旦需求發生變化和調整,就及時同步調整測試需求和測試設計,包括在原來基礎上進行的更改調整和增量調整.
在測試執行階段,按已開展的測試設計和測試用例優先級執行測試,在測試執行過程中將輸出的bug實時提交到團隊缺陷管理系統; 在當前測試版本已執行部分測試但尚未完成全部測試的情況下,開發人員提交下一個迭代版本,測試人員更換新版本進行測試; 對開發人員提交的迭代版本,首先進行已修復bug的回歸測試,然后按原測試用例順序繼續執行測試,按照最可能出現問題的部分最先測試的原則[10],優先測試未執行過的測試用例和新增開發代碼功能. 經過多次小規模迭代,直至達到圖1中版本n經過一輪完整測試且無bug輸出,或輸出的bug經團隊評估不影響版本發布,版本n完成技術測試發布并提交用戶進行驗收測試.
對開發人員提交迭代的版本,需要同開發人員協商確定準入準則,如開發人員已經完成了一定規模的增量開發,達到了前期商定的迭代規模,或者已經修復了某些致命、高優先級的bug. 測試人員和開發人員根據迭代測試情況對迭代規模進行動態調整,使版本測試周期與迭代周期能夠相對保持同步.
階梯模型是在敏捷理念基礎上結合項目實踐經驗提出的. 在某型通信控制設備競標樣機項目中,要進行大規模的嵌入式軟件開發測試,存在項目周期短且可能面臨招標方隨時通知交標的情況. 在該項目中,項目團隊采用小規模迭代的開發測試方式,基本上3天左右迭代一個版本,測試人員按階梯模型中闡述的測試方式開展快速迭代測試,經過反復迭代,每個已開發功能都進行了多輪測試,保證了軟件的穩定性、可靠性,并且在全部需求開發完成后很短的周期內即完成了版本測試發布. 在該項目多個投標單位樣機競標比測中,取得了滿分第一的成績. 可以想象,如果按照開發、測試串行的方式在完成所有需求開發后再進行全面測試,版本發布周期會大大加長,并且沒有足夠的時間保證軟件質量. 在一些短周期交付項目中,由于采用傳統開發測試模型,導致沒有足夠的時間進行充分測試,為了保證交付進度,往往犧牲在測試上的時間投入,軟件必然無法保證高質量的交付.
本文在敏捷理念基礎上,吸收傳統測試模型的一些優點,并結合項目實踐經驗提出了一種基于敏捷開發模式的軟件測試模型——階梯模型,該模型充分體現了軟件的具體迭代過程,對測試人員執行測試具有很強的指導性. 項目實際應用結果表明,階梯模式在敏捷項目開發中能夠有效縮短開發測試周期,提高軟件開發質量.