Tom's IT notebook

         最近，因為公司替即將上線的系統做壓力測試引發出許多問題，促使我開始重新思考一些開發流程的疑問： 先 SIT，UAT然後才進行壓力測試真的是正確的測試標準流程嗎？          會開始有這樣的疑問，在於壓力測試若沒有過關，若要解決關鍵的效能問題，有時候會導致更改低層設計的 re-design 發生，而偏偏測試走到這階段，正是系統即將上線前的 deadline，底層的重構 ( 尤其改資料庫結構 ) 常常動一髮牽全身，之前的功能測試的保證等於失效，想準時上線根本沒機會重測。在沒人敢擔下上線日期跳票的責任下，一個沒有 well-testing 的系統就這麼被推上火線對外營運了。

        自從我替自己的工作室建置整合了 SVN + Hudson + NANT 的 build server solution ，開始享受這甜美的果實，為了讓整體發揮最大功效，上個月我把原本使用 WindowsXP Pro 的伺服器重灌成 Windows 2003 Ent，沒想到從此我的專案建置開始變得愁雲滿天！

        最近幾週，公司在進行即將上線的系統的壓力測試。而故事發展往往是這樣的，平日跑起來沒甚麼異狀的系統，平平安安度過 UAT 與 SIT，然而壓力一來，各種匪夷所思難以解釋的現象開始一一浮現...。         這次就有個詭異到不行的莫名現象搞得我差點走投無路準備燒香拜拜，花了一週的時間終於在靈光一閃的狀況下背我看破端倪。

        最近公司在為了即將上線的產品進行壓力測試，產品內有個結帳功能是同事 A 先生的得意代表作，結帳功能在 A 先生信誓旦旦拍胸脯保證三百萬筆資料秒殺的信心下，平行作業卻發生了 Deadlock。