性能測試用例選擇的原則及方法

2021-01-16 說說軟體測試那些事兒

性能測試用例選擇的原則:

a. 重要的(業務上)

b. 重複的(最常用的模塊)

重量級的(消耗大量系統資源的)

1、具體性能指標分為幾類:

a. 系統容量(數據容量、用戶量、並發用戶量),

b. 系統並發度指標(註冊用戶、在線用戶、並發用戶),

c. 響應度指標(正常壓力下響應能力、峰值壓力下的響應能力,以及異常壓力下的響應能力)

2、理解整個系統及其實現之後,再列出自己分析得到的性能需求點。

3、詢問客戶的具體性能需求,共同分析,是否測試,測試的優先級。

4、寫出性能測試計劃和用例,並要得到客戶認可。

下面列出了一些性能要求的測試點:

1) 查詢2) 保存3) 統計4) 刷新5) 顯示6) 傳輸7) 響應8) 下載

打開網絡上其它介質上的文件時,可製造網絡擁擠情況下的文件打開操作。

主要測試點,集中在幾個點上。

一是:數據量小的時候主要的查詢統計刷新等功能點;

二是:數據量積累到一定程度時的查詢統計刷新時間,這裡的一定程度是根據實際的項目和客戶需求來定的。

性能測試分為基本性能測試和高級性能測試

基本性能測試

主要內容包括:安全可靠性、資源佔用率測試、兼容性、易用性、用戶文檔、效率、可擴充性。

(1)安全可靠性測試

序號 測試項目 描述 測試結果

1 用戶權限限制 考察隊不同的用戶權限限制情況 符合/基本符合/不符合

2 用戶和密碼封閉性 對於相應用戶和密碼進行次數限制 符合/基本符合/不符合

3 屏蔽用戶操作錯誤 考察對用戶常見的操作錯誤的提示和屏蔽情況 符合/基本符合/不符合

4 錯誤提示的準確性 對用戶的錯誤提示的準確程度 符合/基本符合/不符合

5 錯誤是否導致系統異常退出 有無操作錯誤引起系統異常退出的情況 符合/基本符合/不符合

6 數據備份與恢復手段 系統是否提供備份及恢復功能,備份手段如何,是否對備份數據加密、壓縮 符合/基本符合/不符合

7 輸入數據有效性檢查 系統對數據錄入的有效性檢查 符合/基本符合/不符合

8 留痕功能 系統是否有操作日誌,操作日誌記錄的操作情況的全面性和準確性,是否包括主要要素,如操作員、操作日期、使用模塊等 符合/基本符合/不符合

9 異常情況的影響 在程序運行過程中,進行掉電實驗,考察數據和系統的受影響程度,若受損,是否提供補救工具,補救的情況如何 符合/基本符合/不符合

10 數據傳輸安全性 對有特殊安全要求的數據傳輸,應對傳輸的數據進行必要的加密處理,使用的算法應符合國家規定 符合/基本符合/不符合

(2)資源佔用率測試

序號 測試項目 描述 測試結果

1 軟體安裝所佔用硬碟空間 考察軟體安裝所佔用硬碟空間 符合/基本符合/不符合

2 模塊裝載後內存佔用量(包括虛存) 考察模塊裝載後內存佔用量(包括虛存) 符合/基本符合/不符合

3 模塊卸載後內存釋放率(包括虛存) 考察模塊卸載後內存釋放率(包括虛存) 符合/基本符合/不符合

(3)兼容性測試

序號 測試項目 描述 測試結果

1 軟體兼容性 軟體測試適用平臺 符合/基本符合/不符合

2 硬體兼容性 硬體平臺的配置要求 符合/基本符合/不符合

(4)易用性測試

序號 測試項目 描述 測試結果

1 易安裝性 安裝的難易程度,符合流行安裝模式 符合/基本符合/不符合

2 用戶界面的友好性 界面的簡潔性如何 符合/基本符合/不符合 3 易學性 相對一般操作人員來說,學習使用的難度如何,對操作人員有何要求符合/基本符合/不符合 4 易操作性 操作的難易程度 符合/基本符合/不符合 5 聯機幫助豐富性 考察聯機幫助的準確性、全面性、在關鍵操作時使用聯機幫助的方便性 符合/基本符合/不符合

(5)用戶文檔測試

序號 測試項目 描述 測試結果

