性能測試--需求提取

性能測試--需求提取

性能測試需求提取

復習了一些常見的理論概念后，我們開始性能測試需求的提取。這個過程是非常重要的，往往測試失敗，就是因為在這個過程中不知道如何得到確切的性能指標，而導致測試無法正常開展。性能測試需求提取一般的流程如圖1- 1所示。

圖1-1性能測試需求提取流程

一、分析提取指標

在用戶需求規格說明書中，會給出系統的功能、界面與性能的要求。規范的需求規格說明書都會給出明確的性能指標，比如單位時間內訪問量要達到多少、業務響應時間不超過多少、業務成功率不低于多少、硬件資源耗用要在一個合理的范圍中，這些指標都會以可量化的數據進行說明。如果，實際項目并沒有這些正規的文檔時，項目經理部署測試任務給測試組長時，一般就會說明是否要對項目的哪些業務模塊進行性能測試，以及測試的要求是什么的。最麻煩的就是項目經理或者客戶要求給出一個測試部門認為可以的數據，這樣非常難做的?？墒恰凹追健蓖际翘嵋蟮模耙曳健敝荒堋盁o條件”接受！

對于正規的項目，用戶需求規格說明書中一般會給出類似表1- 1的性能測試要求：

測試項

響應時間

業務成功率

并發數

CPU使用率

內存使用率

用戶登錄

<=3秒

>98%

20

<75%

<75%

表1-1需求規格說明書中的性能要求

表1- 1給出的指標非常明確，在測試過程中，我們只需收集用戶登錄模塊的響應時間、登錄成功率、并發數、CPU使用率、內存使用率的數據，然后與表5- 1的指標進行比較即可，通過的，就認為達到了客戶要求的性能，未達到就分析原因，并給出測試報告及解決建議。

大多數是沒有明確的需求，需要我們自己根據各種資料、使用各種方法去采集測試指標。以OA系統為例，假設《OA系統需求規格說明書》中并未指明系統的性能測試要求，需要測試工程師自己分析被測系統及采集性能衡量指標。

分析OA系統的結構，所有功能中僅有考勤模塊可能是被測系統最終用戶經常使用的業務點，那么我們的重點應該在放在該模塊上。一般我們可以從下面三個方面來確定性能測試點：

第一、?????????????用戶常用的功能。常用的功能一旦性能無法滿足，比如登錄功能，從輸入用戶名與密碼點擊登錄按鈕到顯示成功登錄信息，花了5分鐘，這樣的速度是人無法忍受的。而對于用戶不常用的，比如年度報表匯總功能，三個季度甚至是一年才使用，等個10分鐘也是正常的，這些是跟用戶的主觀感受相關的，得根據實際情況區分。

第二、?????????????系統業務邏輯復雜，數據流轉頻繁的功能。這些地方最終用戶可能看不到、用不到，但在系統是個關鍵點，沒有它其他功能就不能正常工作，即使用戶未提出做性能測試，作為測試部門也應該對這些地方進行性能測試，以保證他們能夠正常工作。

第三、?????????????與外部系統的接口處。有時候本系統需要使用其他系統的組件。我做過的一個項目，B/S結構的企業信息管理系統，其用戶管理模塊中的用戶數據就是使用早期C/S結構的ERP系統。前一個使用Oracle數據，后一個是用Sybase數據，設定了每三個小時更新一下用戶信息，以保證兩個系統用戶信息是一致的。這樣的功能，也是應該做測試的，特別是涉及到多系統的。

綜合考慮，與考勤模塊相關的是登錄模塊，因為登錄是考勤的前置條件，所以在實際的測試中不僅要測試考勤的，還應該考察登錄模塊的性能表現，盡管這不是用戶要求的。

OA系統是一個面向廣大企業用戶的辦公自動化系統。根據大多數公司的作息安排，早上九點基本是公司的上班時間。那么根據實際業務分析，早上8:40到9:10可能是OA系統登錄的高峰期。因為很多人集中在這個時候達到公司進行考勤業務操作。這個時候，就可以確定系統測試的一個時間段了。接下來，需要調查一般會有多少人使用OA系統，這個數據比較難，應該公司的規模不一樣，人數也就不一樣。既然是面向公眾，那么就可以由開發工程師給出一個參考值，比如開發工程師說可以支持2000 人同時使用，那么我們就將使用系統的人數定為2000人。既然說是2000人同時使用，我們可以理解為2000人在8:40到9:10這30分鐘的時間里都要完成登錄、考勤操作，并且不能有失敗的業務。也就是說業務的成功率要求在100%。這樣一來，到目前為止，得到了下面幾個數據：

