對壓力測試有感

        最近，因為公司替即將上線的系統做壓力測試引發出許多問題，促使我開始重新思考一些開發流程的疑問：先 SIT，UAT然後才進行壓力測試真的是正確的測試標準流程嗎？

        會開始有這樣的疑問，在於壓力測試若沒有過關，若要解決關鍵的效能問題，有時候會導致更改低層設計的 re-design 發生，而偏偏測試走到這階段，正是系統即將上線前的 deadline，底層的重構 ( 尤其改資料庫結構 ) 常常動一髮牽全身，之前的功能測試的保證等於失效，想準時上線根本沒機會重測。在沒人敢擔下上線日期跳票的責任下，一個沒有 well-testing 的系統就這麼被推上火線對外營運了。

        以這樣的 case 而言，可以推諉測試時間不夠充裕嗎？我想是不行，畢竟 SIT / UAT 實際上給了足夠長的時間。

        在軟體開發上，大家逐漸理解傳統式的瀑布流程之不可行，因為計畫永遠趕不上需求的變化，這就是軟體業的常態。所以因應時勢所須，XP / Agile / Scrum 等快速反應需求與適應變更的方法論如雨後春筍般湧出。

        然而，反觀測試流程，像是被忽略的孩子未受到應有的重視，大多數仍舊延續著舊世代的思維，採用類似瀑布式的階段式作法。

        新的測試思維應該與時俱進地。其中我這次所受到的啟發，就是壓力測試應該在專案的每一個階段就適當地介入，而不是等到功能盡數完成並通過 Functional testing 才開始實施。

        當然這個變革絕不是我這邊嘴巴說說這麼簡單。如同要導入 unit testing 需要許多新的開發技巧配合，不懂這些技巧的程式設計師只會跟你說：做不到。不懂技術的專案經理也只好摸摸鼻子，專心打手上有的牌。

        再來就是參與開發者的心態。因為更多的測試介入，絕對伴隨著更多的開發準備工作與書面報告的負擔，這是逃避不了的事情。參與者若心態懶散，很容易形成白做虛功的無效測試，與是乎，到了專案後期，該發生的慘劇一樣發生，像是宿命一般地難逃。

        說真的，要理想地實踐並不容易，但難度也僅跟其他方法論一樣：成敗的關鍵在於人！

        但無論如何，讓壓力測試介入專案的每個階段，是一個值得好好考慮採納的做法。