一種基于敏捷開發(fā)模式的軟件測(cè)試模型
——階梯模型研究

杜以團(tuán)，趙 林，楊小娟

(中國(guó)電子科技集團(tuán)公司第三十研究所，四川 成都 610041)

0 引 言

隨著軟件質(zhì)量越來(lái)越為大家所重視，軟件測(cè)試逐步發(fā)展為一個(gè)獨(dú)立于軟件開發(fā)的一系列活動(dòng)，就每一個(gè)軟件測(cè)試的細(xì)節(jié)而言，都有一個(gè)獨(dú)立的操作流程. 軟件測(cè)試模型是指軟件測(cè)試活動(dòng)全部的過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架. 軟件測(cè)試模型是對(duì)軟件測(cè)試活動(dòng)的抽象，它來(lái)源于軟件測(cè)試實(shí)踐，同時(shí)用于指導(dǎo)軟件測(cè)試活動(dòng)的開展和過(guò)程控制管理，同軟件開發(fā)模型一樣，都遵循軟件工程和管理學(xué)原理[1]. 軟件測(cè)試模型對(duì)指導(dǎo)測(cè)試工作開展具有十分重要的意義，軟件測(cè)試根據(jù)不同的測(cè)試對(duì)象、測(cè)試背景、被測(cè)對(duì)象質(zhì)量要求、項(xiàng)目進(jìn)度要求等，可以采用不同的測(cè)試模型實(shí)施測(cè)試活動(dòng)，指導(dǎo)軟件測(cè)試活動(dòng)安排.

傳統(tǒng)軍工科研院所項(xiàng)目大多采用瀑布式的開發(fā)模型，開發(fā)測(cè)試基本按照V模型和W模型開展. 在軍工科研院所轉(zhuǎn)制、軍民融合發(fā)展的背景下，軍品項(xiàng)目競(jìng)標(biāo)常態(tài)化、軍轉(zhuǎn)民項(xiàng)目逐步落地，傳統(tǒng)的開發(fā)測(cè)試模型無(wú)法滿足部分項(xiàng)目開發(fā)測(cè)試周期和市場(chǎng)競(jìng)爭(zhēng)要求. 近年來(lái)，敏捷開發(fā)已成為主流的開發(fā)方式，軍工科研院所一方面多數(shù)項(xiàng)目采用重量級(jí)的軟件工程化的開發(fā)方式； 一方面部分項(xiàng)目為了適應(yīng)市場(chǎng)形式的變化和滿足快速的產(chǎn)品交付要求，積極開展輕量級(jí)的敏捷開發(fā)實(shí)踐. 同時(shí)，傳統(tǒng)的測(cè)試模型無(wú)法有效指導(dǎo)敏捷測(cè)試項(xiàng)目或項(xiàng)目局部敏捷測(cè)試工作的開展，而且敏捷開發(fā)方式目前也沒有建立一個(gè)行之有效的測(cè)試模型，這就使得測(cè)試人員在開展測(cè)試工作時(shí)面臨諸多困惑.

1 軟件測(cè)試模型論述

1.1 軟件測(cè)試模型研究現(xiàn)狀

自20世紀(jì)80年代后期由Paul Rook提出最具代表性的軟件測(cè)試模型之一V模型[2]后，國(guó)外軟件測(cè)試模型研究先后經(jīng)歷了W模型、X模型、H模型、前置測(cè)試模型等發(fā)展演變[3]，這幾種測(cè)試模型也發(fā)展成為世界上主流測(cè)試模型. 國(guó)內(nèi)軟件工程化和測(cè)試技術(shù)基本引進(jìn)學(xué)習(xí)國(guó)外主流技術(shù)、經(jīng)驗(yàn)，對(duì)軟件開發(fā)測(cè)試基礎(chǔ)技術(shù)研究不夠且起步較晚，對(duì)軟件測(cè)試模型的研究大多是基于主流測(cè)試模型如V模型、X模型的項(xiàng)目應(yīng)用實(shí)踐和主流模型的適應(yīng)性改進(jìn). 2000年以來(lái)，國(guó)內(nèi)研究學(xué)者也提出了一些測(cè)試模型，但由于缺乏鮮明的特色、不具備普適性和國(guó)內(nèi)基礎(chǔ)技術(shù)研究環(huán)境等各方面因素，沒有形成具備一定行業(yè)知名度和影響力的測(cè)試模型.

