Ch6-集成測試與系統(tǒng)測試-STMT

Zhu.Kerry@朱少民KerryZhu軟件測試方法和技術

第2版

第6章集成測試和系統(tǒng)測試第5章回顧Zhu.Kerry@單元測試的定義與進行單元測試的重要性單元測試的目標與任務靜態(tài)測試技術的運用動態(tài)測試技術的運用調試與評估單元測試的過程與文檔管理單元測試的常用工具簡介第6章集成測試和系統(tǒng)測試Zhu.Kerry@6.1系統(tǒng)集成的模式與方法6.2功能測試6.3回歸測試6.4非功能性測試6.1系統(tǒng)集成的模式與方法Zhu.Kerry@6.1.1集成測試前的準備6.1.2集成測試的模式6.1.3自頂向下和自底向上集成方法6.1.4大棒與三明治集成方法6.1.5持續(xù)集成6.1.1集成測試前的準備

人員安排

測試計劃

測試內容

集成模式

測試方法Zhu.Kerry@為什么總是集成不起來？Zhu.Kerry@6.1.2集成測試的模式漸增式測試模式與非漸增式測試模式非漸增式測試模式：先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序，如大棒模式。漸增式測試模式：把下一個要測試的模塊同已經(jīng)測試好的模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試。各自的優(yōu)缺點Zhu.Kerry@6.1.3自頂向下和自底向上集成方法

Zhu.Kerry@驅動程序/驅動模塊（driver），用以模擬被測模塊的上級模塊。驅動模塊在集成測試中接受測試數(shù)據(jù)，把相關的數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應的結果。樁程序/樁模塊（stub），也有人稱為存根程序，用以模擬被測模塊工作過程中所調用的模塊。樁模塊由被測模塊調用，它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口自頂向下法(Top-downIntegration)

Zhu.Kerry@自頂向下法的主要優(yōu)缺點Zhu.Kerry@自頂向下法(Top-downIntegration)

自底向上法(Bottom-upIntegration)

Zhu.Kerry@自底向上法的主要優(yōu)缺點自底向上法(Bottom-upIntegration)

Zhu.Kerry@混合策略(ModifiedTop-downIntegration)

Zhu.Kerry@混合法：對軟件結構中較上層，使用的是“自頂向下”法；對軟件結構中較下層，使用的是“自底向上”法，兩者相結合

6.1.4大棒集成方法(Big-bangIntegration)Zhu.Kerry@采用大棒集成方法,先是對每一個子模塊進行測試（單元測試階段），然后將所有模塊一次性的全部集成起來進行集成測試。因為所有的模塊一次集成的，所以很難確定出錯的真正位置、所在的模塊、錯誤的原因。這種方法并不推薦在任何系統(tǒng)中使用，適合在規(guī)模較小的應用系統(tǒng)中使用。三明治集成方法(SandwichIntegration)

Zhu.Kerry@采用三明治方法的優(yōu)點是：它將自頂向下和自底向上的集成方法有機地結合起來，不需要寫樁程序因為在測試初自底向上集成已經(jīng)驗證了底層模塊的正確性。采用這種方法的主要缺點是：在真正集成之前每一個獨立的模塊沒有完全測試過。改善的三明治集成方法Zhu.Kerry@改進的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模塊得到單獨的測試，使測試進行得比較徹底。6.1.5持續(xù)集成Zhu.Kerry@通常系統(tǒng)集成都會采用持續(xù)集成的策略，軟件開發(fā)中各個模塊不是同時完成，根據(jù)進度將完成的模塊盡可能早的進行集成，有助于盡早發(fā)現(xiàn)Bug，避免集成中大量Bug涌現(xiàn)

而且容易定位Bug、修正Bug，最終提高軟件開發(fā)的質量與效率幾種集成方法性能的比較

Zhu.Kerry@自底向上自頂向下混合策略大棒三明治改進三明治集成早早早晚早早基本程序能工作時間晚早早晚早早需要驅動程序是否是是是是需要樁程序否是是是是是工作并行性中低中高中高特殊路徑測試容易難容易容易中等容易計劃與控制容易難難容易難難6.2功能測試

Zhu.Kerry@目的和內容

