軟件測試復(fù)習(xí)題word文檔良心出品

1、軟件測試總復(fù)習(xí)題一、單選1.對程序中已發(fā)現(xiàn)的錯誤進(jìn)行錯誤定位和確定出錯性質(zhì),并改正這些錯誤,同時修改相關(guān)的文檔，稱為（B ）2.A）測試B）調(diào)試C ）錯誤分析D）驗(yàn)證數(shù)據(jù)流覆蓋關(guān)注的是程序中某個變量從其聲明、賦值到引用的變化情況,它是下列哪一種覆蓋的變種（A ）A）語句覆蓋B）控制覆蓋C）分支覆蓋D)路徑覆蓋3.A) 5B) 6C) 7D) 8程序的流程圖如下圖所示，采用路徑覆蓋法進(jìn)行測試， 則至少需要幾個測試用例可以覆蓋所有可能的路徑（C ）4.如果一個判定中的復(fù)合條件表達(dá)式為（A 1 ） or （ B 1） or（B = 3 ） ，則為了達(dá)到 100%的條件覆蓋率，至少需要設(shè)計多少個測試用

2、例（B)20.A) 1B) 2C) 3D) 4自底向上單元測試的策略是首先對模塊調(diào)用圖上的哪一層模塊進(jìn)行測試（A)A）最底層B）下一層C ）最高層D ）上一層21.基本路徑測試滿足（ A ）A）語句覆蓋B）路徑覆蓋C ）分支覆蓋D ）條件覆蓋22.23.24.A）正確性B）可靠性C ）可使用性D ）可維護(hù)性在軟件性能測試中，下列指標(biāo)中哪個不是軟件性能的指標(biāo)（A）響應(yīng)時間B）吞吐量C ）資源利用率下列關(guān)于軟件性能測試的說法中，正確的是（B)D)D ）并發(fā)進(jìn)程數(shù)集成測試對系統(tǒng)內(nèi)部的交互以及集成后系統(tǒng)功能檢驗(yàn)了何種質(zhì)量特性（A）性能測試的目的不是為了發(fā)現(xiàn)軟件缺陷B）壓力測試與負(fù)載測試的目的都是為了探

3、測軟件在滿足預(yù)定性能需求的情況下所能負(fù)擔(dān)的最大壓力C）性能測試通常要對測試結(jié)果進(jìn)行分析才能獲得測試結(jié)論D）在性能下降曲線上，最大建議用戶數(shù)通常處于性能輕微下降區(qū)與性能急劇下降區(qū)的交界處A)25. 下列關(guān)于軟件可靠性測試的說法中，錯誤的是（A）系統(tǒng)測試B）驗(yàn)收測試A)發(fā)現(xiàn)軟件缺陷是軟件可靠性測試的主要目的B)軟件可靠性測試通常用于有可靠性要求的軟件C)在一次軟件可靠性測試中，執(zhí)行的測試用例必須完全符合所定義的軟件運(yùn)行剖面D)可靠性測試通常要對測試結(jié)果進(jìn)行分析才能獲得測試結(jié)論26. 下列關(guān)于面向?qū)ο筌浖y試的說法中，正確的是（A)A）在測試一個類時，只要對該類的每個成員方法都進(jìn)行充分的測試就完成了

4、對該類充分的測試B）在存在多態(tài)的情況下，為了達(dá)到較高的測試充分性，應(yīng)對所有可能的綁定都進(jìn)行測C）假設(shè)類B是類A的子類，如果類 A已進(jìn)行了充分的測試，在測試類B 時不必測試任何類B繼承類A的成員方法D）對于一棵繼承樹上的多個類，只有處于葉節(jié)點(diǎn)的類需要測試27.下列哪種測試不屬于面向?qū)ο髥卧獪y試考慮的范疇（C）類樹的測試B）類的測試A）成員方法的測試D）多個相互協(xié)作的類樹的測試28.下列關(guān)于面向?qū)ο蠹蓽y試的說法中，正確的是（B)29.A)B)C)D)大突擊集成是面向?qū)ο蠹蓽y試最常用且最有效的方法自底向上集成和自頂向下集成都需要為集成測試開發(fā)大量代碼協(xié)作集成在任何情況下都優(yōu)于自底向上集成和自頂向

