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

1、軟件測試方法和技術(shù)軟件測試方法和技術(shù) - Ch.6集成測試和系統(tǒng)測試集成測試和系統(tǒng)測試 Zhu.K Kerry Zhu Zhu.K 第五章回顧 Zhu.K 單元測試的定義與進行單元測試的重要性單元測試的定義與進行單元測試的重要性 單元測試的目標與任務(wù)單元測試的目標與任務(wù) 靜態(tài)測試技術(shù)的運用靜態(tài)測試技術(shù)的運用 動態(tài)測試技術(shù)的運用動態(tài)測試技術(shù)的運用 調(diào)試與評估調(diào)試與評估 單元測試的過程與文檔管理單元測試的過程與文檔管理 單元測試的常用工具簡介單元測試的常用工具簡介 第六章 集成測試和系統(tǒng)測試 Zhu.K 6.1 系統(tǒng)集成的模式與方法 6.2 功能測試 6.3 系統(tǒng)測試 6.4 壓力測試、容量測試和

2、性能測試 6.5安全性、可靠性和容錯性測試 6.16.1系統(tǒng)集成的模式與方法系統(tǒng)集成的模式與方法 人員安排人員安排 測試計劃測試計劃 測試內(nèi)容測試內(nèi)容 集成模式集成模式 測試方法測試方法 Zhu.K 為什么總是集成不起來？為什么總是集成不起來？ Zhu.K 集成測試的模式集成測試的模式 漸增式測試模式與非漸增式測試模式漸增式測試模式與非漸增式測試模式 非漸增式測試模式非漸增式測試模式：先分別測試每個模塊，再把所有模塊 按設(shè)計要求放在一起結(jié)合成所要的程序，如大棒模式。 漸增式測試模式漸增式測試模式：把下一個要測試的模塊同已經(jīng)測試好的 模塊結(jié)合起來進行測試，測試完以后再把下一個應(yīng)該測 試的模塊結(jié)合

3、進來測試。 各自的優(yōu)缺點各自的優(yōu)缺點 Zhu.K 自頂向下和自底向上集成方法自頂向下和自底向上集成方法 Zhu.K 驅(qū)動程序驅(qū)動程序/驅(qū)動模塊驅(qū)動模塊（driver），用以模擬被測 模塊的上級模塊。驅(qū)動模塊在集成測試中 接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測 模塊，啟動被測模塊，并打印出相應(yīng)的結(jié) 果。 樁程序樁程序/樁模塊樁模塊（stub），），也有人稱為存根程序， 用以模擬被測模塊工作過程中所調(diào)用的模 塊。樁模塊由被測模塊調(diào)用，它們一般只 進行很少的數(shù)據(jù)處理，例如打印入口和返 回，以便于檢驗被測模塊與其下級模塊的 接口 自頂向下法自頂向下法(Top-down Integration) Zhu.

4、K 自頂向下法的主要優(yōu)缺點自頂向下法的主要優(yōu)缺點 Zhu.K 自頂向下法自頂向下法(Top-down Integration) 自底向上法自底向上法(Bottom-up Integration) Zhu.K 自底向上法的主要優(yōu)缺點自底向上法的主要優(yōu)缺點 自底向上法自底向上法(Bottom-up Integration) Zhu.K 混合策略混合策略(Modified Top-down Integration) Zhu.K 混合法：對軟件結(jié)構(gòu)中較上層，使用的是混合法：對軟件結(jié)構(gòu)中較上層，使用的是“自頂向下自頂向下”法；對軟件結(jié)構(gòu)中法；對軟件結(jié)構(gòu)中 較下層，使用的是較下層，使用的是“自底向上自底向

