測試流程與規範

1 編寫目的
制定完整且具體的測試流程和規範指引，為快速、高效和高質量的軟體測試提出基礎流程框架，最終目標是實現軟體測試規範化、標準化。
明確測試團隊各個角色的工作內容，並具體指引工作細則；最佳化崗位設定，明確崗位職責，合理配置人員；加強溝通協調，提高工作效率。規範工作標準，提升產出質量與工作成果。
本規範內容根據實際工作變化情況，與提出的最佳化修改建議，不定期更新併發布，目前要求每半年更新一次。

2 測試組職能與崗位職責劃分
2.1 測試組職能
軟體測試是軟體開發過程中的重要組成部分，測試團隊主要肩負著如下責任：

2.2 崗位職責
在人力資源有限的情況下：

一個團隊成員可能會同時擔任同一專案裡面的多個角色（崗位）；
或者一個團隊成員可能會擔任多個專案裡面的同一角色（崗位）。

3 軟體測試流程及規範
3.1 測試流程

3.2 過程規範
測試相關人員把測試工作前置到專案的開始階段，提早介入測試，盡最大可能提高工作效率。測試規範根據專案&測試組目前實際情況（包括資源，成本等）制定，根據內部業務與規模的發展不定期做相應的調整。

3.2.1 需求分析
在專案的需求評審階段，測試人員需要參與需求評審，把測試工作前置，讓產品、技術、與測試人員對需求文件的理解達成共識。

3.2.2 設計評審
在專案的設計階段，測試編寫可行的測試計劃與方案，測試用例。

3.2.3 SIT 測試
測試工程師根據測試計劃和測試用例執行測試，當日提交當天的測試記錄到缺陷管理系統中，測試主管根據專案的具體進度，適當調整測試計劃。

3.2.4 UAT 測試

3.2.5 上線與驗收
測試人員與產品負責人進行上線驗收測試。驗收透過後，才能正式對外公佈功能上線。

3.2.6 注意事項
原則上，上線版本需經完整的測試流程方可更新到正式環境。只有緊急情況下才可先更新正式環境然後再提交給測試人員進行補測。補測過程與正式提測過程一致；
原則上，測試人員不得直接修改測試環境資料庫的數值、伺服器系統時間等，去檢驗迴歸的問題；
原則上，不允許本次提測的版本中又再加插其他測試內容，除非是緊急需求變更或者是修復正式環境的某個嚴重的缺陷。
報障後，第一時間做好測試跟進，並把問題填寫到缺陷管理系統上（Tapd）或指定 confluence 的 QAC 資料夾中，要新增報障日期、問題狀態等關鍵欄位。
測試組內部不定時針對生產環境問題做好總結分析，做測試改進。
3.2.7 生產環境問題處理
3.3 處理機制
3.3.1 退回機制
若在測試過程中發生如下情況，將系統退回到申請部門：
通常是指 1 級用例測試不透過，但具體要根據實際情況做判斷。
經過測試後，發現與需求說明書中定義的功能項存在較大的差異；
單一模組，測試過程中發現缺陷較多或者無法繼續進行系統其它功能模組的測試，繼續測試無意義；
測試過程中頻繁當機或者系統崩潰；
主業務流程不完整。

3.3.2 異常情況處理機制
非正式情況下，需要進行特別處理的形式：

上線後，生產正式環境發現緊急重大錯誤，需要馬上修改並更新正式環境的，可優先更新生產正式環境再提交修改後的版本到測試環境，讓測試工程師再測試。
測試過程中發現測試需要的時間與計劃的時間有很大差別，需要及時向專案經理、測試主管以及產品部的負責人彙報情況；
測試過程中測試工程師根據要求和約定，及時有效的彙報測試情況。
3.3.3 報告機制

3.4 測試完成標準
軟體產品釋出須符合以下標準：
完成計劃中所有的工作；
實現了需求定義的所有功能特性；
完成所有的測試；
嚴重的缺陷都已修正；
新發現的缺陷趨於穩定並接近零；
產品、文件都已就緒；
達到其它行業質量標準，完成計劃中所有的工作；
軟體產品未經測試合格，有嚴重 bug 時，不允許釋出：
一級缺陷、致命錯誤，100% 得到修改並且複測透過；
二級缺陷、致命錯誤，100% 得到修改並且複測透過
特殊情況由產品、開發、測試負責人等共同商議。

3.5 產出文件標準與模板
文件名稱
對應模板
測試計劃
測試方案
測試用例
測試報告