第10章集成測試本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman2什么是集成測試？也叫做組裝測試、聯(lián)合測試、子系統(tǒng)測試和部件測試。是在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。3單元測試、集成測試與系統(tǒng)測試的差別4集成測試系統(tǒng)測試單元測試灰盒測試，采用較多黑盒方法構(gòu)造測試用例黑盒測試大量采用白盒測試方法測試方法模塊間的集成和調(diào)用關(guān)系整個系統(tǒng)，包括系統(tǒng)軟硬件等模塊內(nèi)部程序代碼對象找出與軟件設(shè)計相關(guān)的程序結(jié)構(gòu)，模塊調(diào)用關(guān)系，模塊間接口方面的問題對整個系統(tǒng)進行一系列的整體、有效性測試消除局部模塊邏輯和功能上的缺陷目的目標說明書需求說明書等程序結(jié)構(gòu)設(shè)計模塊詳細設(shè)計模塊外部說明測試依據(jù)集成測試關(guān)注的重點在把各個模塊連接起來時，穿越模塊接口的數(shù)據(jù)是否會丟失。各個子功能組合起來，能否達到預期要求的父功能。一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響。全局數(shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改單個模塊的誤差積累起來，是否會放大，從而達到不可以接受的程度。5集成測試的層次產(chǎn)品開發(fā)過程：一個分層設(shè)計和逐步細化的過程6系統(tǒng)結(jié)構(gòu)圖軟件結(jié)構(gòu)7軟件結(jié)構(gòu)圖軟件模塊結(jié)構(gòu)圖集成測試的層次集成測試可分成3個層次——集成測試都應(yīng)覆蓋：模塊內(nèi)集成測試子系統(tǒng)內(nèi)集成測試子系統(tǒng)間集成測試面向?qū)ο蟮膽?yīng)用系統(tǒng)來說，可分為2個層次：類內(nèi)集成測試類間集成測試8本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman9系統(tǒng)體系結(jié)構(gòu)設(shè)計測試系統(tǒng)體系結(jié)構(gòu)的“4+1”視圖描述：

用例視圖：用例視圖定義系統(tǒng)的外部行為。邏輯視圖：邏輯視圖描述邏輯結(jié)構(gòu)。實現(xiàn)視圖：實現(xiàn)視圖描述用于組建系統(tǒng)的物理組件。進程視圖：進程視圖描述將系統(tǒng)分解為過程和任務(wù)。部署視圖：描述系統(tǒng)的物理網(wǎng)絡(luò)布局及程序分布。系統(tǒng)體系結(jié)構(gòu)設(shè)計測試主要驗證系統(tǒng)各組件間的結(jié)構(gòu)設(shè)計是否合理，屬于模塊間接口和交互的測試范疇。10數(shù)據(jù)結(jié)構(gòu)設(shè)計測試數(shù)據(jù)結(jié)構(gòu)設(shè)計確定軟件涉及的文件系統(tǒng)的結(jié)構(gòu)以及數(shù)據(jù)庫的模式、子模式，進行數(shù)據(jù)完整性和安全性的設(shè)計。它包括以下幾個方面：確定輸入、輸出文件的詳細數(shù)據(jù)結(jié)構(gòu)；結(jié)合算法設(shè)計，確定算法所必需的邏輯數(shù)據(jù)結(jié)構(gòu)及操作；內(nèi)部模塊之間的接口數(shù)據(jù)格式設(shè)計；數(shù)據(jù)庫設(shè)計合理性，具體見數(shù)據(jù)庫專業(yè)書籍。數(shù)據(jù)結(jié)構(gòu)設(shè)計測試主要驗證數(shù)據(jù)結(jié)構(gòu)設(shè)計文檔的規(guī)范性、邏輯正確性與接口一致性。通過評審設(shè)計文檔、檢查數(shù)據(jù)模型、分析接口定義來發(fā)現(xiàn)潛在缺陷，確保設(shè)計符合需求且易于實現(xiàn)。11類圖靜態(tài)測試類圖進行靜態(tài)測試時主要關(guān)注的內(nèi)容：完整性檢查：驗證類圖中是否包含了所有必要的類，包括實體類、控制類和邊界類等。正確性驗證：確認類之間的關(guān)系是否準確表示了領(lǐng)域模型和系統(tǒng)設(shè)計。一致性檢驗：確保類圖與系統(tǒng)的需求文檔和設(shè)計文檔相一致，沒有遺漏或多余的元素。訪問控制檢查：檢查類之間的訪問權(quán)限是否合理。重用和代碼質(zhì)量：檢查類的設(shè)計是否促進了代碼的重用，例如通過繼承和接口實現(xiàn)；評估類和類之間的關(guān)系是否遵循了良好的設(shè)計原則，如單一職責原則和開閉原則。設(shè)計模式的應(yīng)用：確認類圖是否正確地實現(xiàn)了設(shè)計模式，檢查設(shè)計模式的應(yīng)用是否提高了系統(tǒng)的靈活性和可維護性。關(guān)聯(lián)和依賴檢查：驗證類之間的關(guān)聯(lián)關(guān)系（如一對一、一對多、多對多）是否正確和必要；檢查依賴關(guān)系是否合理，確保類之間的耦合度適中，不會導致過高的復雜性。抽象和具體類的平衡：評估類圖中抽象類和具體類的比例，確保它們在設(shè)計中扮演了合適的角色；檢查是否有過度使用抽象類或接口，導致設(shè)計過于復雜。12本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman13集成測試策略非增量方式先測試好每一個軟件單元，然后一次性組裝在一起再測試整個程序。增量方式逐步把下一個要被組裝的軟件單元或部件，同已測好的軟件部件結(jié)合起來測試。增量方式主要包括自頂向下、自底向上、自頂向下與自底向上相結(jié)合等方法。14大系統(tǒng)中較復雜、也是核心集成測試策略非增量方式

大爆炸（BigBang）增量方式自頂向下方法（Top-Down

）自底向上方法（Bottom-Up

）“三明治”方法（Sandwich）15大爆炸集成（BigBang）將所有系統(tǒng)組件一次性集成到被測系統(tǒng)中16d1、d2、d3、d4、d5是為單元測試時建立的驅(qū)動模塊s1、s2、s3、s4、s5是為單元測試而建立的樁模塊先測每一個思考：1）在基于Junit的單元測試中樁和驅(qū)動程序呢？集中測試中如何編寫？在哪運行？大爆炸集成（BigBang）優(yōu)點：可以迅速完成集成測試；并且只要極少數(shù)的驅(qū)動和樁模塊；用例也是最少的（為什么？）；簡單；資源利用率高缺點：一次試運行成功的可能性不大，問題定位和修改比較困難，許多接口錯誤很容易躲過測試。適應(yīng)于一個維護型項目或被測試系統(tǒng)較小17增量測試測試單獨的模塊可能需要一個特殊的驅(qū)動模塊和一個或多個樁模塊驅(qū)動模塊是為測試編寫的一個小模塊，用來將測試用例驅(qū)動或傳輸數(shù)據(jù)到被測模塊。驅(qū)動模塊還需要向測試人員顯示被測模塊的結(jié)果。樁模塊充當被測模塊調(diào)用的模塊，模擬該模塊的功能。例如測試模塊B時需要一個驅(qū)動模塊，和一個模擬模塊E的樁模塊ABDCFE非增量測試和增量測試19增量測試非增量測試使用前面測試過的模塊來取代非增量測試中所需要的驅(qū)動模塊或樁模塊。要設(shè)計驅(qū)動模塊和樁模塊可以較早發(fā)現(xiàn)模塊中與不匹配接口、不正確假設(shè)等編程錯誤。到了測試過程的最后階段，模塊之間才能“互相看到”容易進行調(diào)試，新出現(xiàn)的錯誤往往與最近添加的模塊有關(guān)直到整個程序組裝之后，模塊之間接口相關(guān)的錯誤才會浮現(xiàn)，難以定位測試可以進行地更徹底，每個模塊經(jīng)受了更多的檢驗使用驅(qū)動模塊和樁模塊而非實際模塊，對被測試模塊的測試只影響自身在測試上花費的時間多，設(shè)計驅(qū)動模塊和樁模塊所用時間少測試時間少，但設(shè)計驅(qū)動模塊和樁模塊需要大量時間并行性差可以同時并行測試很多模塊

