該規范作為測試部各項工作的指導與部門成員工作的參照執行標准。確保測試工作流程的控制，明確軟件工程的各階段測試團隊應完成的工作。
軟件測試部門工作規范
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數) |
| 0 |
0 |
0 |
0 |
填寫說明：
-
描述本周做了哪些工作，每項工作大概使用多少工時（單位：天），情況如何。
-
對本周的bug情況進行總結。
4.2.3 工作月報
月報內容包括：
1）本周主要任務分布：（%）
| 項目名稱 |
測試任務（天） |
文檔編寫/修改（天） |
外部技術支持（天） |
其他（天） |
| XX項目 |
10 |
20% |
50% |
20% |
填寫說明：
-
對本月的工作做一個歸納總結，描述每個項目中每個任務占用工作天數。
-
對當月發現的問題進行總結，任何方面的問題都可以，並簡單分析一下產生問題的原因，給出一些建議和意見。