5、上”法，兩者相結(jié)合法，兩者相結(jié)合 大棒集成方法大棒集成方法(Big-bang Integration) Zhu.K 采用大棒集成方法采用大棒集成方法,先是對每一個子模塊進行測試（單元測試階段），先是對每一個子模塊進行測試（單元測試階段）， 然后將所有模塊一次性的全部集成起來進行集成測試然后將所有模塊一次性的全部集成起來進行集成測試 。 因為所有的模塊一次集成的，所以很難確定出錯的真正位置、所在 的模塊、錯誤的原因。這種方法并不推薦在任何系統(tǒng)中使用，適合在規(guī) 模較小的應(yīng)用系統(tǒng)中使用。 三明治集成方法三明治集成方法(Sandwich Integration) Zhu.K 采用三明治方法的優(yōu)點是：它

6、將自頂向下和自底向上的集成方法有機地 結(jié)合起來，不需要寫樁程序因為在測試初自底向上集成已經(jīng)驗證了底層模塊 的正確性。采用這種方法的主要缺點是：在真正集成之前每一個獨立的模塊 沒有完全測試過。 改善的三明治集成方法改善的三明治集成方法 Zhu.K 改進的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模改進的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模 塊得到單獨的測試，使測試進行得比較徹底塊得到單獨的測試，使測試進行得比較徹底 。 幾種集成方法性能的比較幾種集成方法性能的比較 Zhu.K 自底向上自底向上 自頂向下自頂向下 混合策略混合策略大棒大棒三明治三明治改進三明治改進三明治 集

7、成集成早早早早早早晚晚早早早早 基本程序能工作時間基本程序能工作時間晚晚早早早早晚晚早早早早 需要驅(qū)動程序需要驅(qū)動程序是是否否是是是是是是是是 需要樁程序需要樁程序否否是是是是是是是是是是 工作并行性工作并行性中中低低中中高高中中高高 特殊路徑測試特殊路徑測試容易容易難難容易容易容易容易中等中等容易容易 計劃與控制計劃與控制容易容易難難難難容易容易難難難難 6.2功能測試功能測試 Zhu.K 目的和內(nèi)容目的和內(nèi)容 p 程序安裝、啟動正常，有相應(yīng)的提示框、錯誤提示等 p 每項功能符合實際要求 p 系統(tǒng)的界面清晰、美觀 p 菜單、按鈕操作正常、靈活，能處理一些異常操作 p 能接受正確的數(shù)據(jù)輸入，對

8、異常數(shù)據(jù)的輸入有提示、容錯處理等 p 數(shù)據(jù)的輸出結(jié)果準確，格式清晰，可以保存和讀取 p 功能邏輯清楚，符合使用者習(xí)慣 p 系統(tǒng)的各種狀態(tài)按照業(yè)務(wù)流程而變化，并保持穩(wěn)定 p 支持各種應(yīng)用的環(huán)境 p 能配合多種硬件周邊設(shè)備 p 軟件升級后，能繼續(xù)支持舊版本的數(shù)據(jù) p 與外部應(yīng)用系統(tǒng)的接口有效 功能測試的方法功能測試的方法 n等價類劃分法等價類劃分法 n邊界值分析法邊界值分析法 n錯誤推測法錯誤推測法 n因果圖法因果圖法 n組合分析法組合分析法 Zhu.K 我要測試所我要測試所 有的功能有的功能 等價類劃分法等價類劃分法 Zhu.K 劃分好等價類測試：防止遺漏測試案例。劃分好等價類測試：防止遺漏測試

9、案例。 邊界值分析法邊界值分析法 Zhu.K 例子：排序程序，邊界條件有： p 序列為空； p 序列僅有一個數(shù)據(jù)； p 序列為滿，用猜錯法補充一下測試用例； p 序列已經(jīng)按要求排好序； p 序列的順序與要求的順序恰好相反； p 序列中的所有數(shù)據(jù)全部相等。 因為錯誤最容易發(fā)生在邊界值附近，所以邊界值分析法對于多變量函 數(shù)的測試很有效，尤其是對于像C/C+數(shù)據(jù)類型要求不是很嚴格的語言 有利 。 錯誤推測法錯誤推測法 Zhu.K 這個錯誤到底在哪？這個錯誤到底在哪？ 因果圖法因果圖法 Zhu.K 因果圖法因果圖法 Zhu.K 混凝土強度為什么不足？混凝土強度為什么不足？ 組合分析法組合分析法 Zhu