程序安裝、啟動正常，有相應的提示框、錯誤提示等每項功能符合實際要求系統(tǒng)的界面清晰、美觀菜單、按鈕操作正常、靈活，能處理一些異常操作能接受正確的數(shù)據(jù)輸入，對異常數(shù)據(jù)的輸入有提示、容錯處理等數(shù)據(jù)的輸出結果準確，格式清晰，可以保存和讀取功能邏輯清楚，符合使用者習慣系統(tǒng)的各種狀態(tài)按照業(yè)務流程而變化，并保持穩(wěn)定支持各種應用的環(huán)境能配合多種硬件周邊設備軟件升級后，能繼續(xù)支持舊版本的數(shù)據(jù)與外部應用系統(tǒng)的接口有效功能測試的方法

等價類劃分法邊界值分析法錯誤推測法因果圖法組合分析法Zhu.Kerry@我要測試所有的功能回歸測試的目的所做的修改達到了預定的目的，如錯誤得到了改正，新功能得到了實現(xiàn)，能夠適應新的運行環(huán)境等；不影響軟件原有功能的正確性。

回歸測試的方法

再測試全部用例基于風險選擇測試基于操作剖面選擇測試再測試修改的部分6.3回歸測試

2000Zhu.Kerry@回歸測試的組織和實施回歸測試

Zhu.Kerry@6.4非功能性測試6.4.1性能測試 6.4.2壓力測試6.4.3容量測試 6.4.4安全性測試6.4.5可靠性測試6.4.6容錯性測試Zhu.Kerry@6.4.1性能測試

Zhu.Kerry@

性能測試(Performancetest)通過測試以確定系統(tǒng)運行時的性能表現(xiàn)，如得到運行速度、響應時間、占有系統(tǒng)資源等方面的系統(tǒng)數(shù)據(jù)。性能測試目的和需求目的：

為了驗證系統(tǒng)是否達到用戶提出的性能指標，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的。性能測試需求：

用戶對各項指標提出的明確需求；如果用戶沒有提出性能指標則根據(jù)用戶需求、測試設計人員的經(jīng)驗來設計各項測試指標。（需求+經(jīng)驗）主要的性能指標：

服務器的各項指標（CPU、內存占用率等）、后臺數(shù)據(jù)庫的各項指標、網(wǎng)絡流量、響應時間性能測試方法負載模擬

并發(fā)用戶+思考時間+每次請求的數(shù)據(jù)量+負載模式性能測試步驟

確定性能測試需求根據(jù)測試需求，選擇測試工具和開發(fā)相應的測試腳本建立性能測試負載模型，就是確定并發(fā)虛擬用戶的數(shù)量、每次請求的數(shù)據(jù)量、思考時間、加載方式和持續(xù)加載的時間等執(zhí)行性能測試結果分析，并提交性能測試報告性能測試的過程評估系統(tǒng)制定測試資產(chǎn)執(zhí)行基線&基準測試分析結果驗證需求完成調試系統(tǒng)識別探索性測試非決定性結果不符合標準調試之后重新進行基準測試開發(fā)探索性的測試符合所有的標準性能測試要點測試環(huán)境應盡量與產(chǎn)品運行環(huán)境保持一致，應單獨運行盡量避免與其他軟件同時使用。性能測試一般使用測試工具和測試人員編制測試腳本來完成。性能測試的重點在于前期數(shù)據(jù)的設計與后期數(shù)據(jù)的分析。性能測試的用例主要涉及到整個系統(tǒng)架構的問題，所以測試用例一旦生成，改動一般不大，所以做性能測試的重復使用率一般比較高。性能測試的方法和技巧

兩種負載類型“flat”測試ramp-up測試 對于企業(yè)級的系統(tǒng)，性能測試的方法主要有：基準測試性能規(guī)劃測試滲入測試峰谷測試兩種負載類型

“Flat”測試:

對于一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然后在預定的時間段內持續(xù)運行。虛擬用戶的數(shù)量兩種負載類型

Ramp-up測試:

用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因為由于用戶的增加是每次一部分，系統(tǒng)的負載在不斷地變化。其優(yōu)點是，可以看出隨著系統(tǒng)負載的改變，測量值是如何改變的據(jù)此選擇要運行的flat測試的范圍。Flat測試“波動”效應

