軟件測試管理辦法

1、軟件測試管理辦法（試行）1. 職責劃分1.1測試組長1. 參與軟件需求設計的評審及項目可行性分析，風險預估，測試資源的申請；2. 編制軟件測試計劃、軟件測試用例，定期進行維護更新；3. 根據(jù)測試組的冒煙測試結果判定是否接受該測試版本；如果達到測試標準則進入測試;4. 實施軟件測試并對測試過程進行跟蹤監(jiān)控，對軟件質量進行控制；5. 參與搭建測試環(huán)境；6. 編寫測試腳本；7. 與其他部門的協(xié)調(diào)和合作。1.2軟件測試工程師1. 按照測試計劃進行測試用例的執(zhí)行，維護；2. 測試記錄的整理，提交、驗證、關閉缺陷；3. 跟蹤缺陷退回的問題，必須有詳細的原因分析我們才可以進行缺陷退回缺陷的否決；4. 完成性

2、能與壓力測試。1.3質量保證QA組1. 對測試過程進行質量監(jiān)督；2. 保證項目按照正常的計劃執(zhí)行；3. 并進行階段性的質量評估。2. 作業(yè)流程詳細規(guī)定了測試組在整個項目中各個階段的職責及相關測試輸出文檔:STAGE作業(yè)過程名作業(yè)內(nèi)容/管理方法PIC輸出結果項目啟動了解和識別軟件 要求了解 <<產(chǎn)品疋義 >>中規(guī)疋的軟件相關的主要功能。參 加軟件項目啟動大會，搜集、分析軟件測試輸入內(nèi)容。測試組長軟件需求分 析報告測試相關 文檔準備測試計劃相關測試人員參加<<軟件開發(fā)計劃 >>, <<軟件開發(fā)時間表>><<軟件需求

3、規(guī)格說明>><<軟件功能菜單樹 >> 的評審會議。測試組長依據(jù)<<軟件開發(fā)計劃>><<軟件開發(fā)時間表>>編寫 <<軟件測試計劃>>測試組長<<軟件測試計劃>>測試計劃測試用例評審、封板1. 測試組長依據(jù)<<軟件需求規(guī)格說明>>,<<軟件功能菜單樹>>編寫 <<冒煙測試用例 >><<測試用例 >>并組織評審。2. 升級項目的測試用例選擇依據(jù)<<測試用例管理辦法

4、>>測試組長<<軟件測試用例>>更新測試用例完成模塊的軟件測試用例，性能測試用例、壓力測試用例；軟件需求變更時，根據(jù)更新的軟件開發(fā)計劃和需求文 檔相應變更和修改 軟件測試用例 和軟件測試 計戈y 。當軟件需求發(fā)生變更時，要及時更新測試用例。測試組長測試工程師更新后的軟件測試計劃、軟件測試用例測試版本 準備新版本發(fā)布1. 開發(fā)部準備測試版本；2. 軟件配置管理工程師進行系統(tǒng)冒煙測試版本的編 譯；軟件配置 管理工程 師冒煙測試冒煙測試3.項目測試組進行系統(tǒng)的冒煙測試；并記錄測試結 果；整理測試報告并發(fā)送給相關人員；計算FailRatio并判斷該版本是否可以進仃測

5、試；（判疋標準：模塊實現(xiàn)100%;Fail Ratio10% ;）；如果達到測試要求；軟件配置管理工程師正式發(fā)布測試版本，測試組長冒煙測試 報告測試執(zhí)行測試記錄 缺陷提交1.測試組長在項目經(jīng)理處申請相關測試資源。項目測試人員依據(jù)測試用例對該版本進行全面的測試，確保軟件所有功能的正確性，性能測試和壓力測試達到預 期結果。測試工程師測試組長項目測試日 報；項目測試周報；2.要求測試工程師將當天發(fā)現(xiàn)的缺陷在下班前提交 到QC測試工程 師QC缺陷記錄缺陷處理 缺陷確定 缺陷報告 缺陷修改 缺陷關閉3.軟件項目經(jīng)理組織對缺陷管理系統(tǒng)中提交的各個 缺陷討論和分析，確定每個缺陷是否是真正的軟件問 題,缺陷所

