！喔的倒顛是都料資的來出查連，字鍵關入輸倒顛要只不，elgooG 的倒顛，站網的趣有個一
http://www.alltooflat.com/geeky/elgoog/
最近把「oldsidney 學習筆記」換到其它的 hosting，換過去後應該不會有被擋掉的問題了，所以大陸的讀者應該可以訪問到「oldsidney 學習筆記」了。
除了換 hosting 之外，也順便把整個網站換成了 WordPress Blog，以後發表文章就更方便囉！
另外還有 ezMoney 的網站也一併建起來了。
基本上這篇文章原本就是 Mercury 的白皮書，所以讀者一定覺得我有幫 Mercury 打廣告的嫌疑。不過撇開 Mercury 產品的內容，我覺得整個白皮書所講的效能測試部分，還是蠻有參考價值的，這也是我之所以會翻譯這篇文章的主要原因。
資料來源：Mercury
|
自動化效能測試是一種手段，透過人、流程與技術，降低應用系統上線、升級以及更新 patch 的風險。在系統上線前，以預期上線後的負載進行測試，並量測其系統效能以及使用者經驗。一個好的效能測試可以回答以下的問題：
- 當預期數量的使用者同時上線時，系統的回應是否夠快？
- 系統是否能夠負荷的了預期的負載，甚至在超出預期的負載下也能正常運作？
- 系統是否能夠處理的了所有的商業交易？
- 在預期的負載或是超出預期的負載下，系統是否穩定？
- 在決定上線時，您能確保使用者將會有良好的使用經驗(如回應時間)？
除此之外一個有效的效能測試，還能幫助您取得更多的資訊以便決定軟體是否可以交付部署，並且減少系統當機時間。透過自動化效能測試，可以將商業變化所造成的衝擊給量化，並藉此明瞭部署軟體的風險。
詳全文
譯註：基本上這篇文章原本就是 Mercury 的白皮書，所以讀者一定覺得我有幫 Mercury 打廣告的嫌疑。不過撇開 Mercury 產品的內容，我覺得整個白皮書所講的效能測試部分，還是蠻有參考價值的，這也是我之所以會翻譯這篇文章的主要原因。
資料來源：Mercury
前言在過去20年來，企業已經把過去軟體的使用轉變成為「數位化工作」。軟體被大量運用來增進工作效率與生產力。在全球化的經濟，軟體更成為提供協同運作以及資訊分享的新媒介。事實上，軟體已經變成是企業關鍵業務 (business-critical) 上資訊分享與交易處理的主要管道。在今天，企業已經脫離不了軟體，不管是電子郵件、 CRM (Customer Relationship Management) 到交易處理，軟體都可以視為是商業。
同時，軟體的開發技術也變得非常成熟，相對的複雜程度也與日俱增，所帶來的影響就是軟體可能存在更多潛在問題，而且更難找出問題所在。
再者，軟體不像是一部車子，壞了只要換個零件就可以了。軟體可能為了保持競爭優勢或是因為商業條件的改變，每週、每月、每年都在演化。所以企業必須對這一連串改變所造成的風險作有效的管理。
我們可以看到軟體正以非常快速的步調在改變，複雜程度有如爆炸般的與日俱增，為整個軟體開發流程帶來巨大的風險。
什麼是效能測試？所謂的「效能測試」是在系統上線前用來測試 end-to-end 效能 (performance) 的一種測試方法，而 end-to-end 意味著效能測試是要從使用者的角度去驗證效能指標。所以效能測試解決方案 (solution) 應該提供：
- 使用最少的硬體資源，模擬成千上百的使用者與系統互動
- 從終端使用者 (end-user) 的角度量測系統回應時間 (response time)
- 能夠以一致的方式重複產生負載
- 監視待測系統的各個元件
- 提供強大的分析工具與報表產生器
自動化效能測試解決方案，通常使用四個主要元件來建立並執行效能測試。這四種主要元件為：
- 虛擬使用者產生器 (Virtual User Generator)：錄製使用者操作的業務流程 (business process) 以產生自動測試腳本 (script)
- 控制器 (Controller)：組織、驅動、管理並監視整個效能測試的執行
- 負載產生器 (Load Generator)：在測試過程中用來執行虛擬使用者 (virtual user) 產生負載
- 分析 (Analysis)：用來檢視、剖析、比較測試的結果
為何要自動化效能測試？自動化效能測試是一種手段，透過人、流程與技術，降低應用系統上線、升級以及更新 patch 的風險。在系統上線前，以預期上線後的負載進行測試，並量測其系統效能以及使用者經驗。一個好的效能測試可以回答以下的問題：
- 當預期數量的使用者同時上線時，系統的回應是否夠快？
- 系統是否能夠負荷的了預期的負載，甚至在超出預期的負載下也能正常運作？
- 系統是否能夠處理的了所有的商業交易？
- 在預期的負載或是超出預期的負載下，系統是否穩定？
- 在決定上線時，您能確保使用者將會有良好的使用經驗(如回應時間)？
除此之外一個有效的效能測試，還能幫助您取得更多的資訊以便決定軟體是否可以交付部署，並且減少系統當機時間。透過自動化效能測試，可以將商業變化所造成的衝擊給量化，並藉此明瞭部署軟體的風險。
自動化效能測試流程
譯註：這張圖說明了整個效能測試的流程，非常具有參考價值喔！
一般而言，自動化效能測試的流程分成四大階段：設計 (design)、建立 (build)、執行 (execute)、診斷與調優 (diagnose and tune)。每個階段都需要有不同的角色參與，以完成不同的工作。
- 在設計階段需要定義要執行效能測試的商業流程 (business process)、在一般以及尖峰時間需執行哪些商業流程、同一時間有多少的使用者上線、以及系統的效能指標如回應時間 (response time)。
- 在建立階段首先要建立整個測試環境，包含待測系統以及基礎建設 (infrastructure)，如網路。並透過自動化效能測試工具，建立測試腳本 (script) 與測試場景 (scenario)。
- 在執行階段則是執行測試場景，並監視系統效能。
- 而診斷與調優主要透過執行測試場景所蒐集到的效能數據，快速地找到問題與瓶頸，以便優化整個系統的效能。這個階段是需要配合執行階段一起反覆進行的。
接下來將針對每一階段的工作做更詳細的說明，以確保效能測試的成功：
設計 (Design)在這個階段，效能測試團隊主要的工作是取得系統的效能需求，效能需求一般可分成四大類 - 商業 (business)、技術 (technical)、系統 (system)、團隊 (team)。
從商業需求的角度，您可以透過與專家 (subject matter experts, SMEs) 開會的方式蒐集商業需求。這些專家可能是商業分析師 (business analusts) 或者是您的使用者。商業需求可能會以下列的方式呈現：
- Application overview：透過使用者示範的方式，讓效能測試團隊從高階的角度，清楚的知道系統是如何被使用。
- Business Process List：一份列出在系統上會被使用者執行的關鍵商業流程清單。
- Business Process Flows：針對清單上的每一個關鍵商業流程，將其操作步驟、螢幕畫面，寫成文件。
- Transaction List：列出關鍵商業流程中，需要被量測效能的關鍵步驟，例如登入、新增訂單。
- Business Process Diagrams：透過流程圖畫出商業流程，以便測試人員了解流程中的分支與條件。
譯註：這些資料會跟你要測試哪些交易流程有關係。
從技術需求的角度，您需要和系統管理員 (syetem administrator) 和 資料庫管理員 (database administrator, DBA) 開個會議，以便了解系統的技術需求有哪些。這些人可能來自開發部門以及營運部門。要取得技術需求，可以透過下列的方式進行：
- An Environment Walkthrough：了解被測系統的環境與架構。
- System Scope Meeting：對整個效能測試涵蓋的系統範圍取得一個共識。
- Production Diagram：Production 環境的系統架構圖，並且要標示出從測試環境轉移到正式環境時，可能影響系統效能的點。
譯註：了解系統環境後，才能建立測試環境，而且當效能出現瓶頸時，也才能夠決定該蒐集哪些資料，以便找出問題所在。
再來是從系統需求的角度，你必須了解高階的系統需求，才能訂出測試的目標，如此一來當測試結果出爐，才能判定系統是否符合需求。系統需求可以從回答以下的問題來取得：
- 系統在一般以及尖峰時間，分別要能夠負荷的了多少個同時上線的用戶？
- 系統每秒必須處理多少交易？
- 針對系統的業務關鍵交易 (business-critical transaction)，可接受的最小與最大回應時間是多久？
- 使用者是透過什麼方式連上系統的？
- 系統在正式環境的負載可能會多大？分別是哪些交易組成的？
譯註：有了這些資料你才能知道該如何設計測市場景。最重要是有目標，你才知道什麼時候測試做完了。
在真正進入下一個「建立」的階段之前，還有一個「團隊需求」要注意。所謂團隊需求最主要就是要決定哪些成員要參予效能測試。一開始可能只是一人團隊，假如希望達到 CoE ( Center of Excellence) 的境界，就必須確定要有後勤支援的資源。
譯註：您可以考慮將這些人抓來參予效能測試：專案經理、測試經理、網管人員、系統管理人員、資料庫管理員、開發人員、系統分析師、有經驗的使用者、技術顧問。
建立 (Build)在「建立」階段，就可以將「設計階段」的業務流程 (business process) 與工作負載 (workload) 轉換成自動化的元件，以驅動可重複的、符合實際情況的負載。此階段的工作可以分成二大類：自動化設定與環境設定。
自動化設定主要由效能工程師 (performance engineer) 依序執行下列的工作：
- 建立腳本 (scripting)：將設計階段的業務流程轉成自動化測試腳本。
- 插入交易 (transactions)：插入用來量測回應時間的點。
- 參數化 (parameteriaztion)：將測試資料如帳號、密碼，轉成參數，讓每個虛擬使用者都可以使用不同的測試資料以進行測試。
- 建立情境 (sceenatios)：建立效能測試的情境，指定使用的測試腳本、虛擬使用者的量、排定執行的時程等。
- 監視器 (monitors)：決定要對哪些伺服器進行監控。
至於環境設定主要是建置一個符合實際情況的測試環境，如軟硬體、測試所使用的資料庫 (譯註：指資料庫內容、資料筆數) 等。主要參予人員有系統管理人員、資料庫管理員、營運人員、業務團隊等。
當可以在一個受控制的測試環境上，執行整個效能測試情境，表示已經完成「建立」階段，可以真正執行測試了。
執行 (Execute)對於剛開始接觸效能測試的新手，通常會有「效能測試只測一次」的誤解。事實上，一個完整的效能測試是由多種不同類型的測試所組成的。每一種類型的測試，都會提供不同的資訊，幫助您了解系統的商業風險。
這些類型的測試包含：
- 基準測試 (baseline test)：透過執行少量的負載，如 5~10 個的虛擬使用者，建立一個效能基準，同時驗證整個效能測試是可以正常執行的。通常在整個效能測試過程的開始與結束，都需要執行基準測試，如此才能了解系統的效能真的有改善了。
- 效能測試 (performance test)：效能測試主要目的在於模擬實際的環境，以了解系統可以處理的「最佳」以及「最大」的使用者數量。所以會以一般的平均負載以及尖峰的負載來進行測試。測試時也要儘可能模擬真實環境，如考量思考時間 (think time)、連線頻寬、不同的瀏覽器設定等。同時也會開啟監視器，以便找出瓶頸點。
- 性能標竿測試 (benchmark test)：當系統有變動，如增加硬體資源、資料庫版本升級、系統架構改變等，都透過性能標竿測試，藉此評估應該使用哪種軟硬體架構，也可以了解變動對系統效能所造成的衝擊，同時及早對未來可能成長的負載進行容量規劃 (capacity planning)。
- 滲透測試 (soak test) (譯註：翻譯的不好)：在模擬實際的負載下，透過長時間的測試，驗證系統的穩定性。
- 尖峰測試 (peak test)：在模擬尖峰的負載下，透過長時間的測試，藉此了解系統的極限。
分析、診斷、調優 (Analyze, Diagnose, and Tune)效能測試的投資報酬率 (ROI) 到底在哪？
- 降低風險：效能測試最主要的就是要降低系統上線後的風險，透過自動化效能測試，可以提供開發人員或專案成員許多清晰、可量化的 (quantifiable) 資訊，以便了解系統上線後的擴展性 (scalability) 與效能。
- 效能最佳化：由於資訊都是可量化的，所以可以確保系統是以最少的硬體資源，獲取最佳的終端使用者 (end-user) 回應時間。
如何達到效能最佳化
- 監視 (Monitoring)：透過監視可以清楚了解效能測試過程中，整個基礎建設的每一個層次的狀況，如 Web server、application server、database server。舉例來說，您可以透過監視 CPU 的使用率，發現在 200 個使用者上線時， CPU 使用率已經維持在 100% 了，而你的目標是系統要能承受 300 個使用者上線。這時您可能就需要增加硬體資源，或是對應用程式的程式碼作最佳化。
- 分析 (Analysis)：您可以分析比對各種資料以了解系統的行為，例如比對使用者的回應時間與 CPU 使用率，可以了解之間的關係。
- 調優 (Tuning)：許多公司使用 LoadRunner 在系統上線前、上線時以及上線後執行自動化效能測試。現在，Mercury 將以前的 ProTune 產品合併成為 LoadRunner 的一部分。透過調優的方法 (methodology)，可以自動調整系統的參數設定，以便達成系統效能目標。
- 診斷 (Diagnostics)：LoadRunner 提供的 Diagnostics 可以讓效能工程師，從整個交易流程向下分析，檢視到每一個元件、方法 (method)、SQL 指令的回應時間。讓開發人員更可以專注最佳化那些最花費時間的瓶頸點上。
效能測試需要哪些人的加入？
- 專案經理 (Project Manager)：協調多個效能測試、管控測試的時程、取得需要的軟硬體、處理資源分配、發現問題。
- 商業分析師 (Business Analyst)：負責從商業角度查核效能測試，並協助開發業務流程，以及量測回應時間的點。
- 效能經理 (Performance Manager)：整個效能測試團隊的聯絡窗口，負責協調效能測試的支援團隊，以及管理日常活動。
- 效能測試人員 (Performance Testers)：負責建立並執行效能測試，蒐集測試的結果。
- 系統架構師 (Application Architect)：對測試結果進行分析診斷，將系統效能做最佳化。
- 基礎設施專家 (Infrastructure Specialists: DBAs, Network Administrators, System Architects)：對測試結果進行分析診斷，將系統效能做最佳化。
譯註：效能測試是個團隊合作才能完成的工作喔！
Why Mercury？Mercury 在全球的效能測試自動化工具市佔率高達 70% (Newport Group, 2003)，以下列出 Mercury LoadRunner 的主要優勢：
- 有需求就可以模擬負載 (On-Demand Production Workload)：LoadRunner 可以驅動成千上萬的虛擬使用者，以及不同的商業流程，藉以模擬系統上線後所實際遭遇的負載，讓您可以在系統上線前，找出潛在的系統瓶頸。
- 支援廣泛的環境 (Enterprise Environment Support)：LoadRunner 支援將近 40 種的通訊協定 (protocol)，如 Web、J2EE、.NET、XML、SAP、Siebel、Oracle、PeopleSoft、wireless、Citrix、主從式架構 (client-server) 等。
- 支援眾多的監視器 (Enterprise Monitoring Support)：LoadRunner 使用非插入式 (non-intrusive) 的即時線上效能監視器，如 web server、application server、database server、ERP、CRM、防火牆、負載平衡等，協助您找出硬體資源極限以及軟體設定所造成的效能問題。
- 診斷 (Diagnostics)：LoadRunner 是唯一針對 J2EE、Oracle、Siebel 提供詳細診斷資訊的效能測試工具，您可以從商業流程的回應時間，一路下向探鑽 (drill down) 到 web、application、database 不同區段的回應時間，進而到每個 method 以及 SQL 指令所花費的時間。
- 基礎建設調優 (Infrastructure Tuning)：根據經驗有 70% 的效能瓶頸是因為基礎建設的設定問題所造成的。LoadRunner 內建 Tuning 模組，協助您找出基礎建設的設定問題。
- 自動化分析 (Automatic Analysis)：LoadRunner 的 AutoCorrelation 精靈，可以依據效能測試結果，自動找出可能是造成效能開始降低的前五大嫌疑犯，節省您找問題的時間。
- 容易使用 (Ease of Use)：LoadRunner 是為 QA 人員所打造的，提供視覺化腳本、資料與自動關聯精靈、ActiveScreen，大大降低學習曲線，讓您的效能工程師可以盡快上手使用 LoadRunner。
- TurboLoad：LoadRunner 的 TurboLoad 技術，可以使用最小的硬體資源產生最大的負載量。
- 廣域網路模擬 (WAN Emulation)：LoadRunner 可以模擬廣域網路的時間延遲 (network latency)與封包遺失 (packet loss)，讓您可以模擬最真實的使用情境。
- 統一的腳本引擎 (Unified Scripting Engine)：LoadRunner 使用與 Mercury Application Management 解決方案相同的腳本引擎，大大降低使用 Mercury 解決方案的教育訓練與建立腳本的成本。
|
GMail Icon Maker
另外 liu 提醒：怕这个网站供给不纯，用这个功能来收集大家的邮件地址。所以用的时候自己小心了
只要在上面這個網頁輸入你的 GMail 的 username，就會幫你產生出屬於你個人的 GMail email address 小圖示。
例如我的 GMail 信箱：