測試時間：不成文的原則“開發砍半”
這只是行業中對於測試排期的泛泛估計，具體情況還要具體分析，也有測試時間會遠遠大於開發時間的情況
項目前
需求評審已過，交互已明確，開發已完成技術調研，就可以輸出各個環節的排期了
測試排期和開發排期是相互依賴的，測試排期依賴開發的實現邏輯和開發量，在某些項目中開發需要測試提前補充功能場景來確認實現邏輯
具體排期輸出時間：
開發測試可以一起評估給出整體項目時間
開發模塊排期提出后，測試依據開發提測模塊排期
開發最好以功能維度提測，開發測試並行進行，縮短項目時間
項目周期，開發整體周期，單個開發人員開發時長，2D/人！=兩個人1D/人
用例設計，評審（邏輯整理）應該在提測前完成(最好在開發聯調過程中)，不延長項目周期
測試時間=功能測試時間（bug整理時間）+相關功能測試時間……同步產品功能時間+數據校驗時間+bug驗證時間+功能回歸時間……產品驗證時間……功能調整時間+整體功能回歸時間（現在預上線驗證不正常）+上線准備……執行上線……線上驗證
線上跟進（數據，功能觀察，反饋跟進）
排期要留有冗余時間：
提測前：
項目周期較長（開發超過3天，個人觀點（經驗之談）：開發測試都應該0.5天冗余）
單個開發周期超過3天，中間插入0.5小時左右溝通會（相關開發，測試加入）
單個開發周期超過5天，建議任務拆分，插入兩次溝通會
涉及跨部門聯調（開發啟動前應該確認雙方信息同步，數據，接口已溝通並落地確認，最好有文檔記錄），測試也要提前溝通
用例評審應該安排在開發提測前，最好0.5或1天前，方便產品，開發自我校驗，提高測試質量，統一功能理解，並強調關注點
提供准入用例，准備測試環境（測試使用的環境），知悉執行的數據腳本，功能所需配置
需求改動：調整測試范圍，重新考慮排期，梳理整體功能，補充用例
阻礙問題：環境，bug，再次梳理功能，可以回顧已測試功能，調整測試計划，爭取不影響整體排期