第四章-軟件測試的執(zhí)行階段ppt課件(全)

1、軟件測試技術(shù) 第4章 軟件測試的執(zhí)行階段第四章 軟件測試的執(zhí)行階段1 單元測試2 集成測試3 系統(tǒng)測試4 驗收測試5 回歸測試2/1044.1 單元測試4.1.1 單元測試和集成測試的關(guān)系4.1.2 對于單元測試的基本認識4.1.3 單元測試的認識誤區(qū)4.1.4 單元測試的意義4.1.5 單元測試的原則4.1.6 單元測試的主要任務(wù)4.1.7 驅(qū)動模塊與樁模塊3/104.1 單元測試單元測試的定義 單元測試就是根據(jù)軟件規(guī)格說明書、詳細設(shè)計說明書、編碼規(guī)范和源程序清單，對軟件設(shè)計中的最小單元進行正確性檢驗的測試工作，主要測試軟件單元在語法、格式和邏輯上的錯誤。 單元測試是軟件測試的第一個執(zhí)行階段

2、，是軟件測試的基礎(chǔ)。能否做好單元測試直接影響到后續(xù)測試階段，并且最終影響到軟件的整體質(zhì)量。4/102.1.1 單元測試和集成測試的關(guān)系 軟件測試的根本目的是為了保證軟件系統(tǒng)的整體質(zhì)量，軟件質(zhì)量控制的步驟與環(huán)節(jié)很大程度上借鑒了傳統(tǒng)工業(yè)制造領(lǐng)域的經(jīng)驗。一個工業(yè)制成品經(jīng)常由成百上千個零件構(gòu)成，圖4-1描述了汽車的主要零件構(gòu)成。圖4-1 汽車的零件構(gòu)成5/104.1.1 單元測試和集成測試的關(guān)系單元測試和集成測試之間的不同：（1）測試目的不同。（2）測試對象不同。（3）測試的起始時間不同。（4）測試方法不同。（5）測試依據(jù)不同。（6）測試能力不同。6/104.1.2 對于單元測試的基本認識（1）什么是

3、軟件單元 軟件單元的界定與劃分與具體的軟件形式有關(guān)，同時也與軟件開發(fā)過程所采用的具體技術(shù)有關(guān)，需要根據(jù)具體情況去判定單元的含義。7/104.1.2 對于單元測試的基本認識（2）如何選擇軟件單元進行單元選擇的依據(jù)主要是：單元具有明確的獨立性。被測單元需要符合“高內(nèi)聚、低耦合”的要求，有明確的可定義的邊界或者接口。單元必須是可測的。這就要求被測單元的行為和輸出是可以觀測的。要選擇好被測軟件單元的大小。8/104.1.2 對于單元測試的基本認識（3）什么時候開始單元測試 單元測試越早進行越好。通常在編碼完成并且已經(jīng)通過編譯后開始單元測試，單元測試之前應(yīng)當準備好單元測試計劃、單元測試用例等。（4）由誰

4、來負責單元測試 單元測試一般由開發(fā)人員自己負責完成?？梢杂砷_發(fā)人員測試自己開發(fā)的代碼，也可以在條件允許的情況下進行開發(fā)人員之間的交叉測試，以便獲得更為客觀的測試結(jié)果。9/104.1.2 對于單元測試的基本認識圖4-2 軟件單元入庫前的人員分工 如圖4-2所示，在一些管理非常細致、嚴格的軟件企業(yè)中，軟件單元在進入軟件代碼庫之前會有不同人員對其進行檢查。但是無論如何，單元測試的主要負責人都是開發(fā)者本人，測試人員負有監(jiān)督執(zhí)行和審批通過的權(quán)利。10/102.1.2 對于單元測試的基本認識（5）單元測試的依據(jù)是什么 單元測試的主要依據(jù)是軟件詳細設(shè)計說明書，也包括源程序本身的代碼和注釋。（6）如何準備單元

5、測試數(shù)據(jù) 單元測試一般不使用真實的業(yè)務(wù)數(shù)據(jù)。由于被測單元規(guī)模一般較小，根據(jù)測試經(jīng)驗手工生成的一些典型測試數(shù)據(jù)往往測試效率和測試效果更佳。11/104.1.2 對于單元測試的基本認識（7）單元測試的通過標準是什么一個較為通用的、可供參考的標準：程序通過了所有單元測試的用例，程序語句的覆蓋率達到了100%，程序分支的覆蓋率達到了85%。核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%。12/104.1.2 對于單元測試的基本認識（8）如何進行單元測試單元測試主要采用白盒測試方法，以黑盒測試方法作為輔助。通常會通過以下方法完成單元測試。靜態(tài)測試。包括檢查代碼是否符合編碼規(guī)范、算法邏輯是否正確和高效

6、、模塊接口是否正確、出錯處理是否完備、表達式和SQL語句是否正確等。通過靜態(tài)測試能夠發(fā)現(xiàn)大約30%-70%的程序邏輯和編碼錯誤。動態(tài)測試。通過設(shè)計和執(zhí)行單元測試用例，檢查軟件單元實際運行結(jié)果是否正確。代碼中大量的隱性錯誤必須通過動態(tài)跟蹤與分析才能捕捉到，因此動態(tài)測試是單元測試的重點與難點。13/104.1.2 對于單元測試的基本認識（8）如何進行單元測試狀態(tài)轉(zhuǎn)換測試。一些軟件單元（如類和組件）可能擁有多種狀態(tài)，各狀態(tài)之間的轉(zhuǎn)換由事件觸發(fā)，狀態(tài)轉(zhuǎn)換又可能引發(fā)動作。軟件單元在不同狀態(tài)之下，對于同樣的輸入會產(chǎn)生不同的輸出結(jié)果，這一點與傳統(tǒng)的軟件單元（如函數(shù)和過程）是不一樣的，增加了單元測試的難度。因

7、此，應(yīng)當對單元可能存在的狀態(tài)、狀態(tài)間轉(zhuǎn)換、狀態(tài)轉(zhuǎn)換后所期望的動作進行測試。通常采用狀態(tài)轉(zhuǎn)換圖來輔助測試用例的設(shè)計。每個測試用例必須包括單元起始狀態(tài)、輸入、預期輸出和轉(zhuǎn)換后的期望狀態(tài)。狀態(tài)轉(zhuǎn)換測試采用的是黑盒測試方法。14/1044.1.3 單元測試的認識誤區(qū)認識誤區(qū)：誤區(qū)一：單元測試的價值不高，浪費的時間太多。誤區(qū)二：開發(fā)人員的職責只是軟件開發(fā)，不應(yīng)當負責單元測試。誤區(qū)三：我的編程水平很高，不需要單元測試。誤區(qū)四：集成測試時會發(fā)現(xiàn)所有軟件單元中的Bug。誤區(qū)五：業(yè)務(wù)邏輯簡單，不值得編寫單元測試。15/1044.1.3 單元測試的認識誤區(qū)除了上述認識誤區(qū)外，項目管理問題也是實際開發(fā)工作中不能充分

