軟體測試流程規範
測試啟動階段（需求分析）
參與軟體需求調研，以測試的角度分析需求的可測性，可構思將來對測試進行的方法、原則等。更重要的是對不可測或難以測試性問題要及時與客戶或者專案經理協調解決。
全面瞭解需求，從客戶角度考慮軟體測試需要達到的驗證的狀態，即哪些功能需要重點測試，哪些則無需測試，以便將來制定測試計劃。
測試人員參與研發人員專案需求會議，明確需求及任務完成時間，研發人員需向測試人員提供產品需求文件、詳細設計說明書、資料庫設計說明書等，明確測試任務，確定測試周期。
制定測試計劃
根據產品需求分析，制定測試計劃目標、測試內容、測試工具，給出測試參考文件、測試風險分析，對測試人員進行分工。測試人員根據專案大小及專案緊急度商討是否需要寫測試計劃。
提取測試要點
根據產品需求文件以及詳細設計文件提煉出測試要點，形成一個測試要點的文件（提取測試需求）。
設計測試用例
在拿到產品功能列表和測試版本之後，參考測試要點文件，測試人員就開始著手設計測試用例了。測試人員根據產品功能列表儘可能多的設計測試用例，儘可能多的覆蓋所有的測試需求。由評審組對測試用例進行評審——修改——再次評審——初步定稿。測試用例最好能錄入到禪道系統，以便及時跟蹤執行測試用例。
搭建測試環境
研發人員需告知搭建好的測試環境的伺服器，如需測試人員搭建環境，研發人員需提供測試環境搭建文件或手冊。準備測試資料，儘量按照真實有效的資料來測試系統，這樣更加符合業務場景。
執行冒煙測試
列出冒煙測試的主要功能、測試點。執行主要流程測試用例與測試資料，檢查主要功能是否已經基本正確實現，初步執行主要功能的效能測試，是否存在明顯的效能缺陷。對測試發現的問題定時進行歸納與總結，預測以後測試可能會存在的風險。需要每天進行一次對當天的測試情況的回顧。
執行測試用例
當測試用例設計完成之後，測試人員就開始全力實施每一條測試用例，當預期結果和實際結果不符時，這時就產生了Bug，測試人員要爭取每個Bug都能重現，便於開發修改；測試人員將Bug記錄到禪道反饋給相關開發人員，開發人員進行修復，測試人員對已修復的Bug進行再次驗證，直到Bug解決為止，把狀態置為關閉，並將測試結果記錄下來。在測試的過程中，如果出現了Bug但研發人員不認為這是Bug，這時應該與需求負責人或者產品經理一起討論判定是否屬於Bug。對於測試過程中發現的不在測試用例範圍的問題應補充到測試用例中，不斷的完善測試用例，提高測試覆蓋率。
Bug跟蹤處理
1、測試人員提交Bug=>開發人員解決Bug=>測試人員驗證關閉；
2、測試人員提交Bug=>開發人員解決Bug=>測試人員驗證未通過=>啟用Bug=>
重新解決=>測試人員驗證關閉。
測試報告輸出
在約定的測試周期內，在所有的用例都執行完，所有的Bug都修復完，測試人員需要針對本次測試專案編寫測試總結報告，將測試結果反饋，以及容易出現Bug的模組給予建議，相關負責人在下次開發中予以借鑑，避免類似錯誤的出現，測試報告輸出後，可通過郵件形式讓相關研發人員知曉。
2.測試結束條件
- 測試遇到的所有問題已經記錄下來；
- 測試覆蓋率>95％，所有測試用例都已執行，95％的測試用例已經成功通過；
- 測試結果已經記錄，測試分析報告已經提交專案經理檢查；
- 無1,2級BUG，BUG解決率大於95%；
- 基本功能都已實現，一些建議性的Bug可以在下一個版本中修復
- 如遇專案緊張，急於上線，測試人員測試基本功能沒問題，對於使用者後續發現的Bug可以進行跟蹤，可與使用者的專案對接人保持不定期的聯絡，詢問客戶使用軟體的情況；這種情況也與公司售後直接聯絡。
備註：測試流程將在以後的測試專案中慢慢的修正和完善，一旦進入測試過程中，不接受任何大模組更改，如需更改需求請走需求流程。