隨著近幾年敏捷開發(fā)模式已成為主流開發(fā)模式，國(guó)內(nèi)除遵循軍工質(zhì)量管理體系標(biāo)準(zhǔn)的企業(yè)主要采用V模型、W模型外，其他多數(shù)企業(yè)轉(zhuǎn)向敏捷開發(fā)模式. 在敏捷開發(fā)模式中，開發(fā)和測(cè)試高度融合，不存在傳統(tǒng)測(cè)試模型中單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試等明確的測(cè)試階段劃分，強(qiáng)調(diào)測(cè)試驅(qū)動(dòng)開發(fā)，對(duì)測(cè)試人員和整個(gè)項(xiàng)目團(tuán)隊(duì)都提出了更高的要求. 然而，基于敏捷開發(fā)模式的測(cè)試尚未形成一個(gè)主流的測(cè)試模型.

1.2 傳統(tǒng)測(cè)試模型簡(jiǎn)介

目前，主流傳統(tǒng)測(cè)試模型有V模型、W模型、X模型、H模型、前置測(cè)試模型，下面對(duì)這5種測(cè)試模型原理、優(yōu)勢(shì)和局限性進(jìn)行對(duì)比介紹，如表 1 所示.

表 1 軟件測(cè)試模型對(duì)比Tab.1 Comparison of software test models

1.3 測(cè)試模型綜合分析

V模型清楚地表明了軟件開發(fā)中的各個(gè)測(cè)試階段，但沒有明確應(yīng)對(duì)軟件的需求、設(shè)計(jì)進(jìn)行測(cè)試. W模型對(duì)此進(jìn)行了補(bǔ)充，并明確提前開展測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)，但同樣是重過(guò)程、重文檔的開發(fā)模式，每一個(gè)階段工作都對(duì)上一個(gè)階段工作有嚴(yán)格的要求. V模型和W模型清晰地體現(xiàn)了開發(fā)和測(cè)試的線性關(guān)系，對(duì)嚴(yán)格遵守軍工質(zhì)量管理體系標(biāo)準(zhǔn)(如GJB5000A、GJB/Z 141等)要求的項(xiàng)目具有很強(qiáng)的指導(dǎo)性. H模型主要體現(xiàn)軟件測(cè)試的獨(dú)立性，對(duì)具體測(cè)試過(guò)程活動(dòng)指導(dǎo)意義不大. X模型體現(xiàn)了編碼和單元測(cè)試、集成測(cè)試的頻繁交互關(guān)系，并定義了探索性測(cè)試. 前置測(cè)試模型將測(cè)試和開發(fā)緊密結(jié)合，將技術(shù)測(cè)試和驗(yàn)收測(cè)試獨(dú)立開來(lái)，驗(yàn)收測(cè)試不再是完成技術(shù)測(cè)試之后的過(guò)程活動(dòng).

傳統(tǒng)軟件測(cè)試模型各有其價(jià)值和優(yōu)勢(shì)，總體來(lái)說(shuō)，體現(xiàn)了軟件測(cè)試的一些基本原則： 軟件測(cè)試要盡早進(jìn)行； 軟件測(cè)試不僅是對(duì)代碼的測(cè)試，還包括需求、設(shè)計(jì)等技術(shù)文檔； 軟件測(cè)試要進(jìn)行測(cè)試計(jì)劃和測(cè)試設(shè)計(jì)，測(cè)試設(shè)計(jì)要有較強(qiáng)的復(fù)用性.

