軟件測試講義

1、第七部分 軟件測試,ftp://tomzhi27:robinson@portal.sjtu.edu.cn/transfer/study/軟件工程/,軟件測試是在軟件投入運行前，對軟件需求分析，設計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關鍵步驟。概念：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；颍很浖y試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設計一批測試用例，并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程。,軟

2、件測試的定義,軟件測試的目的,基于不同的立場，存在著兩種完全不同的測試目的：從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。,Myers軟件測試目的,(1) 測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤(2) 一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤(3) 一個

3、成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試,換言之，測試的目的是系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷能夠證明軟件的功能和性能與需求說明相符合測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤,軟件測試的原則,1. 應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。2. 測試用例應由測試輸入數(shù)據(jù)和對應的預期輸出結(jié)果這兩部分組成。3. 程序員應避免檢查自己的程序。4. 在設計測試用例時，應當包括合理的輸入條件和不合理

4、的輸入條件。,developer,independent tester,,Understands the system but will test “gently” and is driven by delivery,Must learn about the system but will attempt to break it and is driven by quality,5. 充分注意測試中的群集現(xiàn)象。經(jīng)驗表明，測試后程序中殘

5、存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比6. 嚴格執(zhí)行測試計劃，排除測試的隨意性。7. 應當對每一個測試結(jié)果做全面檢查。8. 妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。,軟件測試的對象,軟件測試并不限于程序測試。軟件測試應貫穿于軟件定義與開發(fā)的整個期間。需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設計規(guī)格說明、詳細設計規(guī)格說明以及源程序，都應成為軟件測試的對象

6、。,為把握軟件開發(fā)各個環(huán)節(jié)的正確性，需要進行各種確認和驗證工作。確認(Validation)，是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。 需求規(guī)格說明的確認 程序的確認驗證(Verification)，試圖證明在軟件生存期各個階段，以及階段間的邏輯協(xié)調(diào)性、完備性和正確性。,軟件生存期各階段之間需要保持的正確性,測試信息流,測試信息流,軟件配置：軟件需求規(guī)格說明、軟件設計規(guī)格說明、源代碼等；測試配

7、置：測試計劃、測試用例、測試程序等；測試工具：測試數(shù)據(jù)自動生成程序、靜態(tài)分析程序、動態(tài)分析程序、測試結(jié)果分析程序、以及驅(qū)動測試的測試數(shù)據(jù)庫等等。,測試結(jié)果分析：比較實測結(jié)果與預期結(jié)果，評價錯誤是否發(fā)生。排錯(調(diào)試)：對已經(jīng)發(fā)現(xiàn)的錯誤進行錯誤定位和確定出錯性質(zhì)，并改正這些錯誤，同時修改相關的文檔。修正后的文檔再測試：直到通過測試為止。,通過收集和分析測試結(jié)果數(shù)據(jù)，對軟件建立可靠性模型利用可靠性分析，評價軟件質(zhì)量： 軟件的質(zhì)量和可

8、靠性達到可以接受的程度； 所做的測試不足以發(fā)現(xiàn)嚴重的錯誤；如果測試發(fā)現(xiàn)不了錯誤，可以肯定，測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。,測試與軟件開發(fā)各階段的關系,軟件開發(fā)過程是一個自頂向下，逐步細化的過程軟件計劃階段定義軟件作用域軟件需求分析建立軟件信息域、功能和性能需求、約束等軟件設計把設計用某種程序設計語言轉(zhuǎn)換成程序代碼測試過程是依相反順序安排的自底向上，逐步集成的過程。,按測試過程是否在實際應用環(huán)境中運行來分類

9、,靜態(tài)測試通過對需求文件、設計文件及源程序的閱讀和分析，找出其中的錯誤或可疑之處。靜態(tài)測試時不執(zhí)行被分析的程序。動態(tài)測試直接在計算機上運行所要測試的程序模塊，從實際運行的結(jié)果發(fā)現(xiàn)并糾正錯誤。功能測試（黑盒測試）和結(jié)構(gòu)測試（白盒測試）,軟件測試用例設計,兩種常用的測試方法 黑盒測試 白盒測試,黑盒測試,這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能