6、屬的模塊，嚴重程度和修改緊急度等，同時 把每個缺陷分配給相應的開發(fā)人員。軟件項目 經(jīng)理開發(fā)工程師測試工程師QC缺陷記錄4.開發(fā)人員修改缺陷后，及時將QC數(shù)據(jù)庫中的狀態(tài) 置為解決狀態(tài)。測試人員在收到新的測試版本后及時（1天內(nèi)）地驗證解決狀態(tài)的缺陷是否確實可以關 閉。如果確認缺陷已經(jīng)修改后，將QC上相應的缺陷置為關閉狀態(tài) 。測試任務表5.測試組長每周一在 & 30將測試任務表發(fā)送給組內(nèi) 成員；組內(nèi)成員按照測試任務表執(zhí)行測試；測試組長接收到開發(fā)組要求的臨時加急任務時需要更新任務 表；測試組長在周五統(tǒng)計本周的測試完成狀態(tài)并安排 下周任務；測試組長測試任務表測試報告6. 軟件測試組長匯總相關測試

7、人員的測試結果，定期總結項目測試報告；測試報告提交給軟件項目經(jīng)理和 部門經(jīng)理。7. 測試組在測試時，對變動比較大的功能； 測試組長 安排測試經(jīng)驗豐富的測試工程師執(zhí)行測試， 確保軟件 功能沒有衰退現(xiàn)象。測試組長 測試工程 師項目測試 日報項目測試 周報1退回缺陷F自的處理8.對于被軟件項目經(jīng)理置為缺陷退回狀態(tài)的記錄；要求有詳細的原因分析；測試組才可以進行缺陷的關 閉。軟件項目 經(jīng)理測試工程 師QC缺陷記錄測試工具 開發(fā)測試工具開發(fā)和 維護1.軟件測試工具研發(fā)組；根據(jù)具體測試需求進行測試 工具研發(fā)。測試工具 開發(fā)組項目總結項目總結1.開發(fā)項目結束后，軟件測試組應進行軟件測試總 結，對軟件測試管理過

8、程， 活動進行分析，為將來的 項目和持續(xù)改進積累經(jīng)驗數(shù)據(jù) .測試組長項目測試 總結報告維護測試項目上線后 客戶反饋1.當項目上線后，對產(chǎn)品的軟件進行維護和售后服 務，在此期間，測試組根據(jù)客戶的反饋的問題列表進 行專項測試；測試組長軟件專項 測試報告問題分析和修改2.軟件項目經(jīng)理組織對缺陷管理系統(tǒng)中提交的各個 缺陷討論和確定每個缺陷是否是真正的軟件問題，缺陷所屬的模塊，嚴重程度和修改緊急度等 ，同時把每 個缺陷分配給相應的開發(fā)人員。軟件項目 經(jīng)理開發(fā)工程師問題驗證和關閉3.開發(fā)人員修改缺陷后，及時通知軟件測試人員， 測試人員及時（1天內(nèi)）地驗證開發(fā)人員修改的缺陷 是否確實可以關閉。然后對所有功能

9、進行全面的測 試，確保產(chǎn)品基本功能的正確性；測試工程師測試報告3. 測試類型和策略按照目前的產(chǎn)品類型和規(guī)模，需要執(zhí)行的測試類型及策略如下:測試類型實施標準類型描述通過標準責任人冒煙測試系統(tǒng)功能集成度80%以上。剩余未集成功能不 影響已集成功能。在版本進入系統(tǒng)測試之前需要執(zhí)行的 基本功能通過性驗證。發(fā)現(xiàn)的缺陷 95%已經(jīng)解 決，其中2級以上的缺陷 100%解決。測試組長功能測試冒煙測試通過。 未集成模塊有明確 的完成日期。全部功能系統(tǒng)測試，包括：通過性、 失效性、兼容性、；視測試系統(tǒng)的成熟 度，缺陷的分布及解決情況安排測試 輪次及各輪次的內(nèi)容。1. 所有的模塊全部集成 且測試完成。2. 沒有遺留

