軟件開發(fā)測試流程(UserGuide)

1、軟件開發(fā)測試流程(User Guide1. 前言軟件測試在開發(fā)軟件的過程中能夠系統(tǒng)的監(jiān)督和評估項目的各個方面,以確保質(zhì)量標準,分析并確定產(chǎn)品是否滿足客戶的需求和期望的所有活動。軟件測試的首要目的就是保證軟件質(zhì)量,確保產(chǎn)品滿足設(shè)計的要求和客戶的需求,同時降低軟件的開發(fā)成本和維護成本,并最終簽發(fā)產(chǎn)品。在開發(fā)過程中,測試也是開發(fā)進度和質(zhì)量的主要度量標準之一。同等數(shù)量代碼與功能模塊中被發(fā)現(xiàn)的Bug的數(shù)量、程序性能瓶頸分析結(jié)果等都可以被用來衡量程序員開發(fā)工作優(yōu)劣。是否能夠通過所有的測試方案也是判斷相應(yīng)功能模塊的開發(fā)工作是否全部完成的主要標志。測試還對開發(fā)團隊靈活適應(yīng)市場、客戶等需求的變化有重要的意義。如

2、果建立了完整的測試方案并實施了高效率的自動化測試,那么當程序員對程序進行修改、重構(gòu)后,程序員能夠迅速通過運行所有相關(guān)測試案例來確定其所做的修改與重構(gòu)是否正確、是否因為修改部分代碼而導(dǎo)致程序的其他部分出現(xiàn)問題。如果沒有完備的測試,由于修改或重構(gòu)程序引起的其他程序的錯誤將被推遲發(fā)現(xiàn),進而大大增加修正錯誤的成本。高質(zhì)量的測試能夠幫助降低軟件的開發(fā)成本。由于在軟件開發(fā)過程中,修改程序、修復(fù)缺陷的成本會隨著開發(fā)進度不斷增大。高質(zhì)量的測試能夠盡早的發(fā)現(xiàn)程序中的缺陷,使之被及時修復(fù),因此能夠幫助降低開發(fā)后期發(fā)現(xiàn)重大缺陷的幾率,降低軟件開發(fā)在成本與進度上的風險。-1-2. CVS實現(xiàn)源代碼管理2.1 什么是C

3、VSCVS(Version Control System即版本控制系統(tǒng)。用來記錄源文件的歷史信息。甚至二進制文件,媒體文件等。例如,當軟件修改時有時會產(chǎn)生Bugs,并且你可能在做這次修改后很長時間不會發(fā)現(xiàn)這些Bugs。使用CVS,你可以容易地回顧老的代碼版本去發(fā)現(xiàn)哪一次的修改導(dǎo)致這些問題。有時候這樣會非常有幫助。你可能會保留你每一次的代碼版本,這可能會浪費你很多的代碼空間。CVS 使用種聰明的辦法保存你的多個版本在一個文件中。它僅僅保留版本間的不同內(nèi)容。它可以協(xié)助一組人共同開發(fā)一個工程。如果你是一個項目中的一組成員之一, CVS也能夠幫助你。除非你特別仔細,你很容易覆蓋其他人的工作。一些編輯器

4、,例如GNUEmacs,試圖去判定一個文件是否被兩人同時修改。不幸的是,如果一個人使用其它的編輯器時,這個安全方式將不再有效。CVS使用讓不同開發(fā)者獨立工作的方式解決了這個問題。每一個開發(fā)者的工作都在他自己的目錄內(nèi),并且CVS將在每個開發(fā)者的工作完成后進行合并工作。2.2基本概念倉庫(RepositoryCVS的倉庫存儲全部的版本控制下的文件copy,通常不容許直接訪問,只能通過cvs命令,獲得一份本地copy,改動后再check in(commit回倉庫。而倉庫通常為與工作目錄分離的。CVS通過多種方式訪問倉庫。每種方法有不同目錄表示形式。數(shù)據(jù)如何存放在repository中:隨著CVS版本

5、的不同,存放結(jié)構(gòu)會發(fā)生變化,一般情況下用戶無需了解數(shù)據(jù)到底是如何存放的。修訂版(Revision每一個file的各個revision都不相同,形如1.1, 1.2.1,一般1.1是該文件的第一個revision,后面的一個將自動增加最右面的一個整數(shù),比如1.2, 1.3, 1.4.有時候會出現(xiàn),這是因為在branch1.3.2之后重新命名了revision。revision總是偶數(shù)個數(shù)字。一般情況下將revision看作時CVS自己內(nèi)部的一個編號,而tag則可以標志用戶的特定信息。標記(Tag用符號化的表示方法標志文件特定revision的信息。通常不需要對某一個孤立的文件作ta

6、g,而是對所有文件同時作一個tag,以后用戶可以僅向特定tag的文件提交或者checkout。另外一個作用是在發(fā)布軟件的時候表示哪些文件及其哪個版本是可用的;各文件不同revision可以包括在一個tag中。如果命名一個已存在的tag 默認將不會覆蓋原來的;分支(Branch當用戶修改一個branch時不會對另外的branch產(chǎn)生任何影響?？梢栽谶m當?shù)臅r候通過合并的方法將兩個版本合起來;branch總是在當前revision后面加上一個偶數(shù)整數(shù)(從2開始,到0結(jié)束,所以branch總是奇數(shù)個數(shù)字,比如1.2后面branch為1.2.2,該分支下revision可能為,1.2.2.

7、2,.沖突(Conflict完全是純文本的沖突,不包含邏輯上的矛盾,比如CVS不能解決如下問題:某人修改了函數(shù)f的參數(shù),而另外一個人在另外一個地方用老的參數(shù)調(diào)用該函數(shù)。文本沖突需要用戶自己參與解決,CVS無法自動解決。WinCVS是CVS的一個客戶端軟件,它運行在Windows上,采用圖形化方式登陸CVS服務(wù)器和CVS相關(guān)的操作與管理,不要學(xué)習(xí)復(fù)雜的cvs命令。企業(yè)內(nèi)部都采用Linux/Unix做服務(wù)器,用Windows做客戶端,所以WinCVS與CVS服務(wù)器是目前應(yīng)用最廣泛的版本控制與管理的組合。詳細使用WinCVS的方法,見“WinCVS操作說明”。-3-3. Bugzilla實現(xiàn)缺陷跟蹤

8、管理3.1 目的缺陷能夠引起軟件運行時產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果,軟件測試過程簡單說就是圍繞缺陷進行的,對缺陷的跟蹤管理一般而言需要達到以下的目標:n 確保每個被發(fā)現(xiàn)的缺陷都能夠被解決;這里解決的意思不一定是被修正,也可能是其他處理方式(例如,在下一個版本中修正或是不修正,總之,對每個被發(fā)現(xiàn)的BUG的處理方式必須能夠在開發(fā)組織中達到一致;n 收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識別測試過程的階段;決定測試過程是否結(jié)束有很多種方式,通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式。n 收集缺陷數(shù)據(jù)并在其上進行數(shù)據(jù)分析,作為組織的過程財富。3.2 Bug描述從狹義上說,B

9、ug是指軟件開發(fā)中的錯誤或缺陷。廣義來說,Bug也包括意見和建議等。只要有軟件開發(fā),就會有Bug存在。對于Bug的管理和控制是保證項目開發(fā)質(zhì)量的重要依據(jù)。Bug系統(tǒng)就是基于此需求開發(fā)的,它記錄一個Bug從最初的登記到最后消亡的整個生存周期,通過對Bug的管理,可以保證提供降低開發(fā)成本、提高產(chǎn)品質(zhì)量和縮短開發(fā)周期,將一些錯誤消滅于萌芽狀態(tài)。Bug是該系統(tǒng)中最重要的概念,可以把Bug理解為任何軟件中的影響軟件質(zhì)量的所有部分,而不僅僅是導(dǎo)致程序運行失敗的程序片斷。3.3 Bug管理流程Reassign 3.4 操作說明3.4.1 用戶登錄及設(shè)置用戶登錄1用戶輸入亞太公司Bugzilla

10、客戶端地址33/。2進入注冊頁面,輸入用戶名和密碼即可登錄。用戶名為Email 地址,初始密碼為服務(wù)端發(fā)E-mail通知,用戶可以修改初始密碼。登錄成功后自動進入查詢頁面Search for bugs。3如忘記密碼,輸入用戶名, 點擊【submit request】,根據(jù)收到的郵件進行重新設(shè)置。修改密碼及設(shè)置1Login登錄后,【Edit prefs】-【account settings】進行密碼修改。2【Edit prefs】-【email settings】進行郵件設(shè)置。3【Edit prefs】- 【permissions】進行權(quán)限查詢。3.

11、4.2 Bug的處理、報告Bug一、測試或開發(fā)人員報告Bug1.請先進行查詢:根據(jù)要求選好各個參數(shù),點擊Search,就會出現(xiàn)一個bug 的列表。這是所有的人存在數(shù)據(jù)庫中的bug。若要查詢自己曾經(jīng)輸入的bug,點擊頁面下方的my bugs鏈接。還可以點擊Report鏈接,可以得到各個bug的狀態(tài)列表。如果要查看bug的詳細信息,可以點擊該bug的序號。2. 確認要提交的bug報告不會在原有記錄中存在,若已經(jīng)存在,不要提交,若有什么建議,可在原有記錄中增加注釋Additional Comments,告知其屬主,讓bug的屬主看到這個而自己去修改。3.若Bug不存在,創(chuàng)建一份有效的b

12、ug報告后進行提交, 操作如下:4.操作:點擊New,選擇產(chǎn)品后,填寫下表。-5-5.填表注意:Assigned to: 為空則默認為設(shè)定的owner, 也可手工制定。CC: 可為多人,需用,隔開。Description中要詳細說明下列情況:1發(fā)現(xiàn)問題的步驟2執(zhí)行上述步驟后出現(xiàn)的情況3期望應(yīng)出現(xiàn)的正確結(jié)果6. 若有若干個group可選擇,選擇后也就限定了此bug對組的權(quán)限;若為空,則為公開。7. 操作結(jié)果:Bug狀態(tài)(status默認為New.系統(tǒng)將自動通過Email通知項目組長或直接通知開發(fā)者。8.幫助:Bug writing guidelines二、Bug的不同處理情況1. Bug的屬主(

13、owner 處理問題后,提出解決意見及方法。1給出解決方法并填寫Additional Comments,還可創(chuàng)建附件(如:更改提交單2具體操作(填表項如下3填表注意:FIXED 描述的問題已經(jīng)修改INVALID 描述的問題不是一個bug (輸入錯誤后,通過此項來取消WONTFIX 描述的問題將永遠不會被修復(fù)。LATER 描述的問題將不會在產(chǎn)品的這個版本中解決.DUPLICATE 描述的問題是一個存在的bug的復(fù)件。WORKSFORME 所有要重新產(chǎn)生這個bug的企圖是無效的。如果有更多的信息出現(xiàn),請重新分配這個bug,而現(xiàn)在只把它歸檔。2. 項目組長或開發(fā)者重新指定Bug的屬主。(owner1

14、為此bug不屬于自己的范圍,可置為Reassigned bug to owner,等待測試人員重新指定。2為此bug不屬于自己的范圍,但知道誰應(yīng)該負責,直接輸入被指定人的Email,進行Reassigned。3操作:(可選項如下* Accept bug (change status to ASSIGNED* Reassign bug to* Reassign bug to owner and QA contact of selected component4操作結(jié)果:此時bug狀態(tài)又變?yōu)镹ew,此bug的owner變?yōu)楸恢付ǖ娜恕Ｈ?、測試人員驗證已修改的Bug.1.測試人員查詢開發(fā)者已修改的b

15、ug,即Status為Resolved, Resolution為Fixed.進行重新測試。(可創(chuàng)建test case附件2.經(jīng)驗證無誤后,修改Resolution為VERIFIED。待整個產(chǎn)品發(fā)布后,修改為CLOSED。若還有問題,REOPENED,狀態(tài)重新變?yōu)椤癗ew,并發(fā)郵件通知。3.具體操作(可選擇項1. Leave as RESOLVED FIXED2. Reopen bug3. Mark bug as VERIFIED4. Mark bug as CLOSED四、Bug報告者(reporter或其他有權(quán)限的用戶修改及補充Bugl 可以修改Bug的各項內(nèi)容。l 可以增加建立附件,增加了

16、相關(guān)性, 并加一些評論來解釋你正在做些什么和你為什么做。-7-l 操作結(jié)果:每當一些人修改了bug報告或加了一個評論,他們將會被加到CC列表中,bug 報告中的改變會顯在要發(fā)給屬主、寫報告者和CC列表中的人的電子郵件中。3.4.3查詢Bug1.直接輸入Bug Id,點擊find 查詢?？梢圆榭碆ug的活動紀錄。2.點擊Query,輸入條件進行查詢。3.查詢Bug活動的歷史view bug activity4.產(chǎn)生報表format for printing。5.幫助:點擊Clue.3.4.4 Bug的處理流程1.測試人員或開發(fā)人員發(fā)現(xiàn)bug后,判斷屬于哪個模塊的問題,填寫bug報告后,通過Email通知項目組長或直接通知開發(fā)者。2.項目組長根據(jù)具體情況,重新reassigned分配給bug所屬的開發(fā)者。3.開發(fā)者收到Email信息后,判斷是否為自己的修改范圍.1若不是,重新rea