軟件測試基本過程

軟件測試基本過程第一頁，共九十七頁，編輯于2023年，星期四4.1軟件測試的復雜性分析1、無法對程序進行完全測試（1）測試所需要的輸入量太大（2）測試的輸出結果太多（3）軟件實現(xiàn)的途徑太多（4）軟件規(guī)格說明沒有一個客觀標準

2、測試無法顯示潛在的軟件缺陷和故障

——通過軟件測試只能報告軟件已被發(fā)現(xiàn)的缺陷和故障，無法報告隱藏的軟件故障。

3、存在的故障現(xiàn)象與發(fā)現(xiàn)的故障數(shù)量成正比

——結論：應當對故障集中的程序段進行重點測試Return第二頁，共九十七頁，編輯于2023年，星期四軟件測試的復雜性分析（續(xù)）4、不能修復所有的軟件故障

——原因：沒有足夠的進行修復；修復的風險較大；不值得修復；可不算做故障的一些缺陷；“殺蟲劑現(xiàn)象”。

——結論：關鍵是要進行正確的判斷、合理的取舍，根據(jù)風險分析決定哪些故障必須修復，哪些故障可以不修復。

5、軟件測試的代價

——工作原則：就是如何將無邊無際的可能性減小到一個可以控制的范圍，以及如何針對軟件風險做出恰當選擇，去粗存精，找到最佳的測試量，使得測試工作量不多也不少，既能達到測試的目的，又能較為經(jīng)濟。

第三頁，共九十七頁，編輯于2023年，星期四軟件測試的復雜性分析（續(xù)）軟件缺陷故障數(shù)量測試工作量測試中測試后測試費用遺漏缺陷數(shù)目優(yōu)化測試量圖4-1測試工作量和軟件缺陷數(shù)量之間的關系第四頁，共九十七頁，編輯于2023年，星期四4.2軟件測試方法與策略4.2.1靜態(tài)測試與動態(tài)測試4.2.2黑盒測試與白盒測試4.2.3軟件測試過程Return第五頁，共九十七頁，編輯于2023年，星期四軟件測試策略什么是軟件測試策略？

——是為軟件工程過程定義的一個軟件測試的模板，也就是把特定的測試用例方法放置進去的一系列步驟。軟件測試策略包含的特征：（1）測試從模塊層開始，然后擴大延伸到整個基于計算機的系統(tǒng)集合中。（2）不同的測試技術適用于不同的時間點。（3）測試是由軟件的開發(fā)人員和（對于大型系統(tǒng)而言）獨立的測試組來管理的。（4）測試和調(diào)試是不同的活動，但是調(diào)試必須能夠適應任何的測試策略。第六頁，共九十七頁，編輯于2023年，星期四軟件測試充分性準則對任何軟件都存在有限的充分測試集合。如果一個軟件系統(tǒng)在一個測試數(shù)據(jù)集合上的測試是充分的，那么再多測試一些數(shù)據(jù)也應該是充分的。這一特性稱為單調(diào)性。即使對軟件所有成分都進行了充分的測試，也并不表明整個軟件的測試已經(jīng)充分了。這一特性稱為非復合性。即使對軟件系統(tǒng)整體的測試是充分的，也并不意味軟件系統(tǒng)中各個成分都已經(jīng)充分地得到了測試。這個特性稱為非分解性。軟件測試的充分性應該與軟件的需求和軟件的實現(xiàn)都相關。軟件越復雜，需要的測試數(shù)據(jù)就越多。這一特性稱為復雜性。測試得越多，進一步測試所能得到的充分性增長就越少。這一特性稱為回報遞減率。第七頁，共九十七頁，編輯于2023年，星期四4.2.1靜態(tài)測試與動態(tài)測試1、靜態(tài)測試靜態(tài)測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估。靜態(tài)測試包括代碼檢查、靜態(tài)結構分析、代碼質(zhì)量度量等。它可以由人工進行，也可以借助軟件工具自動進行。靜態(tài)測試方法也可利用計算機作為對被測程序進行特性分析的工具，但與人工測試方式有著根本區(qū)別。另一方面，因它并不真正運行被測程序，只進行特性分析，這又與動態(tài)方法不同。所以，靜態(tài)方法常常稱為“分析”，靜態(tài)測試是對被測程序進行特性分析方法的總稱。第八頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）

代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面。代碼檢查的具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等。代碼檢查的優(yōu)點：在實際使用中，代碼檢查比動態(tài)測試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。代碼檢查的缺點：非常耗費時間，而且代碼檢查需要知識和經(jīng)驗的積累。第九頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）

