軟件測試過程管理實踐_第1頁
軟件測試過程管理實踐_第2頁
軟件測試過程管理實踐_第3頁
軟件測試過程管理實踐_第4頁
軟件測試過程管理實踐_第5頁
已閱讀5頁,還剩5頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

軟件測試過程管理實踐

摘要

隨著測試技術的蓬勃發(fā)展,測試過程的管理顯得猶為重要,過程管理已成為測試成功的重要保證。經(jīng)過多年努力,測試專家提出了許多測試過程模型,包括V模型、W模型、H模型等等。這些模型定義了測試活動的流程和方法,為測試管理工作提供了指導。但這些模型各有長短,并沒有哪種模型能夠完全適合于所有的測試項目,在實際測試中應該吸取各模型的長處,歸納出合適的測試理念。“盡早測試”、“全面測試”、“全過程測試”和“獨立、迭代的測試”是從各模型中提煉出來的四個理念,這些思想在實際測試項目中得到了應用并收到了良好的效果。在運用這些理念指導測試的同時,測試組應不斷關注于基于度量和分析的過程的改進活動,不斷提高測試管理水平,更好的提高測試效率、降低測試成本。關鍵詞

測試過程模型測試管理理念可持續(xù)改進

引言

1963年,在美國發(fā)生了這樣一件事:編程人員把一個FORTRAN程序的循環(huán)語句DO5I=1,3誤寫為DO5I=1.3。一點之差導致飛往火星的火箭爆炸,造成1000多萬美元的損失。這種情況的發(fā)生,迫使人們考慮在軟件投入使用之前必須進行徹底的測試。今天,在軟件比較發(fā)達的國家,軟件測試已經(jīng)成為一個獨立的產(chǎn)業(yè),軟件公司紛紛建立獨立的測試隊伍研究測試技術并開展測試工作。中國的軟件測試起步較晚,但隨著我國軟件產(chǎn)業(yè)的蓬勃發(fā)展以及人們對軟件質(zhì)量的重視,軟件測試正在成為一個新興的產(chǎn)業(yè)。近兩年來,國內(nèi)新成立專業(yè)性測試機構(gòu)10余家,一批批專業(yè)的軟件測試人員正涌現(xiàn)出來。每年國內(nèi)都有大量的測試技術交流會議舉辦,有大量的測試研究論文在專業(yè)刊物上發(fā)表。在測試技術發(fā)展的同時,測試過程的管理顯得猶為重要。一個成功的測試項目,離不開對測試過程科學的組織和監(jiān)控,過程管理已成為測試成功的重要保證。

1測試過程概述

1.1軟件測試過程概述

軟件測試過程是一種抽象的模型,用于定義軟件測試的流程和方法。眾所周知,開發(fā)過程的質(zhì)量決定了軟件的質(zhì)量,同樣的,測試過程的質(zhì)量將直接影響測試結(jié)果的準確性和有效性。軟件測試過程和軟件開發(fā)過程一樣,都遵循軟件工程原理,遵循管理學原理。

隨著測試過程管理的發(fā)展,軟件測試專家通過實踐總結(jié)出了很多很好的測試過程模型。這些模型將測試活動進行了抽象,并與開發(fā)活動有機的進行了結(jié)合,是測試過程管理的重要參考依據(jù)。

1.2軟件測試過程模型介紹

V模型

V模型最早是由PaulRook在20世紀80年代后期提出的,旨在改進軟件開發(fā)的效率和效果。V模型反映出了測試活動與分析設計活動的關系。在圖1-1中,從左到右描述了基本的開發(fā)過程和測試行為,非常明確的標注了測試過程中存在的不同類型的測試,并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應關系。

圖1-1軟件測試V模型

V模型指出,單元和集成測試應檢測程序的執(zhí)行是否滿足軟件設計的要求;系統(tǒng)測試應檢測系統(tǒng)功能、性能的質(zhì)量特性是否達到系統(tǒng)要求的指標;驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。

但V模型存在一定的局限性,它僅僅把測試作為在編碼之后的一個階段,是針對程序進行的尋找錯誤的活動,而忽視了測試活動對需求分析、系統(tǒng)設計等活動的驗證和確認的功能。

W模型

W模型由Evolutif公司公司提出,相對于V模型,W模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動。如圖1-2所示,W模型由兩個V字型模型組成,分別代表測試與開發(fā)過程,圖中明確表示出了測試與開發(fā)的并行關系。