10、.K 組合分析是一種基于每對參數(shù)組合的測試技術(shù)，主要考 慮參數(shù)之間的影響是主要的錯誤來源和大多數(shù)的錯誤起 源于簡單的參數(shù)組合。 在產(chǎn)品漢化過在產(chǎn)品漢化過 程中哪個組合程中哪個組合 出錯了？出錯了？ 6.3 系統(tǒng)測試系統(tǒng)測試 p壓力測試壓力測試 (Stress test) p容量測試容量測試 (Capacity test) p性能測試性能測試 (Performance test) p安全測試安全測試 (Security test) p容錯測試容錯測試 (Recovery test) Zhu.K 回歸測試的目的回歸測試的目的 p 所做的修改達到了預(yù)定的目的，如錯誤得到了改正， 新功能得到了實現(xiàn)，能

11、夠適應(yīng)新的運行環(huán)境等； p 不影響軟件原有功能的正確性。 回歸測試的方法回歸測試的方法 p 再測試全部用例 p 基于風(fēng)險選擇測試 p 基于操作剖面選擇測試 p 再測試修改的部分 回歸測試回歸測試 2000 Zhu.K 回歸測試的組織和實施回歸測試的組織和實施 回歸測試回歸測試 Zhu.K 6.4 壓力測試、容量測試和性能測試壓力測試、容量測試和性能測試 Zhu.K 壓力測試、容量測試和性能測試的測試目的雖然有所不同，但其壓力測試、容量測試和性能測試的測試目的雖然有所不同，但其 手段和方法在一定程度上比較相似，通常會使用特定的測試工具，來手段和方法在一定程度上比較相似，通常會使用特定的測試工具，

12、來 模擬超常的數(shù)據(jù)量、負載等，監(jiān)測系統(tǒng)的各項性能指標，如模擬超常的數(shù)據(jù)量、負載等，監(jiān)測系統(tǒng)的各項性能指標，如CPUCPU和內(nèi)和內(nèi) 存的使用情況、響應(yīng)時間、數(shù)據(jù)傳輸量等。存的使用情況、響應(yīng)時間、數(shù)據(jù)傳輸量等。 一定要設(shè)法破壞一定要設(shè)法破壞 它它! 性能測試性能測試 Zhu.K 0 5 10 15 20 25 30 1X5 1X100 1X500 1X700 1X900 10X5 HTTP TCP HTTP n如果所有用戶是在一個非常短的時間內(nèi)同時與系統(tǒng)通信， 就應(yīng)該使用flat測試，將所有的用戶同時加載到服務(wù)器 什么是確定容量的最好方法？什么是確定容量的最好方法？ 結(jié)合兩種負載類型的優(yōu)點，并運行

13、一系列的測試 如：首先使用ramp-up測試確定系統(tǒng)支持的用戶范圍該 范圍內(nèi)不同的并發(fā)用戶負載進行一系列的flat測試，更精 確地確定系統(tǒng)的容量。 性能規(guī)劃測試性能規(guī)劃測試 (2) 滲入測試滲入測試 滲入測試是一種比較簡單的性能測試。滲入測試所需時 間較長，它使用固定數(shù)目的并發(fā)用戶測試系統(tǒng)的總體健 壯性。這些測試將會通過內(nèi)存泄漏、增加的垃圾收集(GC) 或系統(tǒng)的其他問題，顯示因長時間運行而出現(xiàn)的任何性 能降低。 建議運行兩次測試一次使用較低的用戶負載（要在系 統(tǒng)容量之下，以便不會出現(xiàn)執(zhí)行隊列），一次使用較高 的負載（以便出現(xiàn)積極的執(zhí)行隊列）。 峰谷測試峰谷測試 兼有容量規(guī)劃ramp-up測試和