8、完成單元測試的一個主要原因。實際工作中經(jīng)常出現(xiàn)以下兩種情況：為了完成編碼任務(wù)，沒有足夠的時間進行單元測試。如果進行完備的單元測試會導致不能按時完成開發(fā)任務(wù)，造成項目延期。項目前期還能夠盡量進行單元測試，但是越到項目后期就越失控。16/1044.1.3 單元測試的認識誤區(qū) 產(chǎn)生上述現(xiàn)象的原因只能說是項目管理不夠正規(guī)和嚴格，并不能作為開發(fā)人員不編寫單元測試的理由。如果開發(fā)人員不能養(yǎng)成編寫單元測試的良好習慣，其編寫的代碼質(zhì)量必定無法得到有效控制。 在敏捷開發(fā)和極限編程開發(fā)方法中，測試驅(qū)動開發(fā)（TDD，Test-Driven Development）已經(jīng)成為核心實踐內(nèi)容。在開發(fā)功能代碼之前，先編寫單元

9、測試用例代碼，然后由測試代碼來決定需要編寫什么產(chǎn)品代碼，從而驅(qū)動整個開發(fā)過程的進行。單元測試的重要性由此可見一斑。17/1044.1.4 單元測試的意義單元測試的意義：（1）產(chǎn)品質(zhì)量方面（2）成本控制方面（3）測試效率方面（4）測試效果方面（5）綜合測試能力方面18/1044.1.5 單元測試的原則 根據(jù)阿里技術(shù)的實踐總結(jié)，良好的單元測試需要遵守AIR原則：A：Automatic（自動化）。單元測試應(yīng)當是非交互式自動執(zhí)行的，大型復雜軟件項目開發(fā)通常定期執(zhí)行測試框架，項目開發(fā)往往采用持續(xù)集成的方式進行，因此要求單元測試過程高度自動化，測試輸出結(jié)果不依賴人工檢查。I：Independent（獨立性

10、）。為了保證單元測試結(jié)果穩(wěn)定可靠，測試用例便于維護，需要保持單元測試的獨立性。單元測試用例之間決不能互相調(diào)用，必須要做到用例間完全解耦，沒有任何的依賴，也不能依賴用例執(zhí)行的先后次序。R：Repeatable（可重復）。單元測試應(yīng)當是可重復進行的，不能受外部環(huán)境的影響。當軟件進行持續(xù)集成時，程序代碼改變后都會執(zhí)行單元測試。如果單元測試依賴外部環(huán)境，例如網(wǎng)絡(luò)、服務(wù)、中間件等，容易導致無法完成持續(xù)集成。19/1044.1.5 單元測試的原則 除此之外，在工程實踐中，還有如下一些單元測試原則可供參考。在設(shè)計評審階段，開發(fā)人員應(yīng)當和測試人員一起確定單元測試的范圍。一個完整的單元測試既應(yīng)當包含正面測試也應(yīng)

11、當包含負面測試。正面測試驗證程序應(yīng)當執(zhí)行的工作，而負面測試驗證程序不應(yīng)當執(zhí)行的工作。對于新增代碼應(yīng)當及時補充單元測試。如果新增代碼影響到原有測試用例，需要及時修正。尤其對于核心模塊的增量代碼，要確保其通過單元測試。對于修改過的代碼應(yīng)當重新進行單元測試，以避免修改代碼引入新的錯誤。20/1044.1.5 單元測試的原則編寫單元測試代碼遵守 BCDE原則，以保證被測試模塊的交付質(zhì)量。Border，邊界值測試，包括循環(huán)邊界、特殊取值、特殊時間點、數(shù)據(jù)順序等。Correct，正確的輸入，并得到預期的結(jié)果。Design，與設(shè)計文檔相結(jié)合來編寫單元測試。Error，強制錯誤信息輸入，如非法數(shù)據(jù)、異常流程等

12、，并得到預期的結(jié)果。對于不可測的程序代碼建議首先對代碼進行必要的修改，使程序代碼變得可測，而不是為了達到測試要求而編寫不規(guī)范的測試代碼。為了更方便地進行單元測試，產(chǎn)品代碼應(yīng)當避免在一個構(gòu)造方法中實現(xiàn)過多的功能，控制全局變量和靜態(tài)方法的數(shù)量，減少程序外部依賴，單元中避免存在過多的條件語句。21/1044.1.6 單元測試的主要任務(wù) 單元測試是由一組獨立的測試用例構(gòu)成，每個測試用例針對一個獨立的軟件單元。單元測試并非是用于檢查軟件單元之間是否能夠良好協(xié)作，而是用于檢查單個軟件單元行為是否正確。 單元測試時，測試人員依據(jù)詳細設(shè)計說明書和源程序清單，在理解模塊的I/O條件和內(nèi)部邏輯結(jié)構(gòu)的基礎(chǔ)上，主要采

13、用白盒測試為主、黑盒測試為輔的方法，對軟件模塊任何合理和不合理的輸入進行全面驗證，檢測程序功能實現(xiàn)的正確性。為了達到上述目標，單元測試需要對程序邏輯、功能、數(shù)據(jù)和安全性等各方面進行測試。22/1044.1.6 單元測試的主要任務(wù) 如圖4-3所示，單元測試的主要任務(wù)包括5個方面的內(nèi)容。軟件模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立路徑出錯處理圖4-3 單元測試的主要任務(wù)（1）模塊接口測試（2）模塊局部數(shù)據(jù)結(jié)構(gòu)測試（3）模塊獨立路徑測試（4）出錯處理測試（5）邊界條件測試23/1044.1.7 驅(qū)動模塊與樁模塊 定義：驅(qū)動模塊（Driver）也稱為驅(qū)動程序，是用于模擬被測模塊的上級模塊，能夠調(diào)用被測模塊

14、。當被測模塊是底層模塊時，需要編寫驅(qū)動模塊。樁模塊（Sub）也稱為存根程序，是用于模擬程序結(jié)構(gòu)中被測模塊所調(diào)用的下級模塊。當被測模塊是上層模塊時，需要編寫樁模塊。24/1044.1.7 驅(qū)動模塊與樁模塊 軟件模塊在編寫完成，經(jīng)過編碼規(guī)范、語法檢查等靜態(tài)測試之后，就需要通過測試用例動態(tài)驗證軟件模塊的正確性。圖4-4 程序結(jié)構(gòu)圖例如，在圖4-4所示的程序結(jié)構(gòu)圖中，如果各個模塊是由不同的開發(fā)人員并行開發(fā)，開發(fā)進度自然會有所不同。假設(shè)模塊C被首先開發(fā)完成，需要對其進行單元測試。模塊C需要通過頂層模塊A的調(diào)用才能運行，并且其完整功能需要通過調(diào)用模塊E和F才能實現(xiàn)，此時模塊A、E和F還未開發(fā)完成。那么，模