1 用戶手冊的完整程度 用戶手冊內容的全面性、完整性 符合/基本符合/不符合 2 用戶手冊的描述與軟體實際功能的一致性 手冊與軟體實際功能的一致程度 符合/基本符合/不符合

3 用戶手冊的易理解程度 用戶手冊對關鍵重要的操作有無圖文說明,例圖的易理解性如何

符合/基本符合/不符合

4 用戶手冊的印刷與包裝質量 用戶手冊包裝的商品化程度印刷質量 符合/基本符合/不符合

5 用戶手冊提供的學習操作實例 對主要功能和關鍵操作提供的應用實例有多少,實例的詳細程度如何 符合/基本符合/不符合

(6)效率測試

序號 測試項目 描述 測試結果

1 通信效率 網絡負載、吞吐率、利用率、響應時間、延遲等 符合/基本符合/不符合

2 設備效率 CPU佔用率、內存佔用率、磁碟佔用率、輸入輸出效率等,包括軟體在不工作狀態下對於硬體資源的佔用情況和進行業務處理過程中對於硬體資源的佔用情況 符合/基本符合/不符合

3 執行效率 典型業務操作的執行效率,例如關鍵的查詢、統計等的響應時間等 符合/基本符合/不符合

(7)可擴充性測試

序號 測試項目 描述 測試結果

1 與異種數據接口 有無與其它數據的接口 符合/基本符合/不符合

2 是否能擴充功能模塊 能否根據用戶要求擴充功能模塊 符合/基本符合/不符合

高級性能測試

主要內容包括:並發性能、系統資源監控、大數據量、速度、疲勞等內容,重點是並發性能測試。

(1)並發性能

並發測試的過程,是一個負載測試和壓力測試的過程。即逐漸增加負載,直到系統的瓶頸或者不能接收的性能點,通過綜合分析交易執行指標和資源監控指標來確定系統並發性能的過程。

並發性能測試及系統資源監控使用自動化負載測試工具及監控工具。

測試案例:例如:中間件應能滿足一定數量的前臺客戶端同時辦公的需要。

測試內容與監控指標:

★ 負載壓力測試;

★ 模擬不同數量並發用戶測試。

模擬不同數量並發用戶執行關鍵業務,測試至系統能夠承受的最大並發用戶數。

主要監控指標如下:

每分鐘事務處理數(Transaction Rate):不同負載下每分鐘成功完成的事務處理數;響應時間(Response Time):伺服器對每個應用請求的處理時間,單位:秒,該項指標反映了系統事務處理的性能,具體包括以下幾項參數:

- Min:最小的伺服器響應時間;

- Mean:平均的伺服器響應時間;

- Max:最大的伺服器響應時間;

- StdDev:事務處理伺服器響應的偏差,值越大,偏差越大;

- Median:中值響應時間;

- 90%:90%事務處理的伺服器響應時間

- 虛擬並發用戶數(Total Virtual Users):測試工具模擬的用戶並發數量。

(2) 系統資源監控

在進行負載壓力測試的同時,用測試工具對資料庫伺服器、Web伺服器、應用伺服器、認證及授權伺服器上的作業系統、資料庫以及中間件等資源進行監控。

監控系統資源指標,在測試中,根據測試需求以及測試環境的變化,選取有意義的數據進行分析。

(3)大數據量

測試案例:例如:考慮系統未來發展需要的存儲空間,添加大數據量測試。

測試內容:

主要包括兩方面內容:

一是:單獨的數據量測試;

二是:與並發性能測試相結合的綜合測試。

測試數據的準備藉助於測試數據管理與生成工具,例如FileAid。

(4)速度

測試案例:例如:磁碟訪問速度、備份速度以及網絡辦公系統運行速度等。

測試內容:

主要是人工測試。

(5)疲勞測試

通常是採用系統穩定運行情況下能夠支持的最大並發用戶數,持續執行一段時間業務,通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程。

性能測試指標一般有2種形式描述:產品需求指標和系統的性能指標。

1.產品需求指標

★ 給出產品性能的主要指標,如在100000記錄中查詢一個特定數據的時間為0.5秒;

★ 以某個已發布的版本為基線,如比上一個版本的性能提高30-50%;

★ 和競爭對手的同類產品比較。

2. 系統的性能指標

★ CPU利用率;

★ 內存佔用率;