2 模型設(shè)計(jì)思路

2.1 敏捷測(cè)試思想

敏捷測(cè)試一般將其理解為遵循敏捷核心思想和敏捷宣言的測(cè)試實(shí)踐活動(dòng)[8]，敏捷宣言強(qiáng)調(diào)敏捷開發(fā)的4個(gè)核心價(jià)值觀： 個(gè)體與交互高于流程和工具； 可用的軟件高于詳盡的文檔； 客戶協(xié)作高于合同談判； 響應(yīng)變化高于遵循計(jì)劃.

傳統(tǒng)軟件測(cè)試模型不適合快速迭代的敏捷開發(fā)模式，不能適應(yīng)頻繁的需求變更[9]. 當(dāng)項(xiàng)目需求頻繁變更、項(xiàng)目周期緊迫的情況下，傳統(tǒng)測(cè)試模型無(wú)法有效應(yīng)對(duì)項(xiàng)目交付周期風(fēng)險(xiǎn)； 采用迭代的開發(fā)測(cè)試模式，能夠降低增量開支，降低產(chǎn)品無(wú)法按既定進(jìn)度進(jìn)入市場(chǎng)的風(fēng)險(xiǎn)，更容易適應(yīng)需求的變化. 前置測(cè)試模型是開發(fā)和測(cè)試的緊密結(jié)合，敏捷測(cè)試則是開發(fā)和測(cè)試的融合.

在敏捷測(cè)試中，測(cè)試人員不再依賴設(shè)計(jì)文檔，不存在明顯的測(cè)試階段劃分，測(cè)試用例作用減弱，測(cè)試人員與開發(fā)人員保持緊密溝通，更多采用思維導(dǎo)圖、探索性測(cè)試，強(qiáng)調(diào)自由度，測(cè)試設(shè)計(jì)和測(cè)試執(zhí)行同時(shí)進(jìn)行，邊設(shè)計(jì)邊測(cè)試，根據(jù)測(cè)試結(jié)果不斷調(diào)整測(cè)試計(jì)劃.

2.2 敏捷測(cè)試中的困惑

傳統(tǒng)的測(cè)試模型有明確的測(cè)試階段劃分、測(cè)試準(zhǔn)入條件和測(cè)試回歸、測(cè)試判定準(zhǔn)則，而在敏捷測(cè)試中這些都不再有明確的標(biāo)準(zhǔn)，頻繁的軟件狀態(tài)變化和版本交付發(fā)布已成為常態(tài)，因此，習(xí)慣于傳統(tǒng)測(cè)試模式的測(cè)試人員在參與敏捷項(xiàng)目時(shí)會(huì)面臨諸多困惑： 應(yīng)該在什么時(shí)機(jī)介入開展測(cè)試？在測(cè)試執(zhí)行過(guò)程中開發(fā)已經(jīng)迭代一個(gè)版本甚至多個(gè)版本怎么辦？當(dāng)前版本未測(cè)試完成對(duì)已修復(fù)的缺陷要不要先進(jìn)行回歸測(cè)試？在敏捷測(cè)試中如何判定版本是否達(dá)到交付要求？

3 階梯模型設(shè)計(jì)

3.1 階梯模型框架

為了解決在敏捷開發(fā)項(xiàng)目中測(cè)試人員存在的困惑，能夠順利的開展軟件測(cè)試活動(dòng)，本文結(jié)合敏捷開發(fā)理念和項(xiàng)目實(shí)踐經(jīng)驗(yàn)，設(shè)計(jì)了一種適用于敏捷開發(fā)模式的軟件測(cè)試模型——階梯模型，如圖 1 所示.