自頂向下測試與自底向上測試自頂向下測試從最頂層模塊開始，逐漸加入下層模塊自底向上測試從最底層模塊開始，逐漸加入上層模塊ABDCFE自定向下方法從頂層控制開始，從程序的頂部模塊開始測試。再選擇后續(xù)模塊添加進來進行增量測試添加的原則是：至少一個調(diào)用該模塊的模塊事先經(jīng)過了測試。有多種可能的測試序列時，應(yīng)該考慮先測試關(guān)鍵模塊和I/O模塊為測試上層模塊，需設(shè)計樁模塊，樁模塊通常要向被測模塊提供測試數(shù)據(jù)，如讀取外部數(shù)據(jù)文件21ABDCFE集成的方式有兩種：深度優(yōu)先組裝法按縱向考慮，層次多的分支優(yōu)先測試廣度優(yōu)先組裝法從橫向考慮，總是先測試下一級的模塊ABDCFE23深度優(yōu)先組裝方式24廣度優(yōu)先組裝方式較復雜的情況圖中共有12個模塊A到L模塊I包含IO的寫操作模塊J包含IO的讀操作ACDBJIHGFLKE自頂向下的增量測試首先測試模塊A，需要設(shè)計代表模塊B,C,D的樁模塊；如圖接著用實際模塊代替樁模塊，如B，并添加B的樁模塊；如圖增量的序列有多種可能，例如：ABFJDICGEKHL，加入I后如圖AstubCstubDstubBstubFstubEBJFDstubHI自頂向下的增量測試中的樁模塊顯示跟蹤信息顯示傳遞信息返回一個值根據(jù)輸入返回一個值A(chǔ)BCD集成步驟（遍歷算法）以主模塊為所測模塊兼驅(qū)動模塊，所有直屬于主模塊的下屬模塊全部用樁模塊對主模塊進行測試采用深度優(yōu)先或廣度優(yōu)先的策略，用實際模塊替換相應(yīng)樁模塊，再用樁代替它們的直接下屬模塊，與已測試的模塊或子系統(tǒng)集成為新的子系統(tǒng)。進行回歸測試（即重新執(zhí)行以前做過的全部測試或部分測試），排除集成過程中引起錯誤的可能判斷是否所有的模塊都已集成到系統(tǒng)中，是則結(jié)束測試，否則轉(zhuǎn)到(2)去執(zhí)行。28ABDCFE自頂向下的增量測試方法特點優(yōu)點：較早地驗證了主要控制和判斷點；按深度優(yōu)先可以首先實現(xiàn)和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅(qū)動，減少驅(qū)動器開發(fā)的費用；支持故障隔離。缺點：樁的開發(fā)量大；底層驗證被推遲；底層組件測試不充分。29ABDCFE30適用范圍產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較??；底層接口未定義或經(jīng)?？赡鼙恍薷?；產(chǎn)品控制組件具有較大的技術(shù)風險，需要盡早被驗證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。ABDCFE31自底向上方法從具有最小依賴性的底層組件開始，按照依賴關(guān)系樹的結(jié)構(gòu)，逐層向上集成，以檢驗系統(tǒng)的穩(wěn)定性。選擇下一個模塊進行增量測試的原則是：該模塊調(diào)用的所有的模塊都已經(jīng)事先經(jīng)過了測試。為了測試低層模塊，需要為它們設(shè)計驅(qū)動模塊：即包含著有效的測試輸入、調(diào)用被測模塊且顯示輸出的模塊。ABDCFE集成示意圖自底向上方法33自底向上方法集成步驟（1）起始于模塊依賴關(guān)系樹的底層葉子模塊，也可以把兩個或多個葉子模塊合并到一起進行測試（2）使用驅(qū)動模塊對步驟１選定的模塊（或模塊組）進行測試（3）用實際模塊代替驅(qū)動模塊，與它已測試的直屬子模塊組裝成一個更大的模塊進行測試（4）重復上面的行為直到系統(tǒng)最頂層模塊被加入到已測系統(tǒng)中ABDCFE34自底向上方法優(yōu)缺點分析優(yōu)點：對底層組件行為較早驗證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。缺點：驅(qū)動的開發(fā)工作量大；對高層的驗證被推遲，設(shè)計上的錯誤不能被及時發(fā)現(xiàn)。ABDCFE35自底向上方法適用范圍：適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。ABDCFE自底向上的增量測試第一步測試E,J,G,K,L和I中的部分或全部模塊既可以串行也可以并行進行；需要設(shè)計驅(qū)動模塊，有的驅(qū)動模塊可以供幾個測試模塊使用ACDBJIHGFLKE自底向上的增量測試接著測試的模塊序列有多種可能如果接下來是測試較關(guān)鍵的模塊F,H，則用它們代替相應(yīng)的驅(qū)動模塊，并加入它們的驅(qū)動模塊JDriverDriverLKIDriverFDriverDDriverH自底向上的增量測試中的驅(qū)動模塊調(diào)用從屬模塊調(diào)用從屬模塊，并傳遞參數(shù)調(diào)用從屬模塊，并要求得到參數(shù)兼有B,C的功能ABCD自頂向下測試和自底向上測試的比較自頂向下優(yōu)點如果主要缺陷發(fā)生在程序頂層將非常有利早期程序框架可以進行演示，即提早發(fā)現(xiàn)主要的控制問題缺點必須開發(fā)樁模塊樁模塊可能要比最初表現(xiàn)的更復雜創(chuàng)建測試環(huán)境可能很難，甚至無法實現(xiàn)觀測測試輸出比較困難自底向上優(yōu)點如果主要的缺陷發(fā)生在程序的底層將非常有利提早發(fā)現(xiàn)程序當中的主要算法問題測試環(huán)境比較容易建立觀測測試輸出比較容易缺點必須開發(fā)驅(qū)動模塊直到最后一個模塊添加進去，程序才形成一個整體40“三明治”方法（Sandwich）混合式集成把系統(tǒng)劃分成三層，中間一層為目標層，目標層之上采用自頂向下集成，之下采用自底向上集成41三明治集成策略集成步驟（1）首先對目標層之上一層使用自頂向下集成，因此測試A，使用樁代替B，C，D（2）其次對目標層之下一層使用自底向上集成，因此測試E，F(xiàn)，使用驅(qū)動代替B，D（3）其三，把目標層下面一層與目標層集成，因此測試（B，E），（D，F(xiàn)），使用驅(qū)動代替A（4）最后，把三層集成到一起，因此測試（A，B，C，D，E，F(xiàn)）42三明治集成策略優(yōu)缺點優(yōu)點：集合了自頂向下和自底向上兩種策略的優(yōu)點缺點：中間層測試不充分適用范圍：適應(yīng)于大部分軟件開發(fā)項目ABDCFE43修改過的三明治集成面向?qū)ο蟮募蓽y試面向?qū)ο蟮募蓽y試特點結(jié)構(gòu)集成測試功能集成測試集成測試方法繼承關(guān)系的類集成測試類交互的集成測試44結(jié)構(gòu)集成測試方法：靜態(tài)測試測試對象：類繼承、類容器、組件的接口目的：結(jié)構(gòu)是否符合設(shè)計可逆性工程：ISA公司的Panorama-2、Rational公司的RoseC++Analyzer對照類關(guān)系圖45功能集成測試方法：檢查類間方法交互、組件間交互等；信息來源：系統(tǒng)的規(guī)約、系統(tǒng)設(shè)計、代碼。其它信息：設(shè)計模型、功能調(diào)用結(jié)構(gòu)圖、類關(guān)系圖或者實體關(guān)系圖46類層次結(jié)構(gòu)繼承－>類交互－>組件－>應(yīng)用類通過繼承集成類通過交互集成類到組件的集成組件到應(yīng)用系統(tǒng)的集成47交互集成對象交互通過消息傳遞實現(xiàn)通過參數(shù)引用48Wood和Flooring集成Flooring類49Wood和Surface單元測試Flooring集成測試其它類交互參數(shù)交互返回類對象類方法中創(chuàng)建對象類引用全局類對象50集成測試步驟選定檢測的類，參考OOD分析結(jié)果，仔細分析類的狀態(tài)和相應(yīng)的行為，類或方法間傳遞消息，前置條件和后置條件的界定等；確定覆蓋標準；利用結(jié)構(gòu)關(guān)系圖確定待測類的所有關(guān)聯(lián)；根據(jù)程序中類的對象構(gòu)造測試用例，確認使用什么輸入激發(fā)類狀態(tài)的改變，使用類的服務(wù)和期望產(chǎn)生什么行為等；進行集成測試，根據(jù)類的層次關(guān)系確定測試的先后順序，盡量使測試用例能夠復用。51集成測試原則首先測試公共類測試僅調(diào)用公共類的類有繼承層次關(guān)系的先測試父類再測試子類集成時盡量一次添加一個被測試的類或組件形成組件的先單獨測試組件再集成到子系統(tǒng)52實例：發(fā)布新聞53“發(fā)布新聞”用例的順序圖發(fā)布新聞，可上傳附件實例：發(fā)布新聞集成測試先測試FileUpload、NewsDao，需要驅(qū)動類News類可以不測然后測試NewsService，需要Mock對象、驅(qū)動類，然后NewsDao對象替換Mock對象再測試NewsController，需要Mock對象、驅(qū)動類最后測AddNewsFrame，

需要Mock對象54本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman55集成測試流程56制定集成測試計劃集成測試分析與設(shè)計集成測試實現(xiàn)集成測試執(zhí)行集成測試評估軟件體系結(jié)構(gòu)初步分析關(guān)鍵特性分析工作量估計資源安排進度安排集成測試對象分析集成策略選擇集成測試工具選擇和設(shè)計集成測試代碼設(shè)計集成測試用例設(shè)計集成測試工具開發(fā)集成測試代碼開發(fā)集成測試用例開發(fā)建立集成測試環(huán)境執(zhí)行集成測試測試結(jié)果記錄集成測試數(shù)據(jù)分析集成測試評估57(1)為系統(tǒng)運行設(shè)計用例——多角度設(shè)計測試用例

