目前（2021.10.20）測試執行過程中實際測試流程【重點看】
【需求評審】——>【案例編寫】——>【案例評審】——>【開發提測，冒煙演示】——>【冒煙通過】——>【測試環境執行用例】
——>【通知驗收】——>【測試環境測試完成】——>【通知開發上stage】——>【stage測試】——>【stage環境測試完成】
——>【測試編寫上線測試報告】——【開上線會】——>【泛微通過上線單審批通過】——>【運維上線】——>【線上數據准備】
——>【線上環境驗證】——>【線上數據復原下架等】
測試環節中不同節點注意事項
- 【案例評審】：一般是評審導圖，研發+產品+測試+其他參與者根據實際需要。
- 【用例編寫】：如下圖，通常情況下，測試用例包括如下三部分：場景測試，功能測試，冒煙測試；
場景測試用例主要是針對項目的整體業務邏輯進行場景設計。
功能測試用例主要是對各模塊內基本業務（場景中需要使用的基本業務需要重點編寫）進行覆蓋。
冒煙測試用例主要提供給開發進行提測前的自測。思維導圖主要是編寫測試用例前對測試業務邏輯的梳理；
- 【通知開發提測，冒煙演示】：提測前需要開發填寫提測單。 冒煙需要建立冒煙測試單，測試單前面增加【冒煙】，關聯對應冒煙用例，給開發執行！（關乎績效）
- 【冒煙通過】：沒有嚴重bug就可以判斷為測試通過，冒煙bug禪道提交跟蹤。
- 【測試執行】：
1、測試的環境為05環境，測試人員自己發版，開發不可發版。測試根據建立測試環境測試單，測試單前最好添加【test05】，測試單時間為測試案例實際執行起止時間（關乎績效）。
2. 測試階段所有的bug都在禪道中記錄，測試過程中所有bug提交禪道跟蹤，並及時跟蹤bug的解決情況，開發已解決的bug及時指回給測試回歸。
3.所有的測試活動都在測試用例中體現。
4.有需求變更的情況，及時更新測試用例。
5.各項目涉及到前后台開發的，允許前台后台分部提測。后台先提測的，開發保證后台的冒煙用例自測通過；前台提測后，開發保證主流程冒煙用例自測通過。
6.開發的冒煙測試用例執行通過並提測后，測試環境內部的測試過程包括：
a. 先執行冒煙測試用例，驗證開發是否真正執行了冒煙測試，冒煙測試未通過的，上報給測試部門和項目，開發修改並繼續執行冒煙測試。
b. 冒煙測試通過的，根據測試用例執行測試，優先執行場景測試用例，以便盡早發現整體業務邏輯是否有問題，有阻止的提bug並在群里及時通知開發。阻止的bug一個小時內未解決的，通知開發主管或測試部門協作解決。場景測試阻止時或者場景測試執行完后，再執行功能測試用例。
c.測試執行階段，每天先跟蹤修復的bug，再執行計划中的用例。
d.原則上，所有的用例執行通過，所有1,2,3級的bug關閉，並且回歸測試沒有問題的，可以發布到Stage環境驗證。
e.有問題群里討論！
- 【通知驗收】：通知人：產品+UI，通知節點：測試到90%左右就可以通知驗收了。
- 【測試環境測試完成】：完成標准: 測試環境bug都已經解決關閉，案例執行100%，允許有遺留bug，但是遺留bug必須經過產品+開發+測試+其他人員根據實際情況的一致同意！
- 【通知開發上stage】: 一般情況，盡量上線前一天（或者更早，根據項目大小確定）上stage，給stage測試留時間。備注：項目緊急情況下是否上stage酌情處理！
- 【stage測試】：
1、在Stage環境，測試根據建立stage環境測試單，測試單前添加stage字樣，測試單時間為實際測試時間，不要和測試環境測試單是一天（關乎績效）。
2、stage環境重新執行用例，根據stage環境發布的時間來決定全部用例執行還是抽取典型用例執行。stage環境驗證無誤后，生產環境上線。
3、stage不能測試的場景需要評估風險！
- 【編寫上線測試報告】：上線報告模板根據公司實際情況
- 【開上線會】：主要是同步一些上線事項，一般是開發TL發起，也可能其他人。生產環境測試發現風險點需要同步評估風險！
- 【泛微通過上線單審批通過】：發起人為開發TL，流程經過測試時需要填寫confluence的測試報告鏈接。
- 【線上驗證】：上線驗證本次上線內容和必測場景。
生產環境驗證checklist：
備注：以上為一般情況測試流程，實際測試過程中可能會有小出入，根據項目酌情處理。