杜以團(tuán),趙 林,楊小娟
(中國電子科技集團(tuán)公司第三十研究所,四川 成都 610041)
隨著軟件質(zhì)量越來越為大家所重視,軟件測試逐步發(fā)展為一個獨(dú)立于軟件開發(fā)的一系列活動,就每一個軟件測試的細(xì)節(jié)而言,都有一個獨(dú)立的操作流程. 軟件測試模型是指軟件測試活動全部的過程、活動和任務(wù)的結(jié)構(gòu)框架. 軟件測試模型是對軟件測試活動的抽象,它來源于軟件測試實(shí)踐,同時用于指導(dǎo)軟件測試活動的開展和過程控制管理,同軟件開發(fā)模型一樣,都遵循軟件工程和管理學(xué)原理[1]. 軟件測試模型對指導(dǎo)測試工作開展具有十分重要的意義,軟件測試根據(jù)不同的測試對象、測試背景、被測對象質(zhì)量要求、項(xiàng)目進(jìn)度要求等,可以采用不同的測試模型實(shí)施測試活動,指導(dǎo)軟件測試活動安排.
傳統(tǒng)軍工科研院所項(xiàng)目大多采用瀑布式的開發(fā)模型,開發(fā)測試基本按照V模型和W模型開展. 在軍工科研院所轉(zhuǎn)制、軍民融合發(fā)展的背景下,軍品項(xiàng)目競標(biāo)常態(tài)化、軍轉(zhuǎn)民項(xiàng)目逐步落地,傳統(tǒng)的開發(fā)測試模型無法滿足部分項(xiàng)目開發(fā)測試周期和市場競爭要求. 近年來,敏捷開發(fā)已成為主流的開發(fā)方式,軍工科研院所一方面多數(shù)項(xiàng)目采用重量級的軟件工程化的開發(fā)方式; 一方面部分項(xiàng)目為了適應(yīng)市場形式的變化和滿足快速的產(chǎn)品交付要求,積極開展輕量級的敏捷開發(fā)實(shí)踐. 同時,傳統(tǒng)的測試模型無法有效指導(dǎo)敏捷測試項(xiàng)目或項(xiàng)目局部敏捷測試工作的開展,而且敏捷開發(fā)方式目前也沒有建立一個行之有效的測試模型,這就使得測試人員在開展測試工作時面臨諸多困惑.
自20世紀(jì)80年代后期由Paul Rook提出最具代表性的軟件測試模型之一V模型[2]后,國外軟件測試模型研究先后經(jīng)歷了W模型、X模型、H模型、前置測試模型等發(fā)展演變[3],這幾種測試模型也發(fā)展成為世界上主流測試模型. 國內(nèi)軟件工程化和測試技術(shù)基本引進(jìn)學(xué)習(xí)國外主流技術(shù)、經(jīng)驗(yàn),對軟件開發(fā)測試基礎(chǔ)技術(shù)研究不夠且起步較晚,對軟件測試模型的研究大多是基于主流測試模型如V模型、X模型的項(xiàng)目應(yīng)用實(shí)踐和主流模型的適應(yīng)性改進(jìn). 2000年以來,國內(nèi)研究學(xué)者也提出了一些測試模型,但由于缺乏鮮明的特色、不具備普適性和國內(nèi)基礎(chǔ)技術(shù)研究環(huán)境等各方面因素,沒有形成具備一定行業(yè)知名度和影響力的測試模型.
隨著近幾年敏捷開發(fā)模式已成為主流開發(fā)模式,國內(nèi)除遵循軍工質(zhì)量管理體系標(biāo)準(zhǔn)的企業(yè)主要采用V模型、W模型外,其他多數(shù)企業(yè)轉(zhuǎn)向敏捷開發(fā)模式. 在敏捷開發(fā)模式中,開發(fā)和測試高度融合,不存在傳統(tǒng)測試模型中單元測試、集成測試、系統(tǒng)測試等明確的測試階段劃分,強(qiáng)調(diào)測試驅(qū)動開發(fā),對測試人員和整個項(xiàng)目團(tuán)隊(duì)都提出了更高的要求. 然而,基于敏捷開發(fā)模式的測試尚未形成一個主流的測試模型.
目前,主流傳統(tǒng)測試模型有V模型、W模型、X模型、H模型、前置測試模型,下面對這5種測試模型原理、優(yōu)勢和局限性進(jìn)行對比介紹,如表 1 所示.
表 1 軟件測試模型對比Tab.1 Comparison of software test models
V模型清楚地表明了軟件開發(fā)中的各個測試階段,但沒有明確應(yīng)對軟件的需求、設(shè)計(jì)進(jìn)行測試. W模型對此進(jìn)行了補(bǔ)充,并明確提前開展測試計(jì)劃、測試設(shè)計(jì),但同樣是重過程、重文檔的開發(fā)模式,每一個階段工作都對上一個階段工作有嚴(yán)格的要求. V模型和W模型清晰地體現(xiàn)了開發(fā)和測試的線性關(guān)系,對嚴(yán)格遵守軍工質(zhì)量管理體系標(biāo)準(zhǔn)(如GJB5000A、GJB/Z 141等)要求的項(xiàng)目具有很強(qiáng)的指導(dǎo)性. H模型主要體現(xiàn)軟件測試的獨(dú)立性,對具體測試過程活動指導(dǎo)意義不大. X模型體現(xiàn)了編碼和單元測試、集成測試的頻繁交互關(guān)系,并定義了探索性測試. 前置測試模型將測試和開發(fā)緊密結(jié)合,將技術(shù)測試和驗(yàn)收測試獨(dú)立開來,驗(yàn)收測試不再是完成技術(shù)測試之后的過程活動.
傳統(tǒng)軟件測試模型各有其價值和優(yōu)勢,總體來說,體現(xiàn)了軟件測試的一些基本原則: 軟件測試要盡早進(jìn)行; 軟件測試不僅是對代碼的測試,還包括需求、設(shè)計(jì)等技術(shù)文檔; 軟件測試要進(jìn)行測試計(jì)劃和測試設(shè)計(jì),測試設(shè)計(jì)要有較強(qiáng)的復(fù)用性.
敏捷測試一般將其理解為遵循敏捷核心思想和敏捷宣言的測試實(shí)踐活動[8],敏捷宣言強(qiáng)調(diào)敏捷開發(fā)的4個核心價值觀: 個體與交互高于流程和工具; 可用的軟件高于詳盡的文檔; 客戶協(xié)作高于合同談判; 響應(yīng)變化高于遵循計(jì)劃.
傳統(tǒng)軟件測試模型不適合快速迭代的敏捷開發(fā)模式,不能適應(yīng)頻繁的需求變更[9]. 當(dāng)項(xiàng)目需求頻繁變更、項(xiàng)目周期緊迫的情況下,傳統(tǒng)測試模型無法有效應(yīng)對項(xiàng)目交付周期風(fēng)險; 采用迭代的開發(fā)測試模式,能夠降低增量開支,降低產(chǎn)品無法按既定進(jìn)度進(jìn)入市場的風(fēng)險,更容易適應(yīng)需求的變化. 前置測試模型是開發(fā)和測試的緊密結(jié)合,敏捷測試則是開發(fā)和測試的融合.
在敏捷測試中,測試人員不再依賴設(shè)計(jì)文檔,不存在明顯的測試階段劃分,測試用例作用減弱,測試人員與開發(fā)人員保持緊密溝通,更多采用思維導(dǎo)圖、探索性測試,強(qiáng)調(diào)自由度,測試設(shè)計(jì)和測試執(zhí)行同時進(jìn)行,邊設(shè)計(jì)邊測試,根據(jù)測試結(jié)果不斷調(diào)整測試計(jì)劃.
傳統(tǒng)的測試模型有明確的測試階段劃分、測試準(zhǔn)入條件和測試回歸、測試判定準(zhǔn)則,而在敏捷測試中這些都不再有明確的標(biāo)準(zhǔn),頻繁的軟件狀態(tài)變化和版本交付發(fā)布已成為常態(tài),因此,習(xí)慣于傳統(tǒng)測試模式的測試人員在參與敏捷項(xiàng)目時會面臨諸多困惑: 應(yīng)該在什么時機(jī)介入開展測試?在測試執(zhí)行過程中開發(fā)已經(jīng)迭代一個版本甚至多個版本怎么辦?當(dāng)前版本未測試完成對已修復(fù)的缺陷要不要先進(jìn)行回歸測試?在敏捷測試中如何判定版本是否達(dá)到交付要求?
為了解決在敏捷開發(fā)項(xiàng)目中測試人員存在的困惑,能夠順利的開展軟件測試活動,本文結(jié)合敏捷開發(fā)理念和項(xiàng)目實(shí)踐經(jīng)驗(yàn),設(shè)計(jì)了一種適用于敏捷開發(fā)模式的軟件測試模型——階梯模型,如圖 1 所示.
在階梯測試模型中,不再像傳統(tǒng)測試模型有單元測試、集成測試、系統(tǒng)測試等明確的階段區(qū)分; 吸收H模型中的指導(dǎo)思想,一旦測試就緒,具備測試條件就立即開展測試; 盡早開展測試,同開發(fā)需求分析和設(shè)計(jì)同步開展測試需求分析和測試設(shè)計(jì),并根據(jù)需求變化隨時調(diào)整測試需求和測試設(shè)計(jì); 對版本進(jìn)行小規(guī)模快速增量迭代,直到達(dá)到版本發(fā)布要求,然后進(jìn)入下一個發(fā)布版本的增量迭代過程; 吸收前置測試模型中技術(shù)測試和驗(yàn)收測試相對獨(dú)立的思想,達(dá)到發(fā)布要求的版本提交用戶進(jìn)行驗(yàn)收測試,同時進(jìn)入下一個版本的技術(shù)測試.
階梯模型的核心思想體現(xiàn)在版本的增量迭代過程,在某個版本測試過程中,可以隨時響應(yīng)下一個版本的迭代,體現(xiàn)了擁抱變化的敏捷開發(fā)理念,使得軟件需求和技術(shù)狀態(tài)的變化不再是測試執(zhí)行過程讓人“懼怕”的因素. 因小版本的快速增量迭代過程像階梯般的推進(jìn),故該模型命名為“階梯模型”.
圖 1 階梯模型Fig.1 Ladder model
下面對階梯模型具體工作內(nèi)容要求和流程準(zhǔn)則等進(jìn)行詳細(xì)闡述.
在項(xiàng)目需求階段,由產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理等角色同用戶溝通,清晰地了解用戶需求,并和客戶協(xié)商確定版本發(fā)布迭代規(guī)模及用戶需求優(yōu)先級. 團(tuán)隊(duì)內(nèi)部對用戶需求開展討論,在技術(shù)決策范疇內(nèi),開發(fā)人員和測試人員協(xié)商決定發(fā)布周期內(nèi)的小版本迭代規(guī)模.
在參與項(xiàng)目需求討論的同時,測試人員分析并確定測試需求,根據(jù)測試需求開展測試方案、用例等設(shè)計(jì),并確定測試用例執(zhí)行優(yōu)先級. 團(tuán)隊(duì)內(nèi)部保持緊密溝通,一旦需求發(fā)生變化和調(diào)整,就及時同步調(diào)整測試需求和測試設(shè)計(jì),包括在原來基礎(chǔ)上進(jìn)行的更改調(diào)整和增量調(diào)整.
在測試執(zhí)行階段,按已開展的測試設(shè)計(jì)和測試用例優(yōu)先級執(zhí)行測試,在測試執(zhí)行過程中將輸出的bug實(shí)時提交到團(tuán)隊(duì)缺陷管理系統(tǒng); 在當(dāng)前測試版本已執(zhí)行部分測試但尚未完成全部測試的情況下,開發(fā)人員提交下一個迭代版本,測試人員更換新版本進(jìn)行測試; 對開發(fā)人員提交的迭代版本,首先進(jìn)行已修復(fù)bug的回歸測試,然后按原測試用例順序繼續(xù)執(zhí)行測試,按照最可能出現(xiàn)問題的部分最先測試的原則[10],優(yōu)先測試未執(zhí)行過的測試用例和新增開發(fā)代碼功能. 經(jīng)過多次小規(guī)模迭代,直至達(dá)到圖1中版本n經(jīng)過一輪完整測試且無bug輸出,或輸出的bug經(jīng)團(tuán)隊(duì)評估不影響版本發(fā)布,版本n完成技術(shù)測試發(fā)布并提交用戶進(jìn)行驗(yàn)收測試.
對開發(fā)人員提交迭代的版本,需要同開發(fā)人員協(xié)商確定準(zhǔn)入準(zhǔn)則,如開發(fā)人員已經(jīng)完成了一定規(guī)模的增量開發(fā),達(dá)到了前期商定的迭代規(guī)模,或者已經(jīng)修復(fù)了某些致命、高優(yōu)先級的bug. 測試人員和開發(fā)人員根據(jù)迭代測試情況對迭代規(guī)模進(jìn)行動態(tài)調(diào)整,使版本測試周期與迭代周期能夠相對保持同步.
階梯模型是在敏捷理念基礎(chǔ)上結(jié)合項(xiàng)目實(shí)踐經(jīng)驗(yàn)提出的. 在某型通信控制設(shè)備競標(biāo)樣機(jī)項(xiàng)目中,要進(jìn)行大規(guī)模的嵌入式軟件開發(fā)測試,存在項(xiàng)目周期短且可能面臨招標(biāo)方隨時通知交標(biāo)的情況. 在該項(xiàng)目中,項(xiàng)目團(tuán)隊(duì)采用小規(guī)模迭代的開發(fā)測試方式,基本上3天左右迭代一個版本,測試人員按階梯模型中闡述的測試方式開展快速迭代測試,經(jīng)過反復(fù)迭代,每個已開發(fā)功能都進(jìn)行了多輪測試,保證了軟件的穩(wěn)定性、可靠性,并且在全部需求開發(fā)完成后很短的周期內(nèi)即完成了版本測試發(fā)布. 在該項(xiàng)目多個投標(biāo)單位樣機(jī)競標(biāo)比測中,取得了滿分第一的成績. 可以想象,如果按照開發(fā)、測試串行的方式在完成所有需求開發(fā)后再進(jìn)行全面測試,版本發(fā)布周期會大大加長,并且沒有足夠的時間保證軟件質(zhì)量. 在一些短周期交付項(xiàng)目中,由于采用傳統(tǒng)開發(fā)測試模型,導(dǎo)致沒有足夠的時間進(jìn)行充分測試,為了保證交付進(jìn)度,往往犧牲在測試上的時間投入,軟件必然無法保證高質(zhì)量的交付.
本文在敏捷理念基礎(chǔ)上,吸收傳統(tǒng)測試模型的一些優(yōu)點(diǎn),并結(jié)合項(xiàng)目實(shí)踐經(jīng)驗(yàn)提出了一種基于敏捷開發(fā)模式的軟件測試模型——階梯模型,該模型充分體現(xiàn)了軟件的具體迭代過程,對測試人員執(zhí)行測試具有很強(qiáng)的指導(dǎo)性. 項(xiàng)目實(shí)際應(yīng)用結(jié)果表明,階梯模式在敏捷項(xiàng)目開發(fā)中能夠有效縮短開發(fā)測試周期,提高軟件開發(fā)質(zhì)量.