目的：測試各個模塊的接口是否能用，驗證系統(tǒng)最基本功能可使用的主要測試分析技術(shù)有（黑盒技術(shù)）：（1）等價類劃分。（2）邊界值分析。（3）基于決策表的測試。58(2)為正向測試設(shè)計用例目的：驗證集成后的模塊是否按照設(shè)計實現(xiàn)了預期的功能?？墒褂萌缦聨追N主要測試分析技術(shù)：（1）輸入域測試。（2）輸出域測試。（3）等價類劃分。（4）狀態(tài)轉(zhuǎn)換測試。正向測試是指，當你輸入一個有效的輸入并且期望軟件能夠完成一些根據(jù)說明書規(guī)定的行為。59(3)為逆向測試設(shè)計用例目的：測試是否多余功能、接口遺漏、接口錯誤、接口異常?？墒褂玫闹饕獪y試分析技術(shù)有：（1）錯誤猜測法。（2）基于風險的測試。（3）基于故障的測試。（4）邊界值分析。（5）特殊值測試。（6）狀態(tài)轉(zhuǎn)換測試。逆向測試是指，當你輸入無效的輸入時并且期望得到一個錯誤的信息。60集成測試用例設(shè)計(4)為滿足特殊需求設(shè)計用例。(5)為高覆蓋設(shè)計用例可使用的主要測試分析技術(shù)有：（1）功能覆蓋分析。（2）接口覆蓋分析。61集成測試流程（思考各階段IO）計劃階段設(shè)計階段實現(xiàn)階段執(zhí)行階段分析評估缺陷跟蹤根據(jù)項目組提供設(shè)計模型和集成構(gòu)建計劃，制定出適合本項目的集成測試計劃根據(jù)集成測試計劃和設(shè)計模型設(shè)計集成測試用例及測試過程獲取工作版本后，由測試設(shè)計員創(chuàng)建測試腳本(可選)、更新測試過程，由設(shè)計員負責設(shè)計驅(qū)動程序和樁，實施員負責實施驅(qū)動和樁測試人員根據(jù)測試腳本(可選)和工作版本執(zhí)行集成測試，并記錄測試結(jié)果依照集成測試計劃和測試結(jié)果，由測試設(shè)計員負責會同集成員、編碼員、設(shè)計人員評估此次測試，并生成測試評估摘要62計劃階段輸入需求規(guī)格說明書概要設(shè)計文檔產(chǎn)品開發(fā)計劃輸出集成測試計劃63計劃階段活動步驟確定被測試對象和測試范圍評估集成測試被測試對象的數(shù)量及難度確定角色分工和劃分工作任務(wù)標識出測試各階段的時間、任務(wù)、約束等條件考慮一定的風險分析及應(yīng)急計劃考慮和準備集成測試需要的測試工具、測試儀器、環(huán)境等資源考慮外部技術(shù)支援的力度和深度，以及相關(guān)培訓安排定義測試完成標準64設(shè)計階段輸入需求規(guī)格說明書概要設(shè)計集成測試計劃輸出集成測試設(shè)計方案集成測試用例65設(shè)計階段活動步驟被測對象結(jié)構(gòu)分析集成測試模塊分析集成測試接口分析集成測試策略分析集成測試工具分析集成測試環(huán)境分析集成測試用例設(shè)計

集成測試工作量估計和安排66體系結(jié)構(gòu)分析從兩個角度出發(fā)劃分出系統(tǒng)實現(xiàn)上的結(jié)構(gòu)層次圖劃分系統(tǒng)組件之間的依賴關(guān)系圖67模塊的大小驅(qū)動和樁模塊數(shù)量消息接口的復雜度……68模塊分析模塊劃分可以從以下幾個角度出發(fā)考慮：本次測試主要希望測試哪個模塊這個模塊與哪幾個模塊有最密切的關(guān)系把該模塊與關(guān)系最密切的模塊首先集成在一起再考慮外圍模塊，消息流是否容易模擬，是否方便控制69接口分析接口分析可以通過以下幾個步驟來完成：確定系統(tǒng)的邊界、子系統(tǒng)的邊界和模塊的邊界確定模塊內(nèi)部的接口確定子系統(tǒng)內(nèi)模塊間接口確定子系統(tǒng)間接口確定系統(tǒng)與操作系統(tǒng)的接口確定系統(tǒng)與硬件的接口確定系統(tǒng)與第三方軟件的接口70環(huán)境分析可以從以下幾個方面進行硬件環(huán)境操作系統(tǒng)環(huán)境數(shù)據(jù)庫環(huán)境網(wǎng)絡(luò)環(huán)境71集成測試環(huán)境示意圖72實現(xiàn)階段輸入需求規(guī)格說明書概要設(shè)計集成測試計劃集成測試設(shè)計輸出集成測試規(guī)程集成測試代碼、集成測試腳本、集成測試工具（如果有）73實現(xiàn)階段活動步驟集成測試規(guī)程設(shè)計集成測試代碼設(shè)計（如果需要）集成測試腳本（如果需要）集成測試工具（如果需要）74執(zhí)行階段輸入需求規(guī)格說明書概要設(shè)計集成測試計劃集成測試設(shè)計集成測試用例集成測試規(guī)程集成測試代碼（如果有）集成測試腳本（如果有）集成測試工具（如果有）詳細設(shè)計代碼單元測試報告輸出集成測試報告75執(zhí)行階段活動步驟執(zhí)行集成測試用例回歸集成測試用例撰寫集成測試報告76相應(yīng)過程的測試文檔計劃階段設(shè)計階段實現(xiàn)階段執(zhí)行階段分析評估缺陷跟蹤集成測試計劃集成測試設(shè)計方案集成測試用例集成測試規(guī)程、（代碼、腳本、工具）集成測試報告本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman77集成測試計劃模板78（1）前言：介紹背景資料，如測試目的、范圍、術(shù)語、測試環(huán)境和參考文獻等。（2）集成策略：集成測試的重點就是集成的具體實現(xiàn)。包括進入集成標準、集成順序、集成元素等，要在集成計劃中明確。（3）集成測試工具和步驟：制定測試工具，測試可以包括軟件集成測試、軟件/硬件集成測試、子系統(tǒng)集成測試和功能測試等。（4）集成測試驗收標準：包括模塊驗收標準和集成測試驗收標準。需要指明測試過程中的掛起、恢復和退出等條件。（5）其他：包括責任人和時間表、記錄和解決問題以及如果有必要安排重新測試程序。本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman79持續(xù)集成工具JenkinsJenkins是一款使用Java開發(fā)的持續(xù)集成工具，其自動化部署可以解決集成、測試、部署等重復性的工作，工具集成的效率明顯高于人工操作；并且持續(xù)集成可以更早的獲取代碼變更的信息，從而更早的進入測試階段，更早的發(fā)現(xiàn)問題。80測試流程81本章內(nèi)容集成測試概述集成靜態(tài)測試集成動態(tài)測試集成測試流程集成測試計劃持續(xù)集成工具Jenkins接口測試工具Postman82接口測試工具Postman接口測試是軟件測試的重要組成部分，專門用于檢查應(yīng)用程序接口的功能、性能和安全性。Postman是一款API測試工具，提供了一種簡單易用的方式來測試和調(diào)試API，可以幫助開發(fā)者Postman可以通過發(fā)送HTTP請求來測試API的功能，支持常見的HTTP請求方式，如GET、POST、PUT、DELETE等。簡化測試流程，提高效率。Postman還支持多種環(huán)境和變量，可以方便地進行不同環(huán)境下的測試和調(diào)試。83Postman功能菜單84第11章系統(tǒng)測試86本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試87本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試系統(tǒng)測試88需求規(guī)格說明書功能性需求非功能性需求開發(fā)驗證系統(tǒng)測試89專門測試人員客觀專業(yè)權(quán)威資源有保證優(yōu)勢：系統(tǒng)測試系統(tǒng)測試（SystemTesting）是將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。90被測軟件系統(tǒng)功能測試91需求規(guī)格說明書軟件功能是否滿足需求是否有功能遺漏是否有功能冗余系統(tǒng)功能測試92需求規(guī)格說明書系統(tǒng)功能測試步驟：1、測試系統(tǒng)中每個功能的場景2、測試系統(tǒng)中的關(guān)聯(lián)功能3、測試系統(tǒng)中的業(yè)務(wù)流程場景測試場景(scenario)是參與者和系統(tǒng)之間的一系列特定的活動和交互也稱為用例實例(usecaseinstance)是使用系統(tǒng)的一個特定情節(jié)或用例的一條執(zhí)行路徑。如：使用現(xiàn)金成功購買商品的場景；信用卡支付被拒絕而購買失敗的場景。93系統(tǒng)順序圖94事件觸發(fā)場景測試在圖中，有一個基本流和四個備選流。每個可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結(jié)合起來，可以確定以下用例場景：場景1

基本流場景2

基本流備選流1場景3

基本流備選流1備選流2場景4

基本流備選流3場景5

基本流備選流3備選流1場景6

基本流備選流3備選流1備選流2場景7

基本流備選流4場景8

