1、第五章 軟件測試過程,5.1 軟件測試的過程 5.2 單元測試 5.3 集成測試 5.4 確認測試 5.5 系統(tǒng)測試 5.6 驗收測試 5.7 測試后的調試,本章教學目標,理解軟件測試的過程 明確單元測試的主要任務和過程 明確集成測試的方法和確認測試的準則 明確系統(tǒng)測試的八個領域測試要點 明確驗收測試的主要內容和相關配置,5.1 軟件測試過程,圖2-2 軟件測試的過程流程,軟件測試過程（續(xù)）,單元測試：針對每個單元的測試， 以確保每個模塊能正常工作為目標。 集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在于檢驗與軟件設計相關的程序結構問題。 確認（有效性）測試：是檢驗所開發(fā)的軟件能否滿

2、足所有功能和性能需求的最后手段。 系統(tǒng)測試：檢驗軟件產品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據庫及操作人員）協(xié)調工作。 驗收（用戶）測試：檢驗軟件產品質量的最后一道工序。主要突出用戶的作用，同時軟件開發(fā)人員也應有一定程度的參與。,一個實用軟件測試過程,一種簡單實用的軟件測試過程模型 POCERM。 測試過程中必需的基本測試活動及其產生的結果： 擬定軟件測試計劃 (Plans) 編制軟件測試大綱 (Outlines) 設計和生成測試用例 (test Case generation) 實施測試 (Execution) 生成軟件測試報告 (software testing Reports) 軟件問題

3、報告SPR (Software Problem Report) 測試結果報告 (test result Reports),一個實用軟件測試過程（續(xù)）,基本特性： （1）計劃性: 任務 人員 設備 時間 相關. （2）平行性: 開發(fā) 編碼 | 測試 再測試 （3）完整性: 計劃+大綱+用例+SPRs+. （4）重用性: 測試 再測試 回歸測試 升級 多平臺 （5）可重復性: SPRs 用例 大綱 再現(xiàn)Bugs （6）周期性: test cycles, regression, update （7）可管理性: well structured and organized QE group + well

4、 planned and prepared task,測試階段,測試過程的三個主要的測試活動（計劃、準備和實施） 可被分成五個階段： The planning and control phase計劃和控制階段 The preparation phase準備階段 The specification phase規(guī)范階段 The execution phase實施執(zhí)行階段 The completion phase完成（收尾）階段,測試的五個階段,計劃與控制階段,它是整個測試過程中最重要的階段，為實現(xiàn)可管理且高質量的測試過程提供基礎 。 本階段的主要工作內容： （1）擬定測試計劃 （2）論證那些使開發(fā)

5、過程難于管理和控制的因素 （3）明確軟件產品的最重要部分 （風險評估） 樣例：SCM測試計劃,準備階段,開始本階段的前提條件： 完成測試計劃的擬定。 需求規(guī)格說明書（第一版）的確定。 本階段的主要工作內容： 對需求規(guī)格說明書的仔細研究。 將要測試的產品分解成可獨立測試的單元。 為每個測試單元確定采用的測試技術。 為測試的下一個階段及其活動制定計劃。,規(guī)范階段,本階段的主要工作內容： 編寫測試大綱/測試用例，測試腳本 搭建測試環(huán)境 （測試數(shù)據庫，軟件環(huán)境，硬件環(huán)境） 測試用例描述的內容： 輸入 執(zhí)行過程 預期輸出 樣例：SCM測試用例設計,實施執(zhí)行階段,根據測試大綱/測試用例/測試腳本進行測試

6、（1）根據測試大綱/測試用例進行測試，找出預期的測試結果和實際測試結果之間的差異 （2）填寫軟件問題報告 （3）確定造成這些差異的原因： 產品有缺陷？規(guī)格說明書有缺陷？ 測試環(huán)境和測試下屬部件有缺陷？測試用例設計不合理？ 測試報告與管理層進行溝通的方式 已測試部分占產品多大的百分比？還有什么工作要做？ 找到了多少個問題或不足？測試的發(fā)展趨勢如何？ 測試可以結束了嗎？ 樣例：SCM測試報告1，測試報告2，測試報告3,完成階段,本階段的主要工作內容： 選擇和保留測試大綱、測試用例、測試結果、測試工具。 提交最終報告。 收尾工作的意義和重要性： 產品如果升級或功能變更，或維護，只要對保留下來的 相關