10、是否符合它的功能說明。黑盒測試又叫做功能測試或數(shù)據(jù)驅(qū)動測試。,黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤: 是否有不正確或遺漏了的功能? 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯誤?,用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出

11、。但這是不可能的。,假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數(shù)，按黑盒方法進行窮舉測試：可能采用的 測試數(shù)據(jù)組： 232×232 ＝264 如果測試一 組數(shù)據(jù)需要1毫秒，一年工作365× 24小時，完成所有測試需5億年。,白盒測試,此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關信息，設計或選擇測試用例，對程序所

12、有邏輯路徑進行測試。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。,軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查： 對程序模塊的所有獨立的執(zhí)行路徑至少測試一次； 對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次； 在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體； 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等。,對一個

13、具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。給出一個小程序的流程圖，它包括了一個執(zhí)行20次的循環(huán)。包含的不同執(zhí)行路徑數(shù)達520條，對每一條路徑進行測試需要1毫秒，假定一年工作365 × 24小時，要想把所有路徑測試完，需3170年。,邏輯覆蓋,語句覆蓋 判定覆蓋 條件覆蓋,判定－條件覆蓋 條件組合覆蓋 路徑覆蓋,邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎的設計測試用例的技術(shù)。它屬白盒測試。,白盒測試的測試用

14、例設計,,舉例：所有路徑為：L1(a->c->e) ,L2(a->b->d), L3(a->b->e), L4(a->c->d),依據(jù)以上推導出來的結(jié)果就可以設計滿足要求的測試用例。,語句覆蓋,語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執(zhí)行語句至少執(zhí)行一次。在圖例中，正好所有的可執(zhí)行語句都在路徑L1上，所以選擇路徑 L1設計測試用例，就可以覆蓋所有的可執(zhí)行語句。,測試用例的

15、設計格式如下【輸入的(A, B, X)，輸出的(A, B, X)】為圖例設計滿足語句覆蓋的測試用例是:【(2, 0, 4)，(2, 0, 3)】　 覆蓋 ace【L1】,,判定覆蓋,判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次。判定覆蓋又稱為分支覆蓋。對于圖例，如果選擇路徑L1和L2，就可得滿足要求的測試用例:,【(2, 0, 4)，(2, 0, 3)】覆蓋 ace【L

16、1】【(1, 1, 1)，(1, 1, 1)】覆蓋 abd【L2】,如果選擇路徑L3和L4，還可得另一組可用的測試用例:【(2, 1, 1)，(2, 1, 2)】覆蓋 abe【L3】【(3, 0, 3)，(3, 1, 1)】覆蓋 acd【L4】,,條件覆蓋,條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執(zhí)行一次。在圖例中，我們事先可對所有條件的取值加以標記。例如，對于第一個判斷： 條

17、件 A＞1 取真為 ，取假為 條件 B＝0 取真為 ，取假為,對于第二個判斷： 條件A＝2 取真為 ，取假為 條件X＞1 取真為 ，取假為測試用例 覆蓋分支 條件取值【(2, 0, 4)，(2, 0, 3)】 L1(c, e) 【(1, 0, 1)，(1, 0, 1)】 L2(b, d) 【(2, 1, 1)，(2, 1, 2)】 L3(b, e)或,測 試 用 例覆蓋分支 條件

18、取值【(1, 0, 3)，(1, 0, 4)】 L3(b, e) 【(2, 1, 1)，(2, 1, 2)】 L3(b, e) 判定－條件覆蓋判定－條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執(zhí)行一次，同時每個判斷中的每個條件的可能取值至少執(zhí)行一次。,測 試 用例 覆蓋分支 條件取值【(2, 0, 4)，(2, 0, 3)】 L1(c, e)【(1, 1, 1)，(1, 1, 1)】 L

19、2(b, d),,由多個基本判斷組成的流程圖,條件組合覆蓋,條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執(zhí)行一次。 記 ① A＞1, B＝0 作 ② A＞1, B≠0 作 ③ A≯1, B＝0 作 ④ A≯1, B≠0 作,,⑤ A＝2, X＞1 作 ⑥ A＝2,

