l

2019年2月19日 星期二

透過測試涵蓋率讓重構更有信心(中):突變測試

Feb. 18 23:47 ~ Feb. 19 00:39

▲Ada:切換為超人模式XD


突變測試

如果測試案例涵蓋足夠多的待測程式(System Under Test;SUT)行為,當待測程式被改變時,重新執行所有的測試案例其結果應該失敗。這代表測試案例捕捉到不正確的程式行為(與測試案例所記載的程式行為不符),突變測試(Mutation Testing)的想法就是從此而來—藉由改變待測程式的邏輯,驗證測試案例是否足夠。

***

例子

▼首先手動把withdraw程式的 amount > 0 改成 amount >1,然後重新執行測試案例。如果測試案例涵蓋率足夠多,其執行結果應該是失敗的(因為此時待測程式的行為被更改和原本測試案例所記錄的行為不同)。


▼執行結果居然是綠燈,原本三個測試案例都通過,也就代表原本的測試案例有遺漏了程式的行為,趕快補寫測試案例吧。


▼先把原本withdraw函數的程式碼復原成突變前的正常版本,然後增加一個單元測試來涵蓋剛剛程式碼突變後所沒捕捉到的行為。


▼重新執行全部四個單元測試案例,成功。


▼這時候在手動把withdraw程式的 amount > 0 改成 amount >1。


▼重新執行四個測試案例,執行結果失敗,代表程式的突變行為被測試案例抓到了。換句話說,透過突變測試技巧,進一步增強測試案例的涵蓋度

***


更多的突變

▼再看一次withdraw的程式碼,鄉民們可以試著把 amount > 0 改成 amount == 0、amount < 0,或是把 balance >= amount 改成「小於等於」或是「等於」,來驗證測試案例是否足夠。

以這個例子來看,上述各種突變狀況都可以被四個測試案例給找出來。這時候鄉民們就有相當高的信心,可以開始動手重構,因為「安全網」(足夠的測試案例)已經準備好了。

***


下集預告

withdraw函數的程式邏輯很簡單,就算沒有用突變測試技巧,也可以用傳統的邊界測試(boundary test)技巧來設計測試案例。

下一集將介紹特徵測試(Characterization Test)技巧與Approval Tests工具,針對程式邏輯複雜到爆掉且沒有人看得懂的函數,產生足夠多的測試案例來支援後續重構活動

***

廣告

對於軟體測試以及軟體重構有興趣的鄉民,可以參考泰迪軟體以下兩個課程:

***

友藏內心獨白:疫苗接踵次數要足夠才能有完整的抵抗力。

沒有留言:

張貼留言