課程特價中

Jmeter 從入門到實戰

從這 15 小時的課程，你會學到

1 你將學會如何給 web 應用程式和 REST API 進行負載測試
2 你將學會如何在給定負載下監控應用程式效能
3 你將學會如何安裝使用 Jmeter 外掛，生成有效報告
4 學會如何整合 Selenium 與 Jmeter
5 學習 Jmeter Beanshell 指令碼基礎知識
6 學習如何實現 Jenkin+Ant+Jmeters 三者整合實現介面自動化測試
7 藉助於 Jenkin+Ant+Jmeters 搭建自動化測試框架
8 學習如何用 beanshell 藉助於JSR223 Sampler 編寫測試框架

https://softnshare.com/jmeter-performance-testing/

今天來和大家聊聊測試！

大家都知道到寫測試非常重要，如果測試寫得好，不但可以大大減少驗證功能所重複花費的時間，還能夠增加系統穩定性，甚至是提升程式碼品質。但你有平常有寫測試的習慣嗎？如果有的話，你有寫哪些測試呢？

在我們公司一個非常特殊的文化是，所有的功能開發團隊（Feature Team）都是沒有專職的 QA 的，從產品的規劃、功能開發到上線前確認，甚至是上線後的監控，都是功能開發團隊的職責。每個團隊對於自己的產品都有很高的自主權，那麼團隊自然而然就必須要對整個產品的生命週期負責任，為了能夠確保快速疊代，及同時維持產品的穩定性，撰寫足夠的測試就會是一件非常重要的事情。為了維持產品的穩定性，我們至少在開發時期就會撰寫這些測試

1. 單元測試 - 覆蓋率最高，也是最快能得到回饋的測試
2. 整合測試 - 所有 Api 都至少能夠用整合測試確保在各種情境能運作正常
3. 自動化測試 - 能夠模擬使用者操作功能的流程，驗證所有情境都能運作正常，確保使用者體驗
4. UI 測試 - 確保功能修正時，不會造成破版或跑版的情形

除了以上這些每次 Merge 回 Master 都會跑的測試之外，我們還有定期的執行安全性掃描、壓力測試甚至是滲透測試，為的都是確保能夠有好的使用者體驗（不會改壞功能），避免資料外洩的風險（因為我們是銀行，而且在歐洲，有非常有名的 GDPR），以及最重要的增加疊代的速度。

很多人看完上面這些，應該會覺得既然是銀行，又要處理這麼多的測試，那應該理所當然是半年或一年才更新一次新功能吧？其實反而相反。

我們的產品目前大約有 2、300 人左右在同一個 Repository 工作，至少有 20 ~ 30 個 Team，每天發行的次數是數十次，所有的修改 Merge 回 master 就會自動發佈了，平常修 Bug 或小功能可能是 0 ~ 3 天就會上線，比較大一點的功能也會是 2~4 週就會能夠上線開放給使用者使用。

所以我也會鼓勵大家盡量的寫測試，好的測試反而可以讓你開發更有效率，你覺得你想寫測試最大的困難是什麼呢?

看吧，每人每天至少 merge 回主幹一次，基於主幹的開發 搭配 feature toggle，才能比較容易達到真實的 CI, CD 的精神。
　
CI 本質是「持續整合」，不是 build server。
CD 是「持續佈署」，不是自動化佈署。
　
TDD 也不是自動化測試，是測試輔助開發，用測試來描述情境，確保每一行程式碼都是剛好的為某些情境而存在，沒有多餘，重構沒有負擔，顆粒度小的單元測試能完整且扎實。（你們確定你們團隊有能力在實務上有效、有用地使用ＴＤＤ來獲得好處嗎？）
　
紅燈除錯時間降到最低，上版後要 hotfix 也可以直接關掉 toggle 再找到問題的原因，快速地 merge 回主幹，直接推到 production 再開 toggle。
　
如果走 feature branch，那你們產品是多久才 merge 回主幹一次？一天多次？如果是，那你會覺得連開 feature branch 本身都是個多餘、不必要的 effort。
　
一切都是基本功，不要只被絢麗的工具、解決方案給迷惑了。
　
#給了你鑿子也不會因此變成米開朗基羅

－－
每次在上課或是在輔導的客戶那邊聊到，Odd-e 幾乎所有人一般都是不走/不建議 用 git flow 之類的 feature branch，工程師們總是十分吃驚。你們不拆 feature branch? 那你們怎麼做的？
　
feature branch 的主要目的就是為了避免 conflict 造成的成本，然後透過 delay merge 來降低這一段成本（事實上降低的是頻率，而不是成本），因此而付出「延遲整合」的代價。
　
其實如果退回來敏捷出來之前的瀑布式或傳統的開發方式，大部份都是 component team 或是專業分工團隊，依據大家的專業去內聚成一個 team, 看起來貌似 efficiency 提高，其實是在增加整合的困難，失去全局概念，增加依賴的不穩定性，甚至「避免」溝通。
　
如果你看過前端一個 team, 後端一個 team 在做一個產品，他們只透過 API spec 跟 文字在溝通如何界接，最終都會導致許多無形的浪費。（怪了，我們這樣分的原始目標還是為了避免浪費）
　
一個需求需要兩個 team 跨 team 合作的配合，才能正常且順利 deliver，分頭開發就是導致延遲整合，如果再用類似 sprint 的 iteration，一個 sprint 的結束之前才來做整合，當時間已經用盡，但整合出現問題時，就會開始出現責任歸屬問題。
　
例如前端改也可以，後端改也可以，那麼誰要改？沒時間了啊...後面的工作跟時程都安排好了。
　
其實，本質問題都是一樣的。
　
總是碰到客戶那邊用了華麗的 build server 之後，再套上潮流的 git-flow, github-flow，再搭配上一個產品超過 3 個團隊在同個 product code-based 上工作，不同專案不同時間點要上線，再加上從 local/dev 到 prod 至少有三個環境。
　
結論就是光一個佈署、merge、上版、退版、pull、解 conflict，他們就身在其中痛苦不已。越痛苦，就希望痛苦的頻率降低，做一次痛總比老是痛來得好。
　
所以，誰晚 merge 誰倒楣。
　
－－
當然啦，feature toggle 也不是萬靈丹，他會帶來 application 複雜度的挑戰，而 application 的複雜度控制，其實卻反而是最簡單的，因為只要設計的底子夠足，這一段可以設計地很美、很無感、很無痛，而且開發維護成本低廉，品質良好。