對壓力測試有感

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


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

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

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

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

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

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

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

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

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

熱門文章