1、? OA系統使用高峰期為30分鐘；

2、? 并發使用人數為2000；

3、? 登錄、考勤成功率100%。

接著分析，在滿足功能的同時，還需要考慮操作的響應時間。很多公司都有遲到處罰制度，我原來的公司遲到一分鐘扣五塊錢，有的公司甚至更狠。所以，如果應為頁面反映慢而導致遲到，會“冤死”一批人，這樣的問題絕對不能出現。那么響應時間為多少算正常呢？說實話，這樣的問題本身就是有問題的，何謂快，何謂慢？都是主觀判斷，你心急的時候覺得它慢，不急的時候覺得它快，所以沒有一個定論，按照業內一個經驗值，就是2、5、8或者3、5區分。2秒或者3秒的功能結果響應時間是非常理想，5秒就有點讓人覺得不爽了，而8秒，甚至更高很可能導致用戶放棄操作，或者再次發起第二次請求。這樣的經驗值在實際測試中對我們確定響應時間有很高的參考價值，當然響應時間還應該根據業務類型定，而不能僅從用戶的感官考慮。我們這里就采用常規的3秒為目標，也就是說OA系統處理登錄、考勤業務的服務器響應時間不超過3秒。

除了軟件的要求外，還應該對硬件資源進行監控，比如應用服務器的CPU使用率、內存使用率、帶寬情況、Web服務器的資源使用情況等等，那么如果用戶未提出要求，我們就按照常識走，CPU的使用率不超過75%，內存使用率不超過70%，其他指標這里就不列出了。之所以選擇這兩數值，是因為他們具有代表性。CPU的使用率超過75%可以說是繁忙，如果持續在90%甚至更高，很可能導致死機、機器響應超級慢等問題。如果過低也不好，說明CPU比較空閑，可能存在資源浪費的問題。對于內存存在同樣的問題。

通過上面的分析，最終采集得到本次測試的性能參考指標如表1- 2所示：

測試項

響應時間

業務成功率

業務總數

CPU使用率

內存使用率

登錄

<=3秒

100%

30分鐘完成2000

<75%

<70%

考勤

<=3秒

100%

30分鐘完成2000

表1-2 OA系統性能參考指標

得出本次測試的性能參考指標后，我們就可以進行測試模型的建立了。

1、建立業務模型

得到性能測試參考指標后，再次分析OA系統的實際使用情況，我們可以進行測試模型的建立，也就是建模。所謂建模，就是建立用戶業務模型。建模是性能測試的基礎。只有建立合理有效的業務模型，才能模擬出真實的系統使用情況，才能找到今后可能發生的缺陷，所以建立恰當的業務模型是我們性能測試成功與否的關鍵。那如何建立用戶業務模型呢？

根據上面的測試要求，我們需要測試OA系統登錄與考勤兩個模塊的性能。這兩個模塊的使用方法是什么樣的？用戶又是怎么使用的？相對其他的業務系統而言，這里的功能比較簡單了。登錄功能很常見，輸入用戶名與密碼，點擊登錄按鈕即可完成登錄操作。登錄成功后，直接進入考勤頁面，點擊考勤按鈕，即可完成考勤操作。所以，不需做太多的分析就能弄清楚這個過程。如果用流程圖表示，則可表示為圖1- 2。

OA 表1-2系統考勤流程圖

建立實際的業務模型如表1- 3所示：

步驟序號

步驟描述

1

用戶打開OA系統首頁地址

2

輸入用戶名“erbao”

3

輸入密碼“123456”

4

點擊【登錄】按鈕

5

進入erbao個人頁面，展開“行政管理”

6

展開“員工事務”，點擊【員工考勤】鏈接

7

默認設置，點擊頁面右邊【發送】按鈕

8

考勤成功，點擊【退出】按鈕，退出系統

表1-3 OA系統考勤業務模型

