關於迴歸測試的那些面試題，都幫你整理好了！

什麼是迴歸測試?

迴歸測試就是當開發人員對軟件產品的基線版本作出任何改變時，測試人員針對這些改變進行的有針對性的測試活動。

以上所說的對軟件產品作出的改變包括:

·開發人員爲了修復一個軟件缺陷而對軟件產品進行的修改。

·開發人員在需求變動時，爲知足新的需求而對軟件產品作出的修改。·在穩定的軟件產品中加入(集成）一個新的模塊。

迴歸測試與軟件產品的基線版本有着很大的聯繫，由於迴歸測試就是針對於軟件產品的基線版本的改變所作的測試。

 

面試試題1

什麼是軟件的基線版本( baseline） ?

解答

軟件產品的基線版本就是軟件在開發的過程當中某一時刻的快照( snapshot)。在這一時刻的軟件產品的版本必定是一個穩定的版本，必定能夠做爲繼續在其上作開發的依據。

此後開發人員要繼續開發就必須在基線版本中拉出一條分支( branch)。待新的功能開發完成並通過測試穩定以後，再通過項目管理人員、開發團隊負責人、測試團隊負責人、軟件配置管理人員（SCM）檢視經過以後造成新的基線版本。須要注意的是，新的基線版本一樣必須是穩定的。

若是新的基線版本在後續的開發及測試中發現有不穩定的現象甚至是影響軟件功能或項目進度的嚴重的設計缺陷或軟件缺陷，則此時新的基線版本可能就會被拋棄。而產品將會會滾( rollback）到以前的那個穩定的基線版本。固然，這種現象不是常常發生的，也是項目相關人員最不肯意看到的。

基線版本的來源:有些軟件項目是從零開始作起的，其軟件產品經過逐步的集成會造成--個包含主要模塊而且逐步趨於穩定的版本。當其版本足夠穩定時，軟件配置管理人員會將其編譯爲基線版本，並通知項目中的其餘角色項目的基線版本已經產生。此後的開發都基於此版本。

有些軟件項目是基於之前較成功的產品進行開發的，在這種狀況下能夠挑選之前產品中較穩定併兼具擴展性的版本做爲新產品的基線版本。此後的開發都基於此版本。

面試試題2

爲何要作迴歸測試?

解答

由於迴歸測試就是針對於軟件產品的基線版本的改變所作的測試，所以經過對產品進行迴歸測試能夠。

驗證開發人員所承諾修復的軟件缺陷是否已被正確修復。

驗證新的軟件修改是否影響了原有的穩定模塊的正確性和穩定性。驗證新的軟件修改是否引入了新的缺陷。

·驗證新的軟件版本是否穩定，從而成爲新的基線版本，以備後續開發使用。

面試試題3

何時開始作迴歸測試?

解答

從迴歸測試的定義（迴歸測試就是當開發人員對軟件產品的基線版本作出任何改變時，測試人員針對這些改變進行的有針對性的測試活動）能夠看出，首先正在開發的軟件產品必須造成了基線版本。固然，這個基線版本能夠是某一個模塊的基線版本（即產品的某一個模塊的版本趨於穩定，此後在這個模塊上的開發都基於該版本)，也能夠是整個項目的基線版本。

另外，還必需要有對基線版本的修改。此時軟件配置管理人員（SCM）會將修改後的代碼編譯成新的版本，而後分發給測試部門進行迴歸測試。

面試試題4

怎麼作迴歸測試?

解答

咱們不難看出迴歸測試是貫穿於集成測試、系統測試和用戶體驗測試等測試階段的一種測試行爲。它的目的是爲了評估在以上階段中修復軟件缺陷、引入新的模塊等行爲對整個基線版本的質量產生的影響以及新的修改自身的質量。

下面以系統測試階段的迴歸測試活動爲例來說述怎麼作迴歸測試。

正在開發的軟件產品進入系統測試階段以後，軟件配置管理人員(SCM）就會爲這個能夠進行系統測試的版本打上系統測試階段的基線版本標籤（Label)，而系統測試部門就能夠開展系統測試了。

此時測試人員按照事先開發完成的測試用例及測試腳本對此基線版本進行測試。測試人員發現疑似軟件缺陷後對其進行復查並確認，若是是軟件缺陷，就將其記錄在缺陷跟蹤管理系統中以備跟蹤。這時測試人員、開發人員、項目管理人員和軟件質量管理人員就會對缺陷的嚴重性和修復的優先級進行定級。在這一輪(cycle）的系統測試結束以後，以上人員將對在缺陷跟蹤管理系統中的全部在這個基線版本上發現的缺陷進行討論，以肯定全部缺陷的修改進入到軟件新版本的日程。

同時，需求人員、測試人員和開發人員等還有可能提出新的軟件功能的需求。這些新的功能擴展的描述也將被記錄在一個跟蹤系統中(有時和缺陷跟蹤管理系統是同一系統)。這時該需求將被需求人員、測試人員、開發人員、項目管理人員和軟件質量管理人員進行討論並評估其風險(該風險包括計劃進度的風險及引入新功能對原有功能模塊的影響)。若是討論和評估經過,則開發人員就能夠開始對新的功能進行開發。待新的功能模塊通過測試而且穩定以後就能夠在某個時刻集成入原有的軟件系統中。

當以上二者狀況的修改都肯定要進入新的軟件版本時，測試人員就須要對這些修改設計新的迴歸測試計劃。

設計迴歸測試計劃的策略。

·在設計新的迴歸測試計劃時，能夠將用於覆蓋上一基線版本的全部測試用例加入到新的迴歸測試計劃中。以後，還必須加入針對新功能模塊開發的新測試用例。這種策略的優勢是測試用例覆蓋率最高，缺點是執行迴歸測試計劃人員的工做量巨大。

·另外一種策略是在新的迴歸測試計劃中只包括對全部軟件缺陷修復的驗證及對新加入功能的系統級的驗證。這種策略的優勢是執行迴歸測試計劃人員的工做量最小，缺點是測試用例覆蓋率最低。

·最後一種策略是在新的迴歸測試計劃中包括對全部因軟件缺陷修復而產生的修改的覆蓋。這就意味着除了驗證軟件缺陷的修復還必須評估這些修復對原有的穩定的模塊的影響。

所以，還必須加入一些用於驗證與被修復的缺陷有密切關係的模塊穩定性的一些測試用例。這些測試用例能夠是原有的測試用例，也能夠是測試人員新開發的用例。同理,對於新加入的功能，除了驗證其自己還要對可能被其影響到的模塊進行再一次的驗證。這種策略的優勢是執行迴歸測試計劃人員的工做量較小，測試用例覆蓋率較高。缺點是新的迴歸測試計劃的質量和測試覆蓋率受開發該計劃的人員的經驗、能力的影響較大，此外開發新的迴歸測試計劃所需的工做量也較大。

此後測試人員又回到了測試的執行階段。待測試完成以後，測試負責人給出測試報告以反映軟件的質量。當軟件的質量還不夠穩定時，就將進入下一輪的缺陷修復與迴歸測試。若是軟件的質量趨於穩定時就可對其進行檢視以肯定軟件是否符合系統測試的出口要求以進入軟件測試的下一階段。

若是對軟件測試有興趣，想了解更多的測試知識，解決測試問題,以及入門指導，幫你解決測試中遇到的困惑，咱們這裏有技術高手。若是你正在找工做或者剛剛學校出來，又或者已經工做可是常常以爲難點不少，以爲本身測試方面學的不夠精想要繼續學習的，想轉行怕學不會的， 均可以加入咱們1079636098，羣內可領取最新軟件測試大廠面試資料和Python自動化、接口、框架搭建學習資料！

 

 

咱們不難看出對軟件進行持續的迴歸測試是使軟件質量趨於穩定的一個重要手段。在一輪又一輪的迴歸測試中軟件的缺陷數量應該是一個逐漸收斂的趨勢(在不加入新的功能並不引入大量新缺陷的狀況下)。當缺陷數量或比例到達某一個預先設定的值時，咱們就認爲該軟件的質量已經知足這一測試階段的出口要求了。此時，有的公司還會對產品軟件產品進行一次全迴歸測試（FullRegression Test)。只有當全迴歸測試計劃中包括可以覆蓋整個軟件產品的全部測試用例時，這個全迴歸測試的測試報告才能被用來做爲認定該軟件的質量是否已經知足這一測試階段的出口要求的依據。