W模型強調(diào):測試伴隨著整個軟件開發(fā)周期,而且測試的對象不僅僅是程序,需求、設計等同樣要測試,也就是說,測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如,需求分析完成后,測試人員就應該參與到對需求的驗證和確認活動中,以盡早地找出缺陷所在。同時,對需求的測試也有利于及時了解項目難度和測試風險,及早制定應對措施,這將顯著減少總體測試時間,加快項目進度。

但W模型也存在局限性。在W模型中,需求、設計、編碼等活動被視為串行的,同時,測試和開發(fā)活動也保持著一種線性的前后關系,上一階段完全結(jié)束,才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當前軟件開發(fā)復雜多變的情況,W模型并不能解除測試管理面臨著困惑。

圖1-2軟件測試W模型[NextPage]

H模型

V模型和W模型均存在一些不妥之處。如前所述,它們都把軟件的開發(fā)視為需求、設計、編碼等一系列串行的活動,而事實上,這些活動在大部分時間內(nèi)是可以交叉進行的,所以,相應的測試之間也不存在嚴格的次序關系。同時,各層次的測試(單元測試、集成測試、系統(tǒng)測試等)也存在反復觸發(fā)、迭代的關系。

為了解決以上問題,有專家提出了H模型。它將測試活動完全獨立出來,形成了一個完全獨立的流程,將測試準備活動和測試執(zhí)行活動清晰地體現(xiàn)出來,如圖1-3所示。

圖1-3軟件測試H模型

這個示意圖僅僅演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標注的其他流程可以是任意的開發(fā)流程。例如,設計流程或編碼流程。也就是說,只要測試條件成熟了,測試準備活動完成了,測試執(zhí)行活動就可以(或者說需要)進行了。

H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產(chǎn)品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備,盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。

其他模型

除上述幾種常見模型外,業(yè)界還流傳著其他幾種模型,例如X模型、前置測試模型等。X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。前置測試模型體現(xiàn)了開發(fā)與測試的結(jié)合,要求對每一個交付內(nèi)容進行測試。這些模型都針對其他模型的缺點提出了一些修正意見,但本身也可能存在一些不周到的地方。所以在測試過程管理中,正確選取過程模型是一個關鍵問題。

1.3軟件測試過程模型選取策略

前面介紹的測試過程模型中,V模型強調(diào)了在整個項目開發(fā)中需要經(jīng)歷的不同的測試級別,但忽視了測試的對象不應該僅僅是程序。而W模型在這一點上進行了補充,明確指出應該對需求、設計進行測試。但是V模型和W模型都沒有將一個完整的測試過程抽象出來,成為一個獨立的流程,這并不適合當前軟件開發(fā)中廣泛應用的迭代模型。H模型則明確指出測試的獨立性,也就是說只要測試條件成熟了,就可以開展測試。

在實際測試工作中我們應該盡可能地去應用各模型中對項目有實用價值的方面,不能強行的為使用模型而使用模型。在測試實踐中,我們采用的方法是:以W模型作為框架,及早的、全面的開展測試。同時靈活運用H模型獨立測試的思想,在達到恰當?shù)木途w點時就應該開展獨立的測試工作,同時將測試工作進行迭代,最終保證完成測試目標。

2測試過程管理理念

生命周期模型為我們提供了軟件測試的流程和方法,為測試過程管理提供了依據(jù)。但實際的測試工作是復雜而煩瑣的,可能不會有哪種模型完全適用于某項測試工作。所以,我們應該從不同的模型中抽象出符合實際現(xiàn)狀的測試過程管理理念,依據(jù)這些理念來策劃測試過程,以不變應萬變。當然測試管理牽涉的范圍非常的廣泛,包括過程定義、人力資源管理、風險管理等等,本節(jié)僅介紹幾條從過程模型中提煉出來的,對實際測試有指導意義的管理理念。

2.1盡早測試

“盡早測試”是從W模型中抽象出來的理念。我們說測試并不是在代碼編寫完成之后才開展的工作,測試與開發(fā)是兩個相互依存的并行的過程,測試活動在開發(fā)活動的前期已經(jīng)開展。

“盡早測試”包含兩方面的含義:第一,測試人員早期參與軟件項目,及時開展測試的準備工作,包括編寫測試計劃、制定測試方案以及準備測試用例;第二,盡早的開展測試執(zhí)行工作,一旦代碼模塊完成就應該及時開展單元測試,一旦代碼模塊被集成成為相對獨立的子系統(tǒng),便可以開展集成測試,一旦有BUILD提交,便可以開展系統(tǒng)測試工作。