7、測試數(shù)只要作相應調整，就能夠進行新的測試。 樣例：測試報告合格品報告,5.2 單元測試,7.2.1 單元測試的主要任務 7.2.2 單元測試的執(zhí)行過程,7.2.1 單元測試的主要任務,單元測試針對每個程序的模塊，主要測試5個方面的問題： 模塊接口、局部數(shù)據結構、邊界條件、獨立的路徑和錯誤處理。,單元測試的主要任務（續(xù)）,模塊接口 這是對模塊接口進行的測試，檢查進出程序單元的數(shù)據流是否正確。模塊接口測試必須在任何其它測試之前進行。 模塊接口測試至少需要如下的測試項目： （1）調用所測模塊時的輸入參數(shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配； （2）所測模塊調用子模塊時，它輸入給子模塊的參數(shù)與

8、子模塊中的形式參數(shù)在個數(shù)、屬性、順序上是否匹配； （3）是否修改了只做輸入用的形式參數(shù)； （4）調用標準函數(shù)的參數(shù)在個數(shù)、屬性、順序上是否正確； （5）全局變量的定義在各模塊中是否一致。,單元測試的主要任務（續(xù)）,局部數(shù)據結構 在模塊工作過程中，必須測試模塊內部的數(shù)據能否保持完整性，包括內部數(shù)據的內容、形式及相互關系不發(fā)生錯誤。 對于局部數(shù)據結構，應該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤： （1）不正確的或不一致的類型說明。 （2）錯誤的初始化或默認值。 （3）錯誤的變量名，如拼寫錯誤或書寫錯誤。 （4）下溢、上溢或者地址錯誤。,單元測試的主要任務（續(xù)）,路徑測試 在單元測試中，最主要的測試是針對

9、路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產生的錯誤。 常見的錯誤有： 誤解的或不正確的算術優(yōu)先級；混合模式的運算；錯誤的初始化；精確度不夠精確；表達式的不正確符號表示。 針對判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯誤： 不同數(shù)據類型的比較；不正確的邏輯操作或優(yōu)先級；應當相等的地方由于精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當遇到分支循環(huán)時不能退出；不適當?shù)匦薷难h(huán)變量。,單元測試的主要任務（續(xù)）,邊界條件 邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設計測試用例，認真仔細地測試為限制數(shù)據處理而設置的邊界處，

10、看模塊是否能夠正常工作。 一些可能與邊界有關的數(shù)據類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低等特征。 在邊界條件測試中，應設計測試用例檢查以下情況： （1）在n次循環(huán)的第0次、1次、n次是否有錯誤。 （2）運算或判斷中取最大值、最小值時是否有錯誤。 （3）數(shù)據流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯誤。,單元測試的主要任務（續(xù)）,出錯處理 測試出錯處理的重點是模塊在工作中發(fā)生了錯誤，其中的出錯處理設施是否有效。 檢驗程序中的出錯處理可能面對的情況有： （1）對運行發(fā)生的錯誤描述難以理解。 （2）所報告的錯誤與實際

11、遇到的錯誤不一致。 （3）出錯后，在錯誤處理之前就引起系統(tǒng)的干預。 （4）例外條件的處理不正確。 （5）提供的錯誤信息不足，以至于無法找到錯誤的原因。,7.2.2 單元測試的執(zhí)行過程,何時進行單元測試？單元測試常常是和代碼編寫工作同時進行的，在完成了程序編寫、復查和語法正確性驗證后，就應進行單元測試用例設計。 在單元測試時，如果模塊不是獨立的程序，需要設置一些輔助測試模塊。輔助測試模塊有兩種： （1）驅動模塊(Drive) 用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數(shù)據，將相關數(shù)據傳送給被測模塊，啟動被測模塊，并打印出相應的結果。 （2）樁模塊(Stub) 用來模擬被測模塊

12、工作過程中所調用的模塊。它們一般只進行很少的數(shù)據處理。 驅動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產品提供給用戶。,單元測試的執(zhí)行過程（續(xù)）,被測模塊、驅動模塊和樁模塊共同構成了一個如下圖所示的單元測試的測試環(huán)境：,5.3 集成測試,集成測試：也叫組裝測試、聯(lián)合測試、子系統(tǒng)測試或部件測試。是在單元測試的基礎上，將所有模塊按照概要設計要求（如類結構圖或功能結構圖等）組裝成子系統(tǒng)或系統(tǒng)。,A,B,C,集成測試內容,集成測試主要考慮以下內容： 在把各個模塊連接起來時，穿越模塊接口的數(shù)據是否會丟失？ 各個子功能組合起來，能否達到預期要求的父功能。 一個模塊的功能功能