★ 磁碟I/O ;

★ 響應時間。

性能測試的方法

性能測試的策略

性能測試策略一般從需求設計階段開始討論制定,策略的內容決定著性能測試工作投入多少資源、什麼時間開始實施等後繼工作如何安排。制定性能測試的策略的因素:

1.預期的指標性能的因素

系統在需求分析、設計階段和產品說明書等文檔中明確的提出都性能指標,這些指標是性能測試要完成的工作。

2. 獨立業務性能測試的因素

獨立業務主要是指軟體產品的模塊具有獨立業務功能,在需求階段就可以確定,要單獨測試其性能。

3. 業務性能組合測試的因素

應用類軟體系統通常不會使所有的用戶只使用一個或者幾個核心業務模塊,可能是對多個業務進行組合使用,對多個業務進行組合性能測試。由於組合業務測試是最能反映用戶使用系統情況,因而業務性能組合測試是測試的核心內容。

4. 疲勞強度性能測試

疲勞強度測試是在系統穩定運行下模擬較大的用戶數量、並長時間運行系統的測試,通過綜合分析執行指標和資源監控來確定系統處理最大業務量時的性能,主要目的是為了測試系統的穩定性。

5. 大數據量性能測試的因素

大數據量測試是為了測試系統的業務處理能力進行的。

大數據量測試第一種是針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試,主要是測試數據增多時的性能情況,第二種是極限狀態下的數據測試,主要是指系統數據量達到一定程度時,通過性能測試來評估系統的響應情況,測試的對象也是某些核心業務或者日常常用的組合業務。

6. 網絡性能測試的因素

網絡性能測試主要是為了準確展示帶寬、延遲、吞吐量、負載、瓶頸和埠的變化是如何影響用戶的響應時間的。重點測試吞吐量指標,因為80%的系統性能瓶頸由吞吐量造成。

性能測試的方法

性能測試方法主要有:能力驗證、規劃性能、性能調優、壓力加載、性能下降曲線分析。

1. 能力驗證

能力驗證強調:系統具備的硬體設備、軟體環境、網絡條件、基礎數據。能力驗證使用到可靠性測試、壓力測試、失效恢復測試 。

規劃性能

規劃性能關心的是要求系統具有的性能,強調系統配置,使系統能夠滿足增長的用戶數的需要等問題。規劃性能使用到負載測試、配置測試、壓力測試。

3. 性能調優

性能調優關心的是要求系統確定基準環境、基準負載和基準性能指標;調整系統運行環境和實現方法;記錄測試結果、進行測試分析。

4. 壓力加載

壓力加載強調:

★ 穩定壓力加載。一次性將負載加到某個水平,持續一段時間;

★ 逐漸加載或交替加載到某個負載水平;

★ 峰谷測試。確定從系統尖峰時間的負載轉為幾乎空閒、再攀升到高負載這樣峰值交替情況下的系統性能狀態/指標。

5. 性能下降曲線分析

性能下降曲線分析 關心的是性能隨著用戶數的增加而出現下降趨勢的曲線分析、查看性能下降的環境點與上下文。確定性能閥值。性能曲線通過單用戶區域、性能平坦區域、壓力區域、性能拐點進行監控和分析。

●作者李龍,山東織雀信息科技有限公司負責人,織雀教育首席講師,中國民主同盟盟員,北京人文大學雲測學院院長、高工,國內軟體測試「川模型」的提出者,全國大學生軟體測試大賽評審委員會專家,致力於軟體測試人才培養

(配圖來源於網絡,如有侵權請聯繫作者刪除)