基本流備選流3備選流495場景測試案例：在線購物用戶進入一個在線購物網(wǎng)站進行購物，選購物品后，進行在線購買，這時需要使用帳號登錄，登錄成功后，進行付錢交易，交易成功后，生成訂購單，完成整個購物過程。96選購商品付錢交易賬號登錄生成訂單場景測試第一步：確定基本流和備選流：97基本流登錄在線購物網(wǎng)站，選擇物品，登錄帳號，付錢交易，生成訂購單備選流1帳號不存在備選流2帳號或密碼錯誤備選流3用戶帳號余額不足備選流4用戶帳號沒有錢備選流x用戶退出系統(tǒng)場景測試第二步：根據(jù)基本流和備選流來確定場景：98場景1-成功購物基本流場景2-帳號不存在基本流備選流1場景3-帳號或密碼錯誤基本流備選流2場景4-用戶帳號余額不足基本流備選流3場景5-用戶帳號沒有錢基本流備選流4場景測試第三步：設(shè)計測試用例對于每一個場景都需要確定測試用例?？梢圆捎镁仃嚮驔Q策表來確定和管理測試用例。右面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。99編號場景/條件帳號密碼用戶帳號余額預期結(jié)果1場景1：成功購物VVV成功購物2場景2：帳號不存在In/an/a提示帳號不存在3場景3：帳號或密碼錯誤（帳號正確，密碼錯誤）VIn/a提示帳號或密碼錯誤，返回基本流步驟34場景3：帳號或密碼錯誤（帳號錯誤，密碼正確）VIn/a提示帳號或密碼錯誤，返回基本流步驟35場景4：用戶帳號余額不足VVI提示余額不足V（有效）I（無效）“n/a”（不適用）常見的非功能性測試類型性能測試容量測試健壯性測試安全性測試可靠性測試協(xié)議一致性測試兼容性測試100安裝性測試可用性測試配置測試文檔測試GUI測試外國語言測試網(wǎng)站測試非功能性系統(tǒng)測試的內(nèi)容質(zhì)量需求容量測試性能測試兼容性測試安全性測試負載測試故障轉(zhuǎn)移測試驗證測試基準測試規(guī)劃測試系統(tǒng)測試性能可用性兼容性可維護性安全性可靠性102本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試什么是軟件的性能世界上第一臺計算機“埃尼阿克”由1.8萬個電子管組成，占地有兩三間教室般大。運算速度僅為每秒5000次加法運算。當時的用戶對軟件要求不高，只要能工作就行。

現(xiàn)在軟件已經(jīng)成為普通的商品，開始從經(jīng)濟學角度考慮軟件。投入產(chǎn)出的關(guān)系：要盡可能的少占用硬件資源；運行速度也要盡可能的快。功能與性能的關(guān)系軟件功能和性能的源頭都是來自用戶的需求。一個郵件系統(tǒng)來講：功能：能支持收發(fā)30種語言為標題和正文的郵件，并支持粘接10MB的附件。性能：能夠在2GBRAM/1GHzCPU的服務(wù)器上，支持10000注冊用戶，日均處理10000郵件，響應(yīng)時間不超過5s/封。總結(jié)：功能的焦點在于“做什么”；性能關(guān)注于“做的如何”，表現(xiàn)為軟件對“空間”和“時間”的敏感度。軟件性能的不同視角用戶視角管理員視角開發(fā)者視角用戶視角的對軟件性能計算性能——用戶最關(guān)心的一個指標，即軟件系統(tǒng)有多快。如，一個典型的業(yè)務(wù)需要花多少時間。資源的利用和回收——就是硬件和軟件資源。硬件包括客戶端硬件、服務(wù)器硬件和網(wǎng)絡(luò)硬件；軟件包括操作系統(tǒng)、中間件和數(shù)據(jù)庫。特別關(guān)注系統(tǒng)對內(nèi)存的使用。啟動時間——用戶希望系統(tǒng)進入正常工作狀態(tài)的時間越短越好。穩(wěn)定性——運行一段時間后會不會出現(xiàn)問題。管理員視角的軟件性能關(guān)注用戶視角關(guān)注的軟件性能指標和系統(tǒng)狀態(tài)相關(guān)的信息例如知道在并發(fā)用戶為100，某業(yè)務(wù)響應(yīng)時間為6秒的情況下，系統(tǒng)狀態(tài)如何？CPU與內(nèi)存達到多少？數(shù)據(jù)庫狀況？伸縮性——比如一個系統(tǒng)，在50個并發(fā)用戶的時候表現(xiàn)正常，但是到1000的時候表現(xiàn)如何？是逐漸下降還是在某個拐點附近急劇下降？107管理員視角的軟件性能管理員關(guān)注的部分性能相關(guān)問題108管理員關(guān)心的問題軟件性能描述1服務(wù)器的資源使用狀況合理嗎資源利用率2應(yīng)用服務(wù)器和數(shù)據(jù)庫的資源使用狀況合理嗎資源利用率3系統(tǒng)是否能夠?qū)崿F(xiàn)擴展系統(tǒng)可擴展性4系統(tǒng)最多能支持多少用戶的訪問系統(tǒng)容量5系統(tǒng)性能可能的瓶頸在哪里系統(tǒng)可擴展性6更換哪些設(shè)備能提高系統(tǒng)性能系統(tǒng)可擴展性7系統(tǒng)能否支持7*24小時的業(yè)務(wù)訪問系統(tǒng)穩(wěn)定性開發(fā)視角的軟件性能開發(fā)人員除了關(guān)注響應(yīng)時間、系統(tǒng)擴展性等性能指標外，更關(guān)心如何調(diào)整設(shè)計和代碼實現(xiàn)、系統(tǒng)設(shè)置等方法提高軟件性能。開發(fā)人員關(guān)注的部分性能問題109開發(fā)人員關(guān)心的問題問題所屬層次1架構(gòu)設(shè)計是否合理系統(tǒng)架構(gòu)2數(shù)據(jù)庫設(shè)計是否存在問題數(shù)據(jù)庫設(shè)計3代碼是否存在性能方面的問題代碼4系統(tǒng)中是否有不合理的內(nèi)存使用方式代碼5系統(tǒng)中是否存在不合理的線程同步方式設(shè)計與代碼6系統(tǒng)中是否存在不合理的資源競爭設(shè)計與代碼性能指標響應(yīng)時間（Responsetime）并發(fā)用戶數(shù)（Concurrentusers）吞吐量（Throughput）資源使用率（Resourceutilization）點擊數(shù)（Hitspersecond）響應(yīng)時間（Responsetime）響應(yīng)時間指的是客戶端發(fā)出請求到得到響應(yīng)的整個過程所經(jīng)歷的時間。用戶接口應(yīng)用服務(wù)器數(shù)據(jù)庫服務(wù)器時間三層體系結(jié)構(gòu)舉例響應(yīng)時間（Responsetime）響應(yīng)時間可以細分為：服務(wù)器端響應(yīng)時間：服務(wù)器完成交易請求執(zhí)行的時間，這個時間可以度量服務(wù)器處理能力。網(wǎng)絡(luò)響應(yīng)時間：網(wǎng)絡(luò)硬件傳輸交易請求和交易結(jié)果所耗費的時間?？蛻舳隧憫?yīng)時間：客戶端在構(gòu)建請求和展現(xiàn)交易結(jié)果時所耗費的時間?？蛻舾惺艿捻憫?yīng)時間=以上三者之和并發(fā)用戶數(shù)并發(fā)：若干用戶同時訪問服務(wù)器或者同一業(yè)務(wù)。OA系統(tǒng)經(jīng)驗公式：

并發(fā)用戶數(shù)=使用系統(tǒng)的用戶數(shù)量*（5%~20%）如果一個OA系統(tǒng)的期望用戶為1000個，則只要測試出系統(tǒng)能支持200個并發(fā)用戶就可以了。但是，一定要考慮典型的業(yè)務(wù)場景例如一個內(nèi)部系統(tǒng)一般上班后30分鐘左右集中出現(xiàn)用戶登錄一個教務(wù)系統(tǒng)一般在期末考試結(jié)束后、選課時出現(xiàn)大量用戶較準確的并發(fā)用戶數(shù)計算是根據(jù)應(yīng)用服務(wù)器的日志吞吐量（Throughput）吞吐量直接體現(xiàn)軟件系統(tǒng)的的性能承載能力，是指單位時間內(nèi)系統(tǒng)處理的客戶請求的數(shù)量。可用訪問人數(shù)/天、業(yè)務(wù)數(shù)/小時等單位來衡量114資源使用率（Resourceutilization）定義：資源使用率指的是對不同資源的使用程度。常見的資源：CPU占用率內(nèi)存使用率磁盤I/O網(wǎng)絡(luò)I/O點擊數(shù)（Hitspersecond）定義：按照客戶端向WebServer發(fā)起了多少次http請求來計算的。一個客戶的業(yè)務(wù)操作可能若干請求其他指標交易成功率——成功的交易數(shù)占總交易請求數(shù)的比率。系統(tǒng)恢復時間——當系統(tǒng)出錯時，修正錯誤并重新啟動系統(tǒng)所需的時間。其實，凡是用戶有關(guān)資源和時間的要求都可以被視作性能指標。性能測試就是為了驗證這些性能指標是否被滿足。常見的性能測試方法負載測試（LoadTesting）LoadRunner、QALoad、WebLoad

壓力測試（StressTesting）ApacheJmeter、LoadRunnerya、webbench并發(fā)測試（ConcurrencyTesting）QALoad、LoadRunner、BenchmarkFactory、

