[{"data":1,"prerenderedAt":51},["ShallowReactive",2],{"article-zh-stress-test-or-volume-test":3},{"article":4,"related":19,"prevArticle":41,"nextArticle":45,"availableLocales":49},{"id":5,"slug":6,"image":7,"date":8,"published":9,"created_at":10,"updated_at":11,"title":12,"excerpt":13,"content":14,"custom_css":15,"keywords":16,"meta_description":17,"og_image":15,"image_width":18,"image_height":18,"category":15},"ee2640fe-2066-4ec2-9c49-e373027f7486","stress-test-or-volume-test","https://cdn.sqa.tw/blog_pictures/invoice_overload.jpg","2025-07-25T09:32:00+00:00",true,"2025-07-25T13:32:14.782776+00:00","2025-07-29T09:03:37.288+00:00","從系統崩潰來看壓力測試的誤區","我們怎麼從統一發票兌獎這件事來看待系統處理與承受能力？","\u003Cp>任何事情不要一廂情願地希望順利，凡事要正面解讀、逆向思考 ———— 聖嚴法師。\u003C/p>\n\n\u003Cp>單數月份25日，是統一發票開獎的日子，我們可以在很多發票相關的系統或App裡，看到各種對獎方案，能不能夠在獎號與中獎名單公布後，快速比對完成並通知用戶對獎結果，這件事看起來簡單，但要做好其實有很多細節，更能從中看出每家廠商的技術能力，今天，歷經多次調整，剛好一個系統通過幾十萬中獎用戶的承受能力認證，我們應景來談談一般SQA不容易遇到的場景。\u003C/p>\n\n\u003Cp>之所以拿聖嚴法師這句話開頭，主要是不小心翻到，覺得第一句話非常像是這個專案裡的開發團隊，非常樂觀的團隊，經歷多次跌倒還是能夠正向思考，精神可嘉，只要有了專業協助，他們肯定可以走的更遠。\u003C/p>\n\n\u003Ch2>自殺式DDoS\u003C/h2>\n\n\u003Cp>這次的例子是發票對獎，讓我們來看這個問題是怎麼發生的。\u003C/p>\n\n\u003Cp>產品經理看到用戶每次開獎後，都需要自己上來App點擊對獎後，才知道自己有沒有中獎，所以他告訴開發團隊，希望可以讓用戶第一時間可以知道自己的發票中獎了，開獎後，要推送消息給有中獎的用戶，用戶點擊後跳到App開獎畫面，這個時候用戶不用再點擊一次對獎，就能看到中獎結果，這是一個非常不錯的產品需求洞察。\u003C/p>\n\n\u003Cp>因為本來用戶的發票與中獎資訊就是放在資料庫裡，用戶使用上一直都正常，後端工程師也沒有多想，在後台計算完中獎資訊後，就一起推送消息給用戶，然後，大部分收到消息的用戶就集中在那短短的一兩個小時，順著產品經理的設想，連上來系統看自己的中獎資訊，接著，就沒有然後了。。。\u003C/p>\n\n\u003Cp>用戶在接下來那一天，一直沒辦法連上這個服務，就如果我們前面說的，工程師設計了一個機制，讓所有的用戶在相對短的時間內，都連上伺服器去看自己中獎情況，再加上沒有先準備好，第一波用戶就直接打掛自己的伺服器了。\u003C/p>\n\n\u003Cp>最後怎麼解掉這個問題是我們另外的專業服務內容 —— 軟體架構設計，容我放在另外一篇再來談，這篇還是談從QA的角度應該怎麼發現跟驗證系統容量是否符合期待。\u003C/p>\n\n\u003Cfigure class=\"text-center my-6\">\n  \u003Cimg src=\"https://cdn.sqa.tw/articles/1753698436671-jb2yzqnig09.jpg\" alt=\"invoice volume processing\" class=\"w-3/4 h-auto rounded-lg shadow-md mx-auto\" />\n\u003Cfigcaption>一次處理幾億張發票沒那麼容易\u003C/figcaption>\n\u003C/figure>\n\n\u003Ch2>壓力(Stress)測試與容量(Volume)測試\u003C/h2>\n\n\u003Cp>先提一件事，就是我找不到好的Volume Test翻譯，他原意取的是大量而不是容量，他雖然也有容量的意思，但在語意上，他是要測試承載大量請求的能力，但真的是找不到合適的名詞，所以我還是沿用一些前輩用的容量測試當作翻譯。\u003C/p>\n\n\u003Cp>很多初學者因為對定義的不熟悉，往往在學習過程中，會認為這兩種測試其實講的是同一件事，但為什麼在專業軟體測試當中，會把這兩個詞分開呢？那為什麼在現在很多應用場景中，我們只能聽到壓力測試呢？\u003C/p>\n\n\u003Cp>我們先回到大部分SQA課程中對這兩者的定義來看。\u003C/p>\n\n\u003Ccode>\u003Cb>壓力測試\u003C/b>專門指系統或程式在資源不足的情況下，正常運作與處理錯誤的能力驗證方式。\u003C/code>\n\u003Ccode>\u003Cb>容量測試\u003C/b>專門指系統或程式在處理\"大量\"的請求時，是否能正常運作或處理錯誤的驗證方式，這裡裡的大量有可能是單次大處理量，像是大檔案或是能形成大工作量的請求，也有可能是短時間內大量湧入的小處理量請求。\u003C/code>\n\n\u003Cp>這其實不難理解為什麼大家習慣性混用這兩種測試型態，在大量用戶端請求下，資源耗盡，所以這就算是壓力測試，的確，大部分開發團隊都是這麼理解的，但如果這麼簡單，為什麼要分開定義呢？為了方便解釋，這篇我們專注討論單次大量的場景，單次大處理量的請求，我們找機會再介紹。\u003C/p>\n\n\u003Cp>簡單地說，這兩種測試看的視角不同，壓力測試其實需要SQA對系統運作的每一個細節都清楚，才能開的出來，譬如說，大部分的SQA不會知道load balancer驅動的擴容策略，也不知道生產環境log的處理方式與rotation policies，更不會知道像是cache mechanism跟cache slot size(or count)這種可以觸達系統極限的條件，更好玩的是，其實大部分開發者也不熟悉，所以在原始碼裡也沒有對應的容錯機制，這很正常，這種連資深工程師都很少遇到的情況，正常開發流程裡，沒人提，你根本就不知道還有這種事，就算真的發生，大部分工程師的處理方式也很簡單粗暴，滿的就清掉或多買點空間，資源不夠就加機器，只有少部分有技術堅持的團隊，會要求把這些細節做到位，這也是為什麼很多系統驗收或上線前都是正常，一上線就會掛掉。\u003C/p>\n\n\u003Cp>又扯遠了。。。我們繼續說容量測試，這種是從外部視角，根據用戶的核心流程，去模擬大量用戶(或請求)同時進到系統時，能不能維持\"體面“？這裡只要服務能持續，能穩定地滿足設計容量內的用戶，讓其他用戶等待，或是稍後再試，基本上就算是及格，如果能在這樣情況下，短時間內擴容並承接著這些設計容量以外的用戶，當然最好，不過這相當考驗DevOps or SRE的能力，通常要發生個幾次事件並諮詢有經驗的前輩才會知道該如何處理。\u003C/p>\n\n\u003Ch2>壓力測試的誤區\u003C/h2>\n\n\u003Cp>回到這篇的主題，這種利用短時間大量請求來測試系統是否能正常運作的方式，有個非常關鍵的設計條件，就是你必須走過\"核心流程\"的每個系統交互環節才成生效，說的白話一點，就是要能完全模擬出來用戶使用中的每一個環節，這看起來很簡單，但其實大部分團隊在所謂的\"壓力測試\"裡，沒有測試到想測試的情況，就是因為忽略\"每一個環節\"這件事，我們底下就介紹三種常見的誤區，以及大家可以自己檢查的方法。\u003C/p>\n\n\u003Ch3>以偏概全\u003C/h3>\n\n\u003Cp>\u003Cb>誤區說明\u003C/b>：把壓力測試簡化為發送大量請求，但實際只跑到部分 API 呼叫或單純的首頁瀏覽，沒有涵蓋完整使用者經驗（如登入、查詢、交易、登出等互動流程）。\u003C/p>\n\u003Cp>\u003Cb>結果\u003C/b>：測出的系統瓶頸偏差，核心流程未被測到 —— 很容易錯過真正的崩潰點。\u003C/p>\n\u003Cp>\u003Cb>檢查\u003C/b>：萃取核心流程中的條件節點，針對大部分用戶會走進的條件分支進行確認。\u003C/p>\n\n\u003Ch3>一葉障目\u003C/h3>\n\n\u003Cp>\u003Cb>誤區說明\u003C/b>：許多團隊在同一網段、同一雲服務供應商內，以多台甚至單台實例集中執行壓力測試腳本，但這其實僅測出該環境內節點或同網段的出口效能。\u003C/p>\n\u003Cp>\u003Cb>結果\u003C/b>：看起來測試的總量很多，但是遇到同樣的量，一樣掛了。\u003C/p>\n\u003Cp>\u003Cb>檢查\u003C/b>：設定同時承受請求數的單位與時長，並設定對應的監控方式，以實際接收的單位時間量為準去驗證。\u003C/p>\n\n\u003Ch3>不識廬山真面目\u003C/h3>\n\n\u003Cp>\u003Cb>誤區說明\u003C/b>：在 UAT/DEV 或與正式環境不同的架構測試壓力，或用等比例的方式去預估壓力。\u003C/p>\n\u003Cp>\u003Cb>結果\u003C/b>：雖然該做的都做到了，但是生產環境還是扛不住。\u003C/p>\n\u003Cp>\u003Cb>檢查\u003C/b>：不要為了省短期的驗證費用(這個真的是驗完就可以關了)，就假設在這些相似甚至是完全不同架構的環境裡可以有一樣的表現，一定要盡量做到高度一致或相似，基於這個原則再去想怎麼省測試費用。\u003C/p>\n\n\u003Ch2>知道了，下一步？\u003C/h2>\n\n\u003Cp>前面講的有點太技術性，來點可操作性比較強的管理方式。\u003C/p>\n\n\u003Cp>\u003Cb>如果你是甲方\u003C/b>，在乙方提出的測試計劃裡，確認壓力測試的方案是按照場景的預期使用量來設計，並且在驗收報告裡，應該有場景中每個路徑節點，在測試過程中承受壓力的統計數據，只要最終結果符合你對使用量的期待，基本上就算過關了。\u003C/p>\n\n\u003Cp>\u003Cb>如果你是產品開發團隊\u003C/b>，照著customer journey map去追壓力測試的路徑是最直接的方式，但如果團隊本來沒有，用GA4(或其他behavior tracking platform)的行為路徑，或後端API requests distribution去追也是可以嘗試的方向，主要是技術團隊能知道這些資料的順序與代表性即可。\u003C/p>\n\n\u003Ch2>看完還是不知道該怎麼做？\u003C/h2>\n\n\u003Cp>最近收到些信跟消息，說自己看完文章還是不知道該怎麼做，問我能不能開課授業，或去他們公司直接評估，其實像本文提到的內容，台灣大部分團隊遇到的機會也不高，大部分都是客戶說了算，驗收過就過了，如果有自己開發產品的準備，或是遇到多次內部提案後還是無法解決，再找我們不遲。\u003C/p>\n\n\n",null,"統一發票,壓力測試,容量測試,Stress Test, Volume Test,軟體測試","壓力測試與容量測試其實有本質上的區別，怎麼區分跟驗證要很好的把握住原則，不然容易誤會系統已經通過我們期待的標準",1024,[20,27,34],{"id":21,"slug":22,"title":23,"excerpt":24,"image":25,"date":26,"category":15},"deb70edd-ff7f-4b6e-b230-fa1c83dc0afa","qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","Qaptly Desktop 的 AI Assistant 從 v0.17.5 開始正式開放 Codex 支持。如果你本來就是 ChatGPT 訂閱用戶，現在可以直接讓 AI Assistant 使用 Codex，在日常測試設計與自動化調整上節省成本。","https://cdn.sqa.tw/blog_pictures/qaptly_support_codex.jpg","2026-05-16T13:01:00+00:00",{"id":28,"slug":29,"title":30,"excerpt":31,"image":32,"date":33,"category":15},"eebc38be-6eec-4e68-af7f-e5dd6c611a0f","ai-agent-workflow-critical-things","AI 協作進入 workflow 之後，那些最容易被低估、卻最關鍵的幾件事","過完年後，基本上都在幫幾間新創與大公司內部的開發部門導入 agentic development。這段時間看了不少團隊的做法，也有一些很直接的感受，想趁這個機會整理一下。","https://cdn.sqa.tw/articles/ai-workflow.jpg","2026-03-24T16:10:00+00:00",{"id":35,"slug":36,"title":37,"excerpt":38,"image":39,"date":40,"category":15},"1092dc59-4718-4902-809c-74cfdfc5fffd","from-tool-to-process-challenges","從單點工具到流程閉環的虛實與挑戰","探討2026年AI在軟體開發生命週期中的實踐，從單點工具普及化到流程閉環協作的轉變，以及QA自動化的真實與虛假繁榮。","https://cdn.sqa.tw/blog_pictures/from_tool_to_process.png","2026-03-02T03:06:00+00:00",{"slug":42,"title":43,"date":44},"sqa_tw_service_introduction","測試怎麼配才合理？帶你認識 SQA TW的服務模式與日常工作方式","2025-06-24T14:05:00+00:00",{"slug":46,"title":47,"date":48},"information-security-is-quite-important","資訊安全應該是必修課？","2025-08-17T14:05:00+00:00",[50],"zh",1786461720561]