PageDownloadedperSecond系統(tǒng)吞吐量

Flat測試“波動”效應

ResourceUsage基準測試同時與服務器通信的連接（或虛擬用戶）的數(shù)目，每個虛擬用戶請求之間間隔時間的長短。隨著服務器上負載的增加，吞吐量會不斷攀升，直到到達一個點,并在這個點上穩(wěn)定下來基準測試的關鍵是要獲得一致的、可再現(xiàn)的結果。假定測試的兩個指標是服務器的響應時間和吞吐量，會受到負載的影響。而負載又受兩個因素影響：與服務器通信的用戶越多，負載就越大。同樣，請求之間間隔時間越短，負載也越大。這兩個因素的不同組合會產(chǎn)生不同的服務器負載等級.基準測試(2) 在某一點上，執(zhí)行隊列開始增長，因為服務器上所有的線程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當線程空閑時再處理。當系統(tǒng)達到飽和點，服務器吞吐量保持穩(wěn)定后，就達到了給定條件下的系統(tǒng)上限。但是，隨著服務器負載的繼續(xù)增長，響應時間也隨之延長，雖然吞吐量保持穩(wěn)定。隊列產(chǎn)生響應時間資源使用將系統(tǒng)置于相同的高負載下，將請求之間間隔時間設為零。這樣服務器會立即超載，并開始構建執(zhí)行隊列。如果請求（虛擬用戶）數(shù)保持一致，基準測試的結果會非常精確flat運行是獲得基準測試數(shù)據(jù)的理想模式基準測試(3)兩個事務的響應時間曲線性能規(guī)劃測試

性能規(guī)劃類型的測試其目標是找出在特定的環(huán)境下，給定應用程序的性能可以達到何種程度。例如，如果要以5秒或更少的響應時間支持8,000個當前用戶，需要多少個服務器？要確定系統(tǒng)的容量，需要考慮幾個因素:用戶中有多少是并發(fā)與服務器通信的。每個用戶的請求間時間間隔是多少。

如何加載用戶以模擬負載狀態(tài)？

最好的方法是模擬高峰時間用戶與服務器通信的狀況。如果用戶負載狀態(tài)是在一段時間內逐步達到的,選擇ramp-up測試，每隔幾秒增加x個用戶;如果所有用戶是在一個非常短的時間內同時與系統(tǒng)通信，就應該使用flat測試，將所有的用戶同時加載到服務器

什么是確定容量的最好方法？

結合兩種負載類型的優(yōu)點，并運行一系列的測試

如：首先使用ramp-up測試確定系統(tǒng)支持的用戶范圍該范圍內不同的并發(fā)用戶負載進行一系列的flat測試，更精確地確定系統(tǒng)的容量。性能規(guī)劃測試(2)滲入測試

滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長，它使用固定數(shù)目的并發(fā)用戶測試系統(tǒng)的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或系統(tǒng)的其他問題，顯示因長時間運行而出現(xiàn)的任何性能降低。

建議運行兩次測試——一次使用較低的用戶負載（要在系統(tǒng)容量之下，以便不會出現(xiàn)執(zhí)行隊列），一次使用較高的負載（以便出現(xiàn)積極的執(zhí)行隊列）。峰谷測試