15、塊C的單元測試工作該如何完成呢？25/1044.1.7 驅(qū)動模塊與樁模塊 首先，需要像圖4-5所示的那樣，編寫兩個模塊SE和SF用來代替和模擬模塊E和F，調(diào)用SE和SF的方法與調(diào)用模塊E和F的方法相同，例如函數(shù)名、傳遞的參數(shù)和返回值都相同。 然后，編寫一個模塊DA，代替和模擬模塊A。模塊DA中包含調(diào)用模塊C和接收返回結(jié)果的語句。模塊SE和SF就是樁模塊，模塊DA就是驅(qū)動模塊。這樣一來，就構(gòu)成了一個測試環(huán)境，能夠?qū)δKC進行獨立的單元測試了。 當然，驅(qū)動模塊和樁模塊僅僅是模擬相關(guān)模塊的功能，只需要實現(xiàn)必要的模擬功能。26/1044.1.7 驅(qū)動模塊與樁模塊 驅(qū)動模塊啟動被測模塊，接受測試數(shù)據(jù)，將

16、測試數(shù)據(jù)傳送給被測模塊并輸出測試用例的測試結(jié)果。樁模塊只做少量的數(shù)據(jù)處理，如簡單條件判斷和返回，模擬被測模塊所需要的調(diào)用結(jié)果即可。圖4-5 驅(qū)動模塊與樁模塊27/1044.2 集成測試4.2.1 對于集成測試的基本認識4.2.2 集成測試的原則4.2.3 集成測試與系統(tǒng)測試的區(qū)別4.2.4 集成測試的策略與模式28/1044.2.1 對于集成測試的基本認識集成測試也被稱為部件測試、組裝測試、聯(lián)合測試或子系統(tǒng)測試，主要測試組合在一起的軟件單元能否正常工作，是單元測試和系統(tǒng)測試之間的一個過渡階段。（1）集成測試的對象是什么 集成測試的對象是已經(jīng)通過了單元測試的軟件單元，更準確地說是這些軟件單元的集

17、合體。（2）集成測試的主要任務(wù)是什么模塊間的數(shù)據(jù)傳輸是否有問題，數(shù)據(jù)是否在模塊接口處丟失。這就需要測試各個模塊間能否通過接口以正確、穩(wěn)定和一致的方式進行交互。29/1044.2.1 對于集成測試的基本認識一個模塊的程序是否對其它模塊的功能產(chǎn)生了錯誤的影響。全局數(shù)據(jù)結(jié)構(gòu)是否出現(xiàn)設(shè)計和運行錯誤。由于全局數(shù)據(jù)結(jié)構(gòu)的存在，使得軟件模塊“高內(nèi)聚、低耦合”的程度降低。模塊組合在一起后，整體功能是否滿足需求和設(shè)計要求。各個模塊的誤差積累在一起之后，積累誤差達到無法接受的程度。30/1044.2.1 對于集成測試的基本認識（3）什么時候開始集成測試 從理論上來講，集成測試應(yīng)當在單元測試之后進行。但是在實際工作

18、中，單元測試和集成測試往往是同時進行的。不可能等到所有的單元測試都完成后才開始集成測試，這樣的測試效率就太低了。注意事項：由于靜態(tài)分析和動態(tài)分析技術(shù)既適用于單元測試也適用用于集成測試，只不過集成測試的重點在于模塊間接口檢查，這就造成很多國內(nèi)軟件公司經(jīng)常將集成測試劃歸單元測試，使得集成測試的起始時間變得很模糊。集成測試的計劃和設(shè)計工作實際上在系統(tǒng)結(jié)構(gòu)設(shè)計階段就已經(jīng)同步開始了，在進入詳細設(shè)計之前要盡可能完成集成測試方案。31/1044.2.1 對于集成測試的基本認識（4）由誰來負責集成測試 集成測試一般是由開發(fā)人員和測試人員共同完成的，其中開發(fā)人員所負責完成的工作通常更多一些。由于集成測試所涉及的

19、具體細節(jié)技術(shù)內(nèi)容仍然較多，因此在集成測試的前期階段，也就是集成粒度仍然比較小的階段，由開發(fā)人員或白盒測試工程師來完成測試。在系統(tǒng)級大粒度的后期集成測試階段，測試工作一般由專門的測試部門來完成。 集成測試的全程測試工作都應(yīng)當在測試人員的監(jiān)督之下完成，測試負責人要保證測試工作采用了合理可行的技術(shù)，完成了充分的集成測試，滿足了質(zhì)量控制目標。32/1044.2.1 對于集成測試的基本認識（5）集成測試的依據(jù)是什么 集成測試的主要依據(jù)是軟件概要設(shè)計說明書。集成測試與軟件開發(fā)的概要設(shè)計階段相對應(yīng)，是以概要設(shè)計所規(guī)定的系統(tǒng)軟件體系結(jié)構(gòu)作為測試用例的設(shè)計基礎(chǔ)。在軟件概要說明中，詳細描述了系統(tǒng)或子系統(tǒng)的模塊分層

20、組織結(jié)構(gòu)以及模塊間的接口，為集成測試的策略選擇提供了主要的參考依據(jù)。同時，集成測試也服務(wù)于系統(tǒng)架構(gòu)設(shè)計，可以檢驗出在系統(tǒng)軟件架構(gòu)設(shè)計中可能存在的錯誤以及不合理之處。（6）如何準備集成測試數(shù)據(jù) 集成測試主要是為了檢測構(gòu)成系統(tǒng)的各模塊之間是否能夠正確地集成在一起，在運行時是否能夠正確地交互，因此測試數(shù)據(jù)在內(nèi)容和難度上要求一般不是很高。通常由測試人員根據(jù)系統(tǒng)設(shè)計要求手工創(chuàng)建測試數(shù)據(jù)，重點是創(chuàng)建具有代表性的模塊間通信數(shù)據(jù)以驗證接口的正確性。33/1044.2.1 對于集成測試的基本認識（7）集成測試所采用的主要技術(shù)是什么 集成測試主要采用黑盒測試方法，以白盒測試方法作為輔助。但是，隨著當前軟件規(guī)模和復

21、雜度的不斷提高，大型軟件系統(tǒng)越來越多。模塊層次、數(shù)量以及交互性的增加使得系統(tǒng)邏輯結(jié)構(gòu)變得更為復雜，因此經(jīng)常會采用白盒測試方法來輔助進行集成測試。例如，利用基本路徑測試法檢查模塊集成后的系統(tǒng)流程是否正確。從這一實際情況來講，可以把集成測試歸結(jié)為灰盒測試。（8）如何劃分集成測試的測試層次 對于傳統(tǒng)軟件進行集成測試時，可以根據(jù)集成粒度將測試過程分為以下3個層次。34/1044.2.1 對于集成測試的基本認識模塊之間的集成測試。單個子系統(tǒng)中的集成測試。子系統(tǒng)之間的集成測試。對于面向?qū)ο蟮能浖到y(tǒng)進行集成測試時，同樣可以根據(jù)集成粒度將測試過程分為以下3個層次。單個類中的集成測試。具有關(guān)聯(lián)性的類間集成測試