Webstress、AB-Apache基準測試（BenchTesting）穩(wěn)定性測試（StabilityTesting）可恢復測試（RecoveryTesting）負載測試（LoadTesting）對負載測試的理解：（1）主要是考察軟件系統(tǒng)在既定負載下的性能表現(xiàn)。（2）站在用戶角度去觀察在一定條件下軟件系統(tǒng)的性能表現(xiàn)（3）負載測試的預期結(jié)果是用戶的性能需求得到滿足。負載測試的例子某網(wǎng)站測試需求：可以支持100個并發(fā)用戶執(zhí)行各種查詢操作，要求各查詢操作的響應(yīng)時間在5秒以內(nèi)，服務(wù)器CPU利用率在80%以下。設(shè)計負載測試用例：并發(fā)用戶數(shù)：20、50、80、100、120壓力測試（StressTesting）對壓力測試的理解：（1）為了考察系統(tǒng)在極端條件下的表現(xiàn)，極端條件可以是超負荷的交易量和并發(fā)用戶數(shù)。（2）這個極端條件并不一定是用戶的性能需求，可能要遠遠高于用戶需求。（3）壓力測試是能讓我們識別系統(tǒng)的弱點和在極限負載下程序?qū)⑷绾芜\行。（4）壓力測試和負載測試的不同是，壓力測試的預期結(jié)果是系統(tǒng)出現(xiàn)問題，而我們考察的是系統(tǒng)處理問題的方式。壓力測試（StressTesting）用戶量壓力測試數(shù)據(jù)量壓力測試例如：系統(tǒng)最大支持的同時在線用戶數(shù)是1000個，壓力測試需要測試在1000個用戶甚至2000個用戶同時在線時系統(tǒng)的表現(xiàn)。例如：在系統(tǒng)內(nèi)存耗盡情況下，測試系統(tǒng)的運行情況，這種情況下被測試系統(tǒng)也不應(yīng)該崩潰。壓力測試的反常規(guī)操作當平均每秒出現(xiàn)1個或2個中斷的情形下，應(yīng)當對每秒出現(xiàn)10個中斷的情形來進行特殊的測試；把輸入數(shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)；應(yīng)當執(zhí)行需要最大的內(nèi)存或其他資源（如CPU,內(nèi)存，磁盤，網(wǎng)絡(luò)）的測試用例；壓力測試的反常規(guī)操作運行一個虛擬的操作系統(tǒng)中可能會引起大量的駐留磁盤數(shù)據(jù)的測試用例；兩倍的已經(jīng)極限的并發(fā)用戶數(shù)或者HTTP連接數(shù)；隨機的關(guān)閉及重開連接到服務(wù)器上的網(wǎng)絡(luò)上集線器/路由器的端口（例如，可通過SNMP命令來實現(xiàn)）；把數(shù)據(jù)庫斷線然后再重啟。容量測試采用特定的手段測試系統(tǒng)能夠承載的處理任務(wù)的極限值的測試工作。這里的特定手段是指測試人員根據(jù)實際運行中可能出現(xiàn)極限，制造相對應(yīng)的任務(wù)組合，來激發(fā)系統(tǒng)出現(xiàn)極限的情況。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理容量測試常應(yīng)用于數(shù)據(jù)庫容量方面的測試，以確定它何時達到使軟件發(fā)生故障的極限。容量測試還可確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負載或工作量。容量測試進行容量測試的首要任務(wù)就是確定被測系統(tǒng)數(shù)據(jù)量的極限，即容量極限。這些數(shù)據(jù)可以是數(shù)據(jù)庫所能容納的最大值，也可以是一次處理所能允許的最大數(shù)據(jù)量等。系統(tǒng)出現(xiàn)問題，通常發(fā)生在極限數(shù)據(jù)量產(chǎn)生或臨界產(chǎn)生的情況下，這時容易造成磁盤數(shù)據(jù)的丟失、緩沖區(qū)溢出等一些問題。由圖11-1可以看到，隨著用戶負載增加，響應(yīng)時間也緩慢的增加，而資源利用率幾乎是線形增長。資源利用率接近百分之百時，會出現(xiàn)一個有趣的現(xiàn)象，就是響應(yīng)以指數(shù)曲線方式下降，這點在容量評估中被稱為飽和點。飽和點是指所有性能指標都不滿足，隨后應(yīng)用發(fā)生恐慌的時間點。容量評估的目標是保證用戶知道這點在哪，并且永遠不要出現(xiàn)這種情況。在這種負載發(fā)生前，管理者應(yīng)優(yōu)化系統(tǒng)或者增加適當額外的硬件。并發(fā)測試（ConcurrencyTesting）對并發(fā)測試的理解：（1）一般是和服務(wù)器端建立大量的并發(fā)連接，通過客戶端的響應(yīng)時間和服務(wù)器端的性能監(jiān)測情況來判斷系統(tǒng)是否達到了既定的并發(fā)能力指標。（2）負載測試往往就會使用并發(fā)來創(chuàng)造負載。（3）并發(fā)測試往往涉及服務(wù)器的并發(fā)容量，以及多進程/多線程協(xié)調(diào)同步可能帶來的問題。并發(fā)測試的例子400并發(fā)用戶，事務(wù)失敗率（failpercent）>1.35%，軟件系統(tǒng)失效。500并發(fā)用戶，事務(wù)失敗率（failpercent）>10%，系統(tǒng)中斷。600并發(fā)用戶，事務(wù)失敗率（failpercent）>80%，系統(tǒng)崩潰?；鶞蕼y試（BenchTesting）對基準測試的理解：（1）當軟件系統(tǒng)中增加一個新的模塊的時候，需要做基準測試，以判斷新模塊對整個軟件系統(tǒng)的性能影響。（2）需要打開/關(guān)閉新模塊至少各做一次測試。關(guān)閉模塊狀態(tài)下的系統(tǒng)各個性能指標記下來作為基準，然后與打開模塊狀態(tài)下的系統(tǒng)性能指標作比較。穩(wěn)定性測試（StabilityTesting）對穩(wěn)定性測試的理解：（1）考察測試系統(tǒng)在一定負載下運行長時間后是否會發(fā)生問題。（2）有些問題只有在運行一天或者一個星期甚至更長的時間才會暴露。這種問題一般是程序占用資源卻不能及時釋放而引起的。穩(wěn)定性測試可能幫助找到一些大型問題，如死機、崩潰、內(nèi)存泄露等，因為有些存在內(nèi)存泄露問題的程序，在運行一兩次時可能不會出現(xiàn)問題，但是如果運行了成千上萬次，內(nèi)存泄露的越來越多，就會導致系統(tǒng)崩潰?？苫謴蜏y試（RecoveryTesting）對可恢復測試的理解：（1）測試系統(tǒng)能否快速地從錯誤狀態(tài)中恢復到正常狀態(tài)。（2）可恢復測試通常結(jié)合壓力測試一起來做。性能計數(shù)器用來衡量被測系統(tǒng)當前的狀況和進行性能測試結(jié)果的分析。分為：操作系統(tǒng)級別應(yīng)用服務(wù)器級別數(shù)據(jù)庫級別等單個性能計數(shù)器只反映系統(tǒng)性能的一個側(cè)面，需要根據(jù)多個性能計數(shù)器進行分析132性能計數(shù)器Windows操作系統(tǒng)的主要性能計數(shù)器133類別計數(shù)器Memory可用物理內(nèi)存由于硬件頁面錯誤而從磁盤讀出的頁面數(shù)文件系統(tǒng)緩存Process被處理器消耗的處理器時間數(shù)量處理線程最近使用的內(nèi)存頁…處理器CPU耗用百分比物理硬盤每秒讀取硬盤次數(shù)…網(wǎng)絡(luò)接口發(fā)送接收字節(jié)的速率系統(tǒng)性能計數(shù)器JavaEE應(yīng)用服務(wù)器的主要性能計數(shù)器134類別計數(shù)器JVMJVM堆大小JVM可用堆大小JDBCConnectionPool等待的連接數(shù)量總的JDBC連接數(shù)JDBC連接池的容量當前活躍的JDBC連接數(shù)ExecuteQueue空閑的線程數(shù)量隊列請求的最久時間已處理的請求總數(shù)掛起請求的數(shù)量性能計數(shù)器數(shù)據(jù)庫服務(wù)器的主要性能計數(shù)器135類別計數(shù)器System數(shù)據(jù)庫進程占用的CPU時間當前的用戶連接數(shù)Memory緩存命中率當前使用的內(nèi)存量Lock鎖平均等待時間每秒的鎖請求數(shù)每秒產(chǎn)生的死鎖數(shù)量I/O被掛起的物理讀寫每秒頁面讀寫的次數(shù)每秒產(chǎn)生的事務(wù)數(shù)量性能測試工具LoadRunnerQTP澤眾公司PerformanceRunnerJmeter...136性能測試工具原理壓力和負載測試工具架構(gòu)137虛擬用戶腳本產(chǎn)生器壓力產(chǎn)生器壓力調(diào)度和監(jiān)控系統(tǒng)壓力結(jié)果分析工具性能測試工具原理虛擬用戶腳本產(chǎn)生器通過Proxy方式實現(xiàn)接收從客戶端發(fā)送的數(shù)據(jù)包，記錄并將其轉(zhuǎn)發(fā)給服務(wù)器端接收從服務(wù)器端返回的數(shù)據(jù)流，記錄并返回給客戶端138性能測試工具原理壓力產(chǎn)生器根據(jù)腳本內(nèi)容產(chǎn)生實際的負載例如某測試場景要求產(chǎn)生100個虛擬用戶，壓力產(chǎn)生器會在調(diào)度下生成100個進程或線程每個線程都對指定的腳本進行解釋執(zhí)行139139虛擬用戶腳本產(chǎn)生器壓力產(chǎn)生器壓力調(diào)度和監(jiān)控系統(tǒng)壓力結(jié)果分析工具性能測試工具原理用戶代理用戶代理是運行在負載機上的進程，該進程與產(chǎn)生負載壓力的進程或線程協(xié)作，接受調(diào)度系統(tǒng)的命令，調(diào)度產(chǎn)生負載壓力的進程或線程140140虛擬用戶腳本產(chǎn)生器壓力產(chǎn)生器壓力調(diào)度和監(jiān)控系統(tǒng)壓力結(jié)果分析工具性能測試工具原理壓力調(diào)度和監(jiān)控系統(tǒng)性能測試工具中直接與用戶交互的主要內(nèi)容壓力調(diào)度工具根據(jù)用戶的場景要求，設(shè)置不同腳本的虛擬用戶量、設(shè)置同步點等監(jiān)控系統(tǒng)可以對各種數(shù)據(jù)庫、應(yīng)用服務(wù)器、服務(wù)器的主要性能計數(shù)器進行監(jiān)控141141虛擬用戶腳本產(chǎn)生器壓力產(chǎn)生器壓力調(diào)度和監(jiān)控系統(tǒng)壓力結(jié)果分析工具性能測試工具原理壓力結(jié)果分析工具輔助進行測試結(jié)果的分析一般附帶的分析工具能夠?qū)⒈O(jiān)控系統(tǒng)獲取的性能計數(shù)器值生成曲線圖、折線圖等圖但是，壓力結(jié)果分析工具本身不能代替分析者進行性能結(jié)果的分析142142虛擬用戶腳本產(chǎn)生器壓力產(chǎn)生器壓力調(diào)度和監(jiān)控系統(tǒng)壓力結(jié)果分析工具性能測試團隊143工作角色具體職責測試經(jīng)理和其他項目干系人交互確保測試的外部環(huán)境制定測試計劃監(jiān)控測試進度發(fā)現(xiàn)和處理測試中的風險測試設(shè)計員定義性能規(guī)劃識別用戶的性能需求建立性能場景測試開發(fā)員實現(xiàn)已設(shè)計的性能場景腳本開發(fā)、調(diào)試確定測試時需要監(jiān)控的性能指標、性能計數(shù)器測試員部署測試環(huán)境執(zhí)行腳本和場景根據(jù)監(jiān)控要求記錄測試結(jié)果、記錄性能指標和性能計數(shù)器值測試分析員根據(jù)測試結(jié)果、性能指標的數(shù)值、性能計數(shù)器值進行分析；根據(jù)性能規(guī)劃，分析出系統(tǒng)性能瓶頸，或是給出優(yōu)化建議性能測試過程模型1446.測試分析2.測試工具引入1.測試前期準備4.測試設(shè)計與開發(fā)3.測試計劃5.測試執(zhí)行與管理性能測試過程通用模型（PTGM）JMeterJmeter簡介/watch/5795678631684416056.html?page=videoMultiNeedJmeter腳本錄制/v_show/id_XOTE3ODQ2ODky.htmlJmeter腳本執(zhí)行/watch/7969513224641868131.html?page=videoMultiNeedJmeter腳本優(yōu)化/watch/03350326185846515067.html?page=videoMultiNeed145JMeter簡介Jmeter是一個開源性能測試工具具有三個典型優(yōu)點：擴展性好開源靈活146Jmeter基礎(chǔ)概念Jmeter與其它性能測試工具具有一致的4個部分：負載發(fā)生器通常以多線程方式模擬用戶行為用戶運行器腳本運行引擎資源監(jiān)視器報表生成器147Jmeter中的主要元件TestPlan（測試計劃）ThreadGroup（線程組）可看成是一個虛擬用戶組Sampler（采樣器）向服務(wù)器發(fā)送請求、記錄響應(yīng)信息、記錄響應(yīng)時間的最小單元LogicController（邏輯控制器）Listener（監(jiān)聽器）對測試結(jié)果數(shù)據(jù)進行處理和可視化展示的一系列元件148Jmeter中的次要元件ConfigElement(配置元件)提供對靜態(tài)數(shù)據(jù)的配置Timer(定時器)用于在操作之間設(shè)置等待時間Assertions(斷言)檢查測試中得到的相應(yīng)數(shù)據(jù)是否符合預期PreProcessors(前處理器)對即將發(fā)出的請求進行特殊處理PostProcessors(后處理器)149Jmeter測試實例一測試中國石油大學（華東）的云課堂/meol/homepage/common/了解該網(wǎng)站在負載達到20QTS（每秒查詢率）時的響應(yīng)時間150Jmeter測試實例一測試步驟：建立空TestPlan為TestPlan增加ThreadGroup增加HttpRequestSampler添加ViewResultsinTable調(diào)試TestPlan151JMeter+BadBoy的性能測試Jmeter在執(zhí)行性能測試時是運行的腳本腳本記錄了執(zhí)行過程BadBoy工具可以錄制一段操作，并導出成Jmeter腳本152JMeter+BadBoy的性能測試測試過程BadBoy錄制腳本Jmeter打開腳本配置線程組的參數(shù)添加監(jiān)聽器開始測試分析測試結(jié)果153Jmeter圖形報表154Jmeter圖形報表樣本數(shù)目是總共發(fā)送到服務(wù)器的請求數(shù)。最新樣本是代表時間的數(shù)字,是服務(wù)器響應(yīng)最后一個請求的時間。吞吐量是服務(wù)器每分鐘處理的請求數(shù)。平均值是總運行時間除以發(fā)送到服務(wù)器的請求數(shù)。中間值是代表時間的數(shù)字，有一半的服務(wù)器響應(yīng)時間低于該值而另一半高于該值。偏離表示服務(wù)器響應(yīng)時間變化、離散程度測量值的大小，或者，換句話說，就是數(shù)據(jù)的分布。155156本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試157明確軟件錯誤、缺陷、故障與失效的概念邊界，建立統(tǒng)一的認知框架錯誤與缺陷錯誤是人為疏忽導致的邏輯偏差，缺陷是錯誤在代碼中的具體體現(xiàn)，二者屬于開發(fā)階段的內(nèi)在問題。故障故障是缺陷被激活后在系統(tǒng)中表現(xiàn)出的異常狀態(tài)，是靜態(tài)缺陷向動態(tài)失效轉(zhuǎn)化的中間環(huán)節(jié)。失效失效是軟件未能執(zhí)行規(guī)定功能的外部可觀測事件，直接體現(xiàn)為系統(tǒng)行為偏離用戶預期。概念關(guān)聯(lián)錯誤引發(fā)缺陷，缺陷在特定條件下觸發(fā)故障，故障積累或傳播最終導致系統(tǒng)失效。