在階梯測(cè)試模型中，不再像傳統(tǒng)測(cè)試模型有單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試等明確的階段區(qū)分； 吸收H模型中的指導(dǎo)思想，一旦測(cè)試就緒，具備測(cè)試條件就立即開展測(cè)試； 盡早開展測(cè)試，同開發(fā)需求分析和設(shè)計(jì)同步開展測(cè)試需求分析和測(cè)試設(shè)計(jì)，并根據(jù)需求變化隨時(shí)調(diào)整測(cè)試需求和測(cè)試設(shè)計(jì)； 對(duì)版本進(jìn)行小規(guī)?？焖僭隽康?，直到達(dá)到版本發(fā)布要求，然后進(jìn)入下一個(gè)發(fā)布版本的增量迭代過(guò)程； 吸收前置測(cè)試模型中技術(shù)測(cè)試和驗(yàn)收測(cè)試相對(duì)獨(dú)立的思想，達(dá)到發(fā)布要求的版本提交用戶進(jìn)行驗(yàn)收測(cè)試，同時(shí)進(jìn)入下一個(gè)版本的技術(shù)測(cè)試.

階梯模型的核心思想體現(xiàn)在版本的增量迭代過(guò)程，在某個(gè)版本測(cè)試過(guò)程中，可以隨時(shí)響應(yīng)下一個(gè)版本的迭代，體現(xiàn)了擁抱變化的敏捷開發(fā)理念，使得軟件需求和技術(shù)狀態(tài)的變化不再是測(cè)試執(zhí)行過(guò)程讓人“懼怕”的因素. 因小版本的快速增量迭代過(guò)程像階梯般的推進(jìn)，故該模型命名為“階梯模型”.

圖 1 階梯模型Fig.1 Ladder model

3.2 階梯模型詳細(xì)介紹

下面對(duì)階梯模型具體工作內(nèi)容要求和流程準(zhǔn)則等進(jìn)行詳細(xì)闡述.

在項(xiàng)目需求階段，由產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理等角色同用戶溝通，清晰地了解用戶需求，并和客戶協(xié)商確定版本發(fā)布迭代規(guī)模及用戶需求優(yōu)先級(jí). 團(tuán)隊(duì)內(nèi)部對(duì)用戶需求開展討論，在技術(shù)決策范疇內(nèi)，開發(fā)人員和測(cè)試人員協(xié)商決定發(fā)布周期內(nèi)的小版本迭代規(guī)模.

在參與項(xiàng)目需求討論的同時(shí)，測(cè)試人員分析并確定測(cè)試需求，根據(jù)測(cè)試需求開展測(cè)試方案、用例等設(shè)計(jì)，并確定測(cè)試用例執(zhí)行優(yōu)先級(jí). 團(tuán)隊(duì)內(nèi)部保持緊密溝通，一旦需求發(fā)生變化和調(diào)整，就及時(shí)同步調(diào)整測(cè)試需求和測(cè)試設(shè)計(jì)，包括在原來(lái)基礎(chǔ)上進(jìn)行的更改調(diào)整和增量調(diào)整.

在測(cè)試執(zhí)行階段，按已開展的測(cè)試設(shè)計(jì)和測(cè)試用例優(yōu)先級(jí)執(zhí)行測(cè)試，在測(cè)試執(zhí)行過(guò)程中將輸出的bug實(shí)時(shí)提交到團(tuán)隊(duì)缺陷管理系統(tǒng)； 在當(dāng)前測(cè)試版本已執(zhí)行部分測(cè)試但尚未完成全部測(cè)試的情況下，開發(fā)人員提交下一個(gè)迭代版本，測(cè)試人員更換新版本進(jìn)行測(cè)試； 對(duì)開發(fā)人員提交的迭代版本，首先進(jìn)行已修復(fù)bug的回歸測(cè)試，然后按原測(cè)試用例順序繼續(xù)執(zhí)行測(cè)試，按照最可能出現(xiàn)問題的部分最先測(cè)試的原則[10]，優(yōu)先測(cè)試未執(zhí)行過(guò)的測(cè)試用例和新增開發(fā)代碼功能. 經(jīng)過(guò)多次小規(guī)模迭代，直至達(dá)到圖1中版本n經(jīng)過(guò)一輪完整測(cè)試且無(wú)bug輸出，或輸出的bug經(jīng)團(tuán)隊(duì)評(píng)估不影響版本發(fā)布，版本n完成技術(shù)測(cè)試發(fā)布并提交用戶進(jìn)行驗(yàn)收測(cè)試.