靜態(tài)結構分析靜態(tài)結構分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結構。例如函數(shù)調(diào)用關系圖、函數(shù)內(nèi)部控制流圖。其中：

——函數(shù)調(diào)用關系圖以直觀的圖形方式描述一個應用程序中各個函數(shù)的調(diào)用和被調(diào)用關系；

——控制流圖顯示一個函數(shù)的邏輯結構，由許多節(jié)點組成，一個節(jié)點代表一條語句或數(shù)條語句，連接結點的叫邊，邊表示節(jié)點間的控制流向。第十頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）

代碼質(zhì)量度量軟件質(zhì)量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質(zhì)量是軟件屬性的各種標準度量的組合。針對軟件的可維護性，目前業(yè)界主要存在三種度量參數(shù)：Line復雜度、Halstead復雜度和McCabe復雜度。其中Line復雜度以代碼的行數(shù)作為計算的基準。Halstead以程序中使用到的運算符與運算元數(shù)量作為計數(shù)目標（直接測量指標），然后可以據(jù)以計算出程序容量、工作量等。McCabe復雜度一般稱為圈復雜度，它將軟件的流程圖轉化為有向圖，然后以圖論來衡量軟件的質(zhì)量。第十一頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）靜態(tài)測試階段的任務：（1）檢查算法的邏輯正確性。（2）檢查模塊接口的正確性。（3）檢查輸入?yún)?shù)是否有合法性檢查。（4）檢查調(diào)用其他模塊的接口是否正確。（5）檢查是否設置了適當?shù)某鲥e處理。（6）檢查表達式、語句是否正確，是否含有二義性。（7）檢查常量或全局變量使用是否正確。（8）檢查標識符的使用是否規(guī)范、一致。（9）檢查程序風格的一致性、規(guī)范性。（10）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。第十二頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）靜態(tài)測試可以完成以下工作：（1）發(fā)現(xiàn)下列程序的錯誤：錯用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當?shù)难h(huán)嵌套或分支嵌套、死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標號或代碼。（2）找出以下問題的根源：從未使用過的變量；不會執(zhí)行到的代碼、從未使用過的標號；潛在的死循環(huán)。（3）提供程序缺陷的間接信息：所用變量和常量的交叉應用表；是否違背編碼規(guī)則；標識符的使用方法和過程的調(diào)用層次。（4）為進一步查找做好準備。（5）選擇測試用例。（6）進行符號測試。第十三頁，共九十七頁，編輯于2023年，星期四靜態(tài)測試與動態(tài)測試（續(xù)）2、動態(tài)測試動態(tài)方法的主要特征是：

——計算機必須真正運行被測試的程序，通過輸入測試用例，對其運行情況即輸入與輸出的對應關系進行分析，以達到檢測的目的。動態(tài)測試包括：（1）功能確認與接口測試（2）覆蓋率分析（3）性能分析（4）內(nèi)存分析第十四頁，共九十七頁，編輯于2023年，星期四4.2.2黑盒測試和白盒測試若測試規(guī)劃是基于產(chǎn)品的功能，目的是檢查程序各個功能是否能夠實現(xiàn)，并檢查其中的功能錯誤，則這種測試方法稱為黑盒測試(Black-boxTesting)方法。

——黑盒測試又稱為功能測試、數(shù)據(jù)驅動測試和基于規(guī)格說明的測試。它是一種從用戶觀點出發(fā)的測試，一般被用來確認軟件功能的正確性和可操作性。若測試規(guī)劃基于產(chǎn)品的內(nèi)部結構進行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個部分功能是否得到充分使用，則這種測試方法稱為白盒測試(White-boxTesting)方法。

——白盒測試又稱為結構測試、邏輯驅動測試或基于程序的測試，一般用來分析程序的內(nèi)部結構。

