進度條

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

產品上線前的最後防線 - 別忘了你的安全性及壓力測試

作者: Vincent Ke 更新日期:

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

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

 內置圖片 5

 

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

 

  1. 壓力測試總時間

  2. 測試前端的主機數

  3. requests數

  4. 網頁執行模式

  5. 連結錯誤數

  6. 回應時間

  7. 測試時間長度

 

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

 

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

 

項目

測試方法

Web服務同時上線人數(外網)

模擬同時上線500人(含)以上,包含100人、200人、300人,連續15分鐘,不能出現停止服務訊息(請參考http狀態碼表,例如4xx、5xx)。

使用者登入時間

本項測試的準則為模擬超過500個使用者,包含100人、200人、300人、400人、500人、600人、700人,同時作業及維持15分鐘的情況下,使用者登入檢核包含認證資料與授權資料。

一般頁面顯示時間

本項測試的準則為模擬300個使用者(另模擬100、200、300人)同時作業及維持10分鐘的情況下之每一網頁的反應時間,靜態網頁需能在3秒內獲得系統回應。

資料庫資料查詢顯示時間

本項測試的準則為模擬100個使用者同時作業資料庫相關作業,及維持10分鐘的情況下之反應時間。

 

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

 

內置圖片 7 

 

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

 

其最初被設計用於Web應用程式的測試,但後來擴展到其他測試領域,也可以對靜態的和動態的資源,如文件,Servlet,Perl腳本,Java物件,資料庫和查詢,FTP伺服器等等的性能進行測試;亦可以用於對伺服器,網路或物件進行繁重的負載,來測試它們的強度或分析不同壓力負荷下的整體性能,並結合視覺化的效能圖形分析,使使用者可以容易了解在大量同時發生的負載下,伺服器與其相關應用程式的穩定性。

 

 

Apache JMeter的特性說明如下:

 

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

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

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

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

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

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

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

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

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

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

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

 

 內置圖片 6

    

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

 

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

 

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

 

十大Web資安漏洞列表

避免方式

A1. 跨網站的入侵字串(Cross Site Scripting,簡稱XSS,亦稱為跨站腳本攻擊):Web應用程式直接將來自使用者的執行請求送回瀏覽器執行,使得攻擊者可擷取使用者的Cookie或Session資料而能假冒直接登入為合法使用者。

請將伺服器與客戶端傳遞參數的內容用htmlEncode編碼。

asp.net 4.0 ,請使用code nugget syntax : <%: %>,此方式預設就會將內容做htmlEncode編碼。

A2. 注入缺失(Injection Flaw):Web應用程式執行來自外部包括資料庫在內的惡意指令,SQL Injection與Command Injection等攻擊包括在內。

避免使用字串串接的方式組合SQL陳述式或指定,請使用變數來傳遞指令或陳述式的參數內容。

A3. 惡意檔案執行(Malicious File Execution):Web應用程式引入來自外部的惡意檔案並執行檔案內容。

程式設計時必須要強烈的規範可接受使用者傳入的檔案、檔案類型。使用防火牆阻擋任何對外部不明網站的連結。

A4. 不安全的物件參考(Insecure Direct Object Reference):攻擊者利用Web應用程式本身的檔案讀取功能任意存取檔案或重要資料,案例包括http://example/read.php?file=../../../../../../../c:\boot.ini。

善用web server的重新導向,使用者存取任何不是服務中的目錄必須要做重新導向。

使用indirect reference maps。

A5. 跨網站的偽造要求 (Cross-Site Request Forgery,簡稱CSRF): 已登入Web應用程式的合法使用者執行到惡意的HTTP指令,但Web應用程式卻當成合法需求處理,使得惡意指令被正常執行,案例包括社交網站分享的 QuickTime、Flash影片中藏有惡意的HTTP請求。

設計階段防止跨網域存取,如:www.google.com 內容不能存取 www.amazon.com

避免”記住我”、”記住密碼”一類服務。

A6. 資訊揭露與不適當錯誤處置 (Information Leakage and Improper Error Handling):Web應用程式的執行錯誤訊息包含敏感資料,案例包括:系統檔案路徑的揭露或資料庫欄位名稱。

程式設計時必須要正確使用錯誤捕捉功能並且要提示標準並對使用者有用的錯誤訊息機制。

測試人員及QA要盡量的測試程式來捕捉遺漏未處理的錯誤。

A7. 遭破壞的鑑別與連線管理(Broken Authentication and Session Management):Web應用程式中自行撰寫的身分驗證相關功能有缺陷。

確保在應用程式身分驗證部分使用SSL。確保所有身分認證的資訊是以Hash模式儲存。

A8. 不安全的密碼儲存器 (Insecure Cryptographic Storage):Web應用程式沒有對敏感性資料使用加密、使用較弱的加密演算法或將金鑰儲存於容易被取得之處。

確保重要資料都必須要編碼及加密(encode)。建議以不容易被破解的加密方式加密,如:MD5、SHA1。確保用來解密的金鑰儲存在安全的地方,不外流。

A9. 不安全的通訊(Insecure Communication):傳送敏感性資料時並未使用HTTPS或其他加密方式。

伺服器與客戶端連結的安全機制可以制定好限制,如:只能經由某些通道連結、限制連線數..等。

使用SSL加密。

A10. 疏於限制URL存取(Failure to Restrict URL Access):某些網頁因為沒有權限控制,使得攻擊者可透過網址直接存取,案例包括允許直接修改Wiki或Blog網頁內容。

有管理者權限的帳號應不被允許執行任何應用程式不使用的檔案型態

要建置有效權限管理機制。

 

在小編過去執行專案的經驗中,多半會使用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掃描原始程式碼進行安全性測試,是一個有效、精準且快速的方式,大家可以不妨使用看看。

 


校正小編沒有用過這幾套軟體,但是N-Stalker看起來是有免費的試用版,各位有興趣可以試試看。
 

 

 內置圖片 3

 

壓力測試的目的是為了測出系統在極端高負荷的情況下,是否有超出負荷或是錯誤處理的狀況產生。而安全測試主要是針對系統的保護與安全機制測試,儘管在產品上線前往往是工程師忙到翻雲覆雨的重要時刻,但若我們只關注在產品功能面上的完整性,卻忽略的實際效能的評估以及安全性的考量,很容易將團隊開發時投注的心血,在關鍵時刻功虧一簣。

身為一個專業的開發者,更應該再撰寫程式的同時,將壓力測試及安全性測試的概念帶入CODE裡面,才有辦法透過最大化的效能,安全、即時的完成使用者的服務需求。最後不管你是PM還是工程師,在產品上線前,千萬不要怠忽了最後防線喔!

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