14、滲入測試的特征,目標是 確定從高負載（例如系統(tǒng)高峰時間的負載）恢復(fù)、轉(zhuǎn) 為幾乎空閑、然后再攀升到高負載、再降低的能力。 性能測試的過程性能測試的過程 評估系統(tǒng)評估系統(tǒng) 制定測試資產(chǎn)制定測試資產(chǎn) 執(zhí)行基線執(zhí)行基線 客戶機與服務(wù)器網(wǎng)絡(luò)中斷; 服務(wù)器相關(guān)的程序CRASH; 系統(tǒng)中全部或部分CORE SERVER出現(xiàn)掉電/網(wǎng)絡(luò)中斷情況. Failover測試的方法和技巧測試的方法和技巧 p將測試系統(tǒng)全部對象描繪出來-系統(tǒng)結(jié)構(gòu)圖 p對圖中的所有可能發(fā)生的故障點設(shè)計測試 用例. 示例示例 1 n簡單的服務(wù)器構(gòu)造簡單的服務(wù)器構(gòu)造 示例示例 1 （contd） 在這個構(gòu)造中，當其中一臺應(yīng)用服務(wù)器出現(xiàn)故障，連接

15、此應(yīng)用服務(wù)器的 兩個web 服務(wù)器將不再獲得從負載平衡服務(wù)器上請求，這樣，所有的負載都會傳遞到剩余 的兩臺web服務(wù)器, 見下圖: 示例二：企業(yè)級服務(wù)器示例二：企業(yè)級服務(wù)器 6.4 壓力測試壓力測試 Zhu.K 在一種需要反常（如長時間的峰值）數(shù)量、頻率或資源的方 式下，執(zhí)行可重復(fù)的負載測試，以檢查程序?qū)Ξ惓Ｇ闆r的 抵抗能力，找出性能瓶頸找出性能瓶頸。從本質(zhì)上來說，測試者是想要 破壞程序。 步驟：步驟： 測試壓力估算測試壓力估算 測試環(huán)境準備測試環(huán)境準備 問題的分析問題的分析 累積效應(yīng)累積效應(yīng) 壓力測試壓力測試 Zhu.K 試試這個游戲站點的承受力試試這個游戲站點的承受力 壓力測試類型壓力測試

16、類型 n 并發(fā)性能測試（重點）并發(fā)性能測試（重點） n 疲勞強度測試疲勞強度測試 n 大數(shù)據(jù)量測試大數(shù)據(jù)量測試 并發(fā)性能測試并發(fā)性能測試 考察客戶端應(yīng)用的性能，測試的入口是客戶端 并發(fā)性能測試的過程，是一個負載測試和壓力 測試的過程。即逐漸增加并發(fā)虛擬用戶數(shù)負載， 直到系統(tǒng)的瓶頸或者不能接收的性能點，通過 綜合分析交易執(zhí)行指標、資源監(jiān)控指標等來確 定系統(tǒng)并發(fā)性能的過程。并發(fā)性能測試是負載 壓力測試中的重要內(nèi)容。 ramp-upramp-up測試測試 疲勞強度測試疲勞強度測試 通常是采用系統(tǒng)穩(wěn)定運行情況下能夠支持 的最大并發(fā)用戶數(shù)或者日常運行用戶數(shù)，持續(xù) 執(zhí)行一段時間業(yè)務(wù)，通過綜合分析交易執(zhí)行指

17、 標和資源監(jiān)控指標來確定系統(tǒng)處理最大工作量 強度性能的過程。 疲勞強度測試案例制定的原則是保證系統(tǒng)長 期不間斷運行的業(yè)務(wù)量，并且應(yīng)該盡量去滿足該 條件。 Flat測試測試 大數(shù)據(jù)量測試大數(shù)據(jù)量測試 n獨立的數(shù)據(jù)量測試獨立的數(shù)據(jù)量測試 針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務(wù)進行大 數(shù)據(jù)量測試 n綜合數(shù)據(jù)量測試綜合數(shù)據(jù)量測試 和壓力性能測試、負載性能測試、并發(fā)性能測試、疲勞 性能測試相結(jié)合的綜合測試方案 容量測試容量測試 Zhu.K 容量測試目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項 指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其 極限值狀態(tài)下還能保持主要功能正常運行。容量測

