軟件測試和發(fā)布程序_第1頁
軟件測試和發(fā)布程序_第2頁
軟件測試和發(fā)布程序_第3頁
軟件測試和發(fā)布程序_第4頁
軟件測試和發(fā)布程序_第5頁
免費預覽已結束,剩余6頁可下載查看

下載本文檔

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

文檔簡介

1、WORD格式可編輯軟件測試與發(fā)布程序文件編號:Q/XKYWT-C-JS-07-20071目的做好產品的測試與檢驗、試驗工作,確保產品質量符合用戶要求。2適用范圍適用對象:技術部業(yè)務范圍:綜合測試、確認測試3方針和職責技術部測試工程師負責開發(fā)過程中的測試;技術部軟件設計工程師負責針對測試中發(fā)現(xiàn)的問題進行修改。4工作程序4.1 測試項目經理接受過軟件工程、項目的應用領域知識、項目管理的培訓或具備相應的能力。軟件綜合測試人員和確認測試人員接受過軟件測試理論、方法、技術、工具等的培訓或具備相應的能力。綜合測試人員和確認測試人員依據(jù)項目計劃中定義的項目軟件過程, 計劃和實施軟件測試。在項目計劃中,要盡早

2、分配測試軟件的資源,以做好充分的測試準備。4.1.1 概述 Overview軟件測試級別包括以下四種:單元測試、綜合測試、確認測試、用戶測試。這四級軟件 測試應按順序進行,前者完成方可開始后續(xù)測試(特殊情況下確認測試可與用戶測試合并進 行)。當被測試軟件或軟件環(huán)境發(fā)生變化時,應在相關級別上適當進行回歸測試。單元測試 在軟件實現(xiàn)程序中描述,綜合測試、確認測試和用戶測試在本程序中描述。4.1.1.1 綜合測試綜合測試,也叫組裝測試。通常,在單元測試的基礎上,需要將所有模塊按照設計要求 組裝成為系統(tǒng)。組裝測試就是發(fā)現(xiàn)在模塊連接中可能出現(xiàn)的缺陷,最終構成要求的軟件系統(tǒng)。測試重點是:1 .在把各個模塊連

3、接起來的時候,穿越模塊接口的數(shù)據(jù)是否會丟失;2 . 一個模塊的功能是否會對另一個模塊的功能產生不利的影響;3 .各個子功能組合起來,能否達到預期要求的功能的父功能;4 .全局數(shù)據(jù)結構是否有問題;5 .單個模塊的誤差累積起來,是否會放大,從而達到不能接受的程度。4.1.1.2 確認測試確認測試又稱有效性測試,是驗證軟件的功能和性能及其他特性是否與軟件需求一致。依據(jù)軟件需求規(guī)格說明進行。合適時,可以邀請用戶一起開發(fā)和評審測試準則。4.1.1.3 測試的合并對于大部分項目,綜合測試、確認測試可以合并進行,進行統(tǒng)一的策劃、實施,形成統(tǒng) 一的測試計劃、測試報告。4.1.2 測試準備 Test Prepa

4、ration確認測試由所在事業(yè)部或部門成立的獨立于項目組的測試組進行(必要時,與客戶一同進行),以證明該軟件滿足軟件需求。測試組依據(jù)項目計劃實施軟件測試工作。必要時(如公司不具備測試所需的特殊設備等),到用戶現(xiàn)場,與客戶一同參與測試活 動,即將確認測試與用戶測試合并進行,詳見剪裁指南。當被測試軟件或測試環(huán)境發(fā)生變化時,適當?shù)剡M行回歸測試。4.1.2.1 制定測試計劃前置條件Precondition1 .確認測試已在項目計劃中定義。2 .確認測試負責人已在項目計劃中定義。輸入Input1 .經過評審并已形成基線的軟件需求分析說明書2 .已形成基線的項目計劃3 .其它支持確認測試、并通過評審的工作

