5.1.10 并發測試（Concurrency Testing）簡介
并發測試（Concurrency Testing）方法通過模擬很多用戶在同一時刻訪問系統或對系統的一個功能進行操作，來測試系統的性能，從中發現問題。網站就是一個很典型的需要并發測試的應用場景：當網站運行的時候，在世界各地同一時刻都可能有很多用戶在進行同一個操作，如圖5-6所示。除此之外，類似的還有銀行的某些系統、航空的某些系統等，它們都需要大量用戶同時訪問和操作。
圖5-6 用戶對Web應用的并發訪問
類似小白在本章開始對公司測試網站的訪問是無法發現可能存在的并發問題的。即使是公司所有的同事一聲令下，也無法做到比較精確的同時訪問，數量也很不夠。因此，并發測試是無法用人工的方式來完成的，必須依賴一些工具軟件來模擬實現，比如HP公司的LoadRunner等，這個軟件我們將在后面的章節專門介紹使用方法。
并發測試所要考察的是系統在并發處理方面是否存在缺陷。實現并發的編碼與原理是比較復雜的，需要很高級的開發技巧，因此不在本書介紹的范圍之內。在實際工作中，我們只需要了解如下3個要點：
并發測試需要用工具模擬多用戶的訪問。
要熟悉第一點提到的工具測試并發的操作。本書介紹的是LoadRunner。
要了解并發測試所關注的性能問題是什么。
至于并發中深入的線程、進程、內存泄露等知識，則需要在工作中遇到問題時來學習了。
5.1.11 并發測試所關注的性能問題
并發測試關注哪些性能上的問題？為了理解方便，我們用一個通俗的例子來說明。
還是利用傳統的類比--飯館，畢竟民以食為天。在某一時刻的飯館中，有很多客人都在吃飯，這可以說是一個并發場景。于是，可能出現的問題有如下幾個（當然不限于以下的這些）：
餐桌是有限的，客人很多，超出桌子數目，只能排隊叫號了。類似這樣搶空閑桌子的情況在程序代碼中也會出現，叫做資源（內存等也被稱為資源，程序運行需要在內存中，而可用的內存又是有限的）的爭用（Race）。
如果飯館還有一個空桌子，但被別人電話預定了，而此時飯館等位的人又很多，服務員該如何處理呢？一般是等待15分鐘、聯系預定人的電話等方法。類似這樣有關保留預定與放棄預定的情況在程序代碼或者數據庫中也會出現，根據條件不同（比較復雜，涉及類似多個客戶訂同一張桌子等細節），分別叫做活鎖（livelock）和死鎖（deadlock）等。
如果飯館的服務員應付眾多的客人已經忙不過來；或者就是服務員忘記了，經常會出現這樣的情況：有一桌客人在吃完飯后已經結賬走人，但服務員并沒有及時的清理桌布，收盤子、擦桌子等，導致后面的客人無法使用這張桌子進餐，無形中使得飯館的接待能力下降。由于代碼的問題使得類似上面這樣的情況在程序運行中也出現，就叫做內存泄露（Memory leak）。
以上幾個類比可能不很確切，但是引申出了一個結論：并發測試所關注的性能問題就是：系統中的內存泄露、線程控制（鎖的問題）和資源爭用。
5.1.12 并發測試的特點與工具
并發測試具備如下的幾個特點：
（1）并發測試可以是黑盒測試，也可以是白盒測試。測試工程師可以不了解代碼實現的細節，通過工具軟件實施并發測試找出Web應用的并發問題。開發工程師也可以通過并發測試對自己編寫的代碼做單元測試。
（2）并發測試可以在項目進行的大部分時候進行。在項目的早期，它可以通過結果大致驗證系統總體設計和結構是否合理；在項目編碼階段，它可以發現代碼的并發問題；在項目的測試階段，它可以發現整個系統的并發問題。
【并發測試工具】
除了前文提到，本書后面章節要介紹的綜合性能測試軟件LoadRunner之外，還有很多專用的并發測試工具，比如在Java平臺下有JProfile、JProbe等；在.NET平臺下有CHESS、Zing等。
由于并發測試這部分內容程度比較深，完全展開需要更多的是開發知識，而不是測試知識本身，感興趣的讀者可閱讀相關的書籍。
5.1.13 配置測試（Configuration Testing）
所謂配置測試（Configuration Testing）方法，是通過對被測系統所處的軟、硬件環境進行設置上的調整，來了解其對于系統性能影響的程度，并根據結果發現環境的最優配置組合。這個測試方法主要用于性能的優化，一般用于Web應用正式投入使用前夕和運行當中。
1．配置測試的實例
實際上，在使用電腦的過程中，我們每個人都可能做過這樣的測試。比如，使用Windows XP一段時間后，電腦運行速度可能有所減慢。那么我們可能就會上網查詢具體變慢的原因，更改一些系統默認的設置，并從實際的效果來驗證這些設置的更改是否有效。無效的配置很可能被恢復成默認值。這可以說就是一種配置測試。
2．配置測試的目的
配置測試的目的就在于發現當前修改的這種配置是否能夠有效提高Web應用的性能。
還記得有一種比較流行的工具軟件：Windows優化大師嗎？它實際上就是通過調整不同的系統軟、硬件參數，使得我們的Windows運行起來感覺更快。Windows優化大師的軟件界面如圖5-7所示，可以發現它是由多個配置修改頁面組成的。
圖5-7 Windows優化大師的界面
3．配置測試實施的時機
那么，什么時候進行配置測試呢？還是與我們平時使用電腦的情況做類比。當我們尚未把所有需要的軟件都安裝完畢之前，一般是不會做配置測試的，這是因為這段時間即使修改了軟、硬件配置、進行了優化，這種配置也可能被新安裝的軟件在之后覆蓋掉，導致優化失效。同樣的道理，在Web應用的程序代碼沒有開發完畢、測試沒有基本完成、有關性能的Bug還遠遠沒有被修改的時候，就進行配置測試、性能優化是不合適的。也就是說，配置測試測試的是Web應用所依賴的軟、硬件配置對于性能的影響，對于Web應用的代碼本身，已經假設它達到了最好的性能。
配置測試所涉及的系統設置要依照Web應用所依賴的環境而定，一般分為軟件和硬件兩部分：
軟件部分：數據庫各參數的設置；操作系統各參數的設置；網絡帶寬的設置等。
硬件部分：硬盤緩存、硬盤運行模式、磁盤陣列的設置等。
5.1.14 耐久度測試（Endurance Testing）
耐久度測試又叫做浸泡測試（Soak Testing），具體方法是令被測試的軟件系統、Web應用在大負荷條件下長時間運行，從中發現問題。從這個定義來看，被測軟件系統或者Web應用長時間處于測試狀態下，用"浸泡"來描述是很恰當的。
耐久度測試所能發現的問題都和被測系統運行時間變長后，一些資源無法釋放，導致系統響應時間慢慢變長有關。詳細而言，有以下幾類：
嚴重的內存泄露（請見并發測試小節）導致系統內存慢慢不夠使用。
數據庫連接、數據庫游標、應用服務器資源等沒有適時釋放，導致系統變慢。
被測系統代碼中的數據結構不甚健壯或合理，在長時間運行后，對其的增加、刪除、修改、查詢等速度出現問題。
耐久度測試需要至少關注以下一些指標：CPU使用率、可用內存、內存使用百分比等。通過隔一段時間記錄以上的指標，最終形成數據表和相應的圖，從中可以找到規律，如圖5-8所示，它是在進行一次耐久度測試時，每小時在線用戶數量的結果繪圖。
圖5-8 某網站最近6天每小時在線用戶統計
根據圖5-8的變化規律，再結合耐久度測試中定時記錄的CPU、內存等指標，如果二者規律不符合（比如當在線用戶數少的時候，內存占用并沒有下降很多），就可以分析出有關資源分配是否正常的結論。
耐久度測試可以在代碼開發階段，也可以在網站版本接近完成、準備上線前，更可以在網站運行當中。因此，根據這幾種情況，進行耐久度測試的時間長度有所不同，但總的原則都是測試時間要盡可能地長，這樣才有"浸泡"的作用。
代碼開發階段，主要看開發工作的時間安排與發現問題的早晚。如果運行早期就發現了內存泄露問題，可以中斷進行代碼的修改。
網站版本接近完成的時候，主要看網站上線時間安排，和發現問題的大小。如果上線時間不變，則耐久度測試進行到上線為止。
網站運行當中的耐久度測試，由于要定時記錄各種指標，對于網站本身可能影響較大，需要擇機進行，比如在長假、長周末等時間。
【耐久度測試與其他測試的區別】
耐久度測試主要考慮的是時間對于系統或者Web應用的影響，因此，它測試的時間要比其他方法，如性能、壓力、負載等測試要長得多。另外，它關注的是系統在一個漸進的資源消耗過程中的表現，與壓力測試關注一個固定指標下（可以看作一個時間點）系統的表現、負載測試關注最終的那個最大負載（也可以看作一個時間點）、并發測試關注并發操作發生時系統的表現（也可以看作一個時間點）都不同。
5.1.15 可靠性測試（Reliability Testing）
可靠性測試（Reliability Testing）方法實際上就是前一節所說的耐久度測試，只是這個詞一般用于測試大型軟件，特別是應用于工業、交通等的行業軟件。這是因為IT領域的可靠性測試這個詞是從制造業"引用"過來的，帶有些許傳統大工業機器制造的意味。
5.1.16 尖峰沖擊測試（Spike Testing）
與可靠性測試類似，尖峰沖擊測試這種方法也是從其他行業借鑒而來。在電力工業，有一種沖擊測試，用來驗證設備在剛剛接通電源時能否經受住涌流的破壞。所謂涌流，通俗地說，就是電源接通瞬間，電流突然變大的現象。涌流過后，電流逐漸恢復到正常的水平。
軟件行業的沖擊測試，或者說本書稱之的尖峰沖擊測試，就是為了驗證網站在用戶突然極具增加的情況下能夠正常工作。我們知道，在網站的運行過程中，會經常出現各種各樣用戶數量的突然增加：
網站開幕時可能導致用戶急劇增加，超過預期。
網站公布與用戶極為相關的信息，比如高考成績、錄取分數等。
網站投放一些商業促銷廣告和促銷活動，比如季節性降價，春節前大促銷。
網站舉辦醞釀已久的明星訪談、在線銷售演出、比賽門票等吸引眼球的活動。
以上這些情況產生的在線用戶數量突然增加都會對網站性能產生巨大影響，讀者一定記得通過網絡購買奧運會門票時，由于用戶非常踴躍，導致售票網站無法打開的案例。
在前文我們介紹過負載測試，但實際情況所產生的負載不會老老實實地遵循最大負載的限制，很可能在短時間內就會超過，這時系統并不一定會出現問題。尖峰沖擊測試就是為了驗證此時網站的應付能力。
如圖5-9所示為網站在某一時刻，在線用戶突然增大，形成一個尖峰的情況。這也正是尖峰沖擊測試中Spike的由來，Spike在英文中是釘子的意思。
【尖峰沖擊測試的實施】
尖峰沖擊測試一般也是采用工具軟件進行自動測試的。在Load Runner中，可以修改之前性能測試的腳本，令某一個時刻用戶數突然增大，就可以達到測試的目的。
圖5-9 網站某時刻在線用戶數突然增大形成尖峰
5.1.17 失敗恢復測試（FailOver Testing）
失敗恢復測試（Failover Testing）方法對于大中型的Web應用是很重要的，它針對有冗余備份（Redundant Backup）、負載均衡（Load Balance）的系統。這種測試方法用于驗證某部分Web應用發生故障時，整個網站是否能夠繼續讓用戶使用的能力。
1．用戶訪問網站可能出現的問題
我們知道，Web應用是存放在服務器的硬盤上供用戶訪問的，而服務器一般來說都位于IDC（互聯網數據中心，Internet Data Center）機房的機架上。用戶訪問一個Web應用的過程如圖5-10所示，為簡單起見，這里只列出大的部分。
圖5-10 用戶訪問網站過程的示意圖
從圖5-10中可以看出，如果一個用戶無法訪問某個網站，那么可能是：
用戶電腦出現了問題。解決方法：維修用戶電腦。
網絡線路出現了問題。解決辦法：更換網線，修正交換機、路由器等設置。
網站服務器出現了問題。解決辦法需要在下文進一步討論。
那么，如何使得網站具有高可用性呢？
【何為高可用性】
所謂高可用性，就是指網站在絕大多數的時間都能夠正常顯示。網站的設計說明書中經常提到"保證網站99.99%的時間都可用"這樣的承諾，這就需要一定的技術保障。但是Web應用比較復雜，軟件代碼可能有Bug；用戶的持續訪問和數量的增加也會造成網站較大的負荷，導致硬件可能失效。
可以用以下幾種方法來提高網站能正常運轉的時間。
主動防御：盡量修改軟件代碼中的Bug，提高Web應用本身的健壯性，減少網站出問題的機會。
被動防御：在保持現有Web應用代碼、服務器配置不變的情況下，通過適當增加服務器的數量、盡量平均分配網站負荷、采用備份的方法提高可用性。在這些措施中，就有冗余備份，負載均衡等方法，我們將在下面的內容中介紹。
2．提高可用性：冗余備份
冗余備份是用兩臺或者多臺服務器構成一個小的服務器場（Server Farm）來承擔網站失敗恢復工作的。簡單地說，一臺服務器作為Web應用的主服務器，另一臺作為它一模一樣的鏡像復制。一旦主服務器發生問題，網站無法正常使用，立刻切換到備用服務器，使得用戶的訪問能夠繼續。它的結構示意如圖5-11所示。
圖5-11 冗余備份的簡單結構示意圖
由于網站所需要的服務器要比圖5-10中多出一臺到多臺，這些服務器中的數據又是互為備份的，因此，我們把這種方式叫做冗余備份。當圖5-10中的Web應用服務器發生故障時，系統檢測到（有多種方法能檢測服務器故障是否發生：比如"心跳"，即HeartBeat，采用定時ping服務器以及其他指標），系統將把連接服務器與外界的線路自動轉接到備份服務器上，從而導致用戶端瀏覽網站時基本感覺不到這種變化，極大地減少了維修Web應用服務器所帶來的網站停止時間。
這種方法在生活中也經常采用。比如家里的手機、電視、汽車等出了故障，維修點一般會先給一個替代用品來滿足維修期間的需要。不同的是，對于網站來說，主服務器和備份服務器的數據要求盡量完全一致。
3．提高可用性：負載均衡
冗余備份看似很完美地解決了服務器故障所帶來的影響，但是它增加了設備，增加了成本，而且備份服務器上網站的備份實際上用戶也是可以使用的，平時閑置的話有些可惜。因此，人們又采用了負載均衡的辦法，在多臺同樣的服務器之前，加入一個"調度員"，將用戶的訪問請求盡量平均分配給它們，導致每臺服務器的負擔下降，因而出問題的幾率也就下降了。整個系統的簡單示意如圖5-12所示。
圖5-12 網站服務器的負載均衡
在實際工作中，還有其他一些方法，人們也往往綜合使用這些方法來達到網站的7×24（7天，每天24小時，也就是全天候）可訪問目標。
【失敗恢復測試的意義】
失敗恢復測試一般都是人工進行，有點類似奧運會開幕式的彩排。在模擬一臺Web服務器出現故障的時候，驗證另外的服務器能否接管用戶的請求。當然，目前這些工作都已經可以由專用軟件、硬件廠商來提供服務，只需要購買就可以了，實際的操作一般不會由測試工程師參與，技術經理和網絡管理參與即可。但是，作為一個Web性能測試工程師，沒有進行失敗恢復測試的意識是不合適的。在以后的章節中，我們將和小白一起編寫測試計劃，在其中，應該給失敗恢復測試留出一定的文字、安排一定的時間。
?。ㄎ赐甏m）
相關鏈接：
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載一)
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載二)
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載三)
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載四)