1.引入版本控制的原因

錯誤觀念：軟體測試不需要版本控制。

• 1
• 2

測試過程中發現的bug提交給開發人員，開發人員在對提交的bug進行修改，bug修改後開發人員會將修改後的程式碼放入當前的軟體版本之中，導致軟體測試版本釋出過於頻繁，測試版本不穩定，導致修改過的bug再次出現，測試重複、失效和混亂。測試進度無法保證，同時不便於追溯跟蹤問題。
原因是：對於修改過的程式碼，不能夠保證他們一定是正確的，很可能在開發人員修改過之後，仍然是錯誤的，或者在修改過之後仍然會給軟體帶來別的問題，測試人員對新提交的程式碼以及之前的程式碼都要再次進行驗證，進行排錯，來確保不會因此而帶來新的隱患，新的漏洞，導致大量重複測試。
引入版本控制的好處：提高開發和測試的效率，提高軟體版本穩定性，便於追溯問題。

2. 版本控制的定義

1、版本控制物件：
開發提交給測試的產品版本。
測試人員提交的bug到了開發人員手中之後，開發人員針對這些bug進行修復工作，並且將修改後的程式碼放入程式中，作為新的軟體版本，而不能直接替換到現有的測試版本中去。

2、版本控制定義：
測試版本的交付在專人控制之下，對每次測試的版本有明確的標識（新增加的功能、修復的bug等），不同版本可以看到穩定度趨勢，每個版本的測試狀態。

3. 版本控制方法

1. 制定合理版本釋出計劃，加強版本控制管理。
協商測試版本釋出及釋出頻率：制定版本進度計劃，該計劃中包括開發團隊提交不同版本的計劃時間、每個版本中新增功能模組列表、提交版本的要求、修復的bug列表等。
測試版本釋出基礎：

2、強化測試准入條件
測試啟動條件：功能是否開發完成、有沒有進行自測（自測報告，避免出現版本質量太差）、軟體版本說明（清楚每一次版本更新都修改了什麼，會對哪些功能造成影響）。
開展冒煙測試：保證系統能跑的起來，不至於讓測試工作做到一半突然出現錯誤導致業務中斷，如果最基本的測試都有問題則直接打回。

（開發人員在試圖解決一個問題的時候，造成了其它功能模組一系列的連鎖反應，原因可能是隻集中考慮了一開始的那個問題，而忽略其它的問題，這就可能引起了新的Bug。）

冒煙測試的通過標準：基本的功能和流程通過就可以。（測試場景/點可以提供）
軟體提測後注意事項：非bug fix的修改，必須周知（如重構），Bug fix涉及的程式碼，程式碼review，明確迴歸範圍，減少質量隱患。

3、強化bug管理
bug內容（發現版本，對應人員，發現模組，迴歸次數，bug關閉的版本號），可以分析不同版本和不同模組bug走勢。
發現此次迭代範圍外的之前遺留的bug，測試記錄後，和開發及專案管理人員商討是否解決，解決方式（程式碼限制OR操作說明中限制），是否佔用此次迭代的開發時間。

4、版本控制文件管理工作
版本資訊、測試記錄、測試結果（開發和測試活動的追溯）

5、及時溝通

4. 版本控制評價標準

效率和質量。

• 1
• 2

5. 如何降低測試的輪次

（轉測版本最多不超過4輪測試，一般控制在3輪。一般在2到3個版本時，就很難發現缺陷。版本越多，質量隱患越大。）

• 1
• 2

保證開發和測試的獨立性：打的包，部署的環境，儘量連線181的服務。測試環境和開發環境分開，儘量做到測試資料不會被開發人員修改。
明確測試需求：需求功能點全部實現，如果有需求不能在規定時間完成，需要在需求階段提出，而不是在測試階段完善需求，從而加長了開發和測試時間，影響效率。
細化提測標準：開發到什麼程度可以接受測試。
預測試：達到送測標準，在伺服器上取下測試的版本，編譯、部署後，對部分主要的功能進行預測試，如果預測試通過了，就可以開始測試。如果預測試不通過，就打回開發部門修改好後再預測試，直到預測試通過為止。
控制需求的變更：變更了軟體需求一定要有記錄和說明，相應的測試用例及時追加和維護。
進行bug分級：介面和易用性的bug等到開發完成和重要bug解決完畢再改。
增強質量意識：上線前臨時改程式碼修復問題或者臨時口頭追加的變動要有記錄，要通知一下。

6. 測試環境的維護

開發文件和產品需求文件生成或者變動後請周知一下，保證測試使用者及時編寫和維護。
測試環境最好是專人維護（開發、運維、測試），頻繁和擅自發布新功能或者修改是不可取的。保證版本的統一性很重要。
測試人員提交的bug到了開發人員手中之後，開發人員針對這些bug進行修復工作，並且將修改後的程式碼放入程式中，作為新的軟體版本，而不能直接替換到現有的測試版本中去。

程式碼提交 ，review後再部署，直接打包部署的程式碼不能保證完整 （提交衝突，和程式碼後釋出失敗等）

轉載自：（原文）https://blog.csdn.net/u010005040/article/details/80277011