20、X≯1 作 ⑦ A≠2, X＞1 作 ⑧ A≠2, X≯1 作 測 試 用 例 覆蓋條件 覆蓋組合【(2, 0, 4), (2, 0, 3)】(L1) ①, ⑤【(2, 1, 1), (2, 1, 2)】(L3) ②, ⑥【(1, 0, 3), (1, 0, 4)】(L3)

21、 ③, ⑦【(1, 1, 1), (1, 1, 1)】(L2) ④, ⑧,路徑測試,路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑。 測 試 用 例 通過路徑 覆蓋條件【(2, 0, 4), (2, 0, 3)】 ace (L1) 【(1, 1, 1), (1, 1, 1)】 abd (L2) 【(

22、1, 1, 2), (1, 1, 3)】 abe (L3) 【(3, 0, 3), (3, 0, 1)】 acd (L3),條件測試路徑選擇,當程序中判定多于一個時，形成的分支結(jié)構(gòu)可以分為兩類：嵌套型分支結(jié)構(gòu)和連鎖型分支結(jié)構(gòu)。對于嵌套型分支結(jié)構(gòu)，若有n個判定語句，需要n+1個測試用例；對于連鎖型分支結(jié)構(gòu)， 若有n個判定語句，需要有2n個測試用例，覆蓋它的2n條路徑。當n較大時將無法測試。,

23、循環(huán)測試路徑選擇,循環(huán)分為4種不同類型：簡單循環(huán)、連鎖循環(huán)、嵌套循環(huán)和非結(jié)構(gòu)循環(huán)。 (1) 簡單循環(huán) ① 零次循環(huán)：從循環(huán)入口到出口 ② 一次循環(huán)：檢查循環(huán)初始值 ③ 二次循環(huán)：檢查多次循環(huán) ④ m次循環(huán)： 檢查在多次循環(huán) ⑤ 最大次數(shù)循環(huán)、比最大次數(shù)多一次、少一次的循環(huán),例：求最小值,k = i; ?for ( j = i+1; j <= n; j++ )

24、 ? ? ? if ( A[j] < A[k] ) then k = j; ? ?,測試用例選擇,,(2) 嵌套循環(huán)① 對最內(nèi)層循環(huán)做簡單循環(huán)的全部測試。所有其它層的循環(huán)變量置為最小值② 逐步外推，對其外面一層循環(huán)進行測試。測試時保持所有外層循環(huán)的循環(huán)變量取最小值，所有其它嵌套內(nèi)層循環(huán)的循環(huán)變量取“典型”值③ 反復

25、進行，直到所有各層循環(huán)測試完畢,④ 對全部各層循環(huán)同時取最小循環(huán)次數(shù)，或者同時取最大循環(huán)次數(shù)(3) 連鎖循環(huán)如果各個循環(huán)互相獨立，則可以用與簡單循環(huán)相同的方法進行測試。但如果幾個循環(huán)不是互相獨立的，則需要使用測試嵌套循環(huán)的辦法來處理。(4) 非結(jié)構(gòu)循環(huán)這一類循環(huán)應該使用結(jié)構(gòu)化程序設計方法重新設計測試用例。,黑盒測試的測試用例設計,等價類劃分 邊界值分析 錯誤推測法 因果圖,等價類劃分,等價類劃分是一種典型的黑盒測試方法，使

26、用這一方法時，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設計測試用例。等價類劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測試用例。,使用這一方法設計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。劃分等價類等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其它值的測試。,等價類的劃分

27、有兩種不同的情況：① 有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。② 無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。,劃分等價類的原則(1) 如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。,例如，在程序的規(guī)格說明中，對輸入條件有一句話： “…… 項數(shù)可以從1到999

28、 ……” 則有效等價類是“1≤項數(shù)≤999”兩個無效等價類是“項數(shù)＜1”或“項數(shù)＞999”。在數(shù)軸上表示成:,(2) 如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如，在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構(gòu)成有效等價類，而不在此集合內(nèi)（不以字母打頭）的歸于無效等價類。,(3) 如果輸入條件是一個布爾量，則可以確定一個有效等