5、產品,如概要設計說明書、操作手冊等過程活動 Process activities1 .軟件需求分析說明書編寫完成后,測試組制定測試計劃(含測試用例),該計劃中要明確操作手冊、軟件系統(tǒng)的功能和性能作為測試項。2 .軟件需求分析說明書變更時,測試組修改測試計劃。3 .測試計劃編寫完成后,應進行同行評審(必要時,用戶參與)。4 .測試計劃通過評審后形成基線,置于配置管理之下。5 .當軟件需求或被測試軟件更改時,相應更改測試方案。輸出Output1.通過評審并形成基線的測試計劃4.1.2.2 實施測試 輸入Input1 .通過評審并形成基線的測試計劃2 .已通過綜合測試且納入基線的可執(zhí)行程序3 .通過

6、評審并形成基線的操作手冊過程活動 Process activities1 .依據(jù)測試計劃中的測試環(huán)境要求,測試組負責完成測試環(huán)境的搭建。2 .測試組依據(jù)測試計劃實施測試。3 .對照納入確認測試基線的軟件,對操作手冊進行驗證。合適時,由用戶和軟件 維護人員對其進行評審和認可。4 .測試組將操作手冊、可執(zhí)行程序功能和性能的測試過程和測試結果記錄在測 試報告的“詳細測試記錄”中。5 .測試完成后,測試負責人填寫測試反饋單反饋給開發(fā)負責人。6 .開發(fā)負責人負責將修改完成后的軟件重新提交給測試組。7 .測試組進行回歸測試。8 .以上步驟重復進行,直到發(fā)現(xiàn)的缺陷全部被關閉。當出現(xiàn)以下情況時,確認測試負責人

7、可以終止確認測試(異常終止)。1 .測試中發(fā)現(xiàn)的缺陷太多;2 .軟件出現(xiàn)缺陷,致使無法進行后續(xù)測試。輸出Output1 .測試報告2 .測試反饋單4.1.2.3 編寫測試報告輸入Input1 .測試記錄單2 .測試反饋單過程活動 Process activities1 .測試組匯總分析操作手冊、可執(zhí)行程序功能和性能的測試情況,編寫測試報 告(參見測試報告模板)。測試報告應包括:測試概要、實際測試與測試計劃 的偏差、在測試中發(fā)現(xiàn)的缺陷、缺陷解決后再次測試的結果,并對測試結果進行分 析,重點是評價軟件的能力是否達到預定目標,是否可以開始下一階段活動,并以 此判斷軟件是否滿足需求。2 .測試報告編寫

8、完成后,項目分管高層經理批準。輸出Output1 .通過評審的測試報告2 . 評審記錄 輸出標準 output criteria1 .測試計劃已形成基線。2 .測試報告通過評審。4.1.3 變更 Change測試方案、測試報告形成基線后,其更改(一般為當軟件需求或軟件設計更改時)應按照軟件配置管理程序進行,并相應更新需求跟蹤矩陣。隨著對軟件理解的加深,如果需要對軟件工作產品、計劃、過程定義和活動方面進行更 改時,應先分析更改對軟件的影響, 合適時予以采納。當需要更改用戶需求時,應先得到批 準,然后再與相關小組協(xié)商對軟件產品和活動作出相應更改。4.1.4 過程度量 Measurement軟件測試

9、活動中應進行的度量包括:1、測試階段的評審中發(fā)現(xiàn)的缺陷數(shù)、嚴重程度、缺陷起源階段;2、花在評審、糾正和批準各任務活動/軟件工作產品上的工作量;3、變更各任務活動軟件工作產品的規(guī)模、費用、工作量。以上數(shù)據(jù)分別體現(xiàn)在里程碑報告及項目狀態(tài)報告中。4.1.5 驗證 Verification項目分管高層經理定期通過項目周報、項目狀態(tài)報告、項目月報、重大里程碑評審來評審軟件測試活動。項目經理定期通過項目例會、項目月報、重大里程碑評審或遇到重要需求分析問題時來評審軟件測試活動。QA人員評審和驗證:1 .需要進行評審的軟件工作產品,已進行了評審;2 .軟件測試活動滿足準備就緒準則和完成準則;3 .軟件產品符合