相關焦點

  • 軟體測試如何入門:軟體測試用例編寫
    相信不少人都想從事軟體測試行業,軟體測試特別適合有計算機基礎的女生,許多人會自學,也有人會選擇軟體測試培訓。那麼軟體測試應該如何入門呢?這篇文章就關於軟體測試用例的編寫與設計做一個簡單的分析。軟體測試人員常用的測試用例設計方法一般是黑盒用例設計方法,用最多的方法應該是等價類劃分法和邊界值分析法,這兩個方法是用例設計方法中比較簡單的。如何設計編寫測試用例1測試用例有哪些基本的組成元素?
  • 測試用例的基本介紹
    評估需求覆蓋率用例的復用積累測試的方法思路以供後續借鑑4.測試用例的設計方法4.1 總體的設計方法4.2具體的設計方法<1> 等價類:依據需求將輸入(特殊情況下會考慮輸出)劃分為若干個等價類,從等價類找那個選出一個測試用例,如果這個測試用例測試通過,則認為所代表的等價類測試通過,這樣就可以用較少的測試用例達到儘量多的功能覆蓋,解決了不能窮舉測試的問題。
  • 如何有效的維護軟體測試用例?遵循原則4步走!
    以下原因可能導致測試用例變更:1)軟體需求變更:軟體需求變更可能導致軟體功能的增加、刪除、修改等變化,應遵循需求變更控制管理方法,同樣變更的測試用例也需要執行變更管理流程。2)測試需求的遺漏和誤解:由於測試需求分析不到位,可能導致測試需求遺漏或者誤解,相應的測試用力也要進行變更。
  • 關於軟體測試/測試用例的問題,答案都在這裡了
    設計用例時容易遺漏。需要怎麼樣做更好呢? 手機應用端測試是最適合應用場景分析方法的,場景設計需要經驗的累積,不是簡單學習知識就行的,建議使用思維導圖,做個有心人,把平時測試的經驗都記錄下來,形成最適合的場景設計方法。 手機測試考慮有各種手機的牌子、型號(還有現在的太陽能手機情況下)、停機、沒電、內存容量等等。
  • 測試用例設計——案例詳解
    針對於輸入項,利用等價類及邊界值用例設計方法進行設計,選擇項則無須設計在步驟中,在測試執行時分別執行勾選與不勾選即可。01.用戶名用戶名共有三個條件:必填、不少於3個字符、不能重複,分別構造有效等價類及無效等價類,具體如表4- 1所示。
  • 一篇圖文帶你了解白盒測試用例設計方法
    覆蓋率:是用來度量測試完整性的一個手段測試設計方法——語句覆蓋語句覆蓋:設計測試用例,使得程序中每條語句至少被執行一次。例如:案例代碼中共有4條可執行語句設計測試用例執行了3條,語句覆蓋率為3/4=75%測試設計方法——判定覆蓋判定覆蓋:也叫分支覆蓋,設計測試用例,使得程序中的每個判的「真」和「假」都至少被執行一次。
  • 如何編寫測試用例?
    逆向思維的方法,其實就是不走尋常路,這也是開發人員常常忽視的地方。大家都在走同樣的路,我卻往反方向走,用與正向思維相反的思維方式設計用例,發現新bug。這是一種歷練,也是歷練中的摸索、創新。通過這種不同尋常的歷練,經常能夠幫助我們總結出適合自己的方法,自己也能得以提高。
  • 你還在問:安全測試要寫測試用例麼?黑客都在用測試用例找漏洞了
    眾所周知,系統測試是需要編寫測試用例的,它是保證測試執行正確性、有效性的基礎。但是,大家可能很難想像神秘的黑客在挖掘漏洞的時候會提前編寫測試用例,然後按照用例去執行。因為他的漏洞挖掘思路是存在腦海中,並且不斷地根據實際情況進行調整的。
  • 軟測大神手把手教你:如何寫出一份邏輯清晰的測試用例?
    理解企業文化和過程 測試期望 吸取教訓 工作量大小 解決方案的類型 技術選擇 預算 時間表 分階段的解決方案3.測試項目簡介>定義了開發產品或測試過程中常用術語的含義7.測試策略測試策略描述測試小組用於測試整體和每個階段的方法。
  • 寫100條測試用例,被正經執行的只有50條?
    一、問題 許多測試類書籍中都有大幅的篇章介紹用例的設計方法,如等價類劃分,邊界值,錯誤推斷,因果圖等。但實際應用中這些理論卻不能給我們很明確的行為指導,尤其是業務複雜,關聯模塊緊密,輸入標準和輸出結果間路徑眾多時,完全的遵循這些方法只能讓我們在心理上得到一種滿足,而無法有效的提高測試效率。 有時我們只有依靠以前項目的用例編寫經驗(或習慣),希望能在這一個項目中更加規範,但多數情況下我們規範的只是「書寫的規範」,在用例設計上以前存在的問題現在依舊。
  • 黑盒測試方法哪些
    (2)、邊界值分析方法 (3)、因果圖方法。(4)、正交實驗設計方法。(5)、功能圖分析方法。(6)、錯誤推測法。(7)、需求文檔轉化法 (8)、隨機測試。9)、對象屬性分析法 等價類劃分若輸入條件中規定了輸入數據的取值範圍,則可劃分出一 個有效等價類和兩個無效等價類若輸入條件中規定了輸入數據的個數,則可劃分出一個有效等價類和兩個無效等價類試若規定了輸入數據必須遵循的原則
  • 只寫測試用例不管代碼?懶人如何高效的做回歸測試
    自動回歸測試將大幅降低系統測試、維護升級等階段的成本。回歸測試作為軟體生命周期的一個組成部分,在整個軟體測試過程中佔有很大的工作量比重,軟體開發的各個階段都會進行多次回歸測試。在漸進和快速迭代開發中,新版本的連續發布使回歸測試進行的更加頻繁,而在極端編程方法中,更是要求每天都進行若干次回歸測試。因此,通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是很有意義的。
  • 思路產品新人應如何撰寫測試用例功能性測試
    但如果你恰恰在一個創業公司,那麼你很可能要擔負器撰寫測試用例的重擔。那麼,作為產品新人的你,該如何撰寫測試用例呢?事先聲明,本文是給產品新人的一個指導方向,如果你是測試大牛,那更希望你能弄出一篇完整的教程來。既然你公司沒有測試,那麼作為產品汪,自然就得擔負起產品測試重責。一、產品測試的意義一個完整的開發流程。從提需求、開發、交付。
  • 打開測試黑盒,從代碼角度編寫測試用例!
    關注我,每周分享軟體測試技術乾貨、面試經驗,想要進入軟體測試學習交流群的可以直接私信我哦~~黑盒測試僅關注輸入和輸出,將程序看成一個黑盒子。在不遺漏需求的情況下,打開這個黑盒子,從代碼實現的角度進行分析,可以更好的理解測試用例,幫助我們完善測試用例設計,更好地提升測試效果。
  • 未名企鵝極客|軟體單元測試的基本原則
    對於這些程序單元的測試,即稱為單元測試。本期未名企鵝極客欄目,研發工程師給大家分享的是一些單元測試的基本原則。 單元測試的粒度要根據實際情況判定,可能是類、方法等,在面向對象編程中,通常認為最小的單元就是方法。
  • Wings-面向企業級的單元測試用例自動編碼引擎
    2020年7月30日,星雲測試在TiD2020質量競爭力大會正式發布最新產品「Wings-企業級單元用例自動編碼引擎」。這是國際首個面向複雜軟體並且可以進行單元測試用例全自動編碼的高端專業軟體測試產品,目前處於國際上商業化程度最高、技術最領先的水平。
  • 羅德與施瓦茨在其工廠安裝並測試5G園區網絡,以探索工業4.0用例
    兩家公司都將使用羅德與施瓦茨網絡測試設備進行5G園區網絡測試,以優化其運營和性能。羅德與施瓦茨推動該項目實施的主要動力即獲得在自己工廠運營專用5G網絡以及如何優化5G網絡部署的經驗和寶貴見解。 5G的容量、響應速度和靈活性能支持各種新的實時用例,包括用於智能工廠的專用無線網絡。隨著5G用例對覆蓋範圍、延遲和可靠性提出了嚴苛要求,5G網絡的部署可能會給網絡規劃人員和運營商帶來挑戰。
  • 身份證測試用例設計分享
    作者:糖小幽以十五位身份證號為例,下面為設計用例分享:1、正確數據-輸入15位身份證號例如320311770706001 -  End  -· 猜你喜歡的文章 ·🔗常用輸入框測試用例設計分享登陸功能測試用例腦圖jmeter
  • 優化回歸測試的三種方法
    讓我們看看質量保證團隊可以做的,以優化他們回歸測試的一些事情:  回歸測試用例選擇  標準測試用例的索引選擇是回歸測試覆蓋的最佳引入點。測試用例的標準化級別應允許版本更新。級別高的是自動測試,以及時間和邊界要求。
  • 回歸測試的最優方法
    也有可能應用程式的新版本同時包含了修復先前報告的缺陷以及具有新的功能。對於「修復」部分,我們通常會有一系列的缺陷的測試腳本(DTS)用來運行以確認是否修復,而對於新的功能,我們將有一系列具體的測試腳本用來測試變更控制通知(CCNS) 。