儒道哲學的浪漫人生

　　上一篇談到了 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

　　這幾天當今世界最火紅的AI高科技晶片設計製造公司輝達的CEO暨創辦人黃仁勳先生旋風來台參展訪問，刮起了一股眾人追星的旋風，就彷彿是麥克傑克生來台灣逛夜市那種難以想像的追星場面，突然間才意識到，現在已經是大老闆網紅行銷時代。

　　這邊講大老闆是網紅沒有不敬或貶低之意，而是說大老闆的個人魅力在現今社交媒體網路發達，尤其是自媒體文化當熱的這個時機點，正是最好的公司企業行銷利器，把老闆當成一種品牌，放在網路上行銷，也成了讓產品被世人看見甚至喜愛而買單的一種商業策略。

　　企業有營利的商業模式，而個人當然也有自己的商業模式，所謂商業模式就是透過一套系統化的方法為自己或組織賺進收益的方式，而在一本名為＂通往財富自由之路＂的書中說明了屬於個人的三種商業模式。

　　首先，我們要先知道個人商業模式的核心成本是什麼，才能更清楚地甄別出個人的商業模式是如何分類。這個核心成本就是每個人用來產生收益的個人資源，而隨著每個人對此資源的運用方式不同，所產生的收益也不同，也就成為了不同的商業模式。那麼這一個個人商業模式的核心成本是什麼呢？就是＂時間＂，我們每個人每天都有24小時的時間，我們利用＂出售時間＂來獲取收入，按照出售時間的方式，我們將個人商業模式分成三類。

在這一篇新聞介紹中，我們知道在2023.12 的時候仍然能夠在電腦 CPU 中發現 “旁路攻擊(side-channel attack)”，本篇文章的 SLAM Attack (Spectre LAM Attack 幽靈LAM攻擊)就是這幾年來一直層出不窮在CPU之中的另一種旁路攻擊

“a new side-channel attack called SLAM that could be exploited to leak sensitive information from kernel memory on current and upcoming CPUs from Intel, AMD, and Arm.”

以前我跟一般非軟體（即軟件）人一樣對app軟體和saas服務一直很難分辯他們的差別，多年後 我終於可以用很簡單的概念介紹給大家：

app軟體和SaaS服務廣義來說是軟體的商業模式在雲端運算出現後產生了變化導致的不同軟體買賣模式.

　　實際算出一個題目，該題目是要在耦合電路上試圖找出在一次側電阻R_L 有最大功率轉移時的 Xc 電容抗值。

　　該題目解析要點：