5、下集成高頻集成是以自底向上集成為基礎(chǔ)，利用冒煙測試進(jìn)行的集成測試下列有關(guān)測試過程 V模型的說法中，正確的是（ C ）A)驗(yàn)收測試應(yīng)確定程序的執(zhí)行是否滿足軟件設(shè)計的要求B)C)系統(tǒng)測試應(yīng)確定系統(tǒng)功能和性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo) 單元測試和集成測試應(yīng)確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求30.D)集成測試在編碼結(jié)束前就可以開始計算機(jī)軟件測試規(guī)范規(guī)定，軟件測試的類別可分為：單元測試、集成測試以及（C)C）系統(tǒng)測試和驗(yàn)收測試D）配置項(xiàng)測試、系統(tǒng)測試和驗(yàn)收測試二、多選1.實(shí)施缺陷跟蹤的目的是：（ABCD2.3.4.5.6.7.A軟件質(zhì)量無法控制C重復(fù)問題接連產(chǎn)生E、確保缺陷得到解決使用軟件

6、測試工具的目的：A幫助測試尋找問題C節(jié)省測試時間E更好的控制缺陷提高軟件質(zhì)量編寫測試計劃的目的是：（A使測試工作順利進(jìn)行C使測試工作更加系統(tǒng)化E軟件過程規(guī)范化的要求選出屬于黑盒測試方法的選項(xiàng)（A條件組合覆蓋D分支覆蓋B、ABCDFABCB輸入覆蓋E、語句覆蓋以測試的形態(tài)分測試可以分為：（A、建構(gòu)性測試B、系統(tǒng)測試問題無法量化解決問題的知識無法保留使問題形成完整的閉環(huán)處理B、D、F、B、D、F、協(xié)助問題的診斷提高 Bug 的發(fā)現(xiàn)率更好的協(xié)助開發(fā)人員使項(xiàng)目參與人員溝通更舒暢軟件工程以及軟件過程的需要控制軟件質(zhì)量B)C 、基路徑測試F 、條件覆蓋ABC )C、專項(xiàng)測試D單元測試E、組件測試F、集成測

7、試進(jìn)行軟件質(zhì)量管理的重要性有：（ABCDEF )A、D、G、AC維護(hù)降低成本B法律上的要求C、市場競爭的需要質(zhì)量標(biāo)準(zhǔn)化的趨勢 E、軟件工程的需要 F、CMMt程的一部分方便與客戶進(jìn)一步溝通為后期的實(shí)施打好基礎(chǔ)） 可以作為軟件測試結(jié)束的標(biāo)志。使用了特定的測試用例B 錯誤強(qiáng)度曲線下降到預(yù)定的水平查出了預(yù)定數(shù)目的錯誤D .按照測試計劃中所規(guī)定的時間進(jìn)行了測試8.導(dǎo)致軟件缺陷的原因有很多，A D是可能的原因，其中最主要的原因包括( ABCD）。A. 軟件需求說明書編寫的不全面，不完整，不準(zhǔn)確，而且經(jīng)常更改B. 軟件設(shè)計說明書C. 軟件操作人員的水平D. 開發(fā)人員不能很好的理解需求說明書和溝通不足9.

8、軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（AD )A.B.所有測試項(xiàng)沒有殘余一級、二級和三級錯誤。軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。C.D.驗(yàn)收測試工件齊全。10. 軟件測試計劃評審會需要哪些人員參加？（ABCD立項(xiàng)審批表、需求分析文檔、設(shè)計文檔和編碼實(shí)現(xiàn)一致。A.項(xiàng)目經(jīng)理B. SQA 負(fù)責(zé)人D.測試組C配置負(fù)責(zé)人11. 下列關(guān)于 alpha 測試的描述中正確的是：（ A DAalpha測試需要用戶代表參加Balpha測試不需要用戶代表參加Calpha測試是系統(tǒng)測試的一種Dalpha測試是驗(yàn)收測試的一種12. 測試設(shè)計員的職責(zé)有：（BCA.制定測試計劃B.設(shè)計測試用例C