第十五頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）白盒測試黑盒測試兩種測試方法從完全不同的角度出發(fā)，反映了測試思路的兩方面情況，適用于不同的測試階段。第十六頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）1、黑盒測試黑盒測試的基本觀點是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程，被測程序被認為是一個打不開的黑盒子，黑盒中的內(nèi)容（實現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測試主要根據(jù)規(guī)格說明書設計測試用例，并不涉及程序內(nèi)部構造和內(nèi)部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。黑盒測試的特點：（1）黑盒測試與軟件的具體實現(xiàn)過程無關，在軟件實現(xiàn)的過程發(fā)生變化時，測試用例仍然可以使用。（2）黑盒測試用例的設計可以和軟件實現(xiàn)同時進行，這樣能夠壓縮總的開發(fā)時間。第十七頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）輸入輸出黑盒測試是在程序接口進行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。也被稱為用戶測試。第十八頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：是否有不正確或遺漏了的功能？在接口上，輸入能否正確地接受？能否輸出正確的結果？是否有數(shù)據(jù)結構錯誤或外部信息訪問錯誤？性能上是否能夠滿足要求？是否有初始化或終止性錯誤？黑盒測試的難點：在哪個層次上進行測試？黑盒測試的具體技術方法：邊界值分析法等價類劃分法因果圖法決策表法第十九頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）2、白盒測試白盒測試將被測程序看作一個打開的盒子，測試者能夠看到被測源程序，可以分析被測程序的內(nèi)部結構，此時測試的焦點集中在根據(jù)其內(nèi)部結構設計測試用例。白盒測試要求是對某些程序的結構特性做到一定程度的覆蓋，或者說這種測試是“基于覆蓋率的測試”。通常的程序結構覆蓋有：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋路徑覆蓋第二十頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）白盒測試需要完全了解程序結構和處理過程，它按照程序內(nèi)部邏輯測試程序，檢驗程序中每條通路是否按預定要求正確工作。也被稱為程序員測試。應用程序第二十一頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）？X=2

y=2xY=4X=2Y=4未知等式與已知等式黑盒白盒3、黑盒測試法和白盒測試法的比較第二十二頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）黑盒測試：

——以用戶的觀點，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系，即根據(jù)程序外部特性進行測試，而不考慮內(nèi)部結構及工作情況。

——黑盒測試技術注重于軟件的信息域（范圍），通過劃分程序的輸入和輸出域來確定測試用例。

——若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤，則應用黑盒測試方法是不能發(fā)現(xiàn)問題的。白盒測試：

——只根據(jù)程序的內(nèi)部結構進行測試。

——測試用例的設計要保證測試時程序的所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。

——如果程序的結構本身有問題，比如說程序邏輯有錯誤或者有遺漏，那也是無法發(fā)現(xiàn)的。第二十三頁，共九十七頁，編輯于2023年，星期四黑盒測試和白盒測試（續(xù)）項目黑盒測試法白盒測試法規(guī)劃方面功能的測試結構的測試優(yōu)點方面能確保從用戶的角度出發(fā)進行測試能對程序內(nèi)部的特定部位進行覆蓋測試缺點方面無法測試程序內(nèi)部特定部位；當規(guī)格說明有誤，則不能發(fā)現(xiàn)問題無法檢查程序的外部特性；無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進行測試應用范圍邊界分析法等價類劃分法決策表測試語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，路徑覆蓋，循環(huán)覆蓋，模塊接口測試第二十四頁，共九十七頁，編輯于2023年，星期四4.2.3軟件測試過程單元測試單元測試單元測試集成測試集成測試確認測試系統(tǒng)測試*這三個測試可能交叉與前后互換被測模塊被測模塊被測模塊設計信息單元軟件需求其它元素用戶信息其它元素*…*驗收測試*交付用戶…圖2-2軟件測試的過程流程第二十五頁，共九十七頁，編輯于2023年，星期四軟件測試過程（續(xù)）單元測試：針對每個單元的測試，

以確保每個模塊能正常工作為目標。集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在于檢驗與軟件設計相關的程序結構問題。系統(tǒng)測試：檢驗軟件產(chǎn)品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作。驗收（用戶）測試：檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用，同時軟件開發(fā)人員也應有一定程度的參與。第二十六頁，共九十七頁，編輯于2023年，星期四一個實用軟件測試過程一種簡單實用的軟件測試過程模型POCERM。測試過程中必需的基本測試活動及其產(chǎn)生的結果：擬定軟件測試計劃(Plans)編制軟件測試大綱(Outlines)設計和生成測試用例(testCasegeneration)實施測試(Execution)生成軟件測試報告(softwaretestingReports)軟件問題報告SPR(SoftwareProblemReport)測試結果報告(testresultReports)第二十七頁，共九十七頁，編輯于2023年，星期四4.3單元測試4.3.1單元測試的主要任務4.3.2單元測試的執(zhí)行過程Return第二十八頁，共九十七頁，編輯于2023年，星期四4.3.1單元測試的定義單元測試（UnitTesting）是指對軟件中的最小可測試單元或基本組成單元進行檢查和驗證。傳統(tǒng)的認識是將單元定義為一個具體的函數(shù)或一個類的方法，但是這樣做存在很多問題。如，有的函數(shù)結構非常短或代碼很短，將導致工作量太大且不一定存在嚴重缺陷，從而降低測試效率。將一個類方法作為單元來測試，破壞面向對象的封裝性，無法有效利用繼承的優(yōu)勢。一般可遵循如下的單元選取原則：（1）對于C語言面向過程的開發(fā)語言來說，單元常指一個韓碩或子過程；（2）對于C++,Java語言等面向對象的開發(fā)語言來說，單元一般指一個類；（3）圖形化軟件中，單元常指一個窗口或一個菜單。注：單元測試是覆蓋代碼區(qū)間的最小單元。第二十九頁，共九十七頁，編輯于2023年，星期四4.3.1單元測試的主要任務單元測試針對每個程序的模塊，主要測試5個方面的問題：