13、是否會對另一個模塊的功能產生不利影響。 全局數(shù)據結構是否有問題，會不會被異常修改？ 單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度？,集成測試策略,5.3.1 大爆炸集成 （非增量式） 5.3.8 基于功能的集成 5.3.2 自頂向下集成 5.3.9 高頻集成 5.3.3 自底向上集成 5.3.10 基于進度的集成 5.3.4 三明治集成 5.3.11 基于風險的集成 5.3.5 修改的三明治集成 5.3.12 基于事件（消息）的集成 5.3.6 基干集成 5.3.13 基于使用的集成 5.3.7 分成集成,7.3.1 大爆炸集成測試,大爆炸集成測試是采用一步到位的方法來構造測試，

14、也叫非增量式測試： 對所有模塊進行個別的單元測試后，按照程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。 實例 采用非增量式測試方法進行集成測試 非增量式測試的缺點： 當一次集成的模塊較多時，非增量式測試容易出現(xiàn)混亂，因為測試時可能發(fā)現(xiàn)了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。,非增量式測試（續(xù)）,（1）程序結構圖,（3）集成測試示意圖,（2）單元測試示意圖,5.3.2 增量式測試,增量式測試的集成是逐步實現(xiàn)的： 逐次將未曾集成測試的模塊和已經集成測試的模塊（或子系統(tǒng)）結合成程序包，再

15、將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產生的問題。 按照不同的實施次序，增量式集成測試又可以分為三種不同的方法： （1）自頂向下增量式測試 （2）自底向上增量式測試 （3）混合增量式測試,自頂向下增量式測試,自頂向下增量式測試表示逐步集成和逐步測試是按照結構圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結構向下進行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結構中去。 深度優(yōu)先方式的集成： 首先集成在結構中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。 廣度優(yōu)先方式的集成： 首先沿著水平方向，

16、把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。,自頂向下增量式測試（續(xù)）,集成測試的整個過程由3個步驟完成： （1）主控模塊作為測試驅動器。 （2）根據集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。 （3）在每個模塊被集成時，都必須進行單元測試。 重復第2步，直到整個系統(tǒng)被測試完成。 實例 按照廣度優(yōu)先方式進行集成測試 實例 按照深度優(yōu)先方式進行集成測試,自頂向下增量式測試（續(xù)）,（1）,（2）,（3）,廣度優(yōu)先方式,自頂向下增量式測試（續(xù)）,（1）,（2）,（3）,深度優(yōu)先方式,（4）,自底向上增量式測試,自底向上增量式測試表示逐步集成和逐步測試的工作是按結構

17、圖自下而上進行的，即從程序模塊結構的最底層模塊開始集成和測試。 由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。 實例 采用自底向上增量式測試方法進行集成測試,自底向上增量式測試（續(xù)）,混合增量式測試,混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結合起來進行集成和測試。這樣可以兼具兩者的優(yōu)點，而摒棄其缺點。 常見的三種混合增量式測試方式： （1）衍變的自頂向下的增量式測試：基本思想是強化對輸入/輸出模塊和引入新算法模塊的測試，并

18、自底向上集成為功能相對完整且相對獨立的子系統(tǒng)，然后由主模塊開始自頂向下進行增量式測試。 （2）自底向上-自頂向下的增量式測試：首先對含讀操作的子系統(tǒng)自底向上直至根節(jié)點模塊進行集成和測試，然后對含寫操作的子系統(tǒng)做自頂向下的集成與測試。 （3）三明治增量式測試：把系統(tǒng)分為3層，中間一層為目標層。測試的時候，對目標層上面的一層使用自頂向下的集成策略，對目標層下面的一層使用時用自頂向上的集成策略，最后在目標層進行會合。,三明治集成策略（續(xù)）,層1,層2,層3,測試E,測試F,測試A,測試B，E,測試D，F(xiàn),測試A，B，C，D，E，F(xiàn),頂層測試,底層測試,三明治測試缺點： 中間層測試不充分,其他集成策略

