一般認知上，要在系統中導入一套新的工具，總有很多事項需要考量，盡量避免破壞原有的運作，其中包含效能好不好，是否會導致系統卡住，而流程引擎作為核心機制更需要這方面的考量。即使 Temporal 已有官方的壓測數據，以及各大公司的使用經驗，或許自己動手去體驗可以帶來更深的理解。 本專案是透過 k6 壓測，分析 Temporal Workflow 在加壓過程中運行的狀況，藉以了解 Temporal 的承載能力。 壓測種類 「壓測」是一個泛用的詞，實際上有著不同的類型，回答不同問題。 類型 主要問題 常見做法 Smoke test 路徑有沒有接通？ 小流量短時間，只確認能跑通 Load test 預期流量下是否穩定？ 用目標流量跑一段固定時間 Stress test 超過預期後怎麼退化？ 逐步加壓，觀察錯誤率、latency、掉壓 Spike test 瞬間尖峰撐不撐得住？ 短時間快速拉高

你知道專案該有測試，可能也在文件或會議裡聽過「BDD」「Gherkin」這些詞，但始終沒弄清楚它們到底是什麼、跟你平常寫的測試有什麼關係。這篇就從這裡開始：先把 BDD 跟 Gherkin 講清楚，再看怎麼讓 AI 分兩步把需求變成測試——先產生一份人人都讀得懂的驗收文件，再把它轉成 Karate 能執行的規格——最後交給 Karate 驗證系統有沒有照規格動。一份規格，同時是大家確認過的需求，也是會自己驗證的可執行測試。 先講清楚：BDD 跟 Gherkin 是什麼 如果你寫過測試，流程大概是這樣：想好要測什麼，然後用 JUnit、Jest 之類的框架，把斷言一條條寫成程式碼。這沒問題，但有個侷限——這些測試只有工程師看得懂。PM、QA、需求方想知道「這個功能到底驗了哪些情況」，沒辦法直接讀你的測試碼。 BDD（Behavior-Driven Development，