18、試還將確定測試 對象在給定時間內(nèi)能夠持續(xù)處理的最大負載或工作量。 度量系統(tǒng)容量舉例度量系統(tǒng)容量舉例 查看現(xiàn)有系統(tǒng)中性能與負載間的關(guān)系，并確定出現(xiàn)響應(yīng) 時間顯著延長的位置 “拐點”?？梢源_定是否需要增 加資源以支持額外的用戶。 Zhu.K 系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-1 交易的響應(yīng)時間交易的響應(yīng)時間如果很長，遠遠超過系統(tǒng)性能需求，表 示耗費CPU的數(shù)據(jù)庫操作，例如排序，執(zhí)行aggregate functions（例如sum、min、max、count）等較多，可考 慮是否有索引以及索引建立的是否合理；盡量使用簡單 的表聯(lián)接；水平分割大表格等方法來降低該值。 Zhu.K 系統(tǒng)瓶頸分析舉例系統(tǒng)

19、瓶頸分析舉例-2 分段排除錯誤。測試工具可以模擬不同的虛擬用 戶來單獨訪問Web服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫 服務(wù)器，這樣，就可以在Web端測出的響應(yīng)時間 減去以上各個分段測出的時間就可以知道瓶頸在 哪并著手調(diào)優(yōu)。 Zhu.K 系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-3 UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標內(nèi)存內(nèi)存 頁交換速率頁交換速率（Paging rate），如果該值偶爾走高， 表明當時有線程競爭內(nèi)存。如果持續(xù)很高，則內(nèi) 存可能是瓶頸。也可能是內(nèi)存訪問命中率低。 “Swap in rate”和“Swap out rate”也有類似的 解釋。 Zhu.K 系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-4

20、UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標CPU 占用率占用率（CPU utilization），如果該值持續(xù)超過 95%，表明瓶頸是CPU?？梢钥紤]增加一個處理 器或換一個更快的處理器 。合理使用的范圍在 60%至70%。 Zhu.K 系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-5 UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標磁盤磁盤 交換率交換率（Disk rate），如果該參數(shù)值一直很高， 表明I/O有問題。可考慮更換更快的硬盤系統(tǒng)、重 新部署業(yè)務(wù)邏輯等，另外設(shè)置Tempdb in RAM， 減低max async IO，max lazy writer IO等措 施都會降低該值。 Zhu.K 系統(tǒng)瓶

21、頸分析舉例系統(tǒng)瓶頸分析舉例-6 SQLServer資源監(jiān)控中指標緩存點擊率緩存點擊率（Cache Hit Ratio），該值越高越好。如果持續(xù)低于80%， 應(yīng)考慮增加內(nèi)存。 注意該參數(shù)值是從SQL Server啟動后，就一直累加記數(shù)，所以運行經(jīng)過 一段時間后，該值將不能反映系統(tǒng)當前值。 Zhu.K 6.5 安全性測試，可靠性和容錯性測試安全性測試，可靠性和容錯性測試 Zhu.K 安全性測試、可靠性測試和容錯性測試的測試目的 不同，其手段和方法也不同，但都屬于系統(tǒng)測試的范疇， 有一定的聯(lián)系，如軟件可靠性要求通常包括了安全性的軟件可靠性要求通常包括了安全性的 要求要求。 安全性測試、可靠性測試和容

22、錯性測試的技術(shù)比較 深、實施比較難，但在應(yīng)用系統(tǒng)中越來越重要。 安全性測試安全性測試 Zhu.K 根據(jù)根據(jù)ISO 8402的定義，安全性是的定義，安全性是“使傷害或損害的風(fēng)使傷害或損害的風(fēng) 險限制在可接受的水平內(nèi)險限制在可接受的水平內(nèi)”。 安全性測試安全性測試 Zhu.K 安全性測試是檢查系統(tǒng)對非法侵入的防范能力。安全測試期 間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。 例如： p 想方設(shè)法截取或破譯口令； p 專門開發(fā)軟件來破壞系統(tǒng)的保護機制； p 故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機非法進入； p 試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。 理論上講，只要有足夠的時間和資源，沒有不可

