第七章 系統(tǒng)測試與集成測試

第七章集成測試與系統(tǒng)測試1內(nèi)容概要2第一節(jié).集成測試集成測試的策略集成測試的過程集成測試階段工作3本章重點(diǎn)：本節(jié)概要常用的集成策略有哪些集成測試的流程集成測試的工作過程重點(diǎn)掌握：4一.常用的集成測試策略（1）大爆炸集成大爆炸集成是一種一次性將系統(tǒng)內(nèi)的組件全部集合到測試系統(tǒng)中進(jìn)行測試的方法。這種方法可以很快看到程序運(yùn)行起來，但很難定位問題，并且該方法必須先對所有單元進(jìn)行單元測試，然后再將所有單元組裝起來進(jìn)行測試。5（2）自頂向下集成自頂向下集成的方法是從最頂層程序開始，所有被主程序調(diào)用的下層單元全部使用樁來代替，然后一層一層向下進(jìn)行測試，每層程序調(diào)用的下一層程序單元都要打樁。整個(gè)集成可以按深度優(yōu)先的策略進(jìn)行，也可按照廣度優(yōu)先的策略進(jìn)行。采用深度優(yōu)先策略可以較快驗(yàn)證一個(gè)子系統(tǒng)的完整功能。6對模塊1進(jìn)行集成測試時(shí)，先測試模塊1的內(nèi)部接口的集成，需對模塊2和模塊3打樁，然后進(jìn)行測試。接著再測試模塊1和模塊2、模塊3的集成關(guān)系，當(dāng)測試模塊1和模塊2的集成關(guān)系時(shí)，需對模塊3打樁，同理，測試模塊1和模塊3的集成關(guān)系時(shí)，需對模塊2打樁。7（3）自底向上集成

從最底層模塊開始按照接口依賴關(guān)系，逐層向上集成。如下圖

測試模塊3時(shí)，不需要寫樁模塊，但是需要為模塊3編寫驅(qū)動(dòng)模塊，測試完模塊3和模塊4后，再對模塊2進(jìn)行集成測試。由于模塊3和模塊4已經(jīng)測試完，不需要寫樁模塊，但還需要為模塊3編寫驅(qū)動(dòng)模塊。8（4）三明治集成

結(jié)合自底向上和自頂向下兩種集成方法，對于底層模塊采用自底向上的法，對于頂層模塊采用自頂向下的集成方法進(jìn)行測試。

測試模塊3采用自底向上集成，測試模塊5采用自頂向下集成。9

測試策略優(yōu)點(diǎn)

缺點(diǎn)

大爆炸集成

可以迅速完成集成測試；需要的樁和樁模塊非常少；需要的用例是最少的，多個(gè)測試人員可以并行測試；操作簡單；資源利用率高

一次試運(yùn)行成功的可能性不大；問題定位和修改比較困難；接口間的交互關(guān)系只被測試到很少一部分，大量的實(shí)際中會運(yùn)行到的程序執(zhí)行路徑?jīng)]有被測試到；風(fēng)險(xiǎn)高。自頂向下集成較早地驗(yàn)證了主要控制和判斷點(diǎn)；按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；功能較早證實(shí)，帶來信心；只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開發(fā)的費(fèi)用；支持故障隔離。缺點(diǎn)：樁的開發(fā)工作量大，底層驗(yàn)證被推遲，底層組件測試不充分。該方法適用于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定，高層接口變化較小，底層接口未定義或經(jīng)?？赡鼙恍薷?，產(chǎn)品控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證，希望盡早能看到產(chǎn)品的系統(tǒng)功能行為的情況。自底向上集成對底層組件行為較早驗(yàn)證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。驅(qū)動(dòng)的開發(fā)工作量大；對高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。適用于底層接口比較穩(wěn)定，高層接口變化比較頻繁，底層組件較早被完成的情況。三明治集成集合了自頂向下和自底向上兩種策略的優(yōu)點(diǎn)。

中間層測試不充分。該方法適用于大部分軟件開發(fā)項(xiàng)目。10其他一些集成測試策略

集成策略

優(yōu)點(diǎn)

缺點(diǎn)基干**集成具有三明治集成的優(yōu)點(diǎn)，更適合于大型復(fù)雜項(xiàng)目的集成。