19、（1）,層1,層2,層3,改進三明治集成：對目標層進行獨立測試（需要驅動和樁）,其他集成策略（2）,基干集成：在很多系統(tǒng)中，尤其是嵌入式系統(tǒng)中，一般分為2部分：內核部分（基干）和外部應用部分。這兩部分通常是不同的人開發(fā)。 基干集成的策略就是： （1）對基干中的每個模塊進行單獨、充分的測試，必要時用驅動和樁； （2）對基干中所有的模塊進行大爆炸集成； （3）對應用控制子系統(tǒng)進行自頂向下集成； （4）把基干和控制子系統(tǒng)進行集成，重新構造子系統(tǒng)； （5）對應用部分采用自底向上集成策略。,其他集成策略（3）,分層集成：對于類似通信系統(tǒng)中，可以把系統(tǒng)按照功能劃分為不同功能層次的子系統(tǒng)（例如：MVC等N層

20、架構或中間件、DLL等），可以采用分層集成。 分層集成的策略就是： （1）劃分系統(tǒng)的層次； （2）劃分層次內部的集成策略：一般對頂層和第二層內部采用自頂向下的集成策略；對中間層采用自底向上的集成策略；對底層采用單獨測試。 （3）層次間的集成可以采用自頂向下、自底向上、大爆炸或三明治集成中的任何一種。,其他集成策略（4）,基于功能的集成：按照功能角度，按照功能的關鍵程度對模塊的集成順序進行組織，有利于提高團隊士氣。 基于功能的集成的策略就是： （1）確定功能的優(yōu)先級別； （2）分析優(yōu)先級最高的功能路徑，把該路徑上的所有模塊集成到一起，必要時使用驅動和樁。 （3）增加關鍵路徑，重復集成。,其他集成

21、策略（4）,高頻集成：在迭代式開發(fā)中，最初只是一個最低功能限度的集成，然后新代碼加入，按照固定的頻率（例如按每隔多少天，或模塊增加）進行增量測試。高頻集成要求:測試包和代碼并行開發(fā)；始終維護是最新版本，必須使用配置管理工具。 基于功能的集成的策略就是： （1）開發(fā)人員完成代碼增量部分；測試人員完成測試包； （2）集成人員將增量代碼集成到原版本中形成新版本，運行測試包； （3）測試、評估結果并修改調整。,其他集成策略（5）,基于進度的集成：將最早獲得的代碼拿來立即進行集成，必要時開發(fā)驅動和樁模塊。 基于風險的集成：在第一時間內驗證高危模塊間的接口。 基于以下假設： 風險最高的塊間集成往往是錯誤集

22、中的地方。,其他集成策略（5）,基于事件（消息）的集成：從驗證消息路徑的正確性出發(fā)，漸增式實現(xiàn)模塊集成。 基于事件（消息）集成策略： （1）從系統(tǒng)的外部看，分析系統(tǒng)可能輸入的消息； （2）選擇一個消息，分析其穿越的模塊； （3）集成這些模塊進行消息接口測試； （4）重復（2）（3）。 注意：盡可能驗證重要的消息，例如工作流（Workflow）或者消息控制鏈。,其他集成策略（6）,基于使用的集成：針對面向對象系統(tǒng)，通過類之間的使用關系（類繼承、方法多態(tài)、接口、方法動態(tài)綁定等）來集成系統(tǒng)。 基于使用的集成策略： （1）劃出類關系圖； （2）首先測試獨立的類； （3）其次測試應用服務器類的類； （4

23、）最后逐步增加使用獨立類的類。,其他集成策略（7）,C/S的集成：針對C/S架構進行集成。 C/S的集成策略： （1）單獨測試客戶端和服務器端，編寫驅動和樁； （2）測試一個客戶端模塊與服務器進行集成； （3）逐步增加多個客戶端模塊和服務器集成。,不同集成測試方法的比較,1、非增量式測試與增量式測試的比較 非增量式測試的方法是先分散測試，然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯誤，只會在最后的集成測試時一下子暴露出來。 增量式測試是逐步集成和逐步測試的方法，把可能出現(xiàn)的差錯分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測試中，得到了較多次的考驗，因此，可能會取得較好

24、的測試效果。 結論：增量式測試要比非增量式測試具有一定的優(yōu)越性。,不同集成測試方法的比較（續(xù)）,2、自頂向下與自底向上增量式測試的比較 自頂向下增量式測試： 主要優(yōu)點在于它可以自然的做到逐步求精，一開始就能讓測試者看到系統(tǒng)的框架。 主要缺點是需要提供樁模塊，并且在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據有一定困難。 自底向上增量式測試： 優(yōu)點在于，由于驅動模塊模擬了所有調用參數(shù)，即使數(shù)據流并未構成有向的非環(huán)狀圖，生成測試數(shù)據也無困難。 主要缺點在于，直到最后一個模塊被加進去之后才能看到整個程序（系統(tǒng)）的框架。,5.4 回歸測試,什么是回歸測試？ 在集成測試策略的環(huán)境中，回歸測試是對某

