殺蟲劑悖論 pesticide paradox
大家應該都聽過，不斷使用某牌的殺蟲劑，最後該環境的蟲子就開始對那牌的殺蟲劑產生抗性。
殺蟲劑漸漸無效，蟲子開心的吃著火鍋唱著歌。
殺蟲劑悖論是測試領域的一個名詞，也如同字面上的意思，產品會漸漸對不斷執行的「相同測試案例」有抗性。
同樣的一組測試案例會漸漸無法發現產品的問題。
所以測試案例需要不斷更新維護，嘗試發現其他問題。
（全文完，大家看到這邊就可以了。）
以下是幹話時間
「為什麼？難道產品是活的，還懂得怎麼搞事嗎？」聽到殺蟲劑悖論時，剛進來的 QA 實習生 A 覺得很驚訝。
「產品是死的，但 Dev 是活的。」資深的前輩 R 又說了讓人無法頓悟的話，然後喝了一口茶。
實習生 A 和前輩 R 並不重要，等一下也不會再提到他們。
為什麼會有殺蟲劑悖論的現象
假設現在有一個非常簡單的產品，這個產品做的就是輸入1個數字，然後顯示這個數字+10之後的結果。
透過一些門路，我們知道產品的 code 長這樣（因為是黑箱測試，測試的人並不知道喔）：
num = int(input("Input a number..."))
print(num + 10)
規格書有說，不輸入就當作0的意思。
對了，這個故事不幸的是，這間公司為了縮減開銷，把 QA 都裁掉了。
現在剩下便宜大碗的實習生 aka 血汗萬用雜工照著前人留下的測試案例來測。
我們現有的測試案例是這樣：
- 輸入正整數 預期結果：正整數+10
- 輸入負數 預期結果：負數+10
- 不輸入 預期結果：10
- 輸入小數 預期結果：小數+10
第一次測試，我們火眼金睛的實習生立刻發現，這個產品在不輸入和輸入小數時會壞掉，於是開2張單請 Dev 修：
- [PDADDNUM-100] Throw an error if no input
- [PDADDNUM-101] Throw an error if a number with a decimal point
我們的 Dev 連夜趕工修好了：
num = 0
input_num = input("Input a number...")
if input_num:
print(float(input_num) + 10)
else:
print(10)
第二次測試，現在不輸入沒問題了，關了一張單(PDADDNUM-100)。
不過實習生眉頭一皺，發現現在顯示的數字都會帶小數點，有點怪怪，規格書也覺得不行。
實習生又開了一張單：
- [PDADDNUM-102] Display number with a decimal point
Dev 又火速修好了：
num = 0
input_num = input("Input a number...")
if input_num:
try:
int(input_num)
print(int(input_num) + 10)
except:
print(float(input_num) + 10)
else:
print(10)
第三次測試，這次全部的測試都通過了，產品無懈可擊！
產品交付後，不知道這間公司燒了多少香，客戶聰明乖巧，只輸入數字，每個月還會繳一些維（讀作：ㄅㄠˇ）護費。
產品每次的測試也都順順利利，歲月靜好。
大家相安無事的過了一陣子。
直到客戶那邊來了一個新人，新人不熟這個系統，輸入了"one"，產品噴出錯誤訊息，密密麻麻的異世界文字嚇到了客戶，客戶真的喔氣氣氣氣氣！為什麼這個產品這麼爛？我們花了大錢就拿到這種品質的產品？
大家都很錯愕，啊測試都過怎麼會這樣？
最後公司撥了一筆經費採購乖乖。
匿名朋友 J 的經驗
朋友J以前在知名大公司當 QA，因為意外上到某加密貨幣起飛的車，現在已經離職，過著半退休的生活。
朋友 J 回憶道：
那個時候我們公司的測試案例來到1萬多條。
主管當年的目標就是衝測試覆蓋率、提升產品通過率，底下的大家也朝著這個目標全速前進。
大家專心寫各種新功能的測試案例，測試案例一寫完就會交給自動化團隊寫成每天跑的自動化測試。
那就不是測試嘛，是回歸測試啊。我們的東西甚至一開始也沒人手動測看看，一開始就自動。
最可怕的是，我們測試的字串永遠是同一組，一輩子，永遠的用下去。
看著 pass rate 越來越高，主管開心，大家開心，相信產品品質一定和 pass rate 一樣越來越好。
朋友 J 忽然打開了前公司的 APP，把手機遞給我看，一邊操作、一邊說：「你看我最近用就發現幾有個 live issue。」
留言
張貼留言