必須對系統(tǒng)的結(jié)構(gòu)和相互依存性進(jìn)行仔細(xì)的分析；驅(qū)動(dòng)和樁開發(fā)量大；局部采用了大爆炸的策略，有些接口可能測試不充分。

分層集成

適用于有明顯層次關(guān)系的系統(tǒng)。基于功能的集成優(yōu)先驗(yàn)證關(guān)鍵功能的正確性，減少驅(qū)動(dòng)的開發(fā)，進(jìn)度要快。

對接口測試不充分，有較大的冗余測試?；谙⒌募蓛?yōu)先驗(yàn)證關(guān)鍵消息的正確性，減少驅(qū)動(dòng)的開發(fā)，進(jìn)度要快。對接口測試不充分，有較大的冗余測試。基于風(fēng)險(xiǎn)的集成最具有風(fēng)險(xiǎn)的組件最早進(jìn)行驗(yàn)證，有助于系統(tǒng)的快速穩(wěn)定。

需要對各組件的風(fēng)險(xiǎn)有一個(gè)清晰的分析。基于進(jìn)度的集成具有較高的并行度，能夠有效縮短項(xiàng)目的開發(fā)進(jìn)度。

樁和驅(qū)動(dòng)工作量較大，有些接口測試不充分，有些測試重復(fù)和浪費(fèi)。11·制定集成測試計(jì)劃

··設(shè)計(jì)集成測試

實(shí)施集成測試

·執(zhí)行集成測試

評估集成測試

二.集成測試五階段12開發(fā)設(shè)計(jì)模型制定集成計(jì)劃實(shí)施類，進(jìn)行單元測試劃型制定計(jì)劃，設(shè)計(jì)用例測試過程，腳本執(zhí)行集成測試，生成測試日志執(zhí)行集成測試，生成測試日志TestDesignerTesterTheDesigner

ImplementerIntegratorDesigner13三.1.集成測試階段工作流程2.人員安排角色職責(zé)測試設(shè)計(jì)員負(fù)責(zé)制定集成測試計(jì)劃、設(shè)計(jì)集成測試、實(shí)施集成測試、評估集成測試測試員執(zhí)行集成測試，記錄測試結(jié)果實(shí)施員負(fù)責(zé)實(shí)施類（包括驅(qū)動(dòng)程序和樁），并對其進(jìn)行單元測試，根據(jù)集成測試發(fā)現(xiàn)的缺陷提出變更申請配置管理員負(fù)責(zé)對測試工作進(jìn)行配置管理集成員負(fù)責(zé)制定集成構(gòu)建計(jì)劃，按照集成計(jì)劃將通過了單元測試的類集成設(shè)計(jì)員負(fù)責(zé)設(shè)計(jì)測試驅(qū)動(dòng)程序和樁；根據(jù)集合測試發(fā)現(xiàn)的缺陷提出變更申請

143.測試計(jì)劃用集成測試計(jì)劃的模板（詳見附錄B：集成測試計(jì)劃模板）寫集成測試計(jì)劃書。計(jì)劃書內(nèi)容通常應(yīng)該包含以下部分：確定集成測試對象，確定集成測試策略，確定集成測試驗(yàn)收標(biāo)準(zhǔn)，確定集成測試掛起和恢復(fù)條件，估計(jì)集成測試工作量，估計(jì)集成測試所需資源；進(jìn)行集成測試任務(wù)劃分（包括任務(wù)名、責(zé)任人、輸入和輸出、風(fēng)險(xiǎn)及應(yīng)對措施、進(jìn)度安排等）等。154.測試內(nèi)容功能性測試

可靠性測試

易用性測試

性能測試

維護(hù)性測試

可移植性測試

165．集成模式的選取

