除了產品的良率之外，上線前我們還必須做好甚麼準備呢?

我們在上一篇文章中解釋了自動化測試的核心理念，以及針對產品開發面的各種測試概要，當一個產品完整開發完成後，以及到正式上線前，這些測試都是不可或缺的首要關卡，但除了產品的良率之外，上線前我們還必須做好甚麼準備呢?

大家一定有使用過拓元、KK Ticket或是寬宏售票系統搶過演唱會門票吧，還記得我們兒時的偶像-周杰倫演唱會門票一票難求的窘境嗎?

在我們抱怨連線速度太慢的同時，是否有想過當初搶票時，同時執行購票的人數是否有超過系統可以負荷的上限嗎?或是當我們在電子商務網站搶購特價商品時，一定也有遭遇過系統回應時間拉長，導致結帳速度變慢搶不到商品的窘境，究竟是網路的問題還是系統效能負擔過大呢?未來在我們自己的產品上線時會不會遇到一樣的問題? 

這時候就是壓力測試的重要了。

壓力測試究竟是什麼呢?執行的目的又是什麼

當產品架設完成並在正式發布之前，開發人員可以提供Web Server一個類似正常的模擬環境，讓使用者獲取資料、發布服務，並可以接受多次接受傳送測試， 來模擬Web系統能同時處理的請求數量及反應時間為壓力測試。並依據測試的結果，使產品或系統，未來在上線後可調校至最佳化狀態，以提供快速、穩定的服務，就是壓力測試的目的。

我們可以想像今天要設計捷運的班距，像大家都知道台北捷運的藍線和文湖線的班距及車廂數就有落差，而這樣的設計也是依據壓力測試做出的結果來決定的，想像我們今天在設計時，一定會考慮到日常通勤的尖峰人潮來作為班距和車廂數量評估的高標，而離峰時間就是低標，這樣的概念我們也應該套用到系統開發的邏輯上來思考，所以進行壓力測試是指實際使用一個高標的尖峰值，來試圖破壞一個Web應用系統，透過系統的反映，測試是測試系統的限制和故障恢復能力，測試Web應用系統，在何種情境下會超過負載，而停止服務。

而在進行網上壓力測試之前, 我們需要作足準備工作，也就是所謂的劇本，就像我們要預估出"尖峰時間"( 例如在早上7點至9點 )以及所搭乘的"捷運人潮"(例如十萬人次)，以及一節車廂可以提供的載客人數，來決定我們要用多少車廂，多少班距，才有辦法評估出在指定的時間內，可否消化掉這些乘客，而這些就是我們所謂的測試腳本。以系統面的測試來說，我們需要的劇本指標數據如下

1. 壓力測試總時間

2. 測試前端的主機數

3. requests數

4. 網頁執行模式

5. 連結錯誤數

6. 回應時間

7. 測試時間長度

想像一下如果今天在搶購商品時，你從購物車連線至結帳頁竟然要300秒的時間才有回應，這樣的系統你敢辦限時優惠特賣嗎?所以首先測試系統前，會記錄需要受測功能的所有參數，然後透過壓力測試，來了解產品是否可以在同一時間提交多個查詢到應用系統(例如登入、結帳、資料填寫及送出)，針對不同應用系統及劇本，設定不同的同時間使用者連線數，測試Web Server是否連線並請求成功。

最後再套入我們的指標測試項目及指定的測試時間，來判斷我們的Request數字在時間內的回應是否正常，也會針對連結錯誤數以及系統的回應時間，來模擬這樣的人潮時，會不會因系統Loading過重，造成回應過久或是404、500等狀況發稱生， 依據小編過去執行專案的經驗，擬列的劇本如下，當然大家也可以依據自己的產品特性來對劇本做修正囉。

所以劇本不僅可以真實的反應出模擬的真實情況，我們也可以依據這樣模擬的情形來針對系統做調校，若系統本身調校的限度有限，小編也建議在特賣時可以關掉一些耗費系統較大資源的工具，來幫助正常運作，而這些依據就會取決在我們測試的劇本以及模擬的結果，所以劇情的設定對測試計畫來說，是不可疏漏的重要環節。

而小編過去在執行專案的經驗上，大多都是使用JMeter做壓測的主要測試 ，Apache JMeter 是一個100％的純Java視窗應用程式，用於壓力測試和性能測量。

Apache JMeter的特性說明如下：

1. l能夠對HTTP和FTP伺服器進行壓力和性能測試，透過JDBC也可以對任何資料庫進行同樣的測試。

2. 完全的可攜性和100％ 純Java撰寫的應用程式。

3. 使用Swing和輕量級元件支援。

4. 使用多執行緒框架允許通過多個執行同時發出請求進行取樣和通過單獨的執行緒群組對不同的功能同時取樣。

5. 擁有可視覺化的圖型介面，並允許快速操作和更精確的計時。

6. 對於測試結果可進行快取和離線分析、重覆進行測試。

7. 可插入的取樣器允許無限制的測試能力。

8. 各種負載統計表和可插入的計時器可供選擇。

9. 資料分析和視覺化Plug-In套件提供了很好的可擴充性以及客製化。

10. 具有提供動態輸入到測試的功能，包括JavaScript。

11. 支援使用Script語法的取樣器。

而除了壓力測試之外，以電子商務網站為例，當大家使用結帳系統輸入信用卡卡號的同時，是否曾經也擔心過會不會因此造成個資及信用卡資料外洩，導致被非法份子盜刷盜領的可能性呢?其實是有的，只要在導頁時加入了惡意的SQL injection來擷取你輸入的資料，其實信用卡和個資就可以輕鬆得手了，儘管我國現在的法律也在推行使用OTP(即時驗證，例如使用SMS簡訊傳送驗證碼等)等方式做了第二層的防護，但是資料在第一層的確仍有被竊取的風險。

那要怎麼樣在自己的網站中避免這樣的風險發生呢，千萬不要忘記在上線前做個安全性測試，也就是執行弱點掃描。

掃描的內容包含資料隱碼(SQL Injection)、Cross Site Scripting(XSS) 及排除OWASP最新公布之十大資安弱點項目等， 而在安全性測試結束後，掃描軟體通常會產出一份針對受測系統的弱點報告，並且依據弱點的嚴重性做出等級，在專案上線前如何在有限的時間把重要的弱點修補起來，就是考驗團隊耐心的時候，透過反覆的修正、測試、再修正、再測試，讓系統的弱點降到最低，這不僅是開發人員的工作，更是義務，也只有防範未然，才可以在使用者真的發現系統漏洞前，做出即時的修正與改善。 OWASP最新公布之十大資安弱點項目如下

在小編過去執行專案的經驗中，多半會使用N-Stalker Web Application Security Scanner做安全性測試，他是N-Stalker公司研發的一個頂級的安全評估工具(很可惜不是免費的)。透過與知名的N-Stealth HTTP Security Scanner及其35,000個web攻擊簽名資料庫合併，和正在專利申請的web應用程式安全評估技術元件作為技術結合，N-Stalker再執行的過程中可徹底消除大量普遍的安全隱患，包括跨站腳本（Cross-site Scripting）和SQL注入（SQL injection），緩存溢出（Buffer Overflow），參數篡改（Parameter Tampering）以及更多攻擊等等。使用N-Stalker掃描原始程式碼進行安全性測試，是一個有效、精準且快速的方式，大家可以不妨使用看看。