軟件失效158軟件可靠性度量可靠度：指軟件在規(guī)定條件下和規(guī)定時間內(nèi)，不引起系統(tǒng)失效的概率。設(shè)規(guī)定的時間為t0，軟件發(fā)生失效的時間為t，則：R(t0)=P(t>t0)失效率：軟件在規(guī)定條件下和規(guī)定時間內(nèi)，喪失規(guī)定功能的概率。設(shè)規(guī)定的時間為t0，軟件發(fā)生失效的時間為t，則：F(t0)=P(t>t0)失效率與可靠度的關(guān)系：F(t0)=1-R(t0)平均失效前時間（MTTF）：指當前時間到下一次失效時間的均值。平均故障間隔時長（MTBF）：周期內(nèi)總時長/故障次數(shù)，代表平均故障間隔時長，用于考核周期內(nèi)的故障的頻繁程度。故障出現(xiàn)了總要修復，修復后可能再次出現(xiàn)，這個指標對經(jīng)常重復出現(xiàn)的故障也很有參考意義。可理解為這個產(chǎn)品平均每隔一個MTBF就會發(fā)生一次故障。平均故障修復時長（MTTR）：每個故障會有一定的不可用時長，MTTR是統(tǒng)計各級故障的平均不可用時長。故障率（風險函數(shù)）：維修率：平均無故障時間平均維護時間有效度殘留的缺陷數(shù)目：可以采用撒播模型、Akiyama模型、Halstead模型等進行估計?？煽啃裕?59軟件運行剖面該系統(tǒng)根據(jù)用戶使用軟件方式分為系統(tǒng)模式1與系統(tǒng)模式2兩種系統(tǒng)模式，其中系統(tǒng)模式1被用戶使用的概率為0.6，系統(tǒng)模式2被用戶使用的概率為0.4。該系統(tǒng)共有功能1~功能5等5個功能，其中系統(tǒng)模式1下使用功能1、功能2、功能3，使用的概率分別為0.2、0.5、0.3；系統(tǒng)模式2下使用功能2、功能4、功能5，使用的概率分別為0.2、0.4、0.4；這樣可以求得每個功能的使用概率，例如功能2的使用概率為：0.6×0.5+0.4×0.2=0.38。軟件可靠性模型軟件可靠性模型類型特點代表性模型呈指數(shù)分布的NHPP模型認為累積缺陷是一個獨立增量過程，其服從Poisson分布，并利用指數(shù)分布來描述缺陷的增長趨勢Jelinski-Moranda模型Schneidewind模型通用指數(shù)模型、Shooman模型Musa基本模型非指數(shù)分布的NHPP模型認為累積缺陷數(shù)是一個獨立增量過程，其服從Poisson分布，并利用非指數(shù)分布來描述缺陷的增長。相對于之后的缺陷排除，早期的缺陷排除對失效強度有更大的影響Musa&Okumoto對數(shù)泊松執(zhí)行時間模型Duane模型Yamada的S型模型Brooks和Motley二項式泊松模型類型貝葉斯模型貝葉斯方法認為，如果一個程序在不被使用的代碼中包含許多缺陷，那么這種軟件所表現(xiàn)出的可靠度可能要比在經(jīng)常使用的代碼中包含一個缺陷的軟件高。貝葉斯模型的特點則是認為可以根據(jù)歷史數(shù)據(jù)或?qū)＜医?jīng)驗對模型中的參數(shù)有一些認識，即可以通過先驗分布來考慮先驗知識與參數(shù)之間的關(guān)系，從而獲得更為準確的評價結(jié)果Litlewood-Verrall模型（L-V模型）軟件可靠性測試軟件可靠性測試是指在預期的使用環(huán)境中，為檢出軟件缺陷，驗證和評估是否達到用戶對軟件可靠性需求而組織實施的一種軟件測試。目的：（1）有效地發(fā)現(xiàn)程序中影響軟件可靠性的缺陷，從而實現(xiàn)可靠性增長。驗證軟件可靠性滿足一定的要求：通過對軟件可靠性測試中觀測到的失效情況進行分析，可以驗證軟件可靠性的定量要求是否得到滿足。估計、預計軟件可靠性水平。通過對軟件可靠性測試中觀測到的失效數(shù)據(jù)進行分析，可以評估當前軟件可靠性的水平，預測未來可能達到的水平，從而為開發(fā)管理提供決策依據(jù)。軟件可靠性增長測試軟件可靠性增長測試的目的是為了有效地發(fā)現(xiàn)程序中影響軟件可靠性的缺陷，通過排除這些缺陷實現(xiàn)軟件可靠性增長；根據(jù)失效數(shù)據(jù)可以評估當前軟件可靠性的水平，預測末來可能達到的水平，從而為軟件開發(fā)管理提供決策依據(jù)。軟件可靠性增長測試的特點測試目的通過測試—可靠性分析—修改—再測試—再分析—再修改的循環(huán)過程，使軟件達到可靠性要求測試人員通常由軟件研制方而非使用方進行測試測試階段通常在軟件系統(tǒng)測試階段測試場所一般在實驗室中進行測試對象軟件產(chǎn)品的中間形式

