出于市場考慮，某集成商準備面向中小企業推出一套基于其開發的J2EE應用的解決方案，該解決方案不僅僅是一套開發完成的產品包，而是包括應用系統、應用服務器、數據庫服務器、服務器在內的解決方案包。從市場策略方面考慮，該解決方案面向的是相對較低的中小企業市場，因此整個解決方案包要求在滿足客戶要求的情況下具有最大的性價比。
解決方案能夠為客戶提供的功能當然是解決方案包首要考慮的問題，但除了功能外，作為整體推出的解決方案包必然需要提供良好的性能；另一方面，由于要求該解決方案包在滿足客戶要求的情況下具有最大的性價比，也就必須通過容量規劃的方式，選擇最合適的硬件設備、操作系統、應用服務器和數據庫的配合。通過前期的選型和決策，擬采用IBM Open Power 710作為服務器，IBM Wep Shpere 9.0作為應用服務器，Oracle 10g作為數據庫服務器，操作系統則從幾個不同的Linux發行版本中選擇最適合的。因此，對本項目來說，性能選型測試一方面需要驗證系統是否滿足預期的性能要求；另一方面，也要求能夠從多種不同的組合方式中選擇出最具有性價比的解決方案架構。
該項目是針對整體解決方案的選型測試，項目中的Web應用系統采用J2EE架構，服務器擬選用IBM Open Power 710，應用服務器選用IBM Web Sphere 9.0，數據庫采用Oracle 10g，操作系統則需要從幾個不同的Linux發行版（Suse、Redhat、Redflag、Turbo）中選取具有最佳性能的一個。
該項目是一個典型的性能選型測試，測試過程中，需要根據不同的組合方式，用同樣的負載條件進行測試，測試目的是找出各種組合中具有最佳性能的那個。
對這種類型的性能選型測試來說，需要重點關注兩個方面：一是規劃合理的組合方式和需要關注的性能指標；二是需要保證每次測試的相同負載條件。
本節描述性能測試的全過程，根據本書第5章的性能測試過程描述，按照PTGM模型分別對性能測試的各階段進行闡述。
在了解該項目的基本狀況之后，首先開始測試前期準備工作。
1.系統基礎功能驗證
在本案例中，系統基礎功能驗證工作不包括在選型測試工作中。
2.組建測試團隊
根據該項目的具體情況，建立一個3人的團隊負責本次測試工作。團隊的3個成員中，1名是系統工程師，1名是性能測試設計和分析人員，1名是性能測試開發和實施人員。所有的成員均來自組織內部，且接受了必要的培訓。
該團隊中的系統工程師承擔的工作較多，一方面需要搭建各種不同的環境；另一方面，在測試過程中，必須保持和相關廠商的聯系，確保操作系統已經經過仔細調優，得到的測試結果是在當前操作系統下的最佳結果。
3.測試工具需求確認
根據系統測試的要求，綜合工具成本和測試團隊已有技能考慮，最終確定測試工具至少能滿足：
- 支持對Web系統的性能測試，支持HTTP和HTTPS協議。
- 負載生成器和調度工具運行在Windows平臺上。
- 支持對WebSphere、Oracle和Linux Server的性能計數器進行監控。
4.性能預備測試
本次性能選型測試需要針對各種不同配置進行，在不同配置下進行相同的測試，我們并沒有安排對每個不同配置下的系統進行性能預備測試。
測試工具引入在本性能測試過程中不作為一個關鍵的過程，根據本性能測試對工具的功能需求以及團隊成員本身使用工具的經驗，最終選擇Mercury公司的LoadRunner 8.0版本工具作為本次測試使用的主要工具。
對本案例來說，由于并不是對系統進行能力驗證的性能測試，因此在測試計劃階段，需要重點關注的是選擇典型的業務和場景，該業務和場景從以往對Web應用的測試中獲取。
1.性能測試領域分析
根據對項目背景的了解，本性能測試要解決的主要問題是在何種配置條件下系統具有最佳的性能表現，根據領域分析，本測試應該落在規劃能力領域。
2.用戶活動剖析與業務建模
該解決方案中的Web業務系統已經在多個客戶現場運行了一段時間，并已經經歷過多次能力驗證領域的性能測試。因此，在本案例中，可以很容易地從以前的測試計劃中獲取典型的業務和場景。
本案例中，選取典型業務的原則是：
- 選取業務量較大的業務。
- 選取業務量不大但消耗系統資源多的業務。
- 選取需要重點關注的業務。
表1描述了在選型測試中將會使用到的所有業務，可以以此為基礎來進一步分析用戶場景，并據此設計相應的測試方案和用例。
表1 選取的業務
當然，按照的要求，需要為每個業務準備其相應的業務操作描述（用例），在其他3個案例（《某省電信公司業務系統的性能測試》、《某通信企業Web業務系統的性能測試》）中，已經展示了對業務操作進行描述的方法，在本案例中這部分內容不是重點，因此不再贅述。
3.確定性能目標
本性能測試的應用領域是規劃能力，由于解決方案包面對的是中小企業，預期的用戶數量主要從營銷部門獲得：
- 頁面響應時間小于5秒。
- 能夠支持的并發用戶數不小于50，最大支持并發用戶數要求為100。
- 在50個并發用戶條件下，服務器的CPU平均使用率小于70%，內存使用率小于75%；在100個并發用戶的條件下，服務器CPU平均使用率小于90%，內存使用率小于85%。
4.制訂測試時間計劃
本案例中，測試時間計劃安排如表2所示。
表2 測試時間計劃
本案例中，由于需要在多個不同的環境中進行性能測試，因此測試環境搭建和測試執行占了主要的時間。
1.測試環境設計
本性能測試需要給出“在何種配置條件下系統具有最佳的性能表現？”這個問題的答案。因此，在性能測試中，需要安排多個不同的配置環境，在不同的配置環境下檢查應用系統的性能，并對不同配置條件下的系統測試結果進行分析。
根據該案例的背景描述，需要為不同的操作系統搭建不同的測試環境。最終確定的測試環境為4個，每個環境上除了操作系統不同外，其他內容都相同，如表3、4、5、6所示。
表3 測試環境1
表4 測試環境2
表5 測試環境3
表6 測試環境4
本案例的數據環境設計根據系統環境進行了簡單估算。以兩個月作為基準的數據存儲周期，大致的數據規模如下。
- 工單數據數量：19800條。
- 知識經驗庫數據數量：10000條。
- 作業計劃數據數量：2800條。
對本案例來說，保證數據環境在每次測試中一致非常重要，否則很可能由于數據基礎的不同而導致對測試結果的分析出現失誤，因此在首次生成基礎的數據記錄后，通過數據庫的export命令將數據導出為本地文件并保存，每次測試開始前，都通過數據庫的import命令將數據直接導入到數據庫，保證數據環境的一致性。
2.測試場景設計
在表1的基礎上，直接使用選擇的每一個業務形成一個場景。此外，還對部分業務形成了組合場景。
3.測試用例設計
確定測試場景之后，原有的業務操作描述，可以更進一步完善為可映射為腳本的測試用例描述。
本案例中，以“新建工單”業務為例，可以給出相應的測試用例描述。
用例編號：TC_XXXX_XX-1
用例條件：用戶已登錄，登錄用戶具有新建工單的權限
用戶步驟和驗證方法。
- 用戶單擊“新建工單”鏈接，進入新建工單頁面。
【驗證】銷售單頁面標題為“新建工單”。
- 用戶在新建工單頁面中輸入工單信息，包括“工單標題”、“工單內容”和“工單要求答復時間”3個域，其他保留默認值，單擊“提交”按鈕。
【驗證】返回HTTP200，轉向的頁面標題為“工單新建成功”。
4.腳本和輔助工具的開發
按照測試用例的描述方式，通過測試工具錄制用例的步驟，并在測試工具中對腳本進行調試和修改，保證腳本能夠達到測試要求，這就是腳本開發過程。本案例設計的業務過程相對簡單，按照用例描述直接錄制即可。
需要注意的是對腳本的參數化等處理。腳本錄制完成后，一般需要對其進行修改操作，包括參數化、關聯和增加檢查點。第12章中以LoadRunner為例，描述了這幾種不同操作的方法和步驟。
輔助工具的開發取決于測試本身的需要，本案例沒有使用任何輔助工具。
在測試執行與管理之前的過程和活動中，己經明確規劃了本性能測試的環境、場景和腳本，在本過程中，只需要按照前面階段的要求，將測試場景和腳本進行部署，然后執行測試并記錄結果即可。
1.建立測試環境
建立測試環境就是按照測試設計中設計的環境設計內容部署測試環境，在本案例中，由于測試的目標之一是要找到硬件配置是否是制約系統性能的主要因素，因此一個較大的風險是能否保證各測試環境之間，體現在測試結果上的差異主要是由操作系統差異導致的，也就是說，在測試環境中，要盡量保證測試的結果不會受到其他因素的影響。為了實現這點，在本測試過程中使用了CheckList來檢查具體的數據庫設置和應用服務器設置，并由系統工程師對其進行了仔細的調整。
2.部署測試腳本和測試場景
部署測試腳本和測試場景通過LoadRunner來控制。LoadRunner本身提供了較為完善的對測試腳本和場景進行部署和管理的機制。
本案例使用的場景類型是Manual Scenario類型，即完全由用戶設定場景的條件。
3.執行測試和記錄結果
LoadRunner工具能夠在運行測試的過程中自行保存測試的結果，因此無需特別設計方法來記錄vu的響應時間等數據，同時，LoadRunner還能夠記錄部分主機和應用服務器的資源使用信息。
根據設計，最終需要運行的測試內容如表7所示。
表7 需要實際執行的測試項目
根據表7的描述，列出執行的各種不同測試結果，并進行分析。為了不使描述顯得過于重復，我們沒有給出全部測試項目的圖表，只是有選擇性地給出了具有代表性的分析過程。以下分析結果以“查詢知識經驗庫”和“新增作業計劃”為例進行說明。
（1）Suse操作系統上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖1和圖2所示。
圖1 50并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
圖2 100并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
從圖1和圖2可以看到，當并發用戶數超過50時，系統出現了一個明顯的性能瓶頸，根據性能下降曲線分析，在Suse操作系統環境下，性能的拐點應該出現在48個Vuser左右。而在50并發用戶情況下，系統的平均響應時間在3～5秒之間。
（2）Redhat操作系統上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖3和圖4所示。
圖3 50并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
圖4 100并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
從圖3和圖4可以看到，當并發用戶數超過58時，系統出現了一個明顯的性能瓶頸，根據性能下降曲線分析，在Redhat操作系統環境下，性能的拐點應該出現在58個Vuser左右。而在50并發用戶情況下，系統的平均響應時間在2～4秒之間。
因此，單從系統能夠支持的并發用戶數考慮，在Redhat環境下的系統比Suse環境下的系統有一定的優勢。
（3）Redffag操作系統上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖5和圖6所示。
圖5 50并發用戶條件下的Running Vusers—Average Transaction Response Time曲線
圖6 100并發用戶條件下的Running Vusers—Average Transaction Response Time曲線
從圖5和圖6可以看到，當并發用戶數超過55時，系統出現了一個明顯的性能瓶頸，根據性能下降曲線分析法，在Redffag操作系統環境下，性能的拐點應該出現在55個Vuser左右。而在50并發用戶情況下，系統的平均響應時間在3～5秒之間。
從曲線上看，Redffag上的性能表現與Suse上的性能表現基本相當。
（4）Turbo操作系統上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線7和圖8所示。
圖7 50并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
圖8 100并發用戶條件下的Running Vusers-Average Transaction Response Time曲線
從圖形上可以明顯地看到，相對于其他3個操作系統，Turbo操作系統下的性能表現明顯要差一些。在100并發用戶條件下，從30個并發用戶開始，響應時間就大于20秒；而在50并發用戶條件下，在25個并發用戶處，系統有一個明顯的性能瓶頸。
由于所有操作系統的優化調整都是由廠商的工程師直接進行的，不排除在調整過程中出現廠商沒有很好地進行操作系統設置優化，導致測試結果存在明顯差異的情況。
（5）其他測試項目分析。
以上僅從系統能夠支持的并發用戶數角度對各種不同配置下的系統進行了比較，其實對選型測試來說，需要比較的內容還遠不止這些。表8給出了總體的比較結果。
表8-1
表8-2 總體比較結果
從表8可以看到，在不同的操作系統上，CPU、內存使用情況都會有一些差異，但從總體來看，差異并不明顯。也就是說，不同的Linux操作系統并不是影響性能的關鍵性因素。綜合總體比較結果以及前面分析的各不同配置條件對并發用戶數的支持來看，RedHat操作系統相對來說具有較優的性能。
該案例的重點在于演示性能選型測試的過程，并進一步演示了如何使用LoadRunner進行結果分析。
性能選型測試/容量規劃測試是實際工作中較為常見的一類性能測試要求，一般而言，這種類型的測試都需要通過性能測試的手段從不同的配置中選取具有最佳性能的配置。這種類型的測試需要在兩個方面特別注意：一是環境的一致性；二是確定性能測試的主要比較指標。
最后要說明的是，本案例僅描述了一個筆者親身經歷過的選型測試，其中包含的數據不能用來說明本案例涉及的Linux操作系統的性能優劣。
標簽：
性能測試軟件測試技術軟件測試
本站文章除注明轉載外，均為本站原創或翻譯。歡迎任何形式的轉載，但請務必注明出處、不得修改原文相關鏈接，如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
金喜正規買球 
16次
相關產品
正式授權
最新文章 
金喜正規買球相關的文章 
微信
在線咨詢
渝公網安備
50010702500608號
客服熱線