22、。構(gòu)成一個組件的組件內(nèi)類簇集成測試。 需要注意的是，集成測試具有可迭代性。軟件開發(fā)以迭代的模式進行是一種常見情況，開發(fā)過程的迭代會直接驅(qū)動集成測試過程同樣以迭代方式進行。這種情況下，集成測試工作會按照測試層次反復進行。35/1044.2.1 對于集成測試的基本認識（9）集成測試的通過標準是什么 一個軟件項目的集成測試通過標準必須在軟件測試計劃中明確說明。不同軟件企業(yè)的集成測試通過標準會有所不同，但是都離不開功能覆蓋率和接口覆蓋率這兩個指標。功能覆蓋中最主要的就是對于軟件需求的覆蓋，需要通過設(shè)計合適數(shù)量的集成測試用例，使得所有的功能需求點都能夠被測試到。相比于功能覆蓋率，接口覆蓋率對于集成測試更

23、為重要，是集成測試需要達到的主要測試指標，要求盡可能達到100%的接口覆蓋率，使得軟件系統(tǒng)中的每個接口都能夠被測試到。36/1044.2.2 集成測試的原則良好的集成測試應(yīng)當遵循以下一些原則：集成測試應(yīng)當以概要設(shè)計為基礎(chǔ)，盡早計劃、設(shè)計與實施。對于概要設(shè)計中有關(guān)模塊和接口的劃分，測試和開發(fā)人員需要充分理解溝通。在選擇集成測試策略時要以工程化思維，綜合考慮測試質(zhì)量、進度和成本。集成測試用例必須經(jīng)過正規(guī)審核。集成測試必須根據(jù)集成測試計劃和設(shè)計進行，要避免隨意性。37/1044.2.2 集成測試的原則良好的集成測試應(yīng)當遵循以下一些原則：集成測試應(yīng)當按一定的層次進行。對于關(guān)鍵模塊和包含I/O的模塊要盡

24、早進行充分的測試。所有的模塊公共接口都必須被測試到。當模塊接口被修改后，接口所涉及的所有模塊要重新進行集成測試。應(yīng)當如實記錄測試用例的執(zhí)行結(jié)果。當滿足了測試計劃中所規(guī)定的結(jié)束標準時，集成測試才能結(jié)束。38/1044.2.3集成測試與系統(tǒng)測試的區(qū)別集成測試和系統(tǒng)測試的主要區(qū)別：測試的起始時間不同。測試的對象不同。測試主要任務(wù)不同。測試方法不同。測試依據(jù)不同。測試角度不同。測試用例的粒度不同。測試用例的數(shù)量不同。39/1044.2.4集成測試的策略與模式 集成測試的策略有很多，如大爆炸集成、自頂向下集成、自底向上集成、三明治集成、基干集成、核心集成、層次集成、高頻集成、基于功能的集成、基于進度的集

25、成、基于風險的集成、基于消息事件的集成、基于使用的集成、客戶/服務(wù)器集成、分布式集成等等。而集成模式是集成策略的具體體現(xiàn)，是成功集成經(jīng)驗的總結(jié)?？梢哉f，集成模式的選擇是集成測試中最為關(guān)鍵的環(huán)節(jié)，直接影響到集成測試的充分性與效率。40/1044.2.4 集成測試的策略與模式集成測試模式：（1）非漸增式集成測試模式與漸增式集成測試模式非漸增式集成測試模式。就是首先對每一個模塊進行單元測試，然后根據(jù)程序設(shè)計結(jié)構(gòu)，將所有模塊一次性集成在一起進行集成測試。漸增式集成測試模式。與一步到位式的非漸增式集成模式相反，漸增式集成模式采用逐步集成的方式，把單元測試和集成測試結(jié)合起來進行，將被測模塊逐步與已經(jīng)測試好

26、的模塊結(jié)合在一起進行測試。41/1044.2.4 集成測試的策略與模式 非漸增式集成測試模式也稱為大爆炸集成（Big Bang Integration）、大棒模式、一次性集成、瞬時集成，是將所有模塊一次性連接起來，將連接后的程序做為一個整體來測試。 圖4-6是一個非漸增式集成測試模式的示例。圖4-6（a）是被測程序的結(jié)構(gòu)圖，圖4-6（b）至圖4-6（g）是測試過程。分別為各模塊配備相應(yīng)的驅(qū)動模塊和樁模塊完成單元測試，然后將各模塊按程序結(jié)構(gòu)圖連接在一起進行集成測試。42/1044.2.4 集成測試的策略與模式圖4-6 非漸增式集成測試模式示例圖43/1044.2.4集成測試的策略與模式 非漸增式

27、集成測試模式的優(yōu)缺點：優(yōu)點：適合于比較小的軟件項目，能夠快速完成集成測試并且所需要的測試用例很少。對于被測系統(tǒng)已經(jīng)很穩(wěn)定，只加入或修改了少數(shù)模塊的情況，也可以考慮采用這種模式。缺點：對于一般的中、大型軟件系統(tǒng)，一次性集成涉及的模塊過多，使得錯誤的定位變得非常困難。修改一個錯誤后，由于模塊之間的關(guān)系比較復雜，可能會引發(fā)更多的錯誤。 如果系統(tǒng)中存在很多接口錯誤，這種模式下的集成測試很容易失敗。因此，對于大中型軟件一般不采用非漸增式集成測試模式。44/1044.2.4集成測試的策略與模式 漸增式集成測試模式是普遍采用的模式。在這種模式下，通過模塊集成逐步構(gòu)建完整的程序，邊構(gòu)建邊測試。這一過程中，發(fā)現(xiàn)

28、的錯誤主要由新增模塊所引起，因此能夠及時發(fā)現(xiàn)錯誤，比較容易地定位和改正錯誤，對模塊接口的測試也更為徹底。而且，在逐步集成的過程中，已集成模塊被進行了多次檢驗，因此可以取得更好的測試效果。但是，漸增式集成測試需要編寫大量的驅(qū)動程序和樁程序，工作量比較大。 總的來講，漸增式集成測試還是要比非漸增式集成測試更能保障程序的質(zhì)量。45/1044.2.4 集成測試的策略與模式 自頂向下的集成測試是按照軟件模塊在設(shè)計中的層次結(jié)構(gòu)，從上到下逐步進行集成和測試。先從最上層的主控模塊開始，軟后沿著軟件的模塊層次向下移動，逐步將軟件所包含的模塊集成在一起。這種測試模式又分為深度優(yōu)先和廣度優(yōu)先兩種集成策略，例如按照圖