兼有容量規(guī)劃ramp-up測試和滲入測試的特征,目標是確定從高負載（例如系統(tǒng)高峰時間的負載）恢復、轉為幾乎空閑、然后再攀升到高負載、再降低的能力。系統(tǒng)瓶頸分析舉例-1交易的響應時間如果很長，遠遠超過系統(tǒng)性能需求，表示耗費CPU的數(shù)據(jù)庫操作，例如排序，執(zhí)行aggregatefunctions（例如sum、min、max、count）等較多，可考慮是否有索引以及索引建立的是否合理；盡量使用簡單的表聯(lián)接；水平分割大表格等方法來降低該值。Zhu.Kerry@系統(tǒng)瓶頸分析舉例-2分段排除錯誤。測試工具可以模擬不同的虛擬用戶來單獨訪問Web服務器、應用服務器和數(shù)據(jù)庫服務器，這樣，就可以在Web端測出的響應時間減去以上各個分段測出的時間就可以知道瓶頸在哪并著手調優(yōu)。Zhu.Kerry@系統(tǒng)瓶頸分析舉例-3UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標內存頁交換速率（Pagingrate），如果該值偶爾走高，表明當時有線程競爭內存。如果持續(xù)很高，則內存可能是瓶頸。也可能是內存訪問命中率低。“Swapinrate”和“Swapoutrate”也有類似的解釋。Zhu.Kerry@系統(tǒng)瓶頸分析舉例-4UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標CPU占用率（CPUutilization），如果該值持續(xù)超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。合理使用的范圍在60%至70%。Zhu.Kerry@系統(tǒng)瓶頸分析舉例-5UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標磁盤交換率（Diskrate），如果該參數(shù)值一直很高，表明I/O有問題?？煽紤]更換更快的硬盤系統(tǒng)、重新部署業(yè)務邏輯等，另外設置TempdbinRAM，減低"maxasyncIO"，"maxlazywriterIO"等措施都會降低該值。Zhu.Kerry@系統(tǒng)瓶頸分析舉例-6SQLServer資源監(jiān)控中指標緩存點擊率（CacheHitRatio），該值越高越好。如果持續(xù)低于80%，應考慮增加內存。注意該參數(shù)值是從SQLServer啟動后，就一直累加記數(shù)，所以運行經(jīng)過一段時間后，該值將不能反映系統(tǒng)當前值。Zhu.Kerry@6.4.2壓力測試Zhu.Kerry@壓力測試(Stresstest)，也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬件環(huán)境及用戶使用過程的系統(tǒng)負荷，長時間或超大負荷地運行測試軟件，來測試被測系統(tǒng)的性能、可靠性、穩(wěn)定性等。壓力測試類型

并發(fā)性能測試（重點）疲勞強度測試大數(shù)據(jù)量測試在一種需要反常（如長時間的峰值）數(shù)量、頻率或資源的方式下，執(zhí)行可重復的負載測試，以檢查程序對異常情況的抵抗能力，找出性能瓶頸。從本質上來說，測試者是想要破壞程序。并發(fā)性能測試考察客戶端應用的性能，測試的入口是客戶端并發(fā)性能測試的過程，是一個負載測試和壓力測試的過程。即逐漸增加并發(fā)虛擬用戶數(shù)負載，直到系統(tǒng)的瓶頸或者不能接收的性能點，通過綜合分析交易執(zhí)行指標、資源監(jiān)控指標等來確定系統(tǒng)并發(fā)性能的過程。并發(fā)性能測試是負載壓力測試中的重要內容。ramp-up測試

疲勞強度測試通常是采用系統(tǒng)穩(wěn)定運行情況下能夠支持的最大并發(fā)用戶數(shù)或者日常運行用戶數(shù)，持續(xù)執(zhí)行一段時間業(yè)務，通過綜合分析交易執(zhí)行指標和資源監(jiān)控指標來確定系統(tǒng)處理最大工作量強度性能的過程。疲勞強度測試案例制定的原則是保證系統(tǒng)長期不間斷運行的業(yè)務量，并且應該盡量去滿足該條件。

Flat測試大數(shù)據(jù)量測試獨立的數(shù)據(jù)量測試

針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務進行大數(shù)據(jù)量測試

綜合數(shù)據(jù)量測試

和壓力性能測試、負載性能測試、并發(fā)性能測試、疲勞性能測試相結合的綜合測試方案6.4.3容量測試

Zhu.Kerry@容量測試目的是通過測試預先分析出反映軟件系統(tǒng)應用特征的某項指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續(xù)處理的最大負載或工作量。度量系統(tǒng)容量舉例查看現(xiàn)有系統(tǒng)中性能與負載間的關系，并確定出現(xiàn)響應時間顯著延長的位置“拐點”?？梢源_定是否需要增加資源以支持額外的用戶。Zhu.Kerry@6.4.4安全性測試Zhu.Kerry@根據(jù)ISO8402的定義，安全性是“使傷害或損害的風險限制在可接受的水平內”。安全性測試

