哪一種測試方法能更好地檢測軟件修改中的bug？來看看回歸測試與背靠背測試的比較吧

定義

ISTQB將回歸測試定義為對已經測試過的程序或修改后的部分功能的重新測試。其目的是證明沒有由于所做的更改而引入錯誤狀態或以前掩蓋的錯誤狀態暴露。

ISTQB將背靠背測試定義為通過對所有變量執行相同的測試用例并比較結果來比較被測系統的兩個或多個變量，或者相同被測系統的仿真模型。

這兩種動態測試方法之間的主要區別是測試資料庫的類型。測試資料庫是測試用例成功的評估基礎。

在回歸測試中，評估基于從需求中得到的預期結果。在背靠背測試中，預期結果是與另一個軟件版本相同的行為。

在我們看來，如果想要做出或確定關于函數行為的聲明，那么回歸測試是合適的。如果測試與需求聯系在一起，那么功能和需求中的bug就可以被清晰明確地分配和評估。

持續集成和持續測試(CI/CT)環境代表了回歸測試的自動化。在大多數配置中，基于更改執行每天的測試。通過CI/CT構建計劃，只執行對產品有影響的測試。

當參考內容，例如軟件的原始版本高度可信時，背靠背測試是非常適合的。當從模型生成代碼時，就會出現這種情況。如果模型已經經通過了廣泛的測試，則給出了較高的置信度。

在實踐中，特別是對于浮點運算中的轉換，背靠背的測試設置可能是具有挑戰性的，例如，當將模型轉換為C代碼時。

乍一看，設置公差似乎很簡單。

當信號級聯時，錯誤會傳播，必須重新考慮將最小有效位(LSB)設置為容差值。如果選擇的公差太小，測試將出現錯誤并失敗。如果選擇的公差太大，測試總是通過，背靠背測試就失去了意義。因此，正確的設置在技術上成為一項艱巨的工程任務。

總結

在TPT中，可以同時執行回歸測試和背靠背測試，并且可以在一次執行中結合這兩種測試方法。

我們建議測試經理在選擇測試方法并做出一個有意識的決定之前，通過進行他們自己的調查，從努力和利益的角度檢查操作的適宜性。