29、4-6（a）的程序結(jié)構(gòu)圖進行集成時，深度優(yōu)先的模塊集成順序為ABDCEF，廣度優(yōu)先的模塊集成順序為ABCDEF。46/1044.2.4集成測試的策略與模式具體的集成測試過程包括的一些步驟： 首先完成對主控模塊的測試，用樁模塊代替主控模塊所調(diào)用的下層模塊。 根據(jù)深度優(yōu)先或者是廣度優(yōu)先策略，每次用一個實際模塊替換一個樁模塊。如果新增模塊具有下層調(diào)用模塊，則用樁模塊代替這些被調(diào)用模塊。 每增加一個模塊的同時都要進行測試。 進行必要的回歸測試以保證增加的模塊沒有引起新的錯誤。 從步驟開始重復進行，直到所有的模塊都被集成到系統(tǒng)中。47/1044.2.4集成測試的策略與模式 以圖4-6（a）的程序結(jié)構(gòu)為例

30、，圖4-7給出了按照深度優(yōu)先方式進行自頂向下集成測試的示例。圖4-7 深度優(yōu)先的自頂向下集成測試示例48/1044.2.4 集成測試的策略與模式自頂向下法的主要優(yōu)點是：一般不需要開發(fā)驅(qū)動程序，只需要開發(fā)樁程序。由于上層模塊更多地體現(xiàn)了系統(tǒng)的主要功能和控制邏輯，因此能夠在測試中較早地驗證這些主要功能和發(fā)現(xiàn)接口錯誤。因此，有利于從系統(tǒng)全局角度抓住測試重點，對系統(tǒng)功能進行比較全面的測試，同時也便于控制測試進度。如果采用深度優(yōu)先策略，能夠在早期實現(xiàn)系統(tǒng)的一些完整功能，增強開發(fā)人員和用戶的信心。底層接口未做充分定義或者修改的可能性較大時，可以避免過早地提交不穩(wěn)定的接口，進而避免了對測試進度造成影響。49

31、/1044.2.4 集成測試的策略與模式自頂向下法的主要缺點是：需要開發(fā)大量的樁程序，測試工作量較大。由于越往下層模塊的數(shù)量越多，通常樁程序的數(shù)量會明顯多于驅(qū)動程序的數(shù)量。在測試開始時涉及的模塊較少，無法做到并行測試，影響了測試效率。底層模塊中的錯誤發(fā)現(xiàn)得較晚。完全依賴樁程序會給測試造成一定的困難。50/1044.2.4 集成測試的策略與模式（3）自底向上的集成測試 自底向上的方法與自頂向下的方法正好相反，是從軟件結(jié)構(gòu)的最底層模塊開始，自下而上地逐步完成模塊的集成和測試工作。由于下層模塊的實際功能都已開發(fā)完成，因此在集成過程中就不需要開發(fā)樁模塊了，只需要開發(fā)相應(yīng)的上層驅(qū)動模塊即可。 圖4-8是

32、一個簡單的自底向上集成測試示例。在軟件的程序結(jié)構(gòu)中，從下往上自然會形成一些如圖4-8（a）所示的功能族，它們代表了程序的子功能。51/1044.2.4 集成測試的策略與模式（3）自底向上的集成測試 自底向上集成測試時，通常根據(jù)功能族的劃分對模塊逐步進行集成，形成不同粒度的功能族并進行測試。然后通過合并已測試過的功能族，逐漸擴大功能族的粒度以反映系統(tǒng)的主要功能。圖4-8 自底向上集成測試示例52/1044.2.4 集成測試的策略與模式具體的自底向上集成測試過程包括以下一些步驟： 將底層模塊組合成實現(xiàn)某一特定系統(tǒng)子功能的功能族。 編寫一個驅(qū)動程序，能夠調(diào)用已組合的模塊，并協(xié)調(diào)測試數(shù)據(jù)的輸入與輸出。

33、 對組合模塊構(gòu)成的子功能族進行測試。 去掉驅(qū)動程序，沿著軟件結(jié)構(gòu)從下往上移動，將已測試過的子功能族組合在一起，形成更大粒度的子功能族。 從步驟開始重復進行，直到所有的模塊都被集成到系統(tǒng)中。53/1044.2.4 集成測試的策略與模式自底向上法的優(yōu)缺點可以說與自頂向下法正好相反，其主要優(yōu)點是：不需要開發(fā)樁程序而只需要開發(fā)驅(qū)動程序，一般來說驅(qū)動程序比較容易開發(fā)?？梢栽跍y試早期完成對軟件基礎(chǔ)功能的測試，為測試高層功能奠定了基礎(chǔ)。便于按照功能族的劃分展開并行測試，大大提高了測試的效率，縮短了測試周期。54/1044.2.4 集成測試的策略與模式自底向上法的主要缺點是：起到控制作用的上層關(guān)鍵模塊在測試后

34、期才能被測試到，而且越往上層的模塊對系統(tǒng)的影響越大，反而被測試到的時間越晚。如果發(fā)現(xiàn)高層模塊中的問題，牽扯面可能會很大，缺陷修復會比較困難，存在一定的測試風險。需要等到最后一個頂層模塊被集成以后才能看到整個系統(tǒng)的框架。只有到測試過程的后期才能發(fā)現(xiàn)時序問題和資源競爭問題。55/1044.2.4 集成測試的策略與模式（4）混合集成測試 混合集成測試又稱為三明治集成測試，是將自頂向下和自底向上兩種方法的優(yōu)點綜合在一起，并且盡可能克服了兩種方法的缺點。 測試中，對于上層模塊采用自頂向下的集成方法，而對于下層模塊采用自底向上的集成方法。 在實際工作中，由于混合集成方法的測試效率很高，因而被廣泛采用。56

35、/1044.2.4 集成測試的策略與模式混合集成測試包括以下一些基本步驟： 確定軟件結(jié)構(gòu)的某一層為中間層。 以中間層作為分界，其上層采用自頂向下集成方法。 對中間層及其下層采用自底向上集成方法，中間層模塊與相應(yīng)的下層模塊集成。 對集成后的系統(tǒng)進行整體測試。57/1044.2.4 集成測試的策略與模式圖4-9給出了一個簡單的混合集成測試過程示例。圖4-9 混合集成測試示例58/1044.2.4 集成測試的策略與模式 在混合集成過程中應(yīng)當靈活應(yīng)用集成策略，盡可能減少開發(fā)驅(qū)動程序和樁程序的工作量。例如，在圖4-8的示例中，模塊C與其下層模塊先進行集成的好處是，只需要開發(fā)一個驅(qū)動模塊模擬模塊A調(diào)用模塊

36、C。如果模塊C先同上層模塊集成則需要開發(fā)兩個樁模塊分別模擬模塊F和模塊G，增加了測試開發(fā)的工作量。 基本的混合集成測試存在著一個缺點，在集成過程中某些模塊并沒有經(jīng)過完整的單元測試。因此存在一種改進的混合集成測試方法，在基本混合集成的基礎(chǔ)上，保證對每一個模塊都進行了徹底的單元測試。圖4-10給出了這種改進后的混合集成測試方法的示例。59/1044.2.4 集成測試的策略與模式圖4-10 改進的混合集成測試示例60/1044.2.4 集成測試的策略與模式混合集成測試方法的主要優(yōu)點是：能盡早發(fā)現(xiàn)錯誤。混合集成采用了持續(xù)集成測試策略，將并行開發(fā)過程中不同時間完成的模塊盡可能早地集成起來，以便于及時發(fā)現(xiàn)