Zhu.Kerry@安全性測試是檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：

想方設法截取或破譯口令；專門開發(fā)軟件來破壞系統(tǒng)的保護機制；故意導致系統(tǒng)失敗，企圖趁恢復之機非法進入；試圖通過瀏覽非保密數(shù)據(jù)，推導所需信息等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設計的準則是，使非法侵入的代價超過被保護信息的價值，此時非法侵入者已無利可圖。6.4.5可靠性測試

Zhu.Kerry@可靠性（Reliability）是產(chǎn)品在規(guī)定的條件下和規(guī)定的時間內完成規(guī)定功能的能力，它的概率度量稱為可靠度。軟件可靠性是軟件系統(tǒng)的固有特性之一，它表明了一個軟件系統(tǒng)按照用戶的要求和設計的目標，執(zhí)行其功能的可靠程度。軟件可靠性與軟件缺陷有關，也與系統(tǒng)輸入和系統(tǒng)使用有關。理論上說，可靠的軟件系統(tǒng)應該是正確、完整、一致和健壯的。規(guī)定的時間

規(guī)定的環(huán)境條件規(guī)定的功能Zhu.Kerry@可靠性測試結果的評估成熟性度量可以通過錯誤發(fā)現(xiàn)率DDP（DefectDetectionPercentage）來表現(xiàn)。在測試中查找出來的錯誤越多，實際應用中出錯的機會就越小，軟件也就越成熟。DDP=測試發(fā)現(xiàn)的錯誤數(shù)量/已知的全部錯誤數(shù)量已知的全部錯誤數(shù)量是測試已發(fā)現(xiàn)的錯誤數(shù)量加上可能會發(fā)現(xiàn)的錯誤數(shù)量之和。故障轉移測試Failover測試:故障轉移(Failover)和故障恢復(Failback).服務器的Failover測試的目的:檢查系統(tǒng)是否具備某種災難性恢復的手段.當系統(tǒng)局部或全部出錯時,能否在指定時間內修正錯誤.具有良好故障恢復的系統(tǒng),當遇到軟件原因或無法克服的自然原因時,能夠進行故障的轉移與恢復.使用戶最低限度的感受到故障的發(fā)生.在服務器的Failover測試中,將包括多種情況,如:客戶機或服務器掉電;客戶機與服務器網(wǎng)絡中斷;服務器相關的程序CRASH;系統(tǒng)中全部或部分CORESERVER出現(xiàn)掉電/網(wǎng)絡中斷情況.Failover測試的方法和技巧將測試系統(tǒng)全部對象描繪出來-系統(tǒng)結構圖對圖中的所有可能發(fā)生的故障點設計測試用例.示例1簡單的服務器構造示例1（cont’d） 在這個構造中，當其中一臺應用服務器出現(xiàn)故障，連接此應用服務器的兩個web服務器將不再獲得從負載平衡服務器上請求，這樣，所有的負載都會傳遞到剩余的兩臺web服務器,見下圖:6.4.6容錯性測試

Zhu.Kerry@容錯性測試是檢查軟件在異常條件下自身是否具有防護性的措施或者某種災難性恢復的手段。如當系統(tǒng)出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統(tǒng)。容錯性測試包括兩個方面：輸入異常數(shù)據(jù)或進行異常操作，以檢驗系統(tǒng)的保護性。如果系統(tǒng)的容錯性好的話，系統(tǒng)只給出提示或內部消化掉，而不會導致系統(tǒng)出錯甚至崩潰。災難恢復性測試。通過各種手段，讓軟件強制性地發(fā)生故障，然后驗證系統(tǒng)已保存的用戶數(shù)據(jù)是否丟失、系統(tǒng)和數(shù)據(jù)是否能盡快恢復。從質量三個緯度看系統(tǒng)測試

Zhu.Kerry@質量維度測試類型

可靠性完整性測試：側重于評估測試對象的強壯性（防止失敗的能力），語言、語法的技術兼容性以及資源利用率的測試。該測試針對不同的測試對象實施和執(zhí)行，包括單元和已集成單元。

結構測試：側重于評估測試目標是否符合其設計和構造的