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

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

第2版

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

人員安排

測試計(jì)劃

測試內(nèi)容

集成模式

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

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

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

自底向上法(Bottom-upIntegration)

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

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

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

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

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

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

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

Zhu.Kerry@目的和內(nèi)容

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

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

回歸測試的方法

再測試全部用例基于風(fēng)險(xiǎn)選擇測試基于操作剖面選擇測試再測試修改的部分6.3回歸測試

2000Zhu.Kerry@回歸測試的組織和實(shí)施回歸測試

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

Zhu.Kerry@

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

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

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

服務(wù)器的各項(xiàng)指標(biāo)（CPU、內(nèi)存占用率等）、后臺數(shù)據(jù)庫的各項(xiàng)指標(biāo)、網(wǎng)絡(luò)流量、響應(yīng)時(shí)間性能測試方法負(fù)載模擬

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

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

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

“Flat”測試:

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

Ramp-up測試:

用戶是交錯(cuò)上升的（每幾秒增加一些新用戶）。ramp-up測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因?yàn)橛捎谟脩舻脑黾邮敲看我徊糠郑到y(tǒng)的負(fù)載在不斷地變化。其優(yōu)點(diǎn)是，可以看出隨著系統(tǒng)負(fù)載的改變，測量值是如何改變的據(jù)此選擇要運(yùn)行的flat測試的范圍。Flat測試“波動”效應(yīng)

PageDownloadedperSecond系統(tǒng)吞吐量

Flat測試“波動”效應(yīng)

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

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

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

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

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

結(jié)合兩種負(fù)載類型的優(yōu)點(diǎn)，并運(yùn)行一系列的測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zhu.Kerry@質(zhì)量維度測試類型

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

結(jié)構(gòu)測試：側(cè)重于評估測試目標(biāo)是否符合其設(shè)計(jì)和構(gòu)造的