大家好哪廓，我是十一缘揪。
前情回顧
我們先來回顧下上篇內(nèi)容：
回歸測試
概念：回歸測試是指修改了舊代碼后博烂，重新對相應(yīng)缺陷（bug）以及相關(guān)功能點進行測試证逻，以確認修改有效乐埠，且修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤。
目的：為了驗證修改的正確性及其影響囚企。
內(nèi)容：測試被修訂的bug或者新功能丈咐；還要測試與其相關(guān)的已有功能。
本章內(nèi)容
上節(jié)課我們介紹了何為回歸測試龙宏，為什么要回歸測試以及回歸測試的內(nèi)容棵逊，今天呢就來講剩余的最最重要的部分：怎樣回歸測試（回歸測試的策略+實踐）。
回歸測試的策略
回歸測試作為軟件生命周期的一個組成部分银酗，在整個軟件測試過程中占有很大的工作量比重辆影，軟件開發(fā)的各個階段都會進行多次回歸測試徒像。在漸進和快速迭代開發(fā) 中，新版本的連續(xù)發(fā)布使回歸測試進行得更加頻繁秸歧，而在極限編程方法中, 更是要求每天都進行若干次回歸測試厨姚。因此，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是非常有意義的键菱。
通常我們做回歸有如下幾種方式：全部回歸谬墙、只回歸修改部分、主線功能回歸经备。下面一一介紹：
ps:
介紹之前我們先來回顧下測試用例庫：我們在對一個產(chǎn)品進行測試之前亲族，都會編寫測試用例项炼，且所有測試用例必須存以及檔入庫，以便后續(xù)測試使用。
全部回歸
再次對測試用例庫中的所有測試用例進行測試顽分。
這其實是最安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風(fēng)險佃乘，它幾乎可以應(yīng)用到任何情況下凳谦，且?guī)缀醪恍枰M行分析。但是也正是因為這樣犁功，此方法的測試成本極其高昂氓轰，隨著開發(fā)工作的進展，測試用例會不斷增多浸卦，那么測試用例庫就會不斷的增大署鸡，如果我們每次回歸測試都將這么極其龐大的測試用例庫跑一遍，可想而知這個工作量有多么龐大限嫌，其預(yù)算和進度將會遠遠超出我們的預(yù)期靴庆。
有人會說那如果我們的自動化測試很完善呢？我們就可以都做全部回歸了怒医！那我認為也不能實現(xiàn)每次提交代碼都全部回歸炉抒，因為自動化測試很完善，意味著本身自動化測試集也是一個大家伙裆熙，他的執(zhí)行也是需要時間的端礼，如果大家提交很頻繁，每次提交都執(zhí)行全部的自動測試集的話入录，可想而知蛤奥，如此高壓高強度的工作服務(wù)器也難當重任呀，遲早崩潰僚稿！正確做法是：定時執(zhí)行全部回歸（自動測試腳本）以及上線前執(zhí)行凡桥。
只回歸修改的部分
當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況蚀同，并分析修改的影響缅刽，將回歸測試局限于被改變的模塊和它的接口上啊掏。
通常，一個回歸錯誤一定涉及一個新的衰猛、修改的或刪除的代碼段迟蜜。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分啡省。
這個方法對測試人員的要求還是很高的娜睛，需要測試人員不僅要熟悉業(yè)務(wù)，還要能看懂代碼且了解代碼結(jié)構(gòu)卦睹。這么來看這個方法風(fēng)險還是很高的畦戒，那么項目規(guī)程可以做稍微改進下，如下：
要求開發(fā)修訂bug后在缺陷管理工具上直接標明影響范圍结序，測試只做審核和實施障斋。
這樣是不是簡單很多且更準確點？畢竟開發(fā)是代碼的創(chuàng)造者徐鹤，他能準確知道代碼結(jié)構(gòu)和其相依性垃环。
主線功能回歸
軟件程序最最常用的功能一定是它的主線功能；比如：淘寶的主線功能就是搜索物品-->點擊購買-->支付-->快遞-->收貨返敬。那淘寶的每次修訂bug或者發(fā)布更新晴裹，如果都能保障主線功能跑通的，那大概率不會出現(xiàn)重大失誤救赐。因此在時間和成本都不足的情況下，我們對主線功能回歸測試是一個不錯的選擇只磷。
回歸測試實踐
通常我們在什么情況下需要回歸測試呢经磅？大致歸為以下幾種情況：
?????? · 開發(fā)修訂了bug
?????? · 版本發(fā)布
?????? · 新功能提測
三者的共同點是期間代碼都發(fā)生了變化；不同點是影響范圍不同钮追，當然回歸范圍也不同：
?????? · 開發(fā)修訂了bug：影響較小预厌，很容易獲悉影響范圍，以及回歸測試用例的選擇元媚；
?????? · 版本發(fā)布/更新：每次版本的發(fā)布或者更新轧叽，都必須保障原有功能的正確性以及新功能的正確性；因此回歸測試的范圍必須是全面的刊棕；
?????? · 新功能提測：新上線的功能炭晒，我們首先要保障新功能的正確性；另外保障它沒有影響與其相關(guān)聯(lián)的功能甥角，即保障其相關(guān)功能的正確性网严。
我們來總結(jié)下其上三者的回歸策略的相同和不同之處：
?????? · 相同之處：三者在回歸時均要回歸修訂過的部分（針對bug）和新增加的部分（針對新功能），保證變動的代碼的正確性嗤无；
?????? · 不同之處：開發(fā)修訂了bug和新功能提測這兩者只需要回歸相關(guān)聯(lián)部分即可震束，而版本發(fā)布/更新要回歸整個產(chǎn)品怜庸，確認產(chǎn)品可用，無明顯bug垢村。
以上都是針對手工測試來說的割疾；如果自動化部分做的很好，我們則可以在新功能提測嘉栓、版本更新/發(fā)布以及固定時間（1天或者一周）執(zhí)行一次全部回歸（執(zhí)行自動化測試用例腳本）宏榕。這樣更能及早的發(fā)現(xiàn)bug，從而保證產(chǎn)品的質(zhì)量胸懈；當然這樣做的前提是必須先回歸變動過的部分担扑，確認變動部分正確，且需要做到實時更新和補充測試用例和自動化測試用例腳本（這樣做才能保證測試用例和自動化測試腳本的完整性趣钱、正確性）涌献。
總結(jié)下：回歸測試需要兩部分，回歸變動的部分（修訂的bug和新增的功能）以及回歸影響的部分首有。
好了燕垃，今天的內(nèi)容到此結(jié)束。我們下期再見井联！