23、進入的系統(tǒng)。 因此系統(tǒng)安全設(shè)計的準則是，使非法侵入的代價超過被保護 信息的價值，此時非法侵入者已無利可圖。 可靠性測試可靠性測試 Zhu.K 可靠性（Reliability）是產(chǎn)品在規(guī)定的條件下和規(guī)定的時間內(nèi)完成 規(guī)定功能的能力，它的概率度量稱為可靠度。軟件可靠性是軟件 系統(tǒng)的固有特性之一，它表明了一個軟件系統(tǒng)按照用戶的要求和 設(shè)計的目標，執(zhí)行其功能的可靠程度。軟件可靠性與軟件缺陷有 關(guān)，也與系統(tǒng)輸入和系統(tǒng)使用有關(guān)。理論上說，可靠的軟件系統(tǒng) 應(yīng)該是正確、完整、一致和健壯的。 l規(guī)定的時間規(guī)定的時間 l規(guī)定的環(huán)境條件規(guī)定的環(huán)境條件 l規(guī)定的功能規(guī)定的功能 Web安全性 Zhu.K 可靠性測試結(jié)果

24、的評估可靠性測試結(jié)果的評估 成熟性度量可以通過錯誤發(fā)現(xiàn)率DDP（Defect Detection Percentage）來 表現(xiàn)。在測試中查找出來的錯誤越多，實際應(yīng)用中出錯的機會就越小，軟 件也就越成熟。 DDP=測試發(fā)現(xiàn)的錯誤數(shù)量測試發(fā)現(xiàn)的錯誤數(shù)量/已知的全部錯誤數(shù)量已知的全部錯誤數(shù)量 已知的全部錯誤數(shù)量是測試已發(fā)現(xiàn)的錯誤數(shù)量加上可能會發(fā)現(xiàn)的錯誤數(shù)量 之和。 容錯性測試容錯性測試 Zhu.K 容錯性測試是檢查軟件在異常條件下自身是否具有防 護性的措施或者某種災(zāi)難性恢復(fù)的手段。如當系統(tǒng)出錯時， 能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)。容錯性 測試包括兩個方面： 輸入異常數(shù)據(jù)或進行異常操作，

25、以檢驗系統(tǒng)的保護性輸入異常數(shù)據(jù)或進行異常操作，以檢驗系統(tǒng)的保護性。如果系統(tǒng) 的容錯性好的話，系統(tǒng)只給出提示或內(nèi)部消化掉，而不會導(dǎo)致系 統(tǒng)出錯甚至崩潰。 災(zāi)難恢復(fù)性測試災(zāi)難恢復(fù)性測試。通過各種手段，讓軟件強制性地發(fā)生故障，然 后驗證系統(tǒng)已保存的用戶數(shù)據(jù)是否丟失、系統(tǒng)和數(shù)據(jù)是否能盡快 恢復(fù)。 從質(zhì)量三個緯度看系統(tǒng)測試從質(zhì)量三個緯度看系統(tǒng)測試 Zhu.K 質(zhì)量維度質(zhì)量維度 測試類型測試類型 可靠性可靠性完整性測試：完整性測試：側(cè)重于評估測試對象的強壯性（防止失敗的能力）， 語言、語法的技術(shù)兼容性以及資源利用率的測試。該測試針對不 同的測試對象實施和執(zhí)行，包括單元和已集成單元。 結(jié)構(gòu)測試：結(jié)構(gòu)測試：側(cè)重于評估測試目標是否符合其設(shè)計和構(gòu)造的測試。通 常對基于 Web 的應(yīng)用程序執(zhí)行該測試，以確保所有鏈接都已連接 、顯示正確的內(nèi)容以及沒有孤立的內(nèi)容。 功能功能配置測試：配置測試：側(cè)重于確保測試對象在不同的硬件和/或軟件配置上按預(yù) 期運行的測試。該測試還可以作為系統(tǒng)性能測試來