時間有限下的測試選擇

昨天我們提了一個方案是每個項目花 30 分鐘寫測試，今天我們來細說一下它具體會長什麼樣子。

我們以一個例子來說明，這個例子經過些許的改編，具體的內容跟實做方法可以參加 91 的 自動測試與 TDD 實務開發，網路上也有很多學員的分享，大家也可以參考。

書店折扣的例子

書店的套書在打折出售，

1. 套書共 5 本，每本都賣 100 元
2. 如果你買了其中不同的 2 本有 5% 折扣
3. 買不同的 3 本享 10% 折扣
4. 買不同的 4 本享 20% 折扣
5. 買一套 5 本享 25%優惠
6. 如果你買 5 本但其中有 4 本不同的，最後 1 本和前面的其中 1 本相同，這樣我們只能算前面 4 本 20% 折扣，最後 1 本還是 100 元，並沒有享受到優惠。

所以以這個例子我們需要付
100 * 4 * 80% + 100 = 420

可能的測試情境

如果團隊拿到的項目是這個，那測試情境可能有

1. 只買 1 本，我們應該要付 100 元
2. 買 2 本不相同的，我們應該要付 190 元
3. 買 3 本不相同的，我們應該要付 270 元
4. 買 4 本不相同的，我們應該要付 320 元
5. 買 5 本不相同的，我們應該要付 375 元
6. 買 4 本不相同的，加上一本和前面一樣的 ，我們應該要付 420 元

還有其他的測試情境，在這裡我們並沒有全部列完。

在時間有限的情況下

假設上面就是我們花了一些時間所想出來的 6 個測試情境，那麼在 30 分鐘的時間裡要做完 6 個，一開始我們可能做不到，那我們就必需要選擇做其中的哪幾個。

這時就要看我們想要挑選哪一些測試案來寫測試，剩下的在時間有限的情況下我們就不寫了。這個方案講的就是這樣的情況，一個 Timebox 的概念。

那些沒寫測試的測試情境怎麼辦？

那些沒寫測試的測試情境怎麼辦？那些就是我們沒有把握的程式碼。還記得我們前面說過，把沒把握的程式碼交付出去就是不專業的表現，而這些程式碼可能有兩種情況

• QA 沒找到問題，那就算你運氣好。
• QA 找到問題了，我們就把它補上測試。

今天我們討論了在有限的時間裡面寫測試的實際情況，我們可以先想想這樣做有什麼優缺點，明天我們再繼續討論。