10、對它們所規(guī)定的標準和要求;4 .已完成了計劃的測試,并記錄了測試結果;5 .評審和測試發(fā)現(xiàn)的問題和缺陷已記錄,并進行了跟蹤和解決;6 . 通過需求跟蹤矩陣對需求進行了跟蹤。4.1.6 剪裁指南 Tailoring Guideline如果公司不具備確認測試的環(huán)境或者應用戶要求,需要到用戶現(xiàn)場進行確認測試,可以將確認測試與用戶測試合并進行。工作程序按用戶測試程序進行。根據(jù)合同要求,如果用戶測試由用戶獨立進行, 則在用戶測試活動中, 測試組只需取得 用戶的書面測試報告;如果用戶測試過程中的部分活動(如編寫用戶測試報告)由用戶獨立進行,則測試組僅需執(zhí)行其它活動,并取得用戶的書面測試報告。4.2發(fā)布4.

11、2.1 概述 Outline一般地,軟件產品發(fā)布在整個軟件產品工程過程中所處的位置如下(以瀑布模型為例)專業(yè)知識整理分享實施準備需求分析綜合測試綜合測試方案編寫確 認 測 試 方 案 編 寫手冊編寫確認測試產品發(fā)布軟件產品發(fā)布前要從以下三個方面驗證其測試的充分性:1 .測試級別:軟件產品是否經過了QM滸規(guī)定的所有測試,即單元測試、綜合測試、確認測試。2 .測試策略:每個級別的測試是否都選擇了合適的測試策略。3 .測試覆蓋率:軟件測試是否達到了預定的測試覆蓋率。軟件產品經過確認測試、所有經過評審和測試發(fā)現(xiàn)的缺陷均關閉并得到驗證、且各類文檔和手冊編寫完成并通過評審后,依據(jù)配置管理計劃中的約定放入受

12、控庫。此時的軟件產品進入發(fā)布階段,以“產品名稱+產品發(fā)行版本號+產品發(fā)布內部版本號”的形式予以 標識,如:XX系統(tǒng) 2.0 a Build 105 。合同類項目的產品發(fā)布過程通常包括:發(fā)布a版產品、發(fā)布3版產品和發(fā)布正式版產品。如下圖所示:產品開發(fā)類項目的產品發(fā)布過程通常包括:發(fā)布m.n (例如:1.1 )版產品、發(fā)布正式版產品。如下圖所示:4.2.2 產品的對外發(fā)布(SCM AC7當項目組要向本項目組外的個人或者組織 (如:客戶、培訓組等)提交軟件工作產品時, 無論是提供給內部用戶還是外部用戶使用, 須遵循以下發(fā)布過程。 所有提交的軟件工作產品 無論是外部使用還是內部使用,都必須由受控庫中的

13、配置項構成。輸入Input受控庫中的配置項過程活動 Process activities1 .項目經理確定需要發(fā)布的產品配置項。并指定審計人員進行配置審計。2 .配置管理員根據(jù)項目經理確定的要發(fā)布的配置項填寫并向CC曜交發(fā)布通知。3 . QA寸擬發(fā)布的產品進行評價,并在發(fā)布通知上簽字。4 . CCB在發(fā)布通知上簽字,批準本次發(fā)布。5 .配置管理員從受控庫中提取配置項,然后在產品庫中建立該次發(fā)布的目錄(目錄名 據(jù)發(fā)布通知中的約定而定),并將提取出來的配置項放入該目錄中。6 .配置管理員(或項目經理指定的人員) 將需要發(fā)布的工作產品復制到物理介質上(如:光盤、磁盤等),然后發(fā)布。輸出Output1

14、 .放入產品庫中的產品。2 .經CCB比準的發(fā)布通知。3 .放在物理介質上的需要發(fā)布的產品。4.2.3發(fā)布中間版產品輸入Input通過確認測試的軟件工作產品過程活動 Process activities1、將經過確認測試,且驗證和關閉了所有已發(fā)現(xiàn)缺陷的軟件工作產品標識為a Build1版,如:XX系統(tǒng)2.0 a Build 1 。填寫發(fā)布通知,并將相應產品放入產品庫。2、合同類項目需從產品庫中提取要發(fā)布的產品包交付用戶測試或使用,產品類項目需將產品包發(fā)送給公司內部測試。3、用戶在測試或使用過程中如果有反饋信息則按照以下過程活動處理:a.收集、分析反饋信息客戶經理、或由項目經理指定的負責人要定期

15、的或事件驅動的收集用戶測試/使用的反饋信息(參見中創(chuàng)軟件客戶溝通規(guī)范),并對這些信息進行分析,提取 出對軟件工作產品進行變更的要求,提交給項目經理。b.軟件工作產品的變更。項目經理組織軟件工程組人員對變更要求進行評估,明確需要變更的內容項、以及受影響的軟件工作產品后提交SCCBW審,評審通過后修改相應的軟件工作產品。(參見軟件配置管理程序之變更控制)。c.測試在項目組修改完軟件工作產品后,確認測試負責人需要組織對產品中本次修改 可能受影響的部分進行確認測試。d. 發(fā)布Build n 版產品將經過確認測試,且驗證和關閉了所有已發(fā)現(xiàn)缺陷的軟件工作產品標識為“Build門版(其中n為前一個Build

16、號數(shù)字白遞增),并放入受控庫中,同時編寫發(fā) 布通知進行產品的發(fā)布。 如:XX系統(tǒng)2.0 a Build 105。從受控庫中提取產品包, 發(fā)送給用戶測試/使用。注:對于合同類項目,如果某次發(fā)版的產品通過用戶初驗,則轉入第二步一一發(fā)布3版產品;對于產品類項目,如果產品通過測試用戶的測試,并且達到了預期的功能、質量要 求,即可轉入第三步一一發(fā)布正式版產品。輸出Output1、發(fā)布通知;2、評審報告;3、軟件工作產品。輸出標準 output criteria1、2、上述各活動中,所有經過評審和測試發(fā)現(xiàn)的缺陷均得到驗證并關閉。4.2.4發(fā)布正式版產品所有對納入基線的軟件工作產品的更改都是按照軟件配置管理

17、程序進行的。輸入Input通過用戶終驗(合同類項目)或經過大范圍用戶測試、達到了預期的功能、質量要求的 產品。過程活動 Process activities1、將通過用戶終驗(合同類項目)或經過大范圍用戶測試、達到了預期的功能、質量要求的產品標識為正式的發(fā)行版本,如:XX系統(tǒng)2.0。并放入受控庫中。同時編寫發(fā)布通知進行產品的發(fā)布。2、由項目經理將受控庫訪問權限進行修改,使得任何人不能夠再對其中的軟件工作產 品進行修改。3、軟件產品的升級需經過收集信息、變更、測試、發(fā)布等各步驟,參照發(fā)布“版產品中過程活動3步驟進行。輸出Output1、發(fā)布通知;2、評審記錄;3、成為正式版的軟件產品。輸出標準

18、output criteria1、本過程活動中所涉及測試的活動中,所有經過評審和測試發(fā)現(xiàn)的缺陷均得到驗證并 關閉。2、所有對納入基線的軟件工作產品的更改都是按照軟件配置管理程序進行的。4.2.5 變更 Modification過程活動 Process activities正式版形成基線后,其更改應按照軟件配置管理程序進行,并相應更新需求跟蹤 矩陣。更改后的發(fā)布參照上述流程進行。輸出Output形成新基線的軟件產品工程各階段產品。4.2.6 度量 Measurement發(fā)版過程中應進行的度量包括:1、評審發(fā)現(xiàn)的缺陷數(shù)、嚴重程度、缺陷起源階段;2、評審產品發(fā)布上的工作量。以上數(shù)據(jù)分別體現(xiàn)在里程碑報告及項目狀態(tài)報告中。4.2.7 驗證 Verification事業(yè)部高層經理定期通過項目周報、項目狀態(tài)報告、項目月報、重大里程碑評審來評審軟件測試活動。項目經理定期通過項目例會、項目月報、重

溫馨提示

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

評論

0/150

提交評論