集成模式是軟件集成測試中的策略體現(xiàn)，其重要性是明顯的，直接關(guān)系到測試的效率、結(jié)果等，一般要根據(jù)具體的系統(tǒng)來決定采用哪種模式。集成測試基本可以概括為以下兩種：非漸增式測試模式和漸增式測試模式。非漸增式測試模式：先分別測試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求一次全部組裝起來，然后進(jìn)行整體測試。漸增式測試模式：把下一個(gè)要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個(gè)模塊結(jié)合進(jìn)來測試。非漸增式測試時(shí)可能發(fā)現(xiàn)一大堆錯(cuò)誤，定位和糾正每個(gè)錯(cuò)誤非常困難，并且在改正一個(gè)錯(cuò)誤的同時(shí)又可能引入新的錯(cuò)誤，新舊錯(cuò)誤混雜，更難斷定出錯(cuò)的原因和位置。與之相反的是漸增式集成模式，程序一段一段地?cái)U(kuò)展，測試的范圍一步一步地增大，錯(cuò)誤易于定位和糾正，接口的測試亦可做到完全徹底。兩種模式中，漸增式測試模式雖然需要編寫的驅(qū)動(dòng)或樁程序較多，發(fā)現(xiàn)模塊間接口錯(cuò)誤相對稍晚些，但仍然具有比較明顯的優(yōu)勢。在實(shí)際測試中，應(yīng)該將兩種模式有機(jī)結(jié)合起來，采用并行的自頂向下、自底向上集成方式，從而形成改進(jìn)的三明治方法。而更重要的是采取持續(xù)集成的策略，軟件開發(fā)中各個(gè)模塊不是同時(shí)完成，根據(jù)進(jìn)度將完成的模塊盡可能早地進(jìn)行集成，有助于盡早發(fā)現(xiàn)缺陷，避免集成階段大量缺陷涌現(xiàn)。同時(shí)自底向上集成時(shí)，先期完成的模塊將是后期模塊的樁程序，而自頂向下集成時(shí)，先期完成的模塊將是后期模塊的驅(qū)動(dòng)程序，從而使后期模塊的單元測試和集成測試出現(xiàn)了部分的交叉，不僅節(jié)省了測試代碼的編寫，也有利于提高工作效率。

17總之，實(shí)際應(yīng)用中，常用的集成策略有：自頂向下集成、自底向上集成和混合集成。因?yàn)檫@三種策略并不相互排斥，因此基于這三種策略的組合可以派生出多種策略。集成策略的選取主要依賴于：（1）集成部件的可用性（例如第三方軟件或硬件）。（2）系統(tǒng)規(guī)模。（3）是新系統(tǒng)還是在現(xiàn)有系統(tǒng)上增加、改變功能。（4）體系架構(gòu)。18第二節(jié).系統(tǒng)測試系統(tǒng)測試類型系統(tǒng)測試內(nèi)容系統(tǒng)測試過程本章重點(diǎn)：19本節(jié)概要五種重要系統(tǒng)測試類型十八種系統(tǒng)測試系統(tǒng)測試主要流程本節(jié)難點(diǎn)：20一.系統(tǒng)測試的類型211.2.3.4.5.6.用戶支持測試

用戶界面測試

可維護(hù)性測試安全性測試

