該規範作為測試部各項工作的指導與部門成員工作的參照執行标準。確定測試工作流程的控制，明确軟體工程的各階段測試團隊應完成的工作。
軟體測試部門工作規範
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 周工作任務統計
| 任務名 | 所用工時（天） | 詳細情況描述 | 工作結果 |
4.2.2 Bug統計表
| New（新錄入bug數） | Reopen（重開bug數） | Closed（關閉bug數） | Reject(開發拒絕bug數) |
填寫說明：
- 描述本周做了哪些工作，每項工作大概使用多少工時（機關：天），情況如何。
- 對本周的bug情況進行總結。
4.2.3 工作月報
月報内容包括：
1）本周主要任務分布：（%）
| 項目名稱 | 測試任務（天） | 文檔編寫/修改（天） | 外部技術支援（天） | 其他（天） |
| XX項目 | 10 | 20% | 50% | 20% |
- 對本月的工作做一個歸納總結，描述每個項目中每個任務占用工作天數。
- 對當月發現的問題進行總結，任何方面的問題都可以，并簡單分析一下産生問題的原因，給出一些建議和意見。