由于及早的開展了測試準備工作,測試人員能夠于早期了解測試的難度、預測測試的風險,從而有效提高了測試效率,規(guī)避測試風險。由于及早的開展測試執(zhí)行工作,測試人員盡早的發(fā)現(xiàn)軟件缺陷,大大降低了BUG修復成本。但是需要注意,“盡早測試”并非盲目的提前測試活動,測試活動開展的前提是達到必須的測試就緒點。

2.2全面測試

軟件是程序、數(shù)據(jù)和文檔的集合,那么對軟件進行測試,就不僅僅是對程序的測試,還應包括軟件“副產(chǎn)品”的“全面測試”,這是W模型中一個重要的思想。需求文檔、設計文檔作為軟件的階段性產(chǎn)品,直接影響到軟件的質(zhì)量。階段產(chǎn)品質(zhì)量是軟件質(zhì)量的量的積累,不能把握這些階段產(chǎn)品的質(zhì)量將導致最終軟件質(zhì)量的不可控。

“全面測試”包含兩層含義:第一,對軟件的所有產(chǎn)品進行全面的測試,包括需求、設計文檔,代碼,用戶文檔等等。第二,軟件開發(fā)及測試人員(有時包括用戶)全面的參與到測試工作中,例如對需求的驗證和確認活動,就需要開發(fā)、測試及用戶的全面參與,畢竟測試活動并不僅僅是保證軟件運行正確,同時還要保證軟件滿足了用戶的需求。

“全面測試”有助于全方位把握軟件質(zhì)量,盡最大可能的排除造成軟件質(zhì)量問題的因素,從而保證軟件滿足質(zhì)量需求。

2.3全過程測試

在W模型中充分體現(xiàn)的另一個理念就是“全過程測試”。雙V字過程圖形象的表明了軟件開發(fā)與軟件測試的緊密結(jié)合,這就說明軟件開發(fā)和測試過程會彼此影響,這就要求測試人員對開發(fā)和測試的全過程進行充分的關注。

“全過程測試”包含兩層含義:第一,測試人員要充分關注開發(fā)過程,對開發(fā)過程的各種變化及時做出響應。例如開發(fā)進度的調(diào)整可能會引起測試進度及測試策略的調(diào)整,需求的變更會影響到測試的執(zhí)行等等。第二,測試人員要對測試的全過程進行全程的跟蹤,例如建立完善的度量與分析機制,通過對自身過程的度量,及時了解過程信息,調(diào)整測試策略。

“全過程測試”有助于及時應對項目變化,降低測試風險。同時對測試過程的度量與分析也有助于把握測試過程,調(diào)整測試策略,便于測試過程的改進。

[NextPage]

2.4獨立的、迭代的測試

我們知道,軟件開發(fā)瀑布模型只是一種理想狀況。為適應不同的需要,人們在軟件開發(fā)過程中摸索出了如螺旋、迭代等諸多模型,這些中需求、設計、編碼工作可能重疊并反復進行的,這時的測試工作將也是迭代和反復的。如果不能將測試從開發(fā)中抽象出來進行管理,勢必使測試管理陷入困境。

軟件測試與軟件開發(fā)是緊密結(jié)合的,但并不代表測試是依附于開發(fā)的一個過程,測試活動是獨立的。這正是H模型所主導的思想?!蔼毩⒌摹⒌臏y試”著重強調(diào)了測試的就緒點,也就是說,只要測試條件成熟,測試準備活動完成,測試的執(zhí)行活動就可以開展。

所以,我們在遵循盡早測試、全面測試、全過程測試理念的同時,應當將測試過程從開發(fā)過程中適當?shù)某橄蟪鰜?,作為一個獨立的過程進行管理。時刻把握獨立的、迭代測試的理念,減小因開發(fā)模型的繁雜給測試管理工作帶來的不便。對于軟件過程中不同階段的產(chǎn)品和不同的測試類型,只要測試準備工作就緒,就可以及時開展測試工作,把握產(chǎn)品質(zhì)量。

3測試過程管理實踐

本節(jié)以一個實際項目系統(tǒng)測試過程(不對單元測試和集成測試過程進行分析)的幾個關鍵過程管理行為為例,來闡述上節(jié)中提出的測試理念。在一個構(gòu)件化ERP項目中,由于前期需求不明確,開發(fā)周期相對較長,為了對項目進行更好的跟蹤和管理,項目采用增量和迭代模型進行開發(fā)。整個項目開發(fā)共分三個階段完成:第一階段實現(xiàn)進銷存的簡單的功能和工作流;第二階段:實現(xiàn)固定資產(chǎn)管理、財務管理,并完善第一階段的進銷存功能;第三階段:增加辦公自動化的管理(OA)。該項目每一階段工作是對上一階段成果的一次迭代完善,同時將新功能進行了一次疊加。