25、些已經進行過的測試的某些子集再重新進行一遍，以保證上述改變不會傳播無法預料的副作用或引發(fā)新的問題。 在更廣的環(huán)境里，回歸測試就是用來保證（由于測試或其他原因的）改動不會帶來不可預料的行為或另外的錯誤。 回歸測試可以通過重新執(zhí)行所有的測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具來進行。 回歸測試集包括三種不同類型的測試用例： （1）能夠測試軟件的所有功能的代表性測試用例 （2）專門針對可能會被修改而影響軟件功能的附加測試 （3）針對修改過的軟件成分的測試,5.5 確認測試,1、確認測試的準則 確認測試也稱為合格性測試，是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行。軟件確認要通過一

26、系列證明軟件功能和要求一致的黑盒測試來完成。 經過確認測試，應該為已開發(fā)的軟件給出結論性評價： （1）經過檢驗的軟件的功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，則可被認為是合格的軟件。 （2）經過檢驗發(fā)現(xiàn)與需求說明書有相當?shù)钠x，得到一個各項缺陷清單。,確認測試（續(xù)）,2、配置審查的內容 確認測試過程的重要環(huán)節(jié)就是配置審查工作。其目的在于確保已開發(fā)軟件的所有文件資料均已編寫齊全，并得到分類編目，足以支持運行以后的軟件維護工作。 配置審查的文件資料包括用戶所需的以下資料： （1）用戶手冊 （2）操作手冊 （3）設計資料 如：設計說明書、源程序以及測試資料（測試說明書、測試報告）等 注意：

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

28、,恢復測試,恢復測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統(tǒng)的恢復能力。 恢復測試包含的內容： 如果系統(tǒng)恢復是自動的（由系統(tǒng)自身完成），則應該檢驗：重新初始化、檢驗點設置機構、數(shù)據恢復以及重新啟動是否正確。 如果這一恢復需要人為干預，則應考慮平均修復時間是否在限定的、可以接受的范圍之內。,安全測試,安全測試的目的在于驗證安裝在系統(tǒng)內的保護機制能否在實際中保護系統(tǒng)且不受非法入侵，不受各種非法干擾。 在安全測試中，測試者扮演著試圖攻擊系統(tǒng)的個人角色： 嘗試去通過外部的手段來獲取系統(tǒng)的密碼 使用可以瓦解任何防守的客戶軟件來攻擊系統(tǒng) 把系統(tǒng)“癱瘓”，使得其他用戶無法訪問 有目

29、的地引發(fā)系統(tǒng)錯誤，期望在恢復過程中侵入系統(tǒng) 通過瀏覽非保密的數(shù)據，從中找到進入系統(tǒng)的鑰匙 系統(tǒng)的安全測試要設置一些測試用例試圖突破系統(tǒng)的安全保密措施，檢驗系統(tǒng)是否有安全保密的漏洞。,強度測試（壓力測試）,從本質上來說，強度測試（也稱壓力測試-Stree Testing）的目的是要檢測非正常的情形，測試是想要破壞程序。 強度測試需要在反常規(guī)數(shù)據量、頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度。 舉例： 如果正常的中斷頻率為每秒5次，強度測試設計為每秒50次中斷。 把輸入數(shù)據的量提高一個數(shù)量級來測試輸入功能會如何響應。 若某系統(tǒng)正常運行可支持200個終端并行工作，強度測試則檢驗1000

30、個終端并行工作的情況。 運行大量的消耗內存或其他系統(tǒng)資源的測試實例。,性能測試,性能測試用來測試軟件在系統(tǒng)集成中的運行性能，特別是針對實時系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。 性能測試可以在測試過程的任意階段進行，但只有當整個系統(tǒng)的所有成份都集成在一起后，才能檢查一個系統(tǒng)的真正性能。 性能測試常常和強度（壓力）測試結合起來進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。,正確性測試,正確性測試檢查軟件的功能是否符合規(guī)格說明。 正確性測試的方法： 枚舉法，即構造一些合理輸入，檢查是否得到期望的輸