37、錯誤和改正錯誤。測試效率高?；旌霞刹捎昧藦纳舷聝啥送瑫r推進的集成方法，已經(jīng)測試完的模塊可以作為后期模塊的驅(qū)動程序或者是樁程序，大大減少了開發(fā)驅(qū)動程序和樁程序的工作量，這也正是混合模式受到廣泛歡迎的一個重要原因。混合集成測試方法的主要缺點是：很多模塊實際上處于同步集成過程中，一定程度上增加了定位缺陷的難度。自頂向下和自底向上兩種方法的綜合運用給集成測試的計劃與控制帶來了一定的復雜性和難度。61/1044.2.4 集成測試的策略與模式（5）幾種基本集成測試模式的比較 非漸增式一次性集成、自頂向下集成、自底向上集成、混合集成和改進的混合集成都屬于基本的集成測試模式，表4-1對上述方法的優(yōu)缺點進行了

38、綜合對比。表4-1 幾種基本集成測試模式的比較名稱一次性集成自頂向下自底向上混合集成改進的混合集成集成晚早早早早基本程序可工作時間晚早晚早早需要驅(qū)動程序是否是是是需要樁程序是是否是是工作并行性高低中中高特殊路徑測試容易難容易中等容易計劃與控制容易難容易難難62/1044.2.4 集成測試的策略與模式（6）核心系統(tǒng)先行集成測試 一些軟件系統(tǒng)在組成方式上由核心系統(tǒng)和一些外圍系統(tǒng)或者說輔助系統(tǒng)構(gòu)成，如果將這樣的系統(tǒng)比喻為一臺復雜精密的機器，那么核心系統(tǒng)就是這臺機器的大腦，其重要性不言而喻。同樣的道理，從構(gòu)成某一系統(tǒng)子功能的模塊來看，某一或某幾個模塊往往是這些模塊中的關(guān)鍵模塊。63/1044.2.4

39、集成測試的策略與模式（6）核心系統(tǒng)先行集成測試 核心系統(tǒng)和關(guān)鍵性模塊的特征：與大部分系統(tǒng)或模塊相關(guān)聯(lián)。如果有問題，則整個系統(tǒng)或子系統(tǒng)無法正常運行。對應(yīng)于多項最重要的系統(tǒng)需求。邏輯結(jié)構(gòu)或功能復雜、易出錯。具有重要的控制功能。有著特殊的性能要求，如實時性的業(yè)務(wù)處理速度。64/1044.2.4 集成測試的策略與模式（6）核心系統(tǒng)先行集成測試 很多系統(tǒng)被設(shè)計為以核心系統(tǒng)為中心的軟件架構(gòu)，輔助功能被盡可能地剝離到外圍系統(tǒng)中去，只留下一個小而精的核心系統(tǒng)處理核心業(yè)務(wù)，即所謂的“瘦核心，胖外圍”。業(yè)務(wù)流程開始于外圍系統(tǒng)，匯總到核心系統(tǒng)完成最重要的處理，再將結(jié)果反饋給外圍系統(tǒng)。這樣的架構(gòu)具有如下一些優(yōu)勢。 6

40、5/1044.2.4 集成測試的策略與模式（6）核心系統(tǒng)先行集成測試 以核心系統(tǒng)為中心的軟件架構(gòu)的優(yōu)勢：能夠快速適應(yīng)需求變化。需求變化時只是增加或修改外圍功能，核心系統(tǒng)的基礎(chǔ)功能很少變化，大幅降低了系統(tǒng)維護成本。核心系統(tǒng)或核心模塊可以由高級開發(fā)人員或?qū)ｉT的團隊開發(fā)，能夠更好地滿足技術(shù)先進性、系統(tǒng)可靠性、安全穩(wěn)定性和技術(shù)保密性等要求。66/1044.2.4 集成測試的策略與模式（6）核心系統(tǒng)先行集成測試 核心系統(tǒng)先行集成測試方法主要包括以下步驟： 完成核心系統(tǒng)中每個模塊的單元測試。 完成核心系統(tǒng)的集成構(gòu)造與測試。 根據(jù)系統(tǒng)的體系結(jié)構(gòu)設(shè)計和外圍軟件部件的重要程度，制定外圍軟件部件與核心系統(tǒng)的集成順

41、序方案，并且對制定的方案進行評審。 在集成外圍軟件部件前，首先完成對外圍軟件部件的內(nèi)部集成測試。 根據(jù)集成計劃逐步集成外圍軟件部件并進行測試，形成最終的軟件系統(tǒng)。67/1044.2.4 集成測試的策略與模式（7）持續(xù)集成測試 持續(xù)集成（Continuous Integration）簡稱CI。敏捷開發(fā)方法的創(chuàng)始人之一Martin Fowler對什么是持續(xù)集成給出了以下說明。 68/104圖4-11 Martin Fowler4.2.4集成測試的策略與模式（7）持續(xù)集成測試 持續(xù)集成是一種軟件開發(fā)實踐，它倡導開發(fā)團隊的成員經(jīng)常性地集成他們的工作，通常每人每天至少集成一次。因而對于整個軟件項目來講，

42、每天都會有許多各種各樣的集成。每次集成都需要通過自動化的構(gòu)建與測試來進行驗證，從而盡可能快速地發(fā)現(xiàn)集成錯誤。大量的開發(fā)實踐證明，這種方法能大大減少集成問題，并且使開發(fā)團隊能夠更為快速地開發(fā)具有內(nèi)聚性的軟件。69/1044.2.4集成測試的策略與模式圖4-12 持續(xù)集成測試的過程70/1044.2.4集成測試的策略與模式 持續(xù)集成過程中，新開發(fā)的代碼會頻繁地與主干程序集成在一起。所有項目的代碼都托管在源程序版本控制服務(wù)器上，如CVS（Concurrent Versions System）、SVN（Subversion）服務(wù)器。只有在本地電腦通過了單元測試的代碼才能上傳到源程序服務(wù)器，以減少后期集

43、成測試的問題。由于需要長時期、高頻率地完成集成測試，因此持續(xù)集成測試工作需要通過測試工具自動執(zhí)行，如持續(xù)集成測試工具Jenkins。CI服務(wù)器服務(wù)器會不斷查詢版本控制庫的變更，如果發(fā)現(xiàn)了變更則檢出變更代碼，執(zhí)行構(gòu)建腳本。71/1044.2.4 集成測試的策略與模式從持續(xù)集成過程可以看出，持續(xù)集成具有以下特點：它是一個自動化的周期性的集成測試過程，從檢出新代碼、編譯構(gòu)建程序、執(zhí)行測試、記錄測試結(jié)果、測試統(tǒng)計分析、通知測試結(jié)果等都是自動完成的，人工的方法是不勝任的。需要在規(guī)定的時間周期內(nèi)，能夠持續(xù)獲得新的、已通過測試的增量程序。測試與開發(fā)工作并行進行。需要有源程序版本控制系統(tǒng)的支持，以便于保障代碼