——模塊接口、局部數(shù)據(jù)結構、邊界條件、獨立的路徑和錯誤處理。模塊模塊接口局部數(shù)據(jù)結構路徑測試出錯處理邊界條件第三十頁，共九十七頁，編輯于2023年，星期四單元測試的主要任務（續(xù)）模塊接口這是對模塊接口進行的測試，檢查進出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進行。模塊接口測試至少需要如下的測試項目：（1）調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配；（2）所測模塊調(diào)用子模塊時，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個數(shù)、屬性、順序上是否匹配；（3）是否修改了只做輸入用的形式參數(shù)；（4）調(diào)用標準函數(shù)的參數(shù)在個數(shù)、屬性、順序上是否正確；（5）全局變量的定義在各模塊中是否一致。第三十一頁，共九十七頁，編輯于2023年，星期四單元測試的主要任務（續(xù)）局部數(shù)據(jù)結構在模塊工作過程中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關系不發(fā)生錯誤。對于局部數(shù)據(jù)結構，應該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：（1）不正確的或不一致的類型說明。（2）錯誤的初始化或默認值。（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。（4）下溢、上溢或者地址錯誤。第三十二頁，共九十七頁，編輯于2023年，星期四單元測試的主要任務（續(xù)）路徑測試在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產(chǎn)生的錯誤。常見的錯誤有：誤解的或不正確的算術優(yōu)先級；混合模式的運算；錯誤的初始化；精確度不夠精確；表達式的不正確符號表示。針對判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯誤：不同數(shù)據(jù)類型的比較；不正確的邏輯操作或優(yōu)先級；應當相等的地方由于精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當遇到分支循環(huán)時不能退出；不適當?shù)匦薷难h(huán)變量。第三十三頁，共九十七頁，編輯于2023年，星期四單元測試的主要任務（續(xù)）邊界條件采用邊界值分析方法來設計測試用例，認真仔細地測試為限制數(shù)據(jù)處理而設置的邊界處，看模塊是否能夠正常工作。一些可能與邊界有關的數(shù)據(jù)類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測試中，應設計測試用例檢查以下情況：（1）在n次循環(huán)的第0次、1次、n次是否有錯誤。（2）運算或判斷中取最大值、最小值時是否有錯誤。（3）數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯誤。第三十四頁，共九十七頁，編輯于2023年，星期四單元測試的主要任務（續(xù)）出錯處理測試出錯處理的重點是模塊在工作中發(fā)生了錯誤，其中的出錯處理設施是否有效。檢驗程序中的出錯處理可能面對的情況有：（1）對運行發(fā)生的錯誤描述難以理解。（2）所報告的錯誤與實際遇到的錯誤不一致。（3）出錯后，在錯誤處理之前就引起系統(tǒng)的干預。（4）例外條件的處理不正確。（5）提供的錯誤信息不足，以至于無法找到錯誤的原因。第三十五頁，共九十七頁，編輯于2023年，星期四4.3.2單元測試的執(zhí)行過程何時進行單元測試？單元測試常常是和代碼編寫工作同時進行的，在完成了程序編寫、復查和語法正確性驗證后，就應進行單元測試用例設計。在單元測試時，如果模塊不是獨立的程序，需要設置一些輔助測試模塊。輔助測試模塊有兩種：（1）驅動模塊(Drive)用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數(shù)據(jù)，將相關數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應的結果。（2）樁模塊(Stub)用來模擬被測模塊工作過程中所調(diào)用的模塊。它們一般只進行很少的數(shù)據(jù)處理。驅動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。第三十六頁，共九十七頁，編輯于2023年，星期四單元測試的執(zhí)行過程（續(xù)）被測模塊、驅動模塊和樁模塊共同構成了一個如下圖所示的單元測試的測試環(huán)境：測試用例被測模塊驅動模塊測試結果樁模塊1樁模塊2樁模塊3樁模塊n樁模塊…第三十七頁，共九十七頁，編輯于2023年，星期四第三十八頁，共九十七頁，編輯于2023年，星期四第三十九頁，共九十七頁，編輯于2023年，星期四4.4集成測試4.4.1非增量式測試4.4.2增量式測試4.4.3不同集成測試方法的比較4.4.4回歸測試Return第四十頁，共九十七頁，編輯于2023年，星期四集成測試的定義集成測試是在單元測試的基礎上，將所有已通過單元測試的模塊按照概要設計的要求組裝成子系統(tǒng)或系統(tǒng)，進行集成測試，目的是確保各單元模塊組合在一起后能夠按既定意圖協(xié)作運行。強調(diào)的是，不經(jīng)過單元測試的模塊是不應進行集成測試的。集成測試與單元測試和系統(tǒng)測試的區(qū)別（1）單元測試主要關注模塊的內(nèi)部，雖然它也關注模塊借口，但它是從內(nèi)部來查看接口，從個數(shù)、屬性和順序等方面查看輸入的實參與形參的匹配情況。而集成測試查看接口時主要關注穿越接口的數(shù)據(jù)、信息是否正確，是否會丟失。（2）集成測試僅對軟件系統(tǒng)展開測試，系統(tǒng)測試中所涉及的系統(tǒng)不僅包括被測試的軟件本身，還包括硬件及其相關外圍設備，即整個軟件系統(tǒng)以及與軟件系統(tǒng)交互的所有硬件與軟件平臺。系統(tǒng)測試更大程度上是站在用戶的角度來評價系統(tǒng)，包括驗證系統(tǒng)的主要功能，核實系統(tǒng)的性能水平、判斷是否達到安全性要求等。第四十一頁，共九十七頁，編輯于2023年，星期四集成測試的內(nèi)容集成測試的內(nèi)容包括模塊之間的接口以及集成后的功能。它使用黑盒測試方法測試集成的功能，并對以前的集成進行回歸測試，具體包含以下幾個方面：（1）將各模塊鏈接起來時，穿越模塊接口的數(shù)據(jù)是否丟失；（2）各子功能組合起來能偶達到預期要求的父功能；（3）一個模塊的功能是否會對其他模塊的功能產(chǎn)生不利影響；（4）全局數(shù)據(jù)結構是否有問題，是否會被異常修改；（5）單個模塊的誤差積累起來，是否會放大到不可接受的程度。集成測試的評價：測試用例的規(guī)模（規(guī)模越小越好）；驅動模塊的設計（數(shù)量越少越好）；樁模塊的設計（數(shù)量越少越好）；缺陷定位的難易程度（集成測試用例涉及的接口數(shù)量越少越好）。第四十二頁，共九十七頁，編輯于2023年，星期四4.4.1非增量式測試非增量式測試是采用一步到位的方法來構造測試：