3.1策劃測試過程

依據(jù)傳統(tǒng)的方法,將系統(tǒng)測試作為軟件開發(fā)的一個階段,系統(tǒng)測試執(zhí)行工作將在三個階段完成后開展,很明顯,這樣做不利于BUG的及時暴露。有些缺陷可能會埋藏至后期發(fā)現(xiàn),這時的修復成本將大大提高。我們依據(jù)“獨立和迭代”的測試理念,在本系統(tǒng)中,對測試過程進行獨立的策劃,找出測試準備就緒點,在就緒點及時開展測試。該系統(tǒng)的三個階段具有相對的獨立性,在每一階段完成所提交的階段產(chǎn)品具有相對的獨立性,可以作為系統(tǒng)測試準備的就緒點。故而,在該系統(tǒng)開發(fā)過程中,系統(tǒng)測試組計劃開展三階段的系統(tǒng)測試,每個階段系統(tǒng)測試具有不同的側(cè)重點,目的在于更好的配合開發(fā)工作盡早發(fā)現(xiàn)軟件BUG,降低軟件成本。軟件開發(fā)與系統(tǒng)測試過程的關系如圖3-1所示。

實踐證明,這種做法起到了預期的效果,與開發(fā)過程緊密結(jié)合而又相對獨立的測試過程,有效的于早期發(fā)現(xiàn)了許多系統(tǒng)缺陷,降低了開發(fā)成本,同時也使基于復雜開發(fā)模型的測試管理工作更加清晰明了。

3.2把握需求

在本系統(tǒng)開發(fā)過程中,需求的獲取和完善貫穿每個階段。對需求的把握很大程度上決定了軟件測試是否能夠成功。系統(tǒng)測試不僅僅確認軟件是否正確實現(xiàn)功能,同時還要確認軟件是否滿足用戶的需要。依據(jù)“盡早測試”和“全面測試”原則,在需求的獲取階段,測試人員參與到了對需求的討論之中。測試人員與開發(fā)人員及用戶一起討論需求的完善性與正確性,同時從可測試性角度為需求文檔提出建議。這些建議對開發(fā)人員來說,是從一個全新的思維角度提出的約束。同時,測試組結(jié)合前期對項目的把握,很容易制定出了完善的測試計劃和方案,將各階段產(chǎn)品的測試方法及進度、人員安排進行了策劃,使整個項目的進展有條不紊。

實踐證明,測試人員早期參與需求的獲取和分析中,有助于加深測試人員對需求的把握和理解,同時也大大促進需求文檔的質(zhì)量。在需求人員把握需求的同時,于早期制定項目計劃和方案,及早準備測試活動,大大提高了測試效率。

3.3變更控制

變更控制體現(xiàn)的是“全過程測試”理念。在軟件開發(fā)過程中,變更往往是不可避免的,變更也是造成軟件風險的重要因素。在本系統(tǒng)測試中,僅第一階段就發(fā)生了7次需求變更,調(diào)整了兩次進度計劃。依據(jù)“全過程測試”理念,測試組密切關注開發(fā)過程,跟隨進度計劃的變更調(diào)整測試策略,依據(jù)需求的變更及時補充和完善測試用例。由于充分的測試準備工作,在測試執(zhí)行過程中,沒有廢棄一個測試用例,測試的進度并沒有因為變更而受到過多影響。

3.4度量與分析

對測試過程的度量與分析同樣體現(xiàn)的“全過程測試”理念。對測試過程的度量有利于及時把握項目情況,對過程數(shù)據(jù)進行分析,很容易發(fā)現(xiàn)優(yōu)勢劣勢,找出需要改進的地方,及時調(diào)整測試策略。

在ERP項目中,我們在測試過程中對不同階段的BUG數(shù)量進行了度量,并分析測試執(zhí)行是否充分。如圖3-2所示,通過分析我們得出:相同時間間隔內(nèi)發(fā)現(xiàn)的BUG數(shù)量呈收斂狀態(tài),測試是充分的。在BUG數(shù)量收斂的狀態(tài)下結(jié)束細測是恰當?shù)摹?/p>

圖3-2軟件開發(fā)與系統(tǒng)測試關系圖

測試中,我們對不同功能點的測試數(shù)據(jù)覆蓋率和

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論