44、的版本一致性，同時作為程序集成構(gòu)建的素材庫。需要專門的集成測試服務(wù)器來執(zhí)行測試。72/1044.2.4 集成測試的策略與模式 持續(xù)集成的目的就是為了適應(yīng)大型復雜系統(tǒng)的快速迭代開發(fā)和多人并行開發(fā)，使開發(fā)團隊能夠直觀地看到軟件項目的有效進度，同時還能保持很高的開發(fā)質(zhì)量。它的核心措施是，新代碼集成到主干程序之前，必須通過自動化的集成測試。只要有一個測試用例執(zhí)行失敗，就不能集成。Martin Fowler曾經(jīng)指出：“持續(xù)集成并不能消除Bug，而是讓它們能夠非常容易地被發(fā)現(xiàn)和改正。73/1044.2.4 集成測試的策略與模式因此持續(xù)集成具有以下主要優(yōu)點：能夠以最快的速度及時發(fā)現(xiàn)新開發(fā)代碼中的問題，然后盡

45、早予以解決，避免了程序問題的大量積累。因此，能夠保證以較快的速度發(fā)布高質(zhì)量的軟件。集成測試過程自動完成，無需過多的人工干預，能夠有效減少重復測試過程，節(jié)省了時間、費用和工作量。支持復雜系統(tǒng)的快速迭代開發(fā)。能夠盡早看到系統(tǒng)級的開發(fā)成果，增強了開發(fā)團隊的信心。支持任何時間、任何地點生成可部署的軟件。提高了對開發(fā)進度的控制能力。及時的問題反饋使得項目負責人能夠更為準確地了解實際項目進度，因此整個開發(fā)進度更加有保障。74/1044.2.4 集成測試的策略與模式應(yīng)用持續(xù)集成方法時，需要遵守以下一些主要原則：開發(fā)人員需要及時向版本控制庫中提交最新代碼，提交前先要完成代碼本地測試。同步開發(fā)與頻繁的版本更新要

46、求開發(fā)人員必須經(jīng)常性地從版本控制庫中更新最新的代碼到本地，以保證代碼版本的一致性，同時可以防止工作中的分支偏離主干程序太多。需要有專門的集成服務(wù)器來執(zhí)行集成構(gòu)建。根據(jù)項目的具體實際情況，可以通過檢測代碼的修改情況來直接觸發(fā)集成構(gòu)建活動，也可以將集成構(gòu)建活動設(shè)定為定時啟動，按一定的時間周期執(zhí)行集成構(gòu)建。75/1044.2.4 集成測試的策略與模式應(yīng)用持續(xù)集成方法時，需要遵守以下一些主要原則：每次集成構(gòu)建都必須成功。如果構(gòu)建失敗，修改構(gòu)建錯誤的工作應(yīng)當是優(yōu)先級最高的工作。一旦修改完成，需要手動啟動一次構(gòu)建任務(wù)。不要拉取構(gòu)建失敗的代碼到本地，避免污染本地代碼。76/1044.3 系統(tǒng)測試4.3.1

47、什么是系統(tǒng)測試4.3.2 系統(tǒng)測試的內(nèi)容4.3.3 系統(tǒng)測試人員4.3.4 系統(tǒng)測試所采用的技術(shù)與數(shù)據(jù)4.3.5 系統(tǒng)測試前的準備工作77/1044.3.1 什么是系統(tǒng)測試系統(tǒng)測試是將經(jīng)過集成測試之后的軟件系統(tǒng)與計算機硬件、輸入輸出設(shè)備、所需要的其它支撐軟件、必須的初始化業(yè)務(wù)數(shù)據(jù)等系統(tǒng)運行必備元素組合在一起，然后對用戶實際運行環(huán)境下的完整計算機系統(tǒng)進行測試。系統(tǒng)測試的目的在于通過檢驗軟件系統(tǒng)各項功能是否正確，以及檢驗軟件系統(tǒng)在性能、安全性、可靠性等非功能特性上的表現(xiàn)是否滿足要求，從而驗證軟件系統(tǒng)與系統(tǒng)的需求定義是否完全一致。78/1044.3.1 什么是系統(tǒng)測試正確理解系統(tǒng)測試需要注意其定義中

48、隱含的兩個含義。系統(tǒng)測試并不只是局限于找出軟件程序中的錯誤，而是為了發(fā)現(xiàn)軟硬件整體系統(tǒng)與需求定義是否存在不符合或矛盾之處。如果沒有一組書面的、可度量的系統(tǒng)目標，系統(tǒng)測試是無法進行的。79/1044.3.2 系統(tǒng)測試的內(nèi)容 系統(tǒng)測試包括很多測試項目。例如：功能測試、用戶界面UI測試、性能測試、壓力測試、容量測試、安全性測試、兼容性測試、安裝與卸載測試、可用性測試、健壯性測試、文檔測試、穩(wěn)定性測試、配置測試、異常故障測試、網(wǎng)絡(luò)測試、在線幫助測試、備份測試等等。80/1044.3.3 系統(tǒng)測試人員測試人員構(gòu)成：獨立測試部門中的專職測試人員。與項目用戶直接溝通，熟悉用戶需求的主要市場人員。部分需求分析

49、、設(shè)計和開發(fā)人員。在業(yè)務(wù)上與本項目密切相關(guān)的其它項目的開發(fā)人員。企業(yè)中負責質(zhì)量體系管理的質(zhì)量保證人員。81/1044.3.4系統(tǒng)測試所采用的技術(shù)與數(shù)據(jù)為滿足測試數(shù)據(jù)的要求，可以采用以下兩種方法。第一種方法是直接采用真實的業(yè)務(wù)數(shù)據(jù)。在用戶授權(quán)許可的情況下，或者是前期項目保留有系統(tǒng)真實數(shù)據(jù)的情況下，可以直接使用這些數(shù)據(jù)完成測試任務(wù)。這種方法的好處是系統(tǒng)測試和后續(xù)的驗收測試在測試數(shù)據(jù)上是相同的，不必擔心兩個階段測試數(shù)據(jù)不同會造成測試結(jié)果不一致的問題，降低了后續(xù)驗收測試的風險，同時也增強了對系統(tǒng)測試結(jié)果的信心。這種方法的缺點。用戶的真實業(yè)務(wù)數(shù)據(jù)受使用習慣和使用周期等因素影響，有時并不能充分暴露系統(tǒng)的一