——對所有模塊進行個別的單元測試后，按照程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。

實例采用非增量式測試方法進行集成測試非增量式測試的缺點：

——當一次集成的模塊較多時，非增量式測試容易出現(xiàn)混亂，因為測試時可能發(fā)現(xiàn)了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。第四十三頁，共九十七頁，編輯于2023年，星期四非增量式測試（續(xù)）AS3S4S5d2Cd4Ed5Fd1Bs1d3s2DABCDEFABCDEF（1）程序結構圖（3）集成測試示意圖（2）單元測試示意圖第四十四頁，共九十七頁，編輯于2023年，星期四4.4.2增量式測試增量式測試的集成是逐步實現(xiàn)的：

——逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實施次序，增量式集成測試又可以分為三種不同的方法：（1）自頂向下增量式測試（2）自底向上增量式測試（3）混合增量式測試第四十五頁，共九十七頁，編輯于2023年，星期四自頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按照結構圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結構向下進行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結構中去。深度優(yōu)先方式的集成：

——首先集成在結構中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。

廣度優(yōu)先方式的集成：

——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。第四十六頁，共九十七頁，編輯于2023年，星期四自頂向下增量式測試（續(xù)）集成測試的整個過程由3個步驟完成：（1）主控模塊作為測試驅動器。（2）根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。（3）在每個模塊被集成時，都必須進行單元測試。重復第2步，直到整個系統(tǒng)被測試完成。

