儒道哲學的浪漫人生

　　星期六這天真是熱爆呀，但是有一個約會讓我不得已來到了新北投，其實原本沒有要跑到這邊來吃飯的，但因為對方突然改地點，我只好跟著來到新北投，這真是一個新開發的秘境，我以前在石牌念書時竟然從沒來過新北投這邊，這實在是太慘了，或許要反過來感謝約我這邊吃飯的人，不然我真的不知道何年何月才會跑到這裡來好好的解鎖新秘境。

　　昨天因為要去士林北投跟人吃飯，所以騎著熟悉的中山北路，一路從重慶南路轉羅斯福路再到中山南北路，很意外地我走在了曾經學生時代每天騎車上下學必經的路上，而由於導航路線所要去的新北投的陶板屋全都在那時候要去學校上學的必經的路上，騎著騎著我的心情複雜了起來。

　　多麻熟悉得一條路呀，但是自從二技畢業之後儘管經過這麼多年在台北打滾，我卻從未曾再騎著機車走在這條曾經熟悉的路上，那時候騎著的是阿爸牌的Hello Kitty Vino 機車，現在騎的是2手牌的Kimco 125，但是那條上學必經的路並未曾改變，陸續走上了福國路福華路來到了捷運德明站和石牌站，我沒有轉入德明路或石牌路往學校而去，一方面是要去的目的地不能轉彎，另一方面是我的心有點近鄉情怯，很多的故事彷彿都還是昨天的事，但是一轉眼已是將近20年的遺憾。

　　今天沒啥可以好好書寫一番的，那就來記錄一下上次要跟女孩子約會見面時隨手找的幾個自己覺得適合用來了解對方的問題，只是純粹自己覺得能用的話題，在這邊稍作紀錄

1. 如果你現在可以去任何地方旅行，你最想去哪裡？
2. 你最喜歡的景點或城市是哪裡？
3. 你的理想職業是什麼？
4. 你小時候總想著長大後想成為什麼？ㄌㄧ
5. 如果你可以跟任何人一起去渡假，你最想跟誰去？
6. 你最喜歡的回憶是什麼？
7. 如果現實中佈滿殭屍，你會怎麼做？
8. 告訴我一些你不曾告訴別人的事？

　　以上，除了第八點我覺得剛開始約會認識不太適合單刀直入去問以外，其他應該都是不錯的話題吧！

　　上週可以說是工作的地獄周，因為突然所有手邊本來就在趕進度的工作突然被一個臨時插進來更緊急的歐洲合規政策簡稱   MICA 用戶專案給硬生生輾壓過去，終於在如火如荼地加班一周後把這件事搞定，雖然中間也穿插一些   Hot Fix 小工作，但也是算安全達陣。

　　只是上周一開始這件   MICA 專案被插進來時，有兩件事我只做對了一件，那就是約團隊一起重新排工作進度，確保在   MICA 專案能順利優先完成的情況下，那些手上緊急的任務可以先暫緩，哪些又可以先停掉，原本以為只要把優先級較低的     Task 直接停掉即可應付，但一場會議下來發現有   4 個跟車 6.26 要上線的需求中有些是   APP 需要的後端需求必須在   6.20 完成驗證上線，這部分就很硬了，因為當時覺得   6.26 跟車是一種跟外部團隊的支票，不太可能延期，那就是無論如何都得在 6.20 前先把後端的需求驗完上線，而 MICA 的驗證結束上線時間也是   6.20，那真的是神仙打架，凡人莫測。

　　上一篇談到了 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 或測試人員的重點。

Automation[13] Automation Test Code Review 是在Review什麼?

　　說起Code Review 實在是一項讓很多人又愛又恨的事。大家都知道要Code Review，但Code Review時到底該Review什麼？Review的準則又該是蛇麼? 每個人對Code都有自己的想法，那到底該聽誰的？

　　來談一下直銷吧，大概是易吸引直銷體質，近三年來我遇到兩家直銷，腦波弱的我都參加了他們的計畫，使用了他們的服務，第一家是賣減重食品的，它們的減重計畫跟知識確實有效，第二家則是做臉做到變直銷，雖說裡面的人跟我相處起來覺得還不錯，曾一度掙扎是否要無條件一直相信他們的感情下去，但﹍﹍終究是直銷。

　　我想直銷的產品雖然有些真的不錯，也可算是貨真價實，但是永遠都是那樣的貴！貴也無所謂，如果是真的有效，且只是買必要的那幾樣，那也是可以接受，但偏偏直銷有個問題：就是要賺錢！

　　測試軟體的Backend Job時通常除了確認Job執行可以正常之外(包含獲得正確的結果)，必須要記住有一測試點一定要考慮到: Job的批次處理特性。這意味著測試Job時必須多驗證Job的不可中斷性。

　　什麼是Job ? Job就是在固定周期內會按時執行一特定任務的程序，通常他是批次的，也就是他執行的目標對象通常不會只有一個，而是有很多個執行對象需要處理，例如每個月第一天執行一次Summarize 上月份的每日營運報表，執行對象就有上個月30個工作日。

[新聞來源] The Hacker News : http://thehackernews.com/2024/04/widely-used-putty-ssh-client-found.html  

News Date: 2024.04.16