軟件測試部測試工作規范

　　測試部測試工作規范

　　1、目的

　　規范專用測試組工作內容和工作流程，通過規范化的工作模式，提高專用測試組的整體工作效率。

　　2、產品測試工作要求

　　2.1 測試工作流程

　　測試工作流程圖如下：

　　2.2 詳細說明

　　2.2.1 初始

　　從項目經理或研發工程師處獲得產品的產品測試計劃情況，包括版本號、計劃完成時間、需求內容、修改內容等，根據不同產品的需要與任務發起人討論產品是否是可測試的。

　　2.2.2 計劃

　　根據產品測試計劃的時間和需求范圍制定測試計劃，選擇已有的測試用例，編寫新功能的測試用例，明確每一輪測試所要用到的用例有哪些，用例的選擇要經過評審確認。

　　輸出：測試計劃、測試用例或測試大綱

　　2.2.3 執行

　　收到提交測試的產品包后，首先須進行冒煙測試，保證基本的安裝/卸載過程正常，數據流正常，才可以進入功能測試。

　　每一輪的測試要將已經確定的測試用例完整執行一遍，將一輪測試中發現的bug更新到團隊任務管理系統的當前工作計劃中，通知研發工程師進行修改，所有的bug修改完成后才可以提交完整包進行下一輪的測試。在下一輪測試開啟前，允許研發工程師提交兩次文件，以替換的方式進行bug驗證，bug驗證通過后再要求開發打包提交進行下一輪測試。

　　輸出：bug列表，階段性測試報告(每一輪測試執行完成后發出)

　　2.2.4 收尾

　　內測完成后要編寫內測報告，編寫版本發布說明、用戶手冊、安裝說明文檔等配套文檔。對于一些子模塊的入庫，可以不提供用戶手冊。

　　輸出：內測報告、版本發布說明、用戶手冊(可選)、安裝說明文檔

　　2.2.5 完成

　　測試通過的包需填寫設計變更通知單并通知工程部，將程序打包上傳到FTP服務器中RELEASE目錄下指定的子目錄，并通知輸出給工程部后認為是測試階段完成。

　　輸出：設計變更通知單

　　2.2.6 注意事項

　　提交的測試工作計劃，要檢查是否符合入口標準，如果描述不清晰、不準確，或者存在明顯的產品命名、版本號不正確之類的錯誤，要求開發修改后重新提交測試申請。

　　保證每一輪都將測試用例跑完，再將bug提交給開發人員，要求開發人員將bug全部修復完成之后再提交測試，如果只是部分修改，除非有合理的理由，否則不接受測試。

　　3、外部技術支持工作

　　3.1 工作流程

　　3.2 詳細說明

　　3.2.1 初始

　　外部問題的提交最好采用郵件的形式進行交互，測試人員收到問題后認真查看問題的描述，如果對于問題描述有不理解的地方直接與問題提交人進行交互。

　　3.2.2 分析

　　判斷問題是否為已知缺陷，如果是已知缺陷，直接答復給問題提交人處理問題的方式。

　　如果不是產品的已知缺陷，需要在現場重現此問題，分析定位問題發生的原因，將分析結論轉給開發人員，由開發人員給出解決方案。同時，要把問題填寫進bug管理系統。

　　3.2.3 收尾

　　給出問題解決的報告，報告內容包括分析定位的結論、如果是已知缺陷給出解決方案。報告要發給問題提交人，抄送給測試主管和產品經理。

　　3.2.4 完成

　　與問題提交人確認問題是否解決，若已解決，則任務完成。

　　3.2.5 注意事項

　　問題的交互最好都采用郵件的方式，以保存問題交互記錄，作為追溯和工作記錄的依據。

　　對于新發現的問題如果是產品缺陷，一定要填寫bug，無論是否已通過其他手動方式解決。

　　4、其他要求

　　4.1 bug填寫說明

　　bug填寫時要描述清楚以下幾個方面的內容：

　　測試時的操作步驟，描述清楚測試的時候是如何做的操作。

　　問題現象，最好可以附上截圖。

　　測試分析結論、建議，給出測試的分析結論。

　　4.2 周報/月報填寫說明

　　4.2.1 周工作任務統計

原文轉自：http://www.anti-gravitydesign.com