經過分析測試要求與建立業務模型兩步，基本上已經確定了本次測試的內容。大多數項目的性能測試分析都可以使用這樣的方法。在分析與建模過程中，最重要的是要弄清楚當前測試的重點是什么，對應的業務流程是什么，就像我們做功能測試一樣的，性能測試也需要在客戶的實際應用基礎上開展，否則脫離實際的測試是無效的。

二、評審確定指標

前面的兩步僅是測試工程師的分析確定過程，并沒有取得項目組的審核，要知道，在一個軟件生產過程中，評審在每一個過程都應該存在。得到測試指標與模型后，就需要編寫對應的性能測試計劃或者性能測試方案，并提交項目進行審批。如果項目組沒有這個要求，測試工程師也需告知項目經理、開發組長與測試組長，并要求得到反饋。我曾做過的一個移動項目，方案改了三次，局方經理才同意，盡管他們并沒有提出什么要求，就是認為不妥，此時我們就必須不斷調整，他不同意，我們就不能開展工作。所以，有時候這個評審可能是個形式，但也得做。一般在這個階段會生成性能測試計劃或者性能測試方案。后期的性能測試工作就按照這些文檔開展。

性能測試用例設計

經過性能測試需求提取階段的努力，測試目的明確了，就需要設計詳細的測試用例了。這個階段主要考慮的是如何實現性能測試模型。

與功能測試用例設計不同的是，性能測試用例一般僅考慮正常的業務流程，而不會去檢查異常流程，但其中的約束條件仍是需要注意的。比如有些在線投票系統是不允許一個IP投多次票的，在性能測試過程中特別需要注意這方面的問題。比如同一個IP僅允許一個用戶登錄、一個用戶僅能操作一次、不允許出現同樣的數據，業務操作中存在臨時會話ID等等問題。

從功能角度考慮，用戶使用OA系統中的考勤功能，只能進行一次到達單位的簽到，如果再次點擊考勤按鈕，則系統不允許提交，給予提示“不能重復考勤”。這樣，在測試過程中，就需要使用不同的用戶名。仔細分析測試數據的約束關系，找出其中容易出問題的地方，然后想辦法解決它。

經過分析，了解到考勤功能不允許重復考勤，也就意味著一個用戶只能進行一次考勤操作。除此之外，還需要考慮同一個IP允不允許多個賬號登錄，在前面的功能測試階段我們得知，OA系統是允許這樣的操作的，那么在測試過程中就不需要進行IP欺騙的操作了。除此之外，似乎OA系統沒有其他的限制了。

再次強調，在設計性能測試用例的時候，一定要弄清楚測試點是否存在約束條件，一般可由該測試點對應的功能測試用例得到。

綜上所有，設計出本次性能測試的用例如表1- 4所示：

約束條件：同一用戶只能進行一次考勤

測試數據：用戶名做參數化，預計5000個

操作步驟：

1、用戶打開OA系統首頁地址

2、輸入用戶名“erbao”

3、輸入密碼“123456”

4、點擊【登錄】按鈕

5、進入erbao個人頁面，展開“行政管理”

6、展開“員工事務”，點擊【員工考勤】鏈接

7、默認設置，點擊頁面右邊【發送】按鈕

8、考勤成功，點擊【退出】按鈕，退出系統

期望結果：

測試項

響應時間

業務成功率

業務總數

CPU使用率

內存使用率

登錄

<=3秒

100%

30分鐘完成2000

<75%

<70%

考勤

<=3秒

100%

30分鐘完成2000

實際結果：

測試項

響應時間

業務成功率

業務總數

CPU使用率

內存使用率

登錄

考勤

測試執行人：

測試日期：

表 OA1-4系統性能測試用例

至此，性能測試需求分析與測試用例設計已經完成，下面就可以利用測試工具進行實際的測試了。這里使用的是HP公司的LoadRunner8.1英文版。LoadRunner是一款專門用于性能測試的測試工具。該工具可以輕松的模擬百萬用戶并發使用軟件系統的情景，同時可利用場景執行功能模擬真實的業務，場景執行完畢后，LoadRunner還提供了強大的測試結果數據分析功能，以便于測試工程師分析系統中所存在的性能問題。

云性能測試服務 CPTS

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。