大家經常會遇到這樣的問題：
在項目中，按照計划安排，開發未在指定的時間內提交測試，占用了測試的時間，那么在這種情況下，如何做好質量控制? 簡單解釋一下，就是按照計划，開發應該在10天內完成開發提測，結果由於各種問題，開發的周期變成了13天，比預期晚了3天提測，一般來說如果項目不延期的話，只能通過減少測試的時間來趕上進度。但如果測試周期變短，測試可能會不充分，從而導致項目質量出現問題，出現線上問題。
怎么解決這個問題呢？
解決這個問題之前我們先問自己另一個問題。開發周期中，測試人員在做什么？
一般來說當開發人員在進行開發的時候，測試人員大部分時間都在寫測試用例，准備測試數據，做一些測試策略和計划的研究。這段時間內由於開發提交的代碼不能跑通E2E測試，也就是大家所說的功能測試，所以測試同學很難在這個周期開展測試。但測試有很多種類，功能測試做不了，我們是不是可以做其他類型的測試？
答案還是值得研究的，不能做全端的功能測試，我們其實還是可以做接口測試和單元測試。如果被測系統有獨立的接口，我們可以先測這些接口的邏輯，接口開發往往比最終的功能完成要快，所以可以通過接口測試提前開始測試。
再看單元測試，按道理來說，只要有代碼就可以做代碼測試，但是一般的開發可能做不了單元測試，這是技能的缺失，同樣也是項目周期和管理風格的共同決定。開發周期中，單元測試是可以做起來的，當然這很難，但是收益卻很大。
回到正題，我們可以通過提前開始測試和開展更多類型測試的方式來緩解測試周期緊張的問題。總而言之，我們的策略是把開發的周期變成測試周期，也就是所謂的測試前移。
我們再往深處想一下，有沒有一種手段可以在開發周期中自動化的做各種類型的測試呢？持續集成可以閃亮登場
假設我們有自動化的接口功能測試用例和一些穩定的UI功能測試用例，那么開發周期中我們可以反復的跑這些用例，從而保證現有的功能不要因為新功能的加入而變得不可用。這種提前的反復回歸，也可以非常有效的緩解測試時間不足的問題。
總而言之
-
測試前移：更多類型的測試
-
測試自動化： 減少人工投入
-
持續集成：每天每時每刻都在做測試