50、些偶然性和深層次問題，仍然需要根據(jù)系統(tǒng)特點和測試經(jīng)驗手工制作一些有針對性的測試數(shù)據(jù)，以便于完成對系統(tǒng)的充分測試。82/1044.3.4系統(tǒng)測試所采用的技術(shù)與數(shù)據(jù)第二種方法是使用真實數(shù)據(jù)的一個復本。出于對數(shù)據(jù)安全性、保密性以及真實數(shù)據(jù)存在較大應(yīng)用風險等情況的考慮，系統(tǒng)測試可能無法使用真實數(shù)據(jù)進行測試。這種情況下可以使用真實數(shù)據(jù)的一個復本，所謂復本數(shù)據(jù)是在數(shù)據(jù)規(guī)模、復雜性、業(yè)務(wù)特征等方面能夠全面模擬和代表真實數(shù)據(jù)的測試數(shù)據(jù)。復本數(shù)據(jù)也可以由去除了安全性等敏感數(shù)據(jù)的真實數(shù)據(jù)構(gòu)成，替代這些敏感數(shù)據(jù)的模擬數(shù)據(jù)必須具備充分的代表性。這種方法的難點是，需要對用戶目標業(yè)務(wù)足夠熟悉，這樣才能生成具有代表性的測試

51、數(shù)據(jù)。83/1044.3.5 系統(tǒng)測試前的準備工作在系統(tǒng)測試前一般需要做好如下準備工作：認真閱讀和理解軟件需求規(guī)格說明書，將其作為系統(tǒng)測試的主要依據(jù)。收集各種支撐軟件、外圍硬件的技術(shù)說明書，作為系統(tǒng)測試的參考。明確系統(tǒng)所需具備的各項功能。明確與系統(tǒng)性能有關(guān)的各項技術(shù)指標，如吞吐量、響應(yīng)時間、傳輸速率等。明確對系統(tǒng)備份與修復有關(guān)的技術(shù)要求。明確對系統(tǒng)軟硬件運行環(huán)境的兼容性要求。84/1044.3.5 系統(tǒng)測試前的準備工作在系統(tǒng)測試前一般需要做好如下準備工作：明確對系統(tǒng)配置的要求。確定對系統(tǒng)安全性相關(guān)的具體要求。在理解上述具體需求的基礎(chǔ)上，制定詳細的系統(tǒng)測試計劃，確定具體的測試內(nèi)容、測試范圍、測試

52、技術(shù)和測試通過標準等。根據(jù)需求說明和測試計劃，收集和制作測試數(shù)據(jù)，設(shè)計系統(tǒng)測試用例。搭建好盡可能接近用戶真實使用環(huán)境的軟硬件系統(tǒng)測試環(huán)境，并且準備好完成規(guī)定測試項目的各類測試工具。85/1044.4 驗收測試4.4.1 對于驗收測試的基本認識4.4.2 驗收測試的主要內(nèi)容4.4.3 驗收測試的注意事項4.4.4 測試與測試4.4.5 四種主要測試執(zhí)行階段的簡要對比86/1044.4.1 對于驗收測試的基本認識（1）什么是驗收測試（2）驗收測試人員（3）驗收測試的依據(jù)（4）驗收測試的數(shù)據(jù)（5）驗收測試的主要技術(shù)87/1044.4.2 驗收測試的主要內(nèi)容 驗收測試總的來講可以分為兩大部分：軟件配置

53、審查和軟件有效性測試。1、軟件配置審查常見的軟件配置項目包括以下內(nèi)容：（1）主要的軟件程序類配置，一般包括源程序、可執(zhí) 行程序、軟件安裝配置腳本，關(guān)鍵測試腳本或測試程序。（2）主要的技術(shù)類文檔。（3）主要的開發(fā)管理類文檔。88/1044.4.2 驗收測試的主要內(nèi)容進行軟件程序類配置檢查時，需要注意對軟件程序完成以下檢查：（1）源代碼檢查規(guī)范性檢查。數(shù)據(jù)類型檢查。外部接口檢查。（2）軟件一致性檢查編譯檢查。安裝與卸載測試。運行模塊一致性檢查。89/1044.4.2 驗收測試的主要內(nèi)容對于移交給用戶的文檔類資料，需要檢查以下內(nèi)容：完備性。規(guī)范性。針對性。完整獨立性。靈活性?？勺匪菪浴?0/1044

54、.4.2 驗收測試的主要內(nèi)容2、軟件有效性測試可執(zhí)行程序的有效性測試的測試內(nèi)容：軟件界面測試?？捎眯詼y試。功能測試，包括正常業(yè)務(wù)流程測試和錯誤處理能力測試。性能測試，包括負載、容量、壓力測試。軟件運行環(huán)境與系統(tǒng)平臺配置測試。健壯性性測試，包括各種軟硬件故障下的恢復測試?？煽啃詼y試。兼容性測試。數(shù)據(jù)備份測試。安全性測試。91/1044.4.2 驗收測試的主要內(nèi)容2、軟件有效性測試通過圖4-13可以概括性地理解驗收測試的流程與內(nèi)容：圖4-13 持續(xù)集成測試的過程92/1044.4.3 驗收測試的注意事項（1）驗收測試前需要編寫正式的驗收測試計劃，明確通過驗收測試的標準，測試通過標準應(yīng)當由用戶進行確

55、認。（2）驗收測試必須在最終用戶的實際使用環(huán)境中進行，或者盡可能模擬用戶的實際運行環(huán)境，避免環(huán)境差異導致無法發(fā)現(xiàn)軟件的一些潛在問題。（3）驗收測試覆蓋的應(yīng)當是軟件的粗粒度、業(yè)務(wù)級功能，而不是軟件的所有細節(jié)功能。驗收測試用例與軟件項目合同、軟件需求規(guī)格說明之間具有可追溯性，驗收測試用例不可能也沒有必要將開發(fā)階段進行的所有測試用例再重新運行一遍。93/1044.4.3 驗收測試的注意事項（4）驗收測試一定要面向用戶，從最終用戶實際使用中的業(yè)務(wù)場景角度出發(fā)，以用戶可以直觀感知的方式進行，使用黑盒測試方法以避免涉及過多的開發(fā)內(nèi)部細節(jié)。（5）設(shè)計驗收測試用例一定要充分考慮用戶的思維方式、使用習慣、業(yè)務(wù)語言等，根據(jù)業(yè)務(wù)主要場景來組織測試用例與測試流程。在保證測試完整性的基礎(chǔ)上，重點測試客用戶最為關(guān)心的功能點和性能點，以便于用戶對測試結(jié)果的理解和認同。（6）面向特定工作單位的項目類軟件驗收測試，一般由用戶和開發(fā)方測試部門共同完成；面向公眾、由開發(fā)方自行研發(fā)的產(chǎn)品類軟件驗收測試，應(yīng)當由測試部門、產(chǎn)品設(shè)計部門、市場部門和產(chǎn)品售后服務(wù)部門共同參與完成。94/1044.4.4 測試與測試 測試是在軟件開發(fā)方內(nèi)部進行的一種驗收測試，是在開發(fā)方人員模擬軟件實際運行環(huán)境和用戶操作行為情況下進行的受控測試。主要用于對軟件產(chǎn)品的功能、性能、可用性和可靠性等做出評價，特別是對軟件界面和易用性進行測試。測