29、價類和一個無效等價類。(4) 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為 每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。,例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。(5) 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則

30、，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。,例如，Pascal語言規(guī)定 “一個語句必須以分號‘;’結(jié)束”。這時，可以確定一個有效等價類 “以‘;’結(jié)束”，若干個無效等價類 “以‘:’結(jié)束”、“以‘,’結(jié)束”、“以‘ ’結(jié)束”、“以LF結(jié)束”等。確立測試用例在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。,再從劃分出的等價類中按以下原則選擇測試用例：(1) 為每一個等價類規(guī)定一個唯一編

31、號；(2) 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；（3）設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。,,用等價類劃分法設計測試用例的實例在某一PASCAL語言版本中規(guī)定：“標識符是由字母開頭，后跟字母或數(shù)字的任意組合構(gòu)成。有效字符數(shù)為8個，最大字符數(shù)為80個?！辈⑶乙?guī)定：“標識符必須先說明，再使

32、用?！?“在同一說明語句中，標識符至少必須有一個?！?用等價類劃分的方法，建立輸入等價類表:,下面選取了9個測試用例，它們覆蓋了所有的等價類。① VAR x，T1234567：REAL； BEGIN x := 3.414； T1234567 := 2.732； ...… (1), (2),

33、(4), (8), (9), (12), (14)② VAR ：REAL； (3)③ VAR x，：REAL; (5),④ VAR T12345678：REAL； (6)⑤ VAR T12345......：REAL； (7) 多于80個字符⑥ VAR T$：CHAR；

34、 (10)⑦ VAR GOTO：INTEGER； (11)⑧ VAR 2T：REAL； (13)⑨ VAR PAR：REAL； (15) BEGIN ...... PAP := SIN (3.14 * 0.8) / 6；,邊界值分析,邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)

35、生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。,比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。 我們應注意到這三個數(shù)值應當滿足 A＞0、B＞0、C＞0、 A＋B＞C、A＋C＞B、B＋C＞A，才能構(gòu)成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構(gòu)成三角形。問題恰出現(xiàn)在容易被疏忽的邊界附近。,這里所說的邊界是指，相

36、當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值做為測試數(shù)據(jù)。,錯誤推測法,人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況

37、，根據(jù)它們選擇測試用例。,因果圖,因果圖的適用范圍如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應產(chǎn)生多個動作的形式來設計測試用例，這就需要利用因果圖。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。,用因果圖生成測試用例的基本步驟(1) 分析軟件規(guī)格說明描述中，哪些是原因 (即輸入條件或輸入條件的等價類)，哪些是結(jié)果 (即輸出條件)，并給每個原因和結(jié)果賦予一個標識符。

38、(2) 分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應的是什么關系? 根據(jù)這些關系，畫出因果圖。,(3) 由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。(4) 把因果圖轉(zhuǎn)換成判定表。(5) 把判定表的每一列拿出來作為依據(jù)，設計測試用例。,在因果圖中出現(xiàn)的基本符號通常在因果圖中用Ci表示原因，用Ei表示結(jié)果，各結(jié)點表示狀態(tài)

39、，可取值“0”或“1”。“0”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。主要的原因和結(jié)果之間的關系有:,表示約束條件的符號為了表示原因與原因之間，結(jié)果與結(jié)果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。,,例如，有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規(guī)格說明如下：若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅

40、燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣?！?(1) 分析這一段說明，列出原因和結(jié)果原因: 1. 售貨機有零錢找 2. 投入1元硬幣 3. 投入5角硬幣 4. 押下橙汁按鈕 5. 押下啤酒按鈕建立中間結(jié)點，表示處理中間狀態(tài)11. 投入1元硬幣且押下飲料按鈕1

41、2. 押下〖橙汁〗或〖啤酒〗的按鈕13. 應當找5角零錢并且售貨機有零錢找14. 錢已付清,結(jié)果： 21. 售貨機〖零錢找完〗燈亮 22. 退還1元硬幣 23. 退還5角硬幣 24. 送出橙汁飲料 25. 送出啤酒飲料(2) 畫出因果圖。所有原因結(jié)點列在左邊，所有結(jié)果結(jié)點列在右邊。 (3)