10、的功能性Bug。3. 發(fā)現(xiàn)的缺陷95%已經(jīng)解 決，其中2級以上的缺陷 100%解決。測試工程師兼容測試可以在功能測試完 成第一輪后開始軟件在各個產(chǎn)品平臺上面都能夠正常的下載、安裝、運行、卸載無缺陷測試工程師升級測試可以在功能測試完 成第一輪后開始產(chǎn)品的升級功能測試，全包及部分更 新文件的測試。無缺陷測試工程師性能測試視系統(tǒng)的穩(wěn)定情 況，可以在功能測 試完成第一輪后開 始注冊、登錄、評論等與服務器有頻繁 交互的壓力測試，性能評估。滿足軟件設計時的性能 標準測試主導，開 發(fā)配合用戶模擬 測試功能測試完成模擬用戶日常使用，綜合各類用戶的 使用習慣設計專門的測試案例。無遺留的的用戶體驗類 缺陷測試組長

11、自由測試回歸測試通過用戶體驗測試，小范圍用戶的實際使 用，主要關注：易用性、實用性。使用者的反饋全部解答 或修改測試組長回歸測試以上所有的測試類 型通過且軟件版本 不再會有較大變化產(chǎn)品上線之前對項目中Level 3,4 級的Bug進行回歸驗證；全部通過測試組長4. 缺陷級別定義等級說明描述4嚴重錯誤由于程序所引起的死機，非法退出死循環(huán)導致數(shù)據(jù)庫發(fā)生死鎖數(shù)據(jù)通訊錯誤：系統(tǒng)與其他系統(tǒng)進行數(shù)據(jù)傳遞時出現(xiàn)錯誤交易類的數(shù)值計算錯誤，分析類的數(shù)值計算偏差在 0.2%以上沒有達到性能指標3較嚴重錯誤功能不符數(shù)據(jù)流錯誤：數(shù)據(jù)在系統(tǒng)內(nèi)部流轉中計算錯誤程序接口錯誤2一般性錯誤界面錯誤，與詳細文檔不符界面內(nèi)容、格式

12、錯誤簡單的輸入限制未放在前臺進行控制 刪除、保存操作未給出確認提示信息 輔助說明描述不清楚顯示格式不規(guī)范長時間操作未給用戶進度提示或提示信息1較小錯誤窗口文字未米用行業(yè)術語可輸入點擊區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志 系統(tǒng)處理未優(yōu)化：系統(tǒng)易用性方面的問題，例如查詢條件 值為空時通常默認為查詢?nèi)?，如果還需要用戶選擇查詢 條件為“全部”則可以認為系統(tǒng)處理未優(yōu)化0測試建議（非缺陷）系統(tǒng)設計之外的優(yōu)化建議5. 缺陷管理流程1. 缺陷描述中要包括詳細、準確的操作步驟、預期結果、實際結果、測試環(huán)境。2. 缺陷提交時在“實際結果”欄目中填寫測試數(shù)據(jù)、執(zhí)行結果內(nèi)容，盡量將缺陷的界面截圖作為附件上傳至 對應的記

13、錄。3. “否決缺陷”、“暫緩處理”此兩類缺陷要求在缺陷“注釋”中注明否決原因或后續(xù)處理方案。4. 對“緊急”級別的缺陷，測試人員應進行隨時地檢查并驗證，及時修改對應缺陷的狀態(tài)。5. 缺陷跟蹤遵循：誰發(fā)現(xiàn)誰跟蹤；開發(fā)管理組進行確認、分配缺陷；開發(fā)人員及時修改缺陷或反饋意見。6. 開發(fā)管理組人員在自己無法及時分配缺陷的情況下要提前找到代理人員完成該工作，避免缺陷在此環(huán)節(jié)滯 留。7. 開發(fā)人員必須對缺陷進行及時修改，缺陷提交后，24小時內(nèi)必須進行處理。如果開發(fā)人員沒有及時修改缺陷，則將缺陷嚴重程度的等級升級（低級 -> 中級，中級-> 高級，高級->緊急）。8. 如果缺陷經(jīng)開發(fā)人員多次修改（修改次數(shù)>2次），測試驗證后仍存在問題，則將缺陷的嚴重程度的等級升級（低級-> 中級，中級-> 高級，高級-> 緊急）。9. 開發(fā)人員必須隨時查看 QC中的缺陷狀態(tài)變化信息，每天最低查看次數(shù)不得少