實例按照廣度優(yōu)先方式進行集成測試實例按照深度優(yōu)先方式進行集成測試第四十七頁，共九十七頁，編輯于2023年，星期四自頂向下增量式測試（續(xù)）ABCDEFAS1S2S3ABCDS4S5ABCDEF（1）（2）（3）廣度優(yōu)先方式第四十八頁，共九十七頁，編輯于2023年，星期四自頂向下增量式測試（續(xù)）ABCDEFAS1S2S3ABS2S3EABCS3E（1）（2）（3）深度優(yōu)先方式（4）第四十九頁，共九十七頁，編輯于2023年，星期四自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結構圖自下而上進行的，即從程序模塊結構的最底層模塊開始集成和測試。由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。實例采用自底向上增量式測試方法進行集成測試第五十頁，共九十七頁，編輯于2023年，星期四自底向上增量式測試（續(xù)）ABCDEFd2Cd1Ed3Fd4BEd5FDABCDEF第五十一頁，共九十七頁，編輯于2023年，星期四混合增量式測試混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結合起來進行集成和測試。這樣可以兼具兩者的優(yōu)點，而摒棄其缺點。常見的兩種混合增量式測試方式：（1）衍變的自頂向下的增量式測試：基本思想是強化對輸入/輸出模塊和引入新算法模塊的測試，并自底向上集成為功能相對完整且相對獨立的子系統(tǒng)，然后由主模塊開始自頂向下進行增量式測試。（2）自底向上-自頂向下的增量式測試：首先對含讀操作的子系統(tǒng)自底向上直至根節(jié)點模塊進行集成和測試，然后對含寫操作的子系統(tǒng)做自頂向下的集成與測試。第五十二頁，共九十七頁，編輯于2023年，星期四4.4.3不同集成測試方法的比較1、非增量式測試與增量式測試的比較非增量式測試的方法是先分散測試，然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯誤，只會在最后的集成測試時一下子暴露出來。增量式測試是逐步集成和逐步測試的方法，把可能出現(xiàn)的差錯分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測試中，得到了較多次的考驗，因此，可能會取得較好的測試效果。

結論：增量式測試要比非增量式測試具有一定的優(yōu)越性。第五十三頁，共九十七頁，編輯于2023年，星期四不同集成測試方法的比較（續(xù)）2、自頂向下與自底向上增量式測試的比較自頂向下增量式測試：

——主要優(yōu)點在于它可以自然的做到逐步求精，一開始就能讓測試者看到系統(tǒng)的框架。

——主要缺點是需要提供樁模塊，并且在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據(jù)有一定困難。自底向上增量式測試：

——優(yōu)點在于，由于驅動模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構成有向的非環(huán)狀圖，生成測試數(shù)據(jù)也無困難。

——主要缺點在于，直到最后一個模塊被加進去之后才能看到整個程序（系統(tǒng)）的框架。第五十四頁，共九十七頁，編輯于2023年，星期四4.5系統(tǒng)測試為什么要進行系統(tǒng)測試？

——由于軟件只是計算機系統(tǒng)中的一個組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運行。因此，在投入運行前要完成系統(tǒng)測試，以保證各組成部分不僅能單獨的得到檢驗，而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。盡管每一個檢驗有特定的目標，然而所有的檢測工作都要驗證系統(tǒng)中每個部分均已得到正確的集成，并能完成指定的功能。嚴格的說，系統(tǒng)測試超出了軟件工程范圍。通常這項工作并不由系統(tǒng)開發(fā)人員或系統(tǒng)開發(fā)組織來承擔，而是由軟件用戶或軟件開發(fā)機構委托獨立測試機構來完成。

Return第五十五頁，共九十七頁，編輯于2023年，星期四功能測試功能測試也稱確認測試，主要是根絕軟件需要規(guī)格說明書來檢驗被測系統(tǒng)是否滿足用戶的功能使用要求，它是系統(tǒng)測試中最基本的測試。

功能測試的主要內(nèi)容：第五十六頁，共九十七頁，編輯于2023年，星期四恢復測試恢復測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統(tǒng)的恢復能力。恢復測試包含的內(nèi)容：

——如果系統(tǒng)恢復是自動的（由系統(tǒng)自身完成），則應該檢驗：重新初始化、檢驗點設置機構、數(shù)據(jù)恢復以及重新啟動是否正確。

——如果這一恢復需要人為干預，則應考慮平均修復時間是否在限定的、可以接受的范圍之內(nèi)。第五十七頁，共九十七頁，編輯于2023年，星期四安全測試安全測試的目的在于驗證安裝在系統(tǒng)內(nèi)的保護機制能否在實際中保護系統(tǒng)且不受非法入侵，不受各種非法干擾。在安全測試中，測試者扮演著試圖攻擊系統(tǒng)的個人角色：