42、 由于 2 與 3 ，4 與 5 不能同時發(fā)生，分別加上約束條件E。(4) 因果圖,,,(5) 轉(zhuǎn)換成判定表,,,軟件測試的策略,測試過程按4個步驟進行，即單元測試、組裝測試、確認測試和系統(tǒng)測試。開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。,組裝測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)

43、格說明中確定了的各種需求，以及軟件配置是否完全、正確。系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成分組合在一起進行測試。,單元測試 (Unit Testing),單元測試又稱模塊測試，是針對軟件設計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計測試用例。多個模塊可以平行地獨立進行單元測試。,1. 單元測試的內(nèi)容,在單元測試時，測試者

44、需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。,(1) 模塊接口測試,在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括： 調(diào)用本模塊的輸入?yún)?shù)是否正確； 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確； 全局量的定義在各模塊中是否一致；,在做內(nèi)外存交換時要考慮： 文件屬性是否正確；

45、 OPEN與CLOSE語句是否正確； 緩沖區(qū)容量與記錄長度是否匹配； 在進行讀寫操作之前是否打開了文件； 在結(jié)束文件處理時是否關閉了文件； 正文書寫／輸入錯誤， I／O錯誤是否檢查并做了處理。,(2) 局部數(shù)據(jù)結(jié)構(gòu)測試,不正確或不一致的數(shù)據(jù)類型說明使用尚未賦值或尚未初始化的變量錯誤的初始值或錯誤的缺省值變量名拼寫錯或書寫錯不一致的數(shù)據(jù)類型全局數(shù)據(jù)對模塊的影響,(3) 路徑測試,選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行

46、路徑進行測試。應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。,(4) 錯誤處理測試,出錯的描述是否難以理解出錯的描述是否能夠?qū)﹀e誤定位顯示的錯誤與實際的錯誤是否相符對錯誤條件的處理正確與否在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等,(5) 邊界測試,注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔

47、細地選擇測試用例，認真加以測試。如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。,2. 單元測試的步驟,模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。 驅(qū)動模塊 (driver) 樁模塊 (stub) ── 存根模塊,,驅(qū)動模塊 (driver) ── 相當于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些

48、數(shù)據(jù)傳送給所測模塊，最后再輸出實測結(jié)果。 樁模塊 (stub) ── 存根模塊。用以代替所測模塊調(diào)用的子模塊。,如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。,組裝測試（Integrated Testing）,組裝測試 (集成測試、聯(lián)合測試）通常

49、，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統(tǒng)。這時需要考慮的問題是： 在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失； 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；,,各個子功能組合起來，能否達到預期要求的父功能； 全局數(shù)據(jù)結(jié)構(gòu)是否有問題； 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。在單元測試的同時可進行組裝測試，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題，最終構(gòu)成要求的軟件

50、系統(tǒng)。,,子系統(tǒng)的組裝測試特別稱為部件測試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。通常，把模塊組裝成為系統(tǒng)的方式有兩種 一次性組裝方式 增殖式組裝方式,1. 一次性組裝方式 (big bang),它是一種非增殖式組裝方式。也叫做整體拼裝。使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。,2. 增殖式組裝方式,這種組裝方式又稱漸增式組裝首先對一

51、個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)在組裝的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題通過增殖逐步組裝成為要求的軟件系統(tǒng)。,(1) 自頂向下的增殖方式,這種組裝方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。,(2) 自底向上的增殖方式,這種組裝的方式是從程序模塊結(jié)構(gòu)的最底層

52、的模塊開始組裝和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。,自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。一般來講，一種方式的優(yōu)點是另一種方式的缺點。,(3) 混合增殖式測試,衍變的自頂向下的增殖測試 首先對輸入／輸出模塊和引入新算法模塊進行測試; 再自底向上組裝成為功

