回歸測試的策略
（1） 可以選擇完全重復測試。把所有的測試用例，全部再完全的執行一邊，以確認問題修改的正確性和修改后周邊是否受到影響。
缺點：由於要把用例全部執行，所以會增加項目成本，也會影響項目進度。所以很難來完全執行，所以引出了回歸測試策略
（2） 可以選擇性重復測試。可以選擇一部分進行執行，以確認問題修改的正確性和修改后周邊是否受到影響。
那么我們怎樣去選擇用例呢？這里有三個方法：
（1）覆蓋修改法，針對發生錯誤的模塊，選取這個模塊的全部用例進行測試。這樣只能驗證本模塊是否還存在缺陷，但不能保證周邊與它有聯系的模塊不會因為這次改動而引發缺陷。
（2）周邊影響法，除了把出錯模塊的用例執行之外，把周邊和它有聯系的模塊的用例也執行一遍，保證回歸測試的質量。當然我們還可以用量化的角度去分析模塊的質量，比如：經過上面的一系列回歸測試后，看看遺留的缺陷率是否已經在允許的范圍之內了，那么我們以此為標准可以結束本次回歸測試。
（3）指標達成法，在測試全部完成后，看看我們有沒有達到既定的指標。
3.回歸測試的流程
1．在測試策略制定階段，制定回歸測試策略
2．確定回歸測試版本
3．回歸測試版本發布，按照回歸測試策略執行回歸測試
4．回歸測試通過，關閉缺陷跟蹤單
5．回歸測試不通過，缺陷單返回開發人員．等重新修改，再次做回歸測試．
每當一個新的模塊被當作集成測試的一部分加進來的時候，軟件就發生了改變。新的數據流路徑建立起來，新的I/O 操作可能也會出現，還有可能激活了新的控制邏輯。這些改變可能會使原本工作得很正常的功能產生錯誤。在集成測試策略的環境中，回歸測試是對某些已經進行過的測試的某些子集再重新進行一遍，以保證上述改變不會傳播無法預料的副作用。
在更廣的環境里，（任何種類的）成功測試結果都是發現錯誤，而錯誤是要被修改的，每當軟件被修改的時候，軟件配置的某些方面（程序、文檔、或者數據）也被修改了，回歸測試就是用來保證（由於測試或者其他原因的）改動不會帶來不可預料的行為或者另外的錯誤。
回歸測試可以通過重新執行所有的測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具來進行。捕獲回放工具使得軟件工程師能夠捕獲到測試用例，然后就可以進行回放和比較。回歸測試集（要進行的測試的子集）包括三種不同類型的測試用例：
* 能夠測試軟件的所有功能的代表性測試用例。
* 專門針對可能會被修改影響的軟件功能的附加測試。
* 針對修改過的軟件成分的測試。
在集成測試進行的過程中，回歸測試可能會變得非常龐大。因此，回歸測試應當設計為只對出現錯誤的模塊的主要功能進行測試，每當進行一個修改時，就對每一個程序功能都重新執行所有的測試是不實際的而且效率很低的。
4.最后，我想說的
其實，之前從來沒有做過類似的作業，把自己每周學到的東西寫成技術博客分享到這上面來。其實一開始真的覺得很無聊，也覺得沒什么大用處，但后來我的想法完全改變了。這種方法不僅可以督促我們的學習進度，幫助我們學到更多的關於軟件測試的內容，還可以幫助同學們和網友們互相交流經驗分享日常學習到的知識。有不會的問題只要在找找看里搜索關鍵字就可以看到很多相關專業的朋友們分享的知識，這令我覺得受益良多。
下一屆的學弟學妹們~~等你們做這個作業的時候歡迎來這里交流經驗喲~那么~先拜拜啦~