9、設(shè)計測試過程、腳本D.評估測試活動13. 軟件實(shí)施活動的進(jìn)入準(zhǔn)則是：（ABC )A需求工件已經(jīng)被基線化B.詳細(xì)設(shè)計工件已經(jīng)被基線化C構(gòu)架工件已經(jīng)被基線化D.項(xiàng)目階段成果已經(jīng)被基線化 14. 下面的哪一項(xiàng)測試步驟中需要進(jìn)行局部數(shù)據(jù)結(jié)構(gòu)測試：A、單元測試B集成測試15.16.17.18.19.20.21.C確認(rèn)測試D系統(tǒng)測試從是否需要執(zhí)行被測軟件的角度，軟件測試技術(shù)可劃分的類型是：（A、靜態(tài)測試B、黑盒測試C、動態(tài)測試D、白盒測試使用軟件測試工具的目的：（A幫助測試尋找問題C節(jié)省測試時間E更好的控制缺陷提高軟件質(zhì)量編寫測試計劃的目的是：（A使測試工作順利進(jìn)行C使測試工作更加系統(tǒng)化E軟件過程規(guī)范化的

10、要求選出屬于黑盒測試方法的選項(xiàng)（A條件組合覆蓋D分支覆蓋在 GB/T17544 中，程 序和數(shù)據(jù)要求。A用戶文檔要求C設(shè)計要求說明AC）。ABCDFABCB輸入覆蓋E、語句覆蓋B、D、F、B、D、F、協(xié)助問題的診斷提高 Bug 的發(fā)現(xiàn)率更好的協(xié)助開發(fā)人員使項(xiàng)目參與人員溝通更舒暢軟件工程以及軟件過程的需要控制軟件質(zhì)量B）C、基路徑測試F 、條件覆蓋軟件包質(zhì)量要求包括三部分，即產(chǎn)品描述要求、B.系統(tǒng)功能要求D .軟件配置要求）、在軟件工程，典型的瀑布模型的四個階段是：（A、分析B、設(shè)計C、編碼ABCDD測試E、需求調(diào)研F、實(shí)施導(dǎo)致軟件缺陷的原因有很多，A D是可能的原因，其中最主要的原因包括ABC

11、D）。A軟件需求說明書編寫的不全面，不完整，不準(zhǔn)確，而且經(jīng)常更改B軟件設(shè)計說明書C軟件操作人員的水平D開發(fā)人員不能很好的理解需求說明書和溝通不足22. 軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（AD )AB所有測試項(xiàng)沒有殘余一級、二級和三級錯誤。軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。CD驗(yàn)收測試工件齊全。23. 軟件測試計劃評審會需要哪些人員參加？（ABCD立項(xiàng)審批表、需求分析文檔、設(shè)計文檔和編碼實(shí)現(xiàn)一致。A.項(xiàng)目經(jīng)理BSQA 負(fù)責(zé)人D.測試組C. 配置負(fù)責(zé)人24. 下列關(guān)于 alpha 測試的描述中正確的是：（ A DA alpha測試需要用戶代表參加B alpha測試不

12、需要用戶代表參加C alpha測試是系統(tǒng)測試的一種D alpha測試是驗(yàn)收測試的一種25. 測試設(shè)計員的職責(zé)有：（BCA制定測試計劃B.設(shè)計測試用例C設(shè)計測試過程、腳本D.評估測試活動26. 軟件實(shí)施活動的進(jìn)入準(zhǔn)則是：（ABC )A需求工件已經(jīng)被基線化B.詳細(xì)設(shè)計工件已經(jīng)被基線化C構(gòu)架工件已經(jīng)被基線化D. 項(xiàng)目階段成果已經(jīng)被基線化A）27. 下面的哪一項(xiàng)測試步驟中需要進(jìn)行局部數(shù)據(jù)結(jié)構(gòu)測試：A、單元測試B集成測試C確認(rèn)測試D系統(tǒng)測試28. 從是否需要執(zhí)行被測軟件的角度，軟件測試技術(shù)可劃分的類型是：（AC）。A、 靜態(tài)測試B、 黑盒測試C、 動態(tài)測試D、 白盒測試29. 從測試階段角度，測試結(jié)束的

