儒道哲學的浪漫人生

　　上一篇談到了 Automation Test Code Review 的重點應該放在產出的 Test Case 上面，那這一篇就來講講 Automation Test Case 應該符合哪些簡要的原則，也就是當你要幫同事做 Automation Test Code Review 時，可以針對這幾點去做審查。

1. 一個Test Case 只測試一件事: 在 Test Code 中，每一條 Test Case 應該都只專注在一個要測試的點，例如測試    POS 系統的點餐功能，測試點就應該放在點餐這件事上，其中可能要驗證的點包含點餐是否餐點名稱正確，數量也對嗎?單價有沒弄錯? 之類，但該測試不該包含結帳功能的驗證，那是另外的   Test Case 該做的事。
2. Test Case 的 驗證點足夠: 如上面所說，光一個點餐，可能要驗證的點就不只一個，因此在   Test Code 是否有包含到該功能所有要驗證的檢查點，也是要評審的要點之一。
3. Test Case 可以獨立執行: 與手動的   E2E 測試不同，Automation Test Case 執行時，為了確保執行結果的正確性以及效率(能夠平行執行多條   Test Case)，每一條   Test Case 都應該盡可能地能夠獨立執行，不與其他     Test Case 產生相依性，例如點餐可能一開始要先開一張新的訂單，然後才能在訂單上點餐，那麼開新訂單的動作就應該在該   Test Case 的執行步驟中實現，而不要倚靠其他開新訂單的    Test Case 結果來拿到一筆新訂單。
4. Test Case 擁有自己的 Test Data: 也因為要確保每一條 Test Case測試的獨立性，因此每一條 Test Case 都應該有自己的   Test Data，避免使用其他   Test Case 的 Data 或分享自身的    Test Data 給其他   Test Case，這樣才不會因為某個     Test Data 有問題而影響其他Test Case的執行結果。
5. 關注點分離(SoC): 每一條   Test Case 的 Test Method 中只針對要測試的對象加入驗證斷言(Assertion)，其他非測試   Method (只是用來讓測試對象浮現的   Method )不要有任何驗證，其實依然是指一個   Test Case 只測試一件事，只是這裡更強調只針對該驗證的驗證，不該驗證的不要驗證，讓測試的目的真正有意義也被測試。
6. Utility 代碼: Test Case 中某些    Function 可能也常常被其他    Test Case 或    Test Method 用到，則這些可重複使用的代碼應該單獨拉出來放到工具箱做有用的Utility，例如API 的內容都需要加密的加密函數，就可以拉出來成為Utility的一個Function，這樣其他的API Test Case也就可以調用呼叫了。
7. Wait 的是應用程式狀態改變而不是時間: 如果Test Case測試時遇到需要等待的步驟，應該要確定該步驟的Wait時間是足夠的，最好是Wait 一個 “狀態”，也就是當某一個狀態出現時就停止等待，繼續執行Test Case，這樣才不會造成測試執行等待時間太久或不足導致測試失敗甚至無法繼續進行。
8. Selector可靠性: 最後如果Test Code的Test Case是屬於前端的Test，那麼若需要抓取某個UI元件，則該 元件的Selector就必須是可靠的，最好是使用元素 Name 或ID 來作為     Selector，如果是用      XPATH 或   CSS PATH 來作為    Selector 將會使測試結果不穩定，因為會對前端頁面產生高度依賴性，只要頁面元素位置改變就可能因為抓取不到元素而測試失敗，這也會是測試假警報，所以    Selector 的選擇也是 Test Code Review 要注意到的一環。

　　前面幾點就是    Test Code Review 應該要有的幾項原則，最重要的其實就是測試結果的有效性和和穩定性，例如如果測試前端的Selector沒有選好，就會常常因為頁面改變或頁面載入太慢而失敗，這樣的    Test Case 就是不穩定的。

　　而每個   Test Case 都應該做到關注點分離，一個    Case 只測試一件事，並且這件事的測試點可能有多個要驗證，同時測試資料不與其他測試案例共享或依賴，如此才能平行執行多條    Test Case測試且彼此互不影響。這就是    Automation Test Code Review 能夠 Focus 並幫忙到 QA 或測試人員的重點。

2024年6月10日星期一