測試方法基于操作剖面的隨機測試方法測試特征測試過程中軟件出現(xiàn)失效后修改軟件、排除引起失效的缺陷，從而實現(xiàn)軟件可靠性的增長軟件可靠性增長測試——流程（1）測試策劃階段（2）測試設(shè)計與實現(xiàn)階段（3）軟件可靠性增長測試執(zhí)行階段（4）軟件可靠性測試總結(jié)階段165本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試安全性測試軟件安全性是指在非正常條件下不發(fā)生安全事故的能力。安全性測試是檢查系統(tǒng)對非法侵入的防范能力，其目的是為了發(fā)現(xiàn)軟件系統(tǒng)中是否存在安全漏洞。在安全性測試過程中，測試者扮演著一個試圖攻擊系統(tǒng)的角色。測試者可以嘗試通過外部的手段來獲取系統(tǒng)的密碼，使用能夠瓦解任何防護的客戶軟件來攻擊系統(tǒng)；可以把系統(tǒng)“制服”，使別人無法訪問；可以有目的地引發(fā)系統(tǒng)錯誤，期望在系統(tǒng)恢復過程中侵入系統(tǒng)；可以通過瀏覽非保密的數(shù)據(jù)，從中找到進入系統(tǒng)的鑰匙等。只要有足夠的時間和資源，好的安全測試就一定能夠侵入一個系統(tǒng)。166安全性測試安全性一般分為兩個層次，即應(yīng)用程序級的安全性和系統(tǒng)級別的安全性，它們的關(guān)系如下：（1）應(yīng)用程序級別的安全性包括對數(shù)據(jù)或業(yè)務(wù)功能的訪問；而系統(tǒng)級別的安全性包括對系統(tǒng)的登錄或遠程訪問。（2）應(yīng)用程序級別的安全性可確保在預期的安全性情況下，操作者只能訪問特定的功能或用例，或者只能訪問有限的數(shù)據(jù)。例如，某財務(wù)系統(tǒng)可能會允許所有人輸入數(shù)據(jù)，創(chuàng)建新賬戶，但只允許管理員才能刪除這些數(shù)據(jù)或賬戶。（3）系統(tǒng)級別的安全性確保只有具備系統(tǒng)訪問權(quán)限的用戶才能訪問應(yīng)用程序，而且只能通過相應(yīng)的入口來訪問。167安全性測試方法功能驗證漏洞掃描模擬攻擊試驗偵聽技術(shù)168安全性測試步驟（1）執(zhí)行系統(tǒng)，進行使用環(huán)境中的風險和威脅分析。（2）以一種它們可以和系統(tǒng)的安全性動作相比較的方式來定義安全性需求和劃分優(yōu)先級。基于威脅分析，為系統(tǒng)定義安全需求，最關(guān)鍵的安全性需求應(yīng)該得到最大程度的關(guān)注。注意，系統(tǒng)最弱的鏈接也是重要的，定義安全性需求是一個多次反復的過程。（3）模擬安全行為。基于劃分的安全需求的優(yōu)先次序，識別形成系統(tǒng)安全動作的功能和它們依賴的優(yōu)先順序。（4）執(zhí)行安全性測試。要求使用合適的證據(jù)收集和測試工具。（5）估計基基于證據(jù)的安全活動的可能性和影響。合計出一個準確的結(jié)果及系統(tǒng)是否滿足安全性需求。169安全性測試工具AppScanAppScan提供了多種安全測試功能，涵蓋了應(yīng)用程序安全測試的各個方面。靜態(tài)應(yīng)用程序安全測試（SAST）通過分析源代碼、字節(jié)碼或二進制文件來檢測安全漏洞，例如SQL注入，提供詳細的修復建議。動態(tài)應(yīng)用程序安全測試（DAST）模擬攻擊者的行為，測試應(yīng)用程序?qū)嶋H攻擊的響應(yīng)和漏洞。交互式應(yīng)用程序安全測試（IAST）結(jié)合SAST和DAST的優(yōu)點，通過監(jiān)控應(yīng)用程序的內(nèi)部行為來識別和定位安全漏洞。此外，AppScan還提供針對iOS和Android應(yīng)用程序的移動應(yīng)用程序安全測試，確保移動應(yīng)用在各種平臺上的安全性。170171本章內(nèi)容系統(tǒng)功能測試性能測試可靠性測試安全性測試可用性測試可用性測試可用性測試（UsabilityTesting）是對于用戶友好性的測試，是指在設(shè)計過程中被用來改善易用性的一系列方法。測試人員為用戶提供一系列的操作場景和任務(wù)，讓他們?nèi)ネ瓿?，這些場景和任務(wù)與產(chǎn)品或服務(wù)密切相關(guān)，通過觀察來發(fā)現(xiàn)完成過程中出現(xiàn)了什么問題、以及用戶喜歡或不喜歡哪些功能和操作方式，并針對問題的根源提出改進的建議。172可用性測試可用性測試的價值在于能夠及早發(fā)現(xiàn)產(chǎn)品或服務(wù)中將會出現(xiàn)的、存在于用戶使用過程中的問題，從而在產(chǎn)品開發(fā)或正式投產(chǎn)之前給出改進建議，以較小的投入幫助開發(fā)人員全面改善產(chǎn)品，節(jié)約開發(fā)成本。典型的可用性測試會包含以下維度：（1）任務(wù)操作的成功率；（2）任務(wù)操作效率；（3）任務(wù)操作前的用戶期待；（4）任務(wù)操作后的用戶評價；（5）用戶滿意度；（6）各任務(wù)出錯率；（7）二次操作成功率；（8）二次識別率用戶操作過程中各認知緯度（視產(chǎn)品情況而定）。173可用性測試可用性測試的文檔主要包括：（1）日程安排文檔（2）用戶背景資料文檔（3）用戶協(xié)議（4）測試腳本（5）測試前問卷（6）測試后問卷（7）任務(wù)卡片（8）測試過程檢查文檔（9）過程記錄文檔（10）測試報告（11）影音資料174可用性測試方法（1）一對一用戶測試（2）啟發(fā)式評估（3）焦點小組175可用性測試方法一些測試人員應(yīng)當關(guān)注的可用性問題包括：（1）過分復雜的功能或者指令；（2）困難的安裝過程；（3）錯誤信息過于簡單，例如“系統(tǒng)錯誤”；（4）語法難于理解和使用；（5）非標準的GUI接口；（6）用戶被迫去記住太多的信息；（7）難以登錄；（8）幫助文本上下文不敏感或者不夠詳細；（9）和其他系統(tǒng)之間的連接太弱；（10）默認不夠清晰；（11）接口太簡單或者太復雜；（12）語法、格式和定義不一致；（13）沒有給用戶提供所有輸入的清晰的認識。176測試案例：石大云課堂第一步測試前期準備組件測試團隊團隊4人，1名數(shù)據(jù)庫工程師，1名系統(tǒng)工程師，1名性能測試設(shè)計和分析人員，1名性能測試開發(fā)和實施人員測試工具需求確認支持對Web系統(tǒng)的性能測試，支持http與https協(xié)議負載生成器和調(diào)度工具運行在windows平臺上支持對weblogic、tomcat、mysql的性能計數(shù)器進行監(jiān)控性能預備測試響應(yīng)時間較長模塊：上傳教學資料、發(fā)布新聞并發(fā)訪問量大的模塊：新聞瀏覽177測試案例：石大云課堂第二步測試工具引入開源性能測試工具JMeter178測試案例：石大云課堂第三步測試計劃用戶活動剖析用戶主要為學生、教師、教學管理人員、其它游客業(yè)務(wù)操作識別出不同用戶的業(yè)務(wù)操作詳細描述各業(yè)務(wù)的操作步驟分析出用戶活動分析表，每個業(yè)務(wù)的使用用戶數(shù)量、業(yè)務(wù)發(fā)生數(shù)確定性能指標瀏覽通知頁面響應(yīng)時間小于5秒服務(wù)器的CPU平均使用率低于70%，內(nèi)存使用率小于75%制定測試時間計劃179測試案例：石大云課堂第四步測試設(shè)計與開發(fā)測試環(huán)境設(shè)計根據(jù)可能的業(yè)務(wù)情況，可設(shè)計多種測試環(huán)境測試場景設(shè)計各業(yè)務(wù)占百分比、測試指標、監(jiān)測哪些性能計數(shù)器測試用例設(shè)計腳本和輔助工具的開發(fā)180測試案例：石大云課堂第五步測試執(zhí)行與管理建立測試環(huán)境部署測試腳本和測試環(huán)境執(zhí)行測試和記錄結(jié)果181測試案例：石大云課堂第六步測試分析部署環(huán)境的系統(tǒng)性能分析硬件設(shè)備對系統(tǒng)性能表現(xiàn)的影響分析不同接入速率對響應(yīng)時間的影響分析其它分析測試中發(fā)現(xiàn)的功能問題182第12章驗收測試主要內(nèi)容驗收測試概述驗收測試計劃驗收測試用例實施驗收測試軟件測試報告184主要內(nèi)容驗收測試概述驗收測試計劃驗收測試用例實施驗收測試軟件測試報告185案例討論：畢業(yè)設(shè)計管理系統(tǒng)如何驗收測試186（1）系統(tǒng)設(shè)置：系統(tǒng)管理員進行的各種系統(tǒng)設(shè)置，包括各種角色的權(quán)限分配、學院個子部門的設(shè)置、教師上報畢業(yè)設(shè)計題目數(shù)量的設(shè)置、畢業(yè)設(shè)計各階段工作的時限設(shè)置。（2）通知公告。（3）基礎(chǔ)信息：學生、教師的信息管理。（4）申報題目：教師申報題目，具有自主上報題目的學生申報題目。（5）審批題目：系主任、教學院長審批申報的題目。（6）學生選題。（7）學生論文：包括指導教師下達任務(wù)書、學生填寫中期報告、學生上傳畢業(yè)論文及其它畢業(yè)設(shè)計成果。（8）論文導出：教學秘書導出學生論文的各類信息，包括《本科生畢業(yè)設(shè)計（論文）選題申報表》、《本科生畢業(yè)設(shè)計（論文）題目匯總表》；學生導出《本科畢業(yè)設(shè)計（論文）手冊》等。驗收測試驗收測試是在軟件產(chǎn)品完成了功能測試和系統(tǒng)測試之后、產(chǎn)品發(fā)布之前所進行的一項黑盒測試，是軟件測試活動的技術(shù)測試的最后一個階段，也稱之為交付測試。驗收測試是為了向用戶表明系統(tǒng)能夠按照用戶需求正常運行。187開發(fā)驗證驗收測試的主要內(nèi)容制定驗收測試標準標準？配置項復審何為配置項？實施驗收測試188驗收測試步驟熟悉軟件需求分析編制《驗收測試計劃》和《項目驗收準則》驗收測試設(shè)計和驗收測試用例設(shè)計驗收測試環(huán)境搭建驗收測試實施驗收測試結(jié)果分析編制驗收測試報告189驗收測試標準要進行驗收測試，同樣需要制訂測試計劃和過程；無論是測試計劃還是測試過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。驗收測試完成標準如下：（1）完全執(zhí)行了驗收測試計劃中的每個測試用例。（2）在驗收測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且通過了測試，或者經(jīng)過評估留待下一版本中修改。（3）完成軟件驗收測試報告。190主要內(nèi)容驗收測試概述驗收測試計劃驗收測試用例實施驗收測試軟件測試報告191驗收測試計劃（1）背景知識包括測試的目的：規(guī)范協(xié)助客戶確認軟件或系統(tǒng)集成項目已達到合同規(guī)定的功能和質(zhì)量要求的程序，適用范圍：適用于向用戶交付的軟件和/或系統(tǒng)集成項目。（2）參與人員和職責管理部門根據(jù)客戶要求進行軟件和/或系統(tǒng)集成項目驗收前的準備，協(xié)助客戶完成驗收。開發(fā)部門根據(jù)客戶要求進行軟件產(chǎn)品或軟件項目驗收前的準備，協(xié)助客戶完成驗收（3）工作程序（4）質(zhì)量記錄：最終要給出“驗收測試報告”。192驗收測試計劃（3）工作程序①驗收前的準備：在產(chǎn)品驗收之前，管理部門開發(fā)部門根據(jù)合同中的驗收準則檢查所有軟件項及其配置是否完整，做好驗收準備。②驗收實施：根據(jù)合同的要求或雙方協(xié)商的結(jié)果，確定驗收時間、進度安排、驗收準則、軟/硬件環(huán)境和資源，以及雙方的具體職責。驗收工作應(yīng)由客戶負責主持，管理部門或開發(fā)部門應(yīng)協(xié)助客戶以便順利驗收，如需測試，本公司的驗收人員還應(yīng)協(xié)助客戶制定“驗收測試計劃”。根據(jù)合同規(guī)定或客戶要求，驗收測試可以是現(xiàn)場測試或在客戶認可的環(huán)境下進行。驗收測試盡可能由客戶實施，由開發(fā)部門給予協(xié)助。驗收過程以驗收準則為依據(jù)，所有與驗收準則不一致的地方，均認為存在問題，并由雙方確認問題的類型，記入“驗收測試報告”。③問題處理：在驗收測試過程中發(fā)現(xiàn)的問題根據(jù)合同規(guī)定來處理。如果合同中沒有規(guī)定，應(yīng)指明問題類型和責任歸屬，由開發(fā)部門與客戶協(xié)商解決辦法。應(yīng)將驗收過程中存在的問題及解決辦法寫入“驗收測試報告”，由項目管理部門存檔。193主要內(nèi)容驗收測試概述驗收測試計劃驗收測試用例實施驗收測試軟件測試報告194驗收測試用例驗收測試的目的決定了驗收測試用例的設(shè)計不同于其它測試，因而具有不同的特點，驗收測試用例應(yīng)當在研發(fā)階段測試用例的基礎(chǔ)上重新組織和編寫，而不能拿來直接使用。驗收測試用例范圍只是軟件功能的子集，并與客戶需求相對應(yīng)，具有粗粒度、面向客戶的特點，設(shè)計過程中要把握客戶的關(guān)注點并適當展示軟件的獨有特性，這樣才能達到較好的測試效果。驗收測試需要對一個已實現(xiàn)的軟件產(chǎn)品運行測試用例集。測試用例集由多個測試用例組成，每個測試用例包含一系列要運行的步驟以保證每個用例得以測試；測試用例也包含輸入數(shù)據(jù)與預期輸出結(jié)果。測試用例的測試結(jié)果是或者通過或者失敗。195驗收測試用例目標一個驗收測試用例有以下幾個主要目標：（1）產(chǎn)品所有者（Productowner）應(yīng)該能夠確認并驗證用戶故事已經(jīng)符合期望的實現(xiàn)。（2）開發(fā)人員能夠檢驗所開發(fā)產(chǎn)品是否符合需求。（3）沒有開發(fā)的部分不能夠被確認。196驗收測試用例不能直接使用研發(fā)階段的測試用例驗收測試用例范圍是軟件功能的子集，對應(yīng)著客戶需求驗收測試用例特點：粗粒度面向客戶197驗收測試用例畢業(yè)設(shè)計管理系統(tǒng)中學生上傳畢業(yè)論文的需求：登錄系統(tǒng)的學生可上傳*.doc格式的論文，文檔不超過20M，上傳的論文統(tǒng)一命名為學號-姓名-論文題目.doc，允許學生多次上傳。思考：如何為該功能模塊設(shè)計驗收測試用例？198驗收測試用例原則（1）驗收測試的目的主要是驗證軟件功能的正確性和需求的符合性。軟件研發(fā)階段的單元測試、集成測試、系統(tǒng)測試的目的是發(fā)現(xiàn)軟件錯誤，將軟件缺陷排除在交付客戶之前，而驗收測試是與客戶共同參與的，旨在確認軟件符合需求規(guī)格的驗證活動。這是組織和編寫驗收測試用例的出發(fā)點。（2）驗收測試用例所覆蓋的范圍應(yīng)該只是軟件功能的子集，而不是軟件的所有功能。在V模型中驗收測試和需求分析階段是對應(yīng)的，因此，驗收測試用例應(yīng)該與軟件需求規(guī)格說明書之間具有可追溯性。一個軟件產(chǎn)品可能使用在多個項目中，因而可能具有復雜多樣的功能，驗收測試不可能也沒有必要把研發(fā)階段所有的測試用例都拿出來重新執(zhí)行一遍。（3）驗收測試用例應(yīng)該是粗粒度的，結(jié)構(gòu)簡單、條理清晰，而不應(yīng)當過多地描述軟件內(nèi)部實現(xiàn)的細節(jié)。驗收測試預期結(jié)果的描述，要從用戶可以直觀感知的方面體現(xiàn)，而不是針對內(nèi)部數(shù)據(jù)結(jié)構(gòu)的展示。因此，需要用黑盒測試的方法，盡量屏蔽軟件的內(nèi)部結(jié)構(gòu)。（4）驗收測試用例的組織應(yīng)當面向客戶，從客戶使用和業(yè)務(wù)場景的角