13、正確順序是：(A、單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試B、單元測試、系統(tǒng)測試、集成測試、確認(rèn)測試C、確認(rèn)測試、集成測試、系統(tǒng)測試、單元測試D、確認(rèn)測試、系統(tǒng)測試、集成測試、單元測試30. 軟件的六大質(zhì)量特性包括：A. 功能性、可靠性、可用性、效率、可維護(hù)、可移植B. 功能性、可靠性、可用性、效率、穩(wěn)定性、可移植C. 功能性、可靠性、可擴(kuò)展性、效率、穩(wěn)定性、可移植D. 功能性、可靠性、兼容性、效率、穩(wěn)定性、可移植三、判斷1.自底向上集成需要測試員編寫驅(qū)動程序。2.測試是證明軟件正確的方法。(3.驗(yàn)收測試是由最終用戶來實(shí)施的。(4.黑盒測試也稱為結(jié)構(gòu)測試。( X5.代碼評審員一般由測試員擔(dān)任。(

14、6.軟件測試的目的是盡可能多的找出軟件的缺陷。7.驗(yàn)收測試是由最終用戶來實(shí)施的。(8.代碼評審是檢查源代碼是否達(dá)到模塊設(shè)計的要求。9.自底向上集成需要測試員編寫驅(qū)動程序。(10.負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。(V)11.測試是調(diào)試的一個部分 ( X )12.軟件測試的目的是盡可能多的找出軟件的缺陷。(13.程序中隱藏錯誤的概率與其已發(fā)現(xiàn)的錯誤數(shù)成正比(14.測試人員要堅持原則，缺陷未修復(fù)完堅決不予通過。V)15.單元測試能發(fā)現(xiàn)約 80%的軟件缺陷。( V16.測試的目的是發(fā)現(xiàn)軟件中的錯誤。(X）17.代碼評審是檢查源代碼是否達(dá)到模塊設(shè)計的要求。（18.19.20.集成測試

15、計劃在需求分析階段末提交。（X）負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（測試中應(yīng)該對有效和無效、期望和不期望的輸入都要測試。（四、名詞解釋1. Beta 測試Beta 測試是從用戶角度進(jìn)行的測試， 是由軟件的多個用戶在一個或多個用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。它是在開發(fā)者無法控制的軟件環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。2. 壓力測試持續(xù)不斷地給被測系統(tǒng)增加壓力，直到系統(tǒng)被壓垮，從而確定系統(tǒng)能承受的最大 壓力。3. 邏輯覆蓋 是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù)。它屬于白盒測試。4. 驅(qū)動模塊：樁模塊（P105）:用于代替所測模塊調(diào)用的子模塊。樁模塊可以進(jìn)行少量的數(shù)據(jù)操作，不

16、需要實(shí)現(xiàn)子模塊的所有功能，但要根據(jù)需要來實(shí)現(xiàn)或代替子模塊的一部分功能。驅(qū)動模塊（P105）：相當(dāng)于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測 模塊，最后再輸出實(shí)際測試結(jié)果。5. 大爆炸集成屬于非增值式集成的一種方法， 也稱為一次性組裝或整體拼裝。 這種集成策略的做法就是把所有通過單元測試的模塊一次性集成到一起進(jìn)行測試，不考慮組件之間的互相依賴性及可能存在的風(fēng)險。6.a測試這個測試一般在可控的環(huán)境下進(jìn)Alpha 測試是由選定的用戶進(jìn)行的產(chǎn)品早期性測試， 行。7.負(fù)載測試讓被測系統(tǒng)在其能忍受的壓力極限范圍內(nèi)連續(xù)運(yùn)行，來測試系統(tǒng)的穩(wěn)定性。8.基路徑覆蓋路徑覆蓋是在組件中被測試執(zhí)行到的路徑

17、的百分比。要求設(shè)計若干測試用例， 執(zhí)行被測試程序時，能夠覆蓋程序中所有的可能路徑。9. 樁模塊樁模塊（P105）:用于代替所測模塊調(diào)用的子模塊。樁模塊可以進(jìn)行少量的數(shù)據(jù)操作,不需要實(shí)現(xiàn)子模塊的所有功能，但要根據(jù)需要來實(shí)現(xiàn)或代替子模塊的一部分功能。10. 三明治集成一種混合增量式測試策略， 綜合了自頂向下和自底向上兩種集成方法的優(yōu)點(diǎn)，因此也屬于基于功能分解的集成。這種方法樁和開發(fā)工作都比較小，但增加了定位缺陷的難度。五、簡答1. 為什么要在一個團(tuán)隊(duì)中開展軟件測試工作？答：軟件測試在整個一個團(tuán)隊(duì)中占有非常重要的地位，具體來說就是測試是一個發(fā)現(xiàn)軟件錯誤的過程，執(zhí)行軟件測試會以最少的人力和時間，系統(tǒng)的

18、找到軟件存在的缺陷和錯誤，建立起開發(fā)人員和使用者對軟件的信心。2. 您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請試述在這個過程中 都有哪些工作要做？分別由哪些不同的角色來完成這些工作？答：軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需求說明書制定項(xiàng)目測試計劃，編寫測試用例，建立測試環(huán)境。軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊及操作手冊，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。3. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測

19、試、驗(yàn)收測試的區(qū)別與聯(lián)系。黑盒測試：把測試對象當(dāng)成一個黑盒子，測試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。白盒測試：把測試對象當(dāng)成一個透明的盒子，允許測試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及相關(guān)信息，設(shè)計或選擇測試用例，對程式所有邏輯路徑進(jìn)行測試。單元測試：白盒測試的一種，對軟件設(shè)計中的單元模塊進(jìn)行測試。集成測試：在單元測試的基礎(chǔ)上，對單元模塊之間的連接和組裝進(jìn)行測試。系統(tǒng)測試：在所有都考慮的情況下，對系統(tǒng)進(jìn)行測試。驗(yàn)收測試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測試。4. 單元測試策略主要有哪三種方式？分別加以說明。1）自頂向下的單元測試策略：從頂層調(diào)用的

20、單元做成樁模塊；對第二層測試，使用上面已測試的單元做驅(qū)動模塊；依次類推，直到全部單元測試結(jié)束。2）自底向上的單元測試策略：先對模塊調(diào)用的最底層模塊進(jìn)行測試，模擬調(diào)用該模塊的模塊為驅(qū)動模塊；其次，對上一層模塊進(jìn)行單元測試，用已經(jīng)被測試過的模塊做樁模塊， 依次類推，直到全部單元測試結(jié)束。3）孤立測試的單元測試策略：無需考慮每個模塊與其他模塊之間的關(guān)系，分別為每個模塊單獨(dú)設(shè)計樁模塊和驅(qū)動模塊，逐一完成所有單元模塊的測試。軟件測試和軟件測試結(jié)束的標(biāo)準(zhǔn)：5. 什么是恢復(fù)性測試，在進(jìn)行恢復(fù)性測試時要考慮的主要問題有哪些？ 恢復(fù)性測試 也叫容錯測試， 用來檢查系統(tǒng)的容錯能力。 通常若計算機(jī)系統(tǒng)出現(xiàn)錯誤， 就

21、必須在一定時間 內(nèi)從錯誤中恢復(fù)過來，修正錯誤并重新啟動系統(tǒng)。恢復(fù)測試是通過各種手段， 讓軟件強(qiáng)制性地出錯， 使其不能正常工作， 從而檢驗(yàn)系統(tǒng)的恢復(fù) 能力。在進(jìn)行恢復(fù)性測試時，要考慮的主要問題有：1)恢復(fù)期間的安全性過程。2)恢復(fù)處理日志方面的能力。3)當(dāng)出現(xiàn)供電問題時的恢復(fù)能力。4)恢復(fù)操作后系統(tǒng)性能是否下降。6.功能測試只對軟件的功能是否滿足用戶需求來做測試。性能測試需要和壓力和負(fù)載測您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試答：有功能測試，性能測試，可靠性測試，安全性測試，負(fù)載測試，壓力測試，安裝/卸載測試，啟動 /停止測試，兼容性測

22、試，互連測試，文檔測試，恢復(fù)測試，回歸測試，可使用性測試，容量測試。試聯(lián)合起來。7. 什么是軟件測試，軟件測試分為哪幾個階段軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 或者說， 軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)，并格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計一批測試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果） 利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯誤的過程。軟件測試過程按各測試階段的先后順序可分為單元測試、集成測試、確認(rèn)（有效性）測試、 系統(tǒng)測試和驗(yàn)收（用戶）測試 5 個階段 軟件測試退出標(biāo)準(zhǔn)為：完成測試需求中列出的所有功能及測試過程中發(fā)現(xiàn)缺陷的回歸測試。8. 判斷系統(tǒng)安全性性能的指標(biāo)有哪些？并加以說明。1）有效

23、性：啟動嚴(yán)格的安全性性能所花費(fèi)的時間占啟動整個系統(tǒng)所花費(fèi)時間的比例。2）生存性：當(dāng)錯誤發(fā)生時，系統(tǒng)對緊急操作的支持，對錯誤的補(bǔ)救措施以及恢復(fù)到正常操 作的能力，即系統(tǒng)的抗挫能力。3）精確性：衡量系統(tǒng)安全性控制的精度指標(biāo)，圍繞所出現(xiàn)的錯誤數(shù)量、發(fā)生頻率及其嚴(yán)重 性判斷。4）反應(yīng)時間： 出錯時系統(tǒng)響應(yīng)速度的快慢， 一個安全性較強(qiáng)的系統(tǒng)要具備快速的反應(yīng)速度。5） 吞吐量：用戶和服務(wù)請求的峰值和平均值。六、綜合1. 常見的黑盒測試方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。1. 等價類劃分 常見的軟件測試面試題劃分等價類 : 等價類是指某個輸入域的子集合 . 在該子集合中

24、,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的. 并合理地假定 :測試某等價類的代表值就等于對這一類其它值的測試 . 因此 , 可以把全部輸入數(shù)據(jù)合理劃分為若干等價類, 在 每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件 ,就可以用少量代表性的測試數(shù)據(jù) . 取得 較好的測試結(jié)果 . 等價類劃分可有兩種不同的情況 : 有效等價類和無效等價類, 大量的錯誤2. 邊界值分析法 邊界值分析方法是對等價類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我是發(fā)生在輸入或輸出范圍的邊界上 ,而不是發(fā)生在輸入輸出范圍的內(nèi)部 . 因此針對各種邊 界情況設(shè)計測試用例 , 可以查出更多的錯誤 .使用邊界值分析方法設(shè)計測試用例 , 首先應(yīng)

25、確定邊界情況 .通常輸入和輸出等價類的邊界 ,就是應(yīng)著重測試的邊界情況 . 應(yīng)當(dāng)選取正好等于 , 剛剛大于或剛剛小于邊界的值 作為測試數(shù)據(jù) , 而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)3. 錯誤推測法基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法 .錯誤推測方法的基本思想 : 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況 , 根據(jù)他們選擇測試用例 . 例如 , 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗(yàn)的總結(jié)。 還有 , 輸入數(shù)據(jù)和輸出數(shù) 據(jù)為 0 的情況。輸入表格為空格或輸入表格只有一行 . 這些都是容易發(fā)生錯誤的情況。可 選擇這些情況下的例子作為測試用例4. 因果圖方法前面介紹的等價類劃分方法和邊界值分析方法, 都是著重考慮輸入條件 , 但未考慮輸入條件之間的聯(lián)系 , 相互組合等 . 考慮輸入條件之間的相互組合 , 可能會產(chǎn)生一些新 的情況 . 但要檢查輸入