53、能相當完整且相對獨立的子系統(tǒng); 然后由主模塊開始自頂向下進行增殖測試。,自底向上?自頂向下的增殖測試 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試; 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試?；貧w測試 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊; 然后將這一部分視為子系統(tǒng)，再自底向上測試。,關鍵模塊問題,在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。關鍵模塊的特征：① 滿足某些軟

54、件需求；② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；③ 較復雜、較易發(fā)生錯誤；④ 有明確定義的性能要求。,確認測試（Validation Testing）,確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎。,,,1. 進行有效性測試（黑盒測試）,有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境)

55、下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。,通過實施預定的測試計劃和測試步驟，確定 軟件的特性是否與需求相符； 所有的文檔都是正確且便于使用； 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試,在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類： 測試結(jié)果與預期的結(jié)果相符。

56、這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。 測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。,2. 軟件配置復查,軟件配置復查的目的是保證 軟件配置的所有成分都齊全； 各方面的質(zhì)量都符合要求； 具有維護階段所必需的細節(jié)； 而且已經(jīng)編排好分類的目錄。應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確

57、性。,3.α測試和β測試,在軟件交付使用之后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預測的。α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。,α測試的目的是評價軟件產(chǎn)品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重產(chǎn)品的界面和特色。α測試可以從軟件產(chǎn)品編碼結(jié)束之時開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認測試過程中產(chǎn)品達到一定的穩(wěn)定和可靠程度

58、之后再開始。,β測試是由軟件的多個用戶在實際使用環(huán)境下進行的測試。這些用戶返回有關錯誤信息給開發(fā)者。測試時，開發(fā)者通常不在測試現(xiàn)場。因而，β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發(fā)者報告。,β測試主要衡量產(chǎn)品的FLURPS （即功能、局域化、可使用性、可靠性、性能和支持） 。著重于產(chǎn)品的支持性，包括文檔、客戶培訓和支持產(chǎn)品生產(chǎn)能力。只有當α測試達到

59、一定的可靠程度時，才能開始β測試。它處在整個測試的最后階段。同時，產(chǎn)品的所有手冊文本也應該在此階段完全定稿。,4.驗收測試（Acceptance Testing）,在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應參加。由用戶參加設計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。,在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維

60、護性、錯誤的恢復功能等進行確認。確認測試應交付的文檔有： 確認測試分析報告 最終的用戶手冊和操作手冊 項目開發(fā)總結(jié)報告,系統(tǒng)測試（System Testing）,系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義

61、不符合或與之矛盾的地方,測試種類,軟件測試是由一系列不同的測試組成。主要目的是對以計算機為基礎的系統(tǒng)進行充分的測試。功能測試功能測試是在規(guī)定的一段時間內(nèi)運行軟件系統(tǒng)的所有功能，以驗證這個軟件系統(tǒng)有無嚴重錯誤。,可靠性測試如果系統(tǒng)需求說明書中有對可靠性的要求，則需進行可靠性測試。① 平均失效間隔時間 MTBF (Mean Time Between Failures) 是否超過規(guī)定時限?② 因故障而停機的時間 MTTR (M

62、ean Time To Repairs) 在一年中應不超過多少時間。,強度測試強度測試是要檢查在系統(tǒng)運行環(huán)境不正常乃至發(fā)生故障的情況下，系統(tǒng)可以運行到何種程度的測試。例如： 把輸入數(shù)據(jù)速率提高一個數(shù)量級，確定輸入功能將如何響應。 設計需要占用最大存儲量或其它資源的測試用例進行測試。,設計出在虛擬存儲管理機制中引起“顛簸”的測試用例進行測試。 設計出會對磁盤常駐內(nèi)存的數(shù)據(jù)過度訪問的測試用例進行測試。強度測試的一個變種就是敏感