對(duì)開發(fā)人員提交迭代的版本，需要同開發(fā)人員協(xié)商確定準(zhǔn)入準(zhǔn)則，如開發(fā)人員已經(jīng)完成了一定規(guī)模的增量開發(fā)，達(dá)到了前期商定的迭代規(guī)模，或者已經(jīng)修復(fù)了某些致命、高優(yōu)先級(jí)的bug. 測(cè)試人員和開發(fā)人員根據(jù)迭代測(cè)試情況對(duì)迭代規(guī)模進(jìn)行動(dòng)態(tài)調(diào)整，使版本測(cè)試周期與迭代周期能夠相對(duì)保持同步.

3.3 階梯模型應(yīng)用

階梯模型是在敏捷理念基礎(chǔ)上結(jié)合項(xiàng)目實(shí)踐經(jīng)驗(yàn)提出的. 在某型通信控制設(shè)備競(jìng)標(biāo)樣機(jī)項(xiàng)目中，要進(jìn)行大規(guī)模的嵌入式軟件開發(fā)測(cè)試，存在項(xiàng)目周期短且可能面臨招標(biāo)方隨時(shí)通知交標(biāo)的情況. 在該項(xiàng)目中，項(xiàng)目團(tuán)隊(duì)采用小規(guī)模迭代的開發(fā)測(cè)試方式，基本上3天左右迭代一個(gè)版本，測(cè)試人員按階梯模型中闡述的測(cè)試方式開展快速迭代測(cè)試，經(jīng)過(guò)反復(fù)迭代，每個(gè)已開發(fā)功能都進(jìn)行了多輪測(cè)試，保證了軟件的穩(wěn)定性、可靠性，并且在全部需求開發(fā)完成后很短的周期內(nèi)即完成了版本測(cè)試發(fā)布. 在該項(xiàng)目多個(gè)投標(biāo)單位樣機(jī)競(jìng)標(biāo)比測(cè)中，取得了滿分第一的成績(jī). 可以想象，如果按照開發(fā)、測(cè)試串行的方式在完成所有需求開發(fā)后再進(jìn)行全面測(cè)試，版本發(fā)布周期會(huì)大大加長(zhǎng)，并且沒有足夠的時(shí)間保證軟件質(zhì)量. 在一些短周期交付項(xiàng)目中，由于采用傳統(tǒng)開發(fā)測(cè)試模型，導(dǎo)致沒有足夠的時(shí)間進(jìn)行充分測(cè)試，為了保證交付進(jìn)度，往往犧牲在測(cè)試上的時(shí)間投入，軟件必然無(wú)法保證高質(zhì)量的交付.

4 結(jié)束語(yǔ)

本文在敏捷理念基礎(chǔ)上，吸收傳統(tǒng)測(cè)試模型的一些優(yōu)點(diǎn)，并結(jié)合項(xiàng)目實(shí)踐經(jīng)驗(yàn)提出了一種基于敏捷開發(fā)模式的軟件測(cè)試模型——階梯模型，該模型充分體現(xiàn)了軟件的具體迭代過(guò)程，對(duì)測(cè)試人員執(zhí)行測(cè)試具有很強(qiáng)的指導(dǎo)性. 項(xiàng)目實(shí)際應(yīng)用結(jié)果表明，階梯模式在敏捷項(xiàng)目開發(fā)中能夠有效縮短開發(fā)測(cè)試周期，提高軟件開發(fā)質(zhì)量.