—嘗試去通過外部的手段來獲取系統(tǒng)的密碼

—使用可以瓦解任何防守的客戶軟件來攻擊系統(tǒng)

—把系統(tǒng)“癱瘓”，使得其他用戶無法訪問

—有目的地引發(fā)系統(tǒng)錯誤，期望在恢復過程中侵入系統(tǒng)

—通過瀏覽非保密的數(shù)據(jù)，從中找到進入系統(tǒng)的鑰匙系統(tǒng)的安全測試要設置一些測試用例試圖突破系統(tǒng)的安全保密措施，檢驗系統(tǒng)是否有安全保密的漏洞。第五十八頁，共九十七頁，編輯于2023年，星期四強度測試從本質(zhì)上來說，強度測試（也稱壓力測試-StreeTesting）的目的是要檢測非正常的情形，測試是想要破壞程序。強度測試需要在反常規(guī)數(shù)據(jù)量、頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度。舉例：

—如果正常的中斷頻率為每秒5次，強度測試設計為每秒50次中斷。

—把輸入數(shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應。

—若某系統(tǒng)正常運行可支持200個終端并行工作，強度測試則檢驗1000個終端并行工作的情況。

—運行大量的消耗內(nèi)存或其他系統(tǒng)資源的測試實例。第五十九頁，共九十七頁，編輯于2023年，星期四性能測試性能測試用來測試軟件在系統(tǒng)集成中的運行性能，特別是針對實時系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測試可以在測試過程的任意階段進行，但只有當整個系統(tǒng)的所有成分都集成在一起后，才能檢查一個系統(tǒng)的真正性能。性能測試常常和強度（壓力）測試結合起來進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。第六十頁，共九十七頁，編輯于2023年，星期四性能測試已成為軟件質(zhì)量最重要的衡量標準之一，就是對軟件運行性能指標指標進行測試，判斷系統(tǒng)集成之后在實際的使用環(huán)境下能否穩(wěn)定、可靠的運行。性能測試是軟件測試的高端領域，主要包含以下兩個方面：（1）時間性能：主要指軟件的一個具體事務的響應時間；（2）空間性能：主要指軟件運行時消耗的系統(tǒng)資源。第六十一頁，共九十七頁，編輯于2023年，星期四性能測試的內(nèi)容：第六十二頁，共九十七頁，編輯于2023年，星期四第六十三頁，共九十七頁，編輯于2023年，星期四正確性測試正確性測試檢查軟件的功能是否符合規(guī)格說明。正確性測試的方法：

——枚舉法，即構造一些合理輸入，檢查是否得到期望的輸出。測試時應盡量設法減少枚舉的次數(shù)，關鍵在于尋找等價區(qū)間，因為在等價區(qū)間中，只需用任意值測試一次即可。

——邊界值測試，即采用定義域或者等價區(qū)間的邊界值進行測試。因為程序設計容易疏忽邊界情況，程序也容易在邊界值處出錯。

第六十四頁，共九十七頁，編輯于2023年，星期四可靠性測試可靠性測試是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達到預期的目標，同時給出當前系統(tǒng)可能的可靠性增長情況。對可靠性性測試來說，最關鍵的測試數(shù)據(jù)包括失效間隔時間，失效修復時間，失效數(shù)量，失效級別等。根據(jù)獲得的測試數(shù)據(jù)，應用可靠性模型，可以得到系統(tǒng)的失效率及可靠性增長趨勢?？煽啃灾笜擞袝r很難測試，通常采用平均無故障時間或系統(tǒng)投入運行后出現(xiàn)的故障不能大于多少數(shù)量這些指標來對可靠性進行評估。第六十五頁，共九十七頁，編輯于2023年，星期四兼容性測試軟件兼容性測試是檢測各軟件之間能否正確地交互和共享信息，其目標是保證軟件按照用戶期望的方式進行交互，使用其它軟件檢查軟件操作的過程。兼容性的測試通常需要解決以下問題：（1）新開發(fā)的軟件需要與哪種操作系統(tǒng)、Web瀏覽器和應用軟件保持兼容，如果要測試的軟件是一個平臺，那么要求應用程序能在其上運行。（2）應該遵守哪種定義軟件之間交互的標準或者規(guī)范。（3）軟件使用何種數(shù)據(jù)與其它平臺、與新的軟件進行交互和共享信息。第六十六頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）軟件兼容的實例：從Web頁面剪切文字，然后在文字處理程序中打開的文檔中粘貼。從電子表格程序保存賬目數(shù)據(jù)，然后在另一個完全不同的電子表格程序中讀入這些數(shù)據(jù)。使圖形處理軟件在同一操作系統(tǒng)下的不同版本正常工作。使文字處理程序從聯(lián)系人管理程序中讀取姓名和地址，打印個性化的邀請函和信封。升級到新的數(shù)據(jù)庫程序，讀入現(xiàn)存所有數(shù)據(jù)庫，并能夠像老版本一樣對其中的數(shù)據(jù)進行處理。第六十七頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）兼容性通常有4種——向前兼容與向后兼容、不同版本間的兼容、標準和規(guī)范、數(shù)據(jù)共享兼容（1）向前兼容和向后兼容向前兼容是指可以使用軟件的未來版本，向后兼容是指可以使用軟件的以前版本。并非所有的軟件都要求向前兼容和向后兼容，這是軟件設計者需要決定的產(chǎn)品特性。使用文本文件可以對向前兼容和向后兼容作一個簡單的演示：在Windows98上用Notepad創(chuàng)建的文本文件，它可以向后兼容MS-DOS1.0后的所有版本，它還可以向前兼容Windows2000甚至以后的版本。第六十八頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）在Windows98上運行的NotepadMYDATE.TXT在MS-DOS1.0上運行的Edit.exe在Windows3.1上運行的Notepad在Windows95上運行的Notepad向后兼容在Windows2000上運行的WordPad在未來操作系統(tǒng)上運行的未知軟件向前兼容第六十九頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）

（2）不同版本間的兼容不同版本間的兼容是指要實現(xiàn)測試平臺和應用軟件多個版本之間能夠正常工作。舉例：現(xiàn)在要測試一個流行的操作系統(tǒng)的新版本，當前操作系統(tǒng)上可能有數(shù)幾十上百萬現(xiàn)有程序，則新操作系統(tǒng)的目標是與它們百分之百兼容。因為不可能在一個操作系統(tǒng)上測試所有的軟件程序，因此需要決定哪些是最重要的、必須進行的。對于測試新應用軟件也一樣，需要決定在哪個平臺版本上測試，以及和什么應用程序一起測試。第七十頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）

（3）標準和規(guī)范適用于軟件平臺的標準和規(guī)范有兩個級別——高級標準和低級標準。高級標準是產(chǎn)品應當普遍遵守的，例如軟件能在何種操作系統(tǒng)上運行？是互聯(lián)網(wǎng)上的程序嗎？它運行于何種瀏覽器？每一項問題都關系到平臺，假若應用程序聲明與某個平臺兼容，就必須最受關于該平臺的標準和規(guī)范。低級標準是對產(chǎn)品開發(fā)細節(jié)的描述，從某種意義上說，低級標準比高級標準更加重要。第七十一頁，共九十七頁，編輯于2023年，星期四兼容性測試（續(xù)）

（4）數(shù)據(jù)共享兼容數(shù)據(jù)共享兼容是指要在應用程序之間共享數(shù)據(jù)，它要求支持并遵守公開的標準，允許用戶與其他軟件無障礙的傳輸數(shù)據(jù)。實例：

—在Windows環(huán)境下，程序間通過剪切、復制和粘貼實現(xiàn)數(shù)據(jù)共享。在此狀況下，傳輸通過剪貼板的程序來實現(xiàn)。若對某個程序進行兼容性測試就要確認其數(shù)據(jù)能夠利用剪切板與其他程序進行相互復制。

—通過讀寫移動外存實現(xiàn)數(shù)據(jù)共享，如軟磁盤、U盤、移動硬盤等，但文件的數(shù)據(jù)格式必須符合標準，才能在多臺計算機上保持兼容。第七十二頁，共九十七頁，編輯于2023年，星期四Web網(wǎng)站測試Web網(wǎng)站的網(wǎng)頁是由文字、圖形、音頻、視頻和超級鏈接組成的文檔。對網(wǎng)站的測試包含許多方面，如配置測試、兼容測試、可用性測試、文檔測試等；黑盒測試、白盒測試、靜態(tài)測試和動態(tài)測試都有可能采用。通常Web網(wǎng)站測試包含以下內(nèi)容：（1）文字測試（2）鏈接測試（3）圖像、圖像測試（4）表單測試（5）動態(tài)內(nèi)容測試（6）數(shù)據(jù)庫測試（7）服務器性能及負載測試（8）安全性測試第七十三頁，共九十七頁，編輯于2023年，星期四用戶界面測試第七十四頁，共九十七頁，編輯于2023年，星期四3）正確性第七十五頁，共九十七頁，編