63、性測試。在程序有效數(shù)據(jù)界限內(nèi)一個小范圍內(nèi)的一組數(shù)據(jù)可能引起極端的或不平穩(wěn)的錯誤處理出現(xiàn)，或者導致極度的性能下降的情況發(fā)生。此測試用以發(fā)現(xiàn)可能引起這種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)組合。,性能測試性能測試是要檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能。特別是對于實時系統(tǒng)或嵌入式系統(tǒng)。性能測試常常需要與強度測試結(jié)合起來進行，并常常要求同時進行硬件和軟件檢測。通常，對軟件性能的檢測表現(xiàn)在以下幾個方面：響應時間、吞吐量、輔助存儲區(qū)，例如

64、緩沖區(qū)，工作區(qū)的大小等、處理精度，等等。,恢復測試恢復測試是要證實在克服硬件故障(包括掉電、硬件或網(wǎng)絡出錯等)后，系統(tǒng)能否正常地繼續(xù)進行工作，并不對系統(tǒng)造成任何損害。為此，可采用各種人工干預的手段，模擬硬件故障，故意造成軟件出錯。并由此檢查： 錯誤探測功能──系統(tǒng)能否發(fā)現(xiàn)硬件失效與故障；,能否切換或啟動備用的硬件； 在故障發(fā)生時能否保護正在運行的作業(yè)和系統(tǒng)狀態(tài)； 在系統(tǒng)恢復后能否從最后記錄下來的無錯誤狀態(tài)開始繼續(xù)執(zhí)行作業(yè)，等

65、等。 掉電測試：其目的是測試軟件系統(tǒng)在發(fā)生電源中斷時能否保護當時的狀態(tài)且不毀壞數(shù)據(jù)，然后在電源恢復時從保留的斷點處重新進行操作。,啟動／停止測試這類測試的目的是驗證在機器啟動及關機階段，軟件系統(tǒng)正確處理的能力。這類測試包括 反復啟動軟件系統(tǒng) (例如，操作系統(tǒng)自舉、網(wǎng)絡的啟動、應用程序的調(diào)用等) 在盡可能多的情況下關機,配置測試這類測試是要檢查計算機系統(tǒng)內(nèi)各個設備或各種資源之間的相互聯(lián)結(jié)和功能分配中的錯誤。它主要包括以下

66、幾種： 配置命令測試：驗證全部配置命令的可操作性（有效性）；特別對最大配置和最小配置要進行測試。軟件配置和硬件配置都要測試。,循環(huán)配置測試：證明對每個設備物理與邏輯的，邏輯與功能的每次循環(huán)置換配置都能正常工作。 修復測試：檢查每種配置狀態(tài)及哪個設備是壞的。并用自動的或手工的方式進行配置狀態(tài)間的轉(zhuǎn)換。,安全性測試安全性測試是要檢驗在系統(tǒng)中已經(jīng)存在的系統(tǒng)安全性、保密性措施是否發(fā)揮作用，有無漏洞。力圖破壞系統(tǒng)的保護機構(gòu)以進入系統(tǒng)的主

67、要方法有以下幾種： 正面攻擊或從側(cè)面、背面攻擊系統(tǒng)中易受損壞的那些部分； 以系統(tǒng)輸入為突破口，利用輸入的容錯性進行正面攻擊；,申請和占用過多的資源壓垮系統(tǒng)，以破壞安全措施，從而進入系統(tǒng)； 故意使系統(tǒng)出錯，利用系統(tǒng)恢復的過程，竊取用戶口令及其它有用的信息； 通過瀏覽殘留在計算機各種資源中的垃圾（無用信息），以獲取如口令，安全碼，譯碼關鍵字等信息； 瀏覽全局數(shù)據(jù)，期望從中找到進入系統(tǒng)的關鍵字； 瀏覽那些邏輯上不存在，但物理上還存

68、在的各種記錄和資料等。,可使用性測試可使用性測試主要從使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查，發(fā)現(xiàn)人為因素或使用上的問題。要保證在足夠詳細的程度下，用戶界面便于使用；對輸入量可容錯、響應時間和響應方式合理可行、輸出信息有意義、正確并前后一致；出錯信息能夠引導用戶去解決問題；軟件文檔全面、正規(guī)、確切。,可支持性測試這類測試是要驗證系統(tǒng)的支持策略對于公司與用戶方面是否切實可行。它所采用的方法是 試運行支持過程(如對有錯部分