一、基本概念
性能測試在軟件的質量保證中起着重要的作用，中國軟件評測中心將性能測試概括爲三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和對瓶頸的預測。
性能測試是指測試在一定條件下系統行爲表現是否符合需求規格的性能指標。
1. 響應時間
響應時間是指“對請求做出響應所需要的時間”，可分解爲網絡傳輸時間、應用延遲時間、數據庫延遲時間等。圖7.1描述了Web應用的頁面響應時間構成，頁面的響應時間分解爲“網絡傳輸時間”(N1+N2+N3+N4)和“應用延遲時間”(A1+A2+A3)，而“應用延遲時間”又分爲“數據庫延遲時間”(A2)和“應用服務器延遲時間”(A1+A3)。
2. 併發用戶數
併發分爲如下兩種情況：一種是嚴格意義上的併發，即所有的用戶在同一時刻做同一件事情或者操作，這種操作一般指做同一類型的業務。
另一種是廣義範圍的併發，與前一種併發的區別是，多個用戶對系統發出了請求或者進行了操作，其請求或者操作可以是相同的，也可以是不同的。對整個系統而言，仍然是有多個用戶同時對系統進行操作。後一種併發包含前一種併發，而且後一種併發更接近用戶的實際使用情況。
實際的性能測試，測試人員比較關心業務併發用戶數，也就是從業務角度關注應該設置多少個併發數比較合理。
下面給出估算併發用戶數的公式。
（1）
（2）
【例7-1】 一個軟件系統每天大約有400個用戶訪問。用戶在一天之內有8小時使用該系統，從登錄到退出該系統的平均時間爲4小時。
【解答】 根據公式(1)和公式(2)，得到：
C=400×4/8=200 
200+3×√200=242
3. 吞吐量
吞吐量是指在一次性能測試過程中網絡上傳輸數據量的總和。一般來說，吞吐量用請求數每秒或頁面數每秒來衡量。從業務角度分析，吞吐量用訪問人數/天或者處理業務數/小時等衡量。其中，吞吐率 = 吞吐量/傳輸時間，體現軟件性能承載能力。
吞吐量指標有如下兩個作用：
(1) 協助設計性能測試場景，以及衡量性能測試場景是否達到了預期的設計目標。在設計性能測試場景時，吞吐量用於協助設計性能測試場景，通過估算吞吐量數據，測試場景的事務發生頻率等。
(2) 協助分析性能瓶頸。吞吐量是性能瓶頸的重要表現形式。因此，有針對性地測試吞吐量，可儘快定位到性能瓶頸所在位置。
吞吐量和併發用戶數之間存在一定的聯繫。計算公式如下所示：
（3）
其中，F表示吞吐量；Nvu表示虛擬用戶個數；R表示每個虛擬用戶發出的請求數量；T表示性能測試所用的時間。遇到性能瓶頸狀況，吞吐量和VU數量之間就不符合公式(3)了。圖7.2爲吞吐量—VU數量關聯圖。
4. 性能計數器
性能計數器是描述服務器或操作系統性能的一些數據指標，具有“監控和分析”作用。例如，Windows系統的內存數、進程數、系統緩存等都是常見的性能計數器。與性能計數器相關的“資源利用率”，是指系統各種資源的使用狀況。
5. 休眠時間
休眠時間又稱爲思考時間，是指用戶請求的間隔時間。在交互式應用中，用戶不大可能持續不斷地發出請求，一般模式是用戶發出一個請求，等待一段時間，再發出下一個請求。因此，自動化測試模擬用戶操作就必須在測試腳本中讓各個操作間隔一段時間，在操作語句之間設置Think函數，實現兩個操作之間的等待時間。
休眠時間與迭代次數、併發用戶數和吞吐量之間存在一定關係。公式(3)說明吞吐量是VU數量Nvu、每個用戶發出請求數R和時間T的函數。其中R可以用時間T和用戶的思考時間Ts來計算，如下所示
（4）
6. 點擊率
點擊率是指每秒用戶向Web服務器提交的HTTP請求數，作爲Web應用的特有指標。Web應用是“請求—響應”模式，即用戶發出一次請求，服務器響應請求，處理後返回給用戶。點擊是Web應用能夠處理的最小單位，點擊率越大，服務器的壓力也就越大。需要注意的是，這裏的點擊並非指鼠標的一次單擊操作，因爲在一次單擊操作中，客戶端可能向服務器發出多個HTTP請求。
二、性能測試分類
（一）負載測試
1. 概述
負載測試(Load Test)是通過測試系統在資源超負荷情況下的表現，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行爲，以及持續正常運行的能力。負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特徵，例如響應時間、事務處理速率和其它與時間相關的方面。
負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，通過不斷加載(如大量重複的行爲、逐漸增加模擬用戶的數量)或其它加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統佔用的資源(如CPU、內存)等，以檢驗系統的行爲和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。
2. 測試的加載方式
負載測試的加載方式通常有如下幾種：
(1) 一次加載。一次性加載某個數量的用戶，在預定的時間段內持續運行。例如，早晨上班時間，訪問網站或登錄網站的時間非常集中，基本屬於扁平負載模式。
(2) 遞增加載。有規律地逐漸增加用戶，每幾秒增加一些新用戶，交錯上升。藉助這種負載方式的測試，容易發現性能的拐點，即性能瓶頸。
(3) 高低突變加載。某個時間用戶數量很大，突然降到很低，過一段時間，又突然加到很高，反覆幾次。藉助這種負載方式的測試，容易發現資源釋放、內存泄露等問題。
(4) 隨機加載方式。由隨機算法自動生成某個數量範圍內變化的、動態的負載，這種方式可能是和實際情況最爲接近的一種負載方式。雖然不容易模擬系統運行出現的瞬時高峯期，但可以模擬系統長時間的高位運行狀態。
（二）壓力測試
1. 概述
壓力測試(Stress Test)也稱強度測試，是在強負載(大數據量、大量併發用戶等)下的測試，通過查看應用系統在峯值使用情況下的操作行爲，發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分爲高負載下的長時間(如24小時以上)的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。
壓力測試可以看做是負載測試的一種，即高負載下的負載測試，或者說壓力測試採用負載測試技術。通過壓力測試，可以發現內存泄漏問題，還可以發現影響系統穩定性的問題。例如，在正常負載情況下，某些功能不能正常使用或系統出錯的概率比較低，可能一個月只出現一次，但在高負載(壓力測試)下，可能一天就出現，從而發現有缺陷的功能或其它系統問題。
微軟測試實踐經驗表明，如果軟件產品通過了72小時壓力測試，則在72小時後出現問題的可能性微乎其微。所以，72小時成爲微軟產品壓力測試的時間標誌。壓力測試用例的參考模板如圖7.3所示。
2. 測試步驟
壓力測試檢查系統在資源超負荷的情況下的表現，壓力測試的其中一個變種——敏感測試是指在有些情況下，數據界限內的很小範圍的數據可能會引起錯誤的運行，或引起性能急劇下降。敏感測試用於發現可能會引起不穩定或錯誤處理的數據組合。
壓力測試的一般步驟如下：
步驟一：進行簡單多任務測試。
步驟二：簡單壓力缺陷修正後，增加系統的壓力直到系統崩潰。
3. 性能測試、負載測試和壓力測試的區分
性能測試、負載測試和壓力測試常常容易混淆，難以區分，從而造成不正確的理解和錯誤的使用。由於負載測試、壓力測試和性能測試往往在測試手段和方法上比較相似，通常會使用相同的測試環境和測試工具，而且都會監控系統所佔用資源的情況以及其它相應的性能指標，因此容易產生概念混淆。
性能測試、負載測試和壓力測試三者的測試目的是不同的。性能測試是爲了獲得系統在某種特定的條件下(包括特定的負載條件下)的性能指標數據；而負載測試、壓力測試是爲了發現軟件系統中所存在的問題，包括性能瓶頸、內存泄漏等。
當通過負載測試爲了獲得系統正常工作時所能承受的最大負載時，負載測試就成爲容量測試。壓力測試用於測試系統在何種極限情況下會崩潰、系統是否具有自我恢復性等，但更多的是爲了確定系統的穩定性。
負載測試與壓力測試區分如下：負載測試是通過逐步增加系統複雜性來測試其變化，看最後在滿足性能的情況下，系統最多能接受多大的負載的測試。壓力測試是通過逐步加系統複雜性來測試其變化，看最後在滿足性能的情況下，施加多大壓力能使系統處於失效的狀態。通俗來說，就是發現系統在什麼條件下其性能會變得不可接受。壓力測試是一種特定類型的負載測試。
負載測試與性能測試區分如下：負載測試是爲了發現系統的性能問題。負載測試需要通過系統性能特性或行爲來發現問題，從而爲性能改進提供幫助。從這個意義看，負載測試可以看做性能測試的一部分。但它們兩者的目的是不一樣的，負載測試是爲了發現缺陷，只測試在一些極端條件下，系統還能否正常工作，或加載到系統崩潰而找出系統性能的瓶頸。而性能測試是爲了獲取性能指標，因爲在性能測試過程中，也可以不調整負載，而是在同樣負載情況下改變系統的結構、算法、硬件配置等來得到性能指標數據。從這個意義看，負載測試可以看做是性能測試的一種技術，即性能測試使用負載測試的技術和工具。性能測試要獲得在不同的負載情況下的性能指標數據。
（三）可靠性測試
軟件可靠性是軟件質量的一個重要標誌。美國電氣和電子工程師協會(IEEE)將軟件可靠性定義爲：系統在特定的環境下，在給定的時間內無故障地運行的概率。軟件可靠性涉及軟件的性能、功能性、可用性、可服務性、可安裝性、可維護性等多方面特性，是對軟件在設計、生產以及在它所預定環境中具有所需功能的置信度的一個度量。
可靠性測試一般伴隨着強壯性測試，是評估軟件在運行時的可靠性。通過可靠性測試，確認平均無故障時間(MTTF，Mean Time To Failure)、故障發生前平均工作時間(MTTFF，Mean Time TO First Failure)或因故障而停機的時間(MTTR，Mean Time To Repairs)在一年中應不超過多少時間。可靠性測試強調隨機輸入，並通過模擬系統實現，很難通過實際系統的運行來實現。
（四）數據庫測試
數據庫測試一般包括數據庫的完整測試和數據庫容量測試。下面依次介紹。
1) 數據庫完整測試
數據庫完整測試是指測試關係型數據庫完整性原則以及數據合理性測試。
數據庫完整性原則是指：
(1) 主碼完整性：主碼不能爲空。
(2) 外碼完整性：外碼必須等於對應的主碼或者爲空。
(3) 用戶自定義完整性。例如性別字段的取值只能是“男”或者“女”。
2) 數據庫容量測試
數據庫容量測試指通過存儲過程往數據庫表中插入一定數量的數據，看相關頁面是否能夠及時顯示數據。數據庫容量測試使測試對象處理大量的數據，以確定是否達到了使軟件發生故障的極限。數據庫容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。比如，通過insert customer往員工表中插入10000個數據，看其是否可以正常顯示顧客信息列表頁面。
（五）安全性測試
安全性測試是測試系統在應付非授權的內/外部訪問、非法侵入或故意的損壞時的系統防護能力，檢驗系統是否有能力使可能存在的內/外部的傷害或損害的風險限制在可接受的水平內。可靠性通常包括安全性，但是軟件的可靠性不能完全取代軟件的安全性，安全性還涉及到數據加密、保密、存取權限等多個方面。
進行安全性測試時需要設計一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密漏洞，驗證系統的保護機制是否能夠在實際使用中不受到非法侵入。在安全測試過程中，測試者扮演成試圖攻擊系統的角色，嘗試獲取系統密碼，利用能夠瓦解任何防守的客戶軟件攻擊系統；或者把系統“制服”，使別人無法訪問。
（六）文檔測試
爲使軟件文檔能起到多種橋樑的作用，使它有助於程序員編制程序，有助於管理人員監督和管理軟件的開發，有助於用戶瞭解軟件的工作和應做的操作，有助於維護人員進行有效的修改和擴充，文檔的編制必須保證一定的質量。
(1) 針對性：文檔編制以前應分清讀者對象。按不同的類型、不同層次的讀者，決定怎樣適應他們的需要。例如，管理文檔主要是面向管理人員的，用戶文檔主要是面向用戶的，這兩類文檔不應像開發文檔(面向開發人員)那樣過多使用軟件的專用術語。
(2) 精確性：文檔的行文應當十分確切，不能出現多義性的描述。同一課題幾個文檔的內容應當是協調一致、沒有矛盾的。
(3) 清晰性：文檔編寫應力求簡明，如有可能，配以適當的圖表，以增強其清晰性。
(4) 完整性：任何一個文檔都應當是完整的、獨立的、自成體系的。例如，前言部分應作一般性介紹，正文給出中心內容，必要時還有附錄，列出參考資料等。
(5) 靈活性：各個不同軟件項目，其規模和複雜程度有着許多實際差別。實際工作中可參閱以下原則：
① 根據具體的軟件開發項目，決定編制的文檔種類。
② 開發的軟件系統非常大時，一種文檔可以分成幾卷編寫。
③ 根據任務的規模、複雜性、項目負責人對該軟件的開發過程及運行環境所需詳細程度的判斷，確定文檔的詳細程度。
④ 文檔內容的繁簡可根據國標GB 8567—88《計算機軟件產品開發文件編制指南》指導進行，其中關於所建議的所有條款都可以擴展，進一步細分；反之，如果條款中有些細節並非必需，也可以根據實際情況進行壓縮合並。
⑤ 程序的設計表現形式可以使用程序流程圖、判定表、程序描述語言(PDI)和問題分析圖(PAD)等。
⑥ 對於文檔的表現形式，沒有規定或限制，可以使用自然語言，也可以使用形式化的語言。
⑦ 當國標GB 8567—88中所規定的文檔種類不能滿足某些應用部門的特殊需要時，可以建立一些特殊的文檔種類要求。這些要求可以包含在本單位的文檔編制實施規定中。
(6) 可追溯性：由於各開發階段編制的文檔與各個階段完成的工作有密切的關係，因此文檔具有一定的繼承關係，項目各個開發階段之間提供的文檔必定存在着可追溯的關係。例如，系統的軟件需求必定在設計說明書、測試計劃甚至用戶手冊中有所體現。
1) 系統類別
分清系統類別是掌握什麼樣的技術的前提。例如：系統類別是B/S結構，需要掌握HTTP協議、Java、HTML等技術；若系統爲C/S結構，需要了解OS、Winsock、COM等。
2) 系統構成
不同的系統構成，性能測試就會得到不同的結果。硬件設置、操作系統設置是性能測試的制約條件，一般性能測試都是利用測試工具模仿大量的實際用戶操作，系統在超負荷情形下運作。
3) 系統功能
系統功能是性能測試中要模擬的環節，是指系統提供的不同子系統，如辦公管理系統中的公文子系統、會議子系統等。
2. 選擇測試度量方法
經過第一步，將會對系統有清醒的認識。接下來進行軟件度量，收集系統相關的數據。
度量包括如下內容：
制定規範
制定相關流程、角色、職責
制定改進策略
制定結果對比標準
3. 學習相關技術和工具
性能測試是通過工具模擬大量用戶操作，對系統增加負載，所以必須熟練地掌握和運用測試工具。性能測試工具一般基於不同的軟件系統架構實現，其腳本語言也不同。
由於每一種性能測試工具都有自身的特點，因此只有經過工具評估，才能選擇符合現有軟件架構的性能測試工具，確定測試工具後，需要組織測試人員學習工具的使用，培訓相關的測試技術。
4. 制定評估標準
任何測試的目的都是確保軟件符合預先規定的目標和要求。通常性能測試有如下4種模型技術用於評估。
(1) 線性投射。通過大量的、過去的、擴展的或者將來可能發生的數據組成散佈圖，利用這個圖表不斷和系統的當前狀況進行對比。
(2) 分析模型。通過預測響應時間，將工作量的數據和系統本質關聯起來，進行模型分析。
(3) 模仿。模仿實際用戶的使用方法，反覆地測試系統。
(4) 基準。定義測試作爲標準，與後面進行的測試結果進行對比。
5. 設計測試用例
設計測試用例的原則是以最小的代價提供最多的測試信息，設計測試用例的目標是一次儘可能地包含多個測試要素，這些測試用例必須是測試工具可以實現的，不同的測試場景將測試不同的功能。
6. 運行測試用例
通過性能測試工具運行測試用例，需要不同的測試環境以及不同的機器配置。
7. 分析測試結果
運行測試用例後，收集相關信息，進行數據統計分析，找到性能瓶頸。通過排除誤差和其它因素，讓測試結果體現真實情況。不同的體系結構所採用的測試方法也不同，B/S結構的系統通常會分析網絡帶寬和流量對用戶操作響應的影響，而C/S結構可能更關心繫統整體配置對用戶操作的影響。
四、網站測試
（一）、網站體系結構
網站屬於客戶/服務器軟件類別，相對於一般的窗口軟件有其明顯的特點，如圖7.4所示，網站的結構模型由以下幾部分組成。
(1) 第一部分是用戶界面，提供使用者交互操作平臺，用於數據輸入和信息獲取。
(2) 第二部分負責將輸入數據進行處埋，送到下一層，也負責將下一層傳回的數據顯示在用戶界面。
(3) 第三部分負責將上一層傳來的數據按照需求規格中特定的業務規則及設定的邏輯進行處理，傳送到數據存儲層。
(4) 第四部分是數據存儲，一般使用數據庫方式。
（二）、網站測試內容
在網站測試中主要進行以下項目的測試：
(1) UI測試。UI測試主要測試頁面是否美觀(包括頁面的佈局是否合理，策劃是否舒服美觀，頁面長度是否合理，前景色與背景色是否搭配，頁面風格是否統一)。
(2) 鏈接測試。鏈接測試用於測試點擊鏈接時是否可以進入所找的頁面，是否能正確返回，鏈接頁面會不會是空白頁面、孤立頁面或根本沒鏈接(也就是說鏈接的是自己本身)。如果鏈接的是空白頁，我們是否可以正確返回；如果使用了框架或內嵌框架，是否可以正確在本框架頁內顯示要查找的頁面；使用內容置頂時是否可以正確實現。
(3) 表單測試。表單測試包括單選按鈕、複選框、文本框、密碼項、菜單項和提交按鈕類按鈕的測試以及後臺數據庫的測試。
(4) 兼容性測試。兼容性測試是指在各種配置不同的操作系統上和分辨率不同的電腦上及使用不同的瀏覽器對其測試，看其是否可以正確顯示，是否有圖片和頁面錯位或太大太小等問題使有的部分無法看到，是否有圖片或視頻無法顯示等。
(5) 網絡配置測試。網絡配置測試主要測試網頁是否可以打印或保存(如果是保密的網頁或不想讓別人保存的頁面可以將其做成Flash格式的，不讓用戶保存)，網頁冗餘代碼是否過多或容量太大導致網絡運行速度過慢等。
(6) 負載測試。負載測試主要測試多個用戶同時上網時其最大的承受能力是多大，如果超過了這個極限會有何反應。
(7) 安全測試。安全測試主要測試用戶名和密碼是否有長度限制，是否有複雜度限制，登錄次數是否受限等。
(8) 接口測試。
一、判斷題
1. 負載測試是驗證要檢驗的系統的能力最高能達到什麼程度。( )
2. 所有軟件必須進行某種程度的兼容性測試。( )
3．以消除瓶頸爲目的的測試是覆蓋測試。( )
二、簡答題
1. 請解釋如下名詞概念。
響應時間 併發用戶數 吞吐量 性能計數器 休眠時間 點擊率
2. 負載測試與壓力測試有哪些異同點？請舉例說明。
3. 什麼是可靠性測試？請舉例說明。
4. 什麼是安全性測試？它與可靠性測試有什麼區別？
5．文檔的編制有什麼特點？
6．網站測試內容有哪些？