31、出。測試時應盡量設法減少枚舉的次數(shù)，關鍵在于尋找等價區(qū)間，因為在等價區(qū)間中，只需用任意值測試一次即可。 邊界值測試，即采用定義域或者等價區(qū)間的邊界值進行測試。因為程序設計容易疏忽邊界情況，程序也容易在邊界值處出錯。,可靠性測試,可靠性測試是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達到預期的目標，同時給出當前系統(tǒng)可能的可靠性增長情況。 對可靠性性測試來說，最關鍵的測試數(shù)據包括失效間隔時間，失效修復時間，失效數(shù)量，失效級別等。根據獲得的測試數(shù)據，應用可靠性模型，可以得到系統(tǒng)的失效率及可靠性增長趨勢。 可靠性指標有時很難測試，通常采用平均無故障時間或系統(tǒng)投入運行后出現(xiàn)的故障不能大于多少數(shù)量這些指標來對

32、可靠性進行評估。 企業(yè)中常規(guī)的問題失效時間？電信級的安全指的是什么？,兼容性測試,軟件兼容性測試是檢測各軟件之間能否正確地交互和共享信息，其目標是保證軟件按照用戶期望的方式進行交互，使用其它軟件檢查軟件操作的過程。 兼容性的測試通常需要解決以下問題： （1）新開發(fā)的軟件需要與哪種操作系統(tǒng)、Web瀏覽器和應用軟件保持兼容，如果要測試的軟件是一個平臺，那么要求應用程序能在其上運行。 （2）應該遵守哪種定義軟件之間交互的標準或者規(guī)范。 （3）軟件使用何種數(shù)據與其它平臺、與新的軟件進行交互和共享信息。,兼容性測試（續(xù)）,軟件兼容的實例： 從Web頁面剪切文字，然后在文字處理程序中打開的文檔中粘貼。 從

33、電子表格程序保存賬目數(shù)據，然后在另一個完全不同的電子表格程序中讀入這些數(shù)據。 使圖形處理軟件在同一操作系統(tǒng)下的不同版本正常工作。 使文字處理程序從聯(lián)系人管理程序中讀取姓名和地址，打印個性化的邀請函和信封。 升級到新的數(shù)據庫程序，讀入現(xiàn)存所有數(shù)據庫，并能夠像老版本一樣對其中的數(shù)據進行處理。,兼容性測試（續(xù)）,兼容性通常有4種向前兼容與向后兼容、不同版本間的兼容、標準和規(guī)范、數(shù)據共享兼容 （1）向前兼容和向后兼容 向前兼容是指可以使用軟件的未來版本，向后兼容是指可以使用軟件的以前版本。并非所有的軟件都要求向前兼容和向后兼容，這是軟件設計者需要決定的產品特性。 使用文本文件可以對向前兼容和向后兼容作

34、一個簡單的演示：在Windows 98上用Notepad創(chuàng)建的文本文件，它可以向后兼容MS-DOS 1.0后的所有版本，它還可以向前兼容Windows 2000甚至以后的版本。,兼容性測試（續(xù)）,兼容性測試（續(xù)）,（2）不同版本間的兼容 不同版本間的兼容是指要實現(xiàn)測試平臺和應用軟件多個版本之間能夠正常工作。 舉例： 現(xiàn)在要測試一個流行的操作系統(tǒng)的新版本，當前操作系統(tǒng)上可能有數(shù)幾十上百萬現(xiàn)有程序，則新操作系統(tǒng)的目標是與它們百分之百兼容。因為不可能在一個操作系統(tǒng)上測試所有的軟件程序，因此需要決定哪些是最重要的、必須進行的。對于測試新應用軟件也一樣，需要決定在哪個平臺版本上測試，以及和什么應用程序一起測試。,兼容性測試（續(xù)）,（3）標準和規(guī)范 適用于軟件平臺的標準和規(guī)范有兩個級別高級標準和低級標準。 高級標準是產品應當普遍遵守的，例如軟件能在何種操作系統(tǒng)上運行？是互聯(lián)網上的程序嗎？它運行于何種瀏覽器？每一項問題都關系到平臺，假若應用程序聲明與某個平臺兼容，就必須最受關于該平臺的標準和規(guī)范。 低級標準是對產品開發(fā)細節(jié)的描述，從某種意義上說，低級標準比高級標準更加重要。,兼容性測試（續(xù)）,（4）數(shù)據共享兼容 數(shù)據共享兼