1、用戶層222、應(yīng)用層23初驗(yàn)測試：系統(tǒng)核心功能、基本業(yè)務(wù)流程的驗(yàn)證。業(yè)務(wù)功能覆蓋：關(guān)注需求規(guī)格定義的所有功能是否都已實(shí)現(xiàn)。業(yè)務(wù)場景測試：模擬用戶操作實(shí)際業(yè)務(wù)場景，遍歷主要業(yè)務(wù)流程和業(yè)務(wù)規(guī)則。業(yè)務(wù)功能分解：將每個(gè)功能分解為測試項(xiàng)，關(guān)注每個(gè)測試項(xiàng)的測試類型都被測試通過。業(yè)務(wù)功能組合：相關(guān)聯(lián)的功能項(xiàng)的組合功能都被正確實(shí)現(xiàn)。業(yè)務(wù)功能沖突：業(yè)務(wù)功能間存在的功能沖突情況均測試通過，例如：共享資源訪問等。異常處理及容錯(cuò)性：輸入異常數(shù)據(jù)，或執(zhí)行異常操作后，系統(tǒng)容錯(cuò)性及錯(cuò)誤處理機(jī)制的健壯性。243、功能層（1）檢驗(yàn)?zāi)芊襁m當(dāng)?shù)亟邮茌斎霐?shù)據(jù)而產(chǎn)生正確的輸出結(jié)果。（2）檢驗(yàn)?zāi)芊窠邮懿煌臄?shù)據(jù)輸入（能接受正確的數(shù)據(jù)輸入、對異常數(shù)據(jù)的輸入進(jìn)行提示和溶出處理）。（3）檢驗(yàn)數(shù)據(jù)輸出結(jié)果是否正確、格式是否清晰，能否保存和讀取。（4）檢驗(yàn)功能邏輯是否清楚，符合使用者的習(xí)慣。（5）檢驗(yàn)系統(tǒng)的各種狀態(tài)是否按照業(yè)務(wù)流程變化，并保持穩(wěn)定。（6）檢驗(yàn)菜單、按鈕操作是否正常、靈活，能處理一些異常操作。（7）檢驗(yàn)系統(tǒng)的界面是否清晰、美觀。（8）支持各種應(yīng)用的環(huán)境，能配合多種硬件周邊設(shè)備，與外部應(yīng)用系統(tǒng)的接口有效。（9）檢驗(yàn)是否所有功能都能夠?qū)崿F(xiàn)，是否存在遺漏功能。（10）檢驗(yàn)是否所有功能都能正常實(shí)現(xiàn)，是否存在不正常功能。（11）檢驗(yàn)是否存在額外的功能，如功能鍵等。（12）檢驗(yàn)功能是否滿足系統(tǒng)設(shè)計(jì)的隱含需求，如系統(tǒng)對意外情況的反應(yīng)能力等。（13）檢驗(yàn)軟件升級后，能否繼續(xù)支持舊版本的數(shù)據(jù)。251、二.系統(tǒng)測試內(nèi)容：2、性能測試應(yīng)包含內(nèi)容26一次加載每個(gè)數(shù)量的用戶，在預(yù)定的時(shí)間段內(nèi)持續(xù)運(yùn)行。例如，早晨上班，用戶訪問網(wǎng)站或登錄網(wǎng)站的時(shí)間非常集中，基本上屬于Flat負(fù)載模式。有規(guī)律地逐漸增加用戶，每幾秒增加一些新用戶，交錯(cuò)上升，這種方式又稱為ra-mp-up模式。借助這種負(fù)載方式的測試，容易發(fā)現(xiàn)性能的拐點(diǎn)，即性能瓶頸的位置。

某個(gè)時(shí)間用戶數(shù)量很大，突然降級到很低，然后，過一段時(shí)間，又突然加到很高，反復(fù)幾次。借助這種負(fù)載方式，容易發(fā)現(xiàn)資源釋放、內(nèi)存泄漏等問題。

由隨機(jī)算法自動(dòng)生成某個(gè)數(shù)量范圍動(dòng)態(tài)的負(fù)載。雖然不容易模擬系統(tǒng)運(yùn)行出現(xiàn)的高峰期，但能模擬長時(shí)間的高位運(yùn)行過程。遞增加載高低突變加載隨機(jī)加載方式

一次加載

3、負(fù)載測試274、壓力測試壓力測試（StressTesting）。壓力測試是持續(xù)不斷地給被測系統(tǒng)增加壓力，直到被測系統(tǒng)被壓垮，從而確定系統(tǒng)能承受的最大壓力。5、疲勞測試通常是采用系統(tǒng)穩(wěn)定運(yùn)行情況下，在一段時(shí)間內(nèi)（經(jīng)驗(yàn)上一般是連續(xù)72個(gè)小時(shí)），保持能夠支持最大并發(fā)用戶數(shù)，持續(xù)執(zhí)行一段時(shí)間業(yè)務(wù)，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)處理最大工作量強(qiáng)度性能的過程。286、易用性測試易用性測試方法有靜態(tài)測試、動(dòng)態(tài)測試以及動(dòng)態(tài)和靜態(tài)結(jié)合測試。易用性測試就是要檢查系統(tǒng)界面和功能是否容易學(xué)習(xí)，使用方式是否規(guī)范一致，是否會誤導(dǎo)用戶或者使用模糊的信息。29安裝測試（InstallingTesting）是確保軟件在正常情況和異常情況下都能進(jìn)行安裝，并核實(shí)軟件在安裝后可立即正常運(yùn)行的測試。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等場景。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進(jìn)行安裝，安裝代碼提供安裝一些程序能夠運(yùn)行的基礎(chǔ)數(shù)據(jù)。進(jìn)行安裝測試時(shí)，從下面3點(diǎn)開展測試工作。（1）檢查系統(tǒng)安裝是否能夠安裝所有需要的文件/數(shù)據(jù)并進(jìn)行必要的系統(tǒng)設(shè)置，是否會破壞其他位置的文件，是否可以終止并恢復(fù)現(xiàn)場。（2）檢查系統(tǒng)是否能夠正確卸載并恢復(fù)現(xiàn)場。（3）檢查安裝和卸載過程的用戶提示和功能是否出現(xiàn)錯(cuò)誤7、安裝測試308、配置測試過程確定所需的硬件類型。確定哪些硬件、型號和驅(qū)動(dòng)程序可用。確定可能的硬件特性、模式和選項(xiàng)。將確定后的硬件配置縮減為可控制的范圍。明確使用硬件配置的軟件唯一特性。設(shè)計(jì)在每一種配置中執(zhí)行的測試用例。在每種配置中執(zhí)行測試。反復(fù)測試直到小組對結(jié)果滿意為止。319、文檔測試文檔測試是檢查系統(tǒng)文檔是否齊全，是否有多余文檔或者死文檔，文檔內(nèi)容是否正確、規(guī)范、一致等。文檔測試開發(fā)文件用戶文件管理文件3210、安全測試安全測試（SecurityTesting）用于檢驗(yàn)系統(tǒng)對非法侵入的防范能力。系統(tǒng)的安全必須能夠經(jīng)受各方面的攻擊。在安全測試的過程中，測試人員扮演非法入侵者的角色，采用各種方法試圖突破系統(tǒng)的安全防線。從理論上講，只要給予足夠的時(shí)間和資源，任何系統(tǒng)都可以侵入。因此，系統(tǒng)安全設(shè)計(jì)原則是將系統(tǒng)設(shè)計(jì)為想攻破系統(tǒng)而付出的代價(jià)應(yīng)大于侵入系統(tǒng)之后得到的信息價(jià)值，使得非法侵入者無利可圖。常見的非法入侵手段有以下3種。（1）嘗試通過外部手段截獲或破譯系統(tǒng)口令。（2）使用甚至專門開發(fā)能夠瓦解防守的客戶軟件來攻擊系統(tǒng)，試圖破壞系統(tǒng)的保護(hù)機(jī)制。（3）故意引發(fā)系統(tǒng)錯(cuò)誤，導(dǎo)致系統(tǒng)失敗，企圖趁系統(tǒng)恢復(fù)時(shí)侵入系統(tǒng)。安全測試應(yīng)包括以下內(nèi)容。（1）檢查系統(tǒng)是否有病毒。（2）檢查系統(tǒng)是否正確加密。（3）系統(tǒng)在非授權(quán)的內(nèi)部或外部用戶訪問或故意破壞時(shí)候是否出現(xiàn)錯(cuò)誤。33人為使系統(tǒng)發(fā)生災(zāi)難（系統(tǒng)崩潰、硬件損壞、病毒入侵等），檢查系統(tǒng)是否能恢復(fù)被破壞的環(huán)境和數(shù)據(jù)。在這種測試中，將把應(yīng)用程序或系統(tǒng)置于極端條件下（或者是模擬的極端條件下），以產(chǎn)生故障，然后調(diào)用恢復(fù)進(jìn)程并監(jiān)測和檢驗(yàn)應(yīng)用程序和系統(tǒng)，核實(shí)應(yīng)用程序或系統(tǒng)和數(shù)據(jù)已得到了正確的恢復(fù)。恢復(fù)測試中考慮的典型問題如下：（1）是否存在潛在的和已確認(rèn)的故障，導(dǎo)致的后果是怎樣。（2）故障恢復(fù)過程是否為錯(cuò)誤提供了足夠的反應(yīng)。（3）恢復(fù)過程是否能夠正確工作。11、恢復(fù)測試34

一種選擇性重新測試，目的是檢測系統(tǒng)或系統(tǒng)組成部分在修改期間產(chǎn)生的缺陷，用于驗(yàn)證已進(jìn)行的修改并未引起不希望的有害效果，或確認(rèn)修改后的系統(tǒng)或系統(tǒng)組成部分仍滿足規(guī)定的要求。設(shè)計(jì)和引入回歸測試數(shù)據(jù)的重要原則，是應(yīng)保證數(shù)據(jù)中可能影響測試的因素與未經(jīng)修改擴(kuò)充