軟件測試與發(fā)布程序

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

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

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

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

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

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

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

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

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

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

11、僅需執(zhí)行其它活動，并取得用戶的書面測試報告。4.2 發(fā)布4.2.1 概述 Outline一般地， 軟件產(chǎn)品發(fā)布在整個軟件產(chǎn)品工程過程中所處的位置如下（以瀑布模型為例）軟件產(chǎn)品發(fā)布前要從以下三個方面驗證其測試的充分性：1. 測試級別：軟件產(chǎn)品是否經(jīng)過了QM卻規(guī)定的所有測試，即單元測試、綜合測試、確認測試。2. 測試策略：每個級別的測試是否都選擇了合適的測試策略。3. 測試覆蓋率：軟件測試是否達到了預(yù)定的測試覆蓋率。軟件產(chǎn)品經(jīng)過確認測試、所有經(jīng)過評審和測試發(fā)現(xiàn)的缺陷均關(guān)閉并得到驗證、且各類文檔和手冊編寫完成并通過評審后，依據(jù)配置管理計劃中的約定放入受控庫。此時的軟件產(chǎn)品進入發(fā)布階段，以“產(chǎn)品名稱+

12、產(chǎn)品發(fā)行版本號+產(chǎn)品發(fā)布內(nèi)部版本號”的形式予以 標識，如：XX系統(tǒng) 2.0 a Build 105。合同類項目的產(chǎn)品發(fā)布過程通常包括：發(fā)布a版產(chǎn)品、發(fā)布3版產(chǎn)品和發(fā)布正式版產(chǎn)品。如下圖所示：產(chǎn)品開發(fā)類項目的產(chǎn)品發(fā)布過程通常包括：發(fā)布m.n （例如：1.1 ）版產(chǎn)品、發(fā)布正式版產(chǎn)品。如下圖所示：4.2.2 產(chǎn)品的對外發(fā)布（SCM AC7當項目組要向本項目組外的個人或者組織 （如:客戶、培訓(xùn)組等）提交軟件工作產(chǎn)品時, 無論是提供給內(nèi)部用戶還是外部用戶使用，須遵循以下發(fā)布過程。 所有提交的軟件工作產(chǎn)品無論是外部使用還是內(nèi)部使用，都必須由受控庫中的配置項構(gòu)成。輸入 Input受控庫中的配置項過程活動

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

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

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

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

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

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