《軟件測試》復(fù)習(xí)重點(精)

1、1. 軟件開發(fā)過程中錯誤之所以不可防止, 從客觀上說, 是由于所開發(fā)的軟件具有相當?shù)膹?fù)雜 性。從主觀方面講,那么是由于人們思維的局限性。2. 軟件測試是指在特定的條件下系統(tǒng)或其中的部件進行操作、 觀測并記錄結(jié)果, 并對系統(tǒng)或 部件的某方面作出評估的過程。3.Myers 給出的三個重要觀點:測試是為了證明程序有錯,而不是證明程序無錯誤;一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤;一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。4. 錯誤出現(xiàn)在書寫程序的過程中導(dǎo)致錯誤的原因 :對需求的誤解;編寫代碼邏輯不清或疏忽軟件配置錯誤故障是錯誤在程序代碼中的表達,程序中的故障就是導(dǎo)致程序按照非預(yù)期的方式運

2、行的因 素, 并不是所有的軟件故障均有編碼錯誤引起, 當一段包含故障的代碼被執(zhí)行且導(dǎo)致不正確 的狀態(tài)并傳播到程序的輸出,即失效發(fā)生。并不是所有的故障均會導(dǎo)致失效,一個故障可能導(dǎo)致多種失效病癥由錯誤故障失效的根本過程:由于程序設(shè)計人員犯了一個錯誤, 并導(dǎo)致軟件源代碼中形成一個故障。 如果在一定的條件下 該故障被執(zhí)行且促使系統(tǒng)產(chǎn)生錯誤的結(jié)果,從而形成了一個失效。5. 軟件可靠性就是軟件在給定條件和給定時間間隔內(nèi)不出現(xiàn)失效的概率。軟件正確性只有當一個程序在 每一種輸入 下都能按預(yù)期執(zhí)行才能被稱為是正確的。 正確性是一種二進制度量,而可靠性那么是 0至 1的區(qū)間度量。6. 軟件調(diào)試是在計算機程序中發(fā)現(xiàn)

3、故障并減少其數(shù)目的一個方法性的過程。Testing 與 Debugging 的區(qū)別測試的目的是顯示存在錯誤, 而調(diào)試的目的是發(fā)現(xiàn)錯誤或?qū)е鲁绦蚴У腻e誤原因, 并修改 程序以修正錯誤。調(diào)試是測試之后的活動。測試和調(diào)試在目標、方法和思路上都有所不同,具體如下:1. 測試從一個的條件開始,使用預(yù)先定義的過程,有預(yù)知的結(jié)果。調(diào)試從一個未知的 條件開始,結(jié)束的過程不可預(yù)計。2. 測試過程可以事先設(shè)計,進度可事先確定。調(diào)試不能描述過程或持續(xù)時間。3. 測試是顯示錯誤的行為;調(diào)試是推理的過程。4. 測試顯示開發(fā)人員的錯誤;調(diào)試是開發(fā)人員為自己辯護。5. 測試能預(yù)期和可控;調(diào)試需要想象,經(jīng)驗和思考。6. 測

4、試能在沒有詳細設(shè)計的情況下完成;沒有詳細設(shè)計的信息調(diào)試不可能進行。7. 測試能由非開發(fā)人員進行;調(diào)試必須由開發(fā)人員進行。7. SQA與 ST 的區(qū)別與聯(lián)系軟件測試和軟件質(zhì)量保證是軟件質(zhì)量工程的兩個不同層面的工作。軟件測試只是軟件質(zhì)量保證工作的一個重要環(huán)節(jié)。質(zhì)量保證 (QA的工作是通過預(yù)防、檢查和改良來保證軟件質(zhì)量。SQA 從流程方面保證軟件的質(zhì)量ST 從技術(shù)方面保證軟件的質(zhì)量QA 采取的方法主要是按照“全面質(zhì)量管理和“過程管理并改良的原來展開工作。 在質(zhì)量 保證的工作中會摻入一些測試活動, 但它所關(guān)注的是軟件質(zhì)量的檢查和測量。 因此, 其主要 工作是著眼于軟件開發(fā)活動中的過程、 步驟和產(chǎn)物,

5、并不是對軟件進行剖析, 找出問題和評 估。測試雖然也與開發(fā)過程緊密相關(guān), 但它所關(guān)心的不是過程的活動, 相對的是關(guān)心結(jié)果。 測試 人員要對過程中的產(chǎn)物 (開發(fā)文檔和源代碼 進行靜態(tài)審核, 運行軟件, 找出問題, 報告質(zhì)量 甚至評估, 而不是為了驗證軟件的正確性。當然, 測試的目的是為了去證明軟件有錯, 否那么 就違背了測試人員的本職了。 因此, 測試雖然對提高軟件質(zhì)量起了關(guān)鍵的作用, 但它只是軟 件質(zhì)量保證中的一個重要環(huán)節(jié)。SQA 重點是對軟件開發(fā)過程進行監(jiān)督、管理、控制;ST 重點是對軟件開發(fā)的成果進行檢查、控制。8. 確認是指如何決定最后的軟件產(chǎn)品是否正確無誤。驗證是指如何決定軟件開發(fā)的每

6、個階段、每個步驟的產(chǎn)品是否正確無誤,并與其前面的 開發(fā)階段和開發(fā)步驟的產(chǎn)品相一致。確認和驗證是有聯(lián)系的,但也有明顯的差異。Boehm 在 1981年是這樣來描述兩者差異的:確認要答復(fù)的問題是:我們正在開發(fā)一個正確無誤的軟件產(chǎn)品嗎?驗證要答復(fù)的問題是:我們正開發(fā)的軟件產(chǎn)品是正確無誤的嗎?9. CMM軟件評估與 軟件測試成熟度 T MM 無聯(lián)系10. 軟件測試方法可以從不同的角度進行分類:按照是否執(zhí)行程序劃分按照代碼的可見性劃分按照測試的實施者劃分按照測試過程劃分針對軟件特定特征的測試11. 靜態(tài)測試 是指不利用計算機運行被測試的程序, 而是通過人工的方式對程序或相關(guān)文檔 進行檢查以到達檢測目的的

7、方法。動態(tài)測試 就是通過執(zhí)行被測程序, 并監(jiān)視其執(zhí)行狀態(tài)、 收集并比照其執(zhí)行結(jié)果以判斷程序是 否正確運行的方法。12. 靜態(tài)測試主要包含的方法有:桌面檢查 (desktopcheck 一種最為傳統(tǒng)的方法,由程序員檢查自己編寫的程序。程序員在 程序通過編譯之后, 對源程序代碼進行分析、 檢驗,并補充相關(guān)的文檔,目的是發(fā)現(xiàn)程序中 的故障。 由于程序員熟悉自己的程序及其程序設(shè)計風(fēng)格, 桌面檢查由程序員自己進行可以節(jié) 省很多的檢查時間,但應(yīng)防止主觀片面性。同行評審 (peer review 由假設(shè)干程序員和測試員組成一個審查小組, 通過閱讀、 討論和爭議, 對程序進行靜態(tài)分析的過程。通常分兩步進行:小

8、組負責(zé)人提前把設(shè)計規(guī)格說明書、控制流程圖、程序文本及有關(guān)要求、標準等分發(fā)給 小組成員,作為審查的依據(jù)。小組成員在充分閱讀這些材料后,進入評審的第二步。召開評審會。在會上,首先由程序員逐句講解程序的邏輯。在此過程中,程序員或其他 小組成員可以提出問題,展開討論,審查缺陷是否存在。實踐說明, 程序員在講解過程中能發(fā)現(xiàn)許多原來自己沒有發(fā)現(xiàn)的錯誤, 而討論和爭議促進了 問題的暴露。代碼走查 (code walkthrough 代碼走查同樣也分兩步進行:第一步也是把材料先發(fā)給走查小組成員,讓他們認真研究程序,然后再開會。開會的程序與同行評審不同,不是簡單地讀程序和對照錯誤檢查單進行檢查,而是讓與 會者“

9、充當計算機, 即首先由測試組成員為所測程序準備一批有代表性的測試用例, 提交 給走查小組。 走查小組開會, 集體扮演計算機角色, 讓測試用例沿程序的邏輯進行運行一遍,隨時記錄程序的執(zhí)行軌跡,供分析和討論用。走查人員借助測試用例的媒介作用, 對程序的邏輯和功能提出各種疑問, 結(jié)合問題開展熱烈 的討論和爭議,能夠發(fā)現(xiàn)更多的問題。13. 功能性測試 , 又稱作黑盒測試、 基于規(guī)格說明的測試等, 是通過軟件的外部表現(xiàn)來發(fā)現(xiàn) 其缺陷和錯誤,檢查程序是否按照需求規(guī)格說明書的規(guī)定正常實現(xiàn)。結(jié)構(gòu)性測試 ,又稱作白盒測試、 基于程序的測試等,通過分析程序的內(nèi)部結(jié)構(gòu),以覆蓋程序 結(jié)構(gòu)元素為目標的一類測試方法的總稱

10、在結(jié)構(gòu)性測試中可使用各種測試方法的綜合策略如下:在測試中,應(yīng)盡量先用工具進行靜態(tài)結(jié)構(gòu)分析。測試中可采取先靜態(tài)后動態(tài)的組合方式:先進行靜態(tài)結(jié)構(gòu)分析、代碼檢查和靜態(tài)質(zhì)量度 量,再進行覆蓋率測試。利用靜態(tài)分析的結(jié)果作為引導(dǎo),通過代碼檢查和動態(tài)測試的方式對靜態(tài)分析結(jié)果進行進 一步確實認,使測試工作更為有效。覆蓋率測試是白盒測試的重點,一般可使用根本路徑測試法到達語句覆蓋標準;對于軟 件的重點模塊,應(yīng)使用多種覆蓋標準衡量代碼的覆蓋率。在不同的測試階段,測試的側(cè)重點不同:在單元測試階段,以代碼檢查、邏輯覆蓋為主; 在集成測試階段,需要增加靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量;在系統(tǒng)測試階段,應(yīng)根據(jù)黑盒測 試的結(jié)果,

11、采取相應(yīng)的白盒測試。14. 過錯缺陷:是指在實現(xiàn)軟件過程中對某些功能進行了錯誤的實現(xiàn)而引起的一類軟件缺 陷。遺漏缺陷:是指在實現(xiàn)軟件過程中遺漏對某些功能的實現(xiàn)而引起的一類軟件缺陷15. 功能性測試 遺漏缺陷結(jié)構(gòu)性測試 過錯缺陷能力強16. 灰盒測試結(jié)合了白盒測試盒黑盒測試的要素,是兩者的折中17. 按照測試實施的組織,軟件測試通?？梢詣澐譃槿缦氯?開發(fā)方測試:通常也叫“驗證測試或“ 測試。用戶方測試:通常也叫 測試第三方測試:介于軟件開發(fā)方和用戶方之間的測試組織實施的測試活動。是由在技術(shù)、 管理和財務(wù)上與開發(fā)方和用戶方相對獨立的組織進行的軟件測試。 一般情況下是在模擬用戶 真實應(yīng)用的環(huán)境下,

12、進行軟件確認測試。18. 功能性測試 v.s. 結(jié)構(gòu)性測試 19. 按照測試過程,通?？梢詣澐譃槿缦滤膫€步驟:單元測試 (Unit Testing:又稱為模塊測試,針對軟件設(shè)計的程序模塊進行正確性檢驗 的測試工作集成測試 (Integrated Testing :集成測試也叫組裝測試,通常是在單元測試的根底上, 對由假設(shè)干個模塊組裝而成的子系統(tǒng)實施的測試。確認測試 (Validation Testing:驗證軟件的功能和性能及其他特性是否與用戶的要求 一致。系統(tǒng)測試 (System Testing:是將通過集成測試的軟件,作為整個基于計算機系統(tǒng)的一 個元素,與計算機硬件、外設(shè)、某些支持軟件、數(shù)

13、據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,在 實際或者模擬運行 (使用 環(huán)境下,對計算機系統(tǒng)進行的一系列測試。驗收測試 (Acceptance Testing:驗收測試往往不是對系統(tǒng)進行全覆蓋測試,而是針對 用戶的核心業(yè)務(wù)流程進行的測試。20. 單元測試要解決的問題:模塊接口:對于被測模塊,信息能否正常無誤地流入和流出。 (應(yīng)首先檢驗 局部數(shù)據(jù)結(jié)構(gòu):在模塊工作過程中,其內(nèi)部的數(shù)據(jù)能否保持其完整性,包括內(nèi)部數(shù)據(jù)的 內(nèi)容、形式及相互關(guān)系不發(fā)生錯誤。邊界條件:在為限制數(shù)據(jù)加工而設(shè)置的邊界處,模塊是否能夠正常工作。覆蓋條件:模塊的運行能否做到滿足特定的邏輯覆蓋。出錯處理:模塊工作中發(fā)生了錯誤,其中的出錯處理設(shè)

14、施是否有效。21. 驅(qū)動模塊 (driver:用以模擬被測模塊的上級模塊。樁模塊 (stub:用以模擬被測模塊工作過程中所調(diào)用的模塊。22. 集成測試的分類:非增量式集成測試增量式集成測試1. 自頂向下集成測試:將模塊按系統(tǒng)程序結(jié)構(gòu),沿控制層次自頂向下進行組裝。 、 測試實施步驟:(1 首先以主模塊作為所測模塊兼驅(qū)動模塊, 所有直屬于主模塊的下屬模塊全部用樁模塊代 替,對主模塊進行測試。(2 再采用深度優(yōu)先或廣度優(yōu)先的策略, 用實際模塊代替相應(yīng)的樁模塊, 再用樁模塊代替它 們的直接下屬模塊,與已測試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)。(3 然后測試新組裝成的子系統(tǒng), 排除組裝過程中引入新錯誤的可能

15、, 直至所有模塊均組裝 到系統(tǒng)中為止。優(yōu)點:(1 在測試過程中較早地驗證了主要的控制和判斷點,能較早地發(fā)現(xiàn)主要控制方面的問題 。(2如果選用按深度方向組裝的方式,可以首先實現(xiàn)和驗證一個完整的軟件功能,可先對邏 輯輸入的分支進行組裝和測試, 檢查和克服潛藏的錯誤和缺陷, 驗證其功能的正確性, 為對 其后分支的組裝和測試提供了保證。缺點:(1 在測試需要建立樁模塊,而要使樁模塊能夠模擬實際子模塊的功能十分困難。(2 涉及復(fù)雜算法和真正輸入 /輸出的模塊一般在底層,它們是最容易出問題的模塊,到組 裝和測試的后期才遇到這些模塊,一旦發(fā)現(xiàn)問題,就會導(dǎo)致過多的重復(fù)測試。2. 自底向上集成測試:實施步驟:(

16、1 首先由驅(qū)動模塊控制最底層模塊的并行測試, 也可以把底層模塊組合成實現(xiàn)某一特定軟 件功能的簇,由驅(qū)動模塊控制它進行測試。(2 再用實際模塊代替驅(qū)動模塊,與它已測試的直屬子模塊組裝成為子系統(tǒng)。(3然后為子系統(tǒng)配備驅(qū)動模塊并進行新的測試,直至組裝到達主模塊為止。優(yōu)點:(1 不需要樁模塊, 而建立一個驅(qū)動模塊一般比建立樁模塊容易。 (2 由于涉及到復(fù) 雜算法和真正輸入 /輸出的模塊最先得到組裝和測試, 可以把容易出問題的局部在早期解決。 (3 可以實施多個模塊的并行測試,從而提高測試效率。缺點:程序一直未能作為一個實體存在, 直到最后一個模塊加上去后才形成一個實體。 也就 是說,在自底向上組裝和測

17、試的過程中,對主要的控制直到最后才接觸到。23. V模型 V 模型是軟件開發(fā)瀑布模型的變種,它反映了測試活動與分析和設(shè)計的關(guān)系,從左到右,描 述了根本的開發(fā)過程和測試行為, 非常明確地說明了測試過程中存在的不同級別, 并且清楚 地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。V 模型的軟件測試策略既包括低層測試又包括了高層測試, 低層測試是為了源代碼的正確性, 高層測試是為了使整個系統(tǒng)滿足用戶的需求。V 模型的局限性:僅僅把測試過程作為在需求分析、概要設(shè)計、詳細設(shè)計及編碼之后的一個階段。容易使人理解為測試是軟件開發(fā)的最后的一個階段, 主要是針對程序進行測試尋找錯誤, 而 需求分析階段隱藏的

18、問題一直到后期的驗收測試才被發(fā)現(xiàn)。V 模型的局限性在于沒有明確地說明早期的測試, 不能表達 “ 盡早地和不斷地進行軟件測試 的原那么。改良措施:在 V 模型中增加軟件各開發(fā)階段應(yīng)同步進行的測試, 被演化為一種 W 模型, 因為實 際上開發(fā)是“ V ,測試也是與此相并行的“ V 。W 模型W 模型的局限性:W 模型和 V 模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動。開發(fā)和測試保持一種線性的前后關(guān)系,無法支持迭代、自發(fā)性以及變更調(diào)整。24. 軟件測試信息流: 軟件配置 :包括軟件需求規(guī)格說明、軟件設(shè)計規(guī)格說明、源代碼等。測試配置 :包括測試方案、測試用例、測試驅(qū)動程序等。實際上,在整

19、個軟件工程中,測試 配置只是軟件配置的一個子集。測試工具 :為測試的實施提供某種效勞, 以減輕測試任務(wù)中的手工勞動。例如:測試數(shù)據(jù)自 動生成程序、靜 (動 態(tài)分析程序、測試結(jié)果分析程序以及驅(qū)動測試的測試數(shù)據(jù)庫等。25. 回歸測試 (Regression Testing :在軟件維護過程中,為了確保修改代碼或新增功能的 正確性,并保證修改局部不帶來副作用的測試活動稱之為回歸測試?；貧w測試的根本過程:(1識別出軟件中被修改的局部。(2從原基線測試用例庫 T 中, 排除所有不再適用的測試用例, 確定那些對新的軟件版本依然 有效的測試用例,其結(jié)果是建立一個新的基線測試用例庫 T0。(3依據(jù)一定的策略從

20、 T0中選擇測試用例測試被修改的軟件。(4如果必要,生成新的測試用例集 T1,用于測試 T0無法充分測試的軟件局部。(5用 T1執(zhí)行修改后的軟件。第 (2和第 (3步測試驗證修改是否破壞了現(xiàn)有的功能, 第 (4和第 (5步測試驗證修改工作本 身。26. 測試用例的維護主要內(nèi)容包括下述幾個方面:(1刪除過時的測試用例。(2改良不受控制的測試用例:一些對輸入或運行狀態(tài)十分敏感的測試用例測試不容易重 復(fù)且結(jié)果難以控制。(3刪除冗余的測試用例。 測試用例集約簡(4增添新的測試用例。26. 在組織回歸測試時需要注意兩點:首先是各測試階段發(fā)生的修改一定要在本測試階段內(nèi)完成回歸,以免將錯誤遺留到下一 測試階

21、段。其次, 回歸測試期間應(yīng)對該軟件版本凍結(jié), 將回歸測試發(fā)現(xiàn)的問題集中修改, 集中回歸。 27. 功能性測試方法1. 邊界值測試2. 等價類 (劃分 測試:把所有可能的輸入數(shù)據(jù),即程序的輸入域劃分成假設(shè)干局部,然后從 每個局部中選取少數(shù) 代表性 數(shù)據(jù)當作測試用例。兩個步驟:(1 劃分等價類;劃分原那么 (1 如果輸入條件規(guī)定了取值范圍, 或值的個數(shù), 那么可以確立一個有效等價類和兩 個無效等價類。例如,在程序的規(guī)格說明中,對輸入條件有一句話:“ 項數(shù)可以從 1到999 那么 有效等價類是“1項數(shù)999, 兩個無效等價類是“項數(shù)<1或“項數(shù)>999。 在數(shù)軸上表示成 :劃分原那么 (

22、2 如果輸入條件規(guī)定了輸入值的集合, 或者是規(guī)定了“必須如何的條件, 這時 可確立一個有效等價類和一個無效等價類。例如, 在 Pascal 語言中對變量標識符規(guī)定為“以字母打頭的串。 那么所有以字母打頭 的構(gòu)成有效等價類,而不在此集合內(nèi) (不以字母打頭 的歸于無效等價類。劃分原那么 (3 如果輸入條件是一個布爾量,那么可以確定一個有效等價類和一個無效等價類。 劃分原那么 (4 如果規(guī)定了輸入數(shù)據(jù)的一組值 (假定 n 個 , 而且程序要對每個輸入值分別進行處 理。 這時可為每一個輸入值確立一個有效等價類 (共 n 個 , 此外針對這組值確立一個無效等 價類,它是所有不允許的輸入值的集合。劃分原那

23、么 (5 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)那么,那么可以確立一個有效等價類 (符合規(guī)那么 和假設(shè)干個無效等價類 (從不同角度違反規(guī)那么 。劃分原那么 (6 如果我們確知,已劃分的等價類中各元素在程序中的處理方式是不同的,那么應(yīng) 將此等價類進一步劃分成更小的等價類。(2 選取測試用例。例:某程序規(guī)定:“輸入三個整數(shù)作為三邊的邊長構(gòu)成三角形。當此三角形為一般三角形、 等腰三角形及等邊三角形時,分別做計算.試用等價類劃分方法為該程序進行測試用例 設(shè)計。依據(jù)程序的需求規(guī)格說明, 可以看出程序輸入條件要求的關(guān)鍵之處有:(1整數(shù) ; (2三個數(shù) ; (3非零數(shù) ; (4正數(shù)輸出條件要求的關(guān)鍵之處有:(5應(yīng)滿

24、足兩邊之和大于第三邊 ; (6等腰 ; (7等邊其中, (3、 (4和 (5并沒有在題目上明顯給出,但這些條件是必要的。 列出等價類表:列出覆蓋上述等價類的測試用例: 覆蓋有效等價類的測試用例: 覆蓋無效等價類的測試用例:3. 判定表測試方法:判定表 (決策表 是分析和表達多邏輯條件下執(zhí)行不同操作的情況下的 工具。判定表的建立步驟:(根據(jù)軟件規(guī)格說明 1. 確定條件及其可能的取值;2. 確定規(guī)那么的個數(shù);3. 確定動作項;4. 填入條件項的可能取值;5. 針對每一條規(guī)那么,填入恰當?shù)膭幼黜椫?6. 驗證規(guī)那么是否正確;7. 化簡規(guī)那么。條件樁 (Condition Stub:列出了問題的所有條

25、件,通常認為列出的條件的次序無關(guān)緊要。 動作樁 (Action Stub:列出了問題規(guī)定可能采取的操作,這些操作的排列順序沒有約束。 條件項 (Condition Entry:列出針對它左列條件 (即條件樁 的取值。動作項 (Action Entry:列出在條件項的各種取值情況下應(yīng)該采取的動作。規(guī)那么 (Rule:任何一個條件組合的特定取值及其相應(yīng)要執(zhí)行的操作。 在判定表中貫穿條件項 和動作項的一列就是一條規(guī)那么。4. 因果圖測試方法因果圖測試方法的根本步驟1、 分析軟件規(guī)格說明描述中, 哪些是原因 (即輸入條件或輸入條件的等價類 , 哪些是結(jié)果 (即 輸出條件 ,并給每個原因和結(jié)果賦予一個標

26、識符。2、分析軟件規(guī)格說明描述中的語義,找出原因與結(jié)果之間、原因與原因之間的關(guān)系。根據(jù) 這些關(guān)系,畫出因果圖。3、標明原因與原因之間,原因與結(jié)果之間不可能出現(xiàn)的組合情況地約束或限制條件。4、把因果圖轉(zhuǎn)換成判定表。5、把判定表的每一列拿出來作為依據(jù),設(shè)計測試用例。例:設(shè)要對一個自動飲料售貨機軟件進行黑盒測試, 該軟件的規(guī)格說明如下:有一個處理單 價為 1元 5角錢的盒裝飲料的自動售貨機軟件。 假設(shè)投入 1元 5角硬幣, 按下“可樂、 “雪碧 或“紅茶按鈕, 相應(yīng)的飲料就送出來。 假設(shè)投入的是 2元硬幣, 在送出飲料的同時退還 5角硬 幣。首先,可以列出原因和結(jié)果如下:原因:(1 投入 1元 5角

27、硬幣; (2 投入 2元硬幣; (3 按“可樂按鈕; (4 按“雪碧按 鈕; (5 按“紅茶按鈕。中間狀態(tài):(11 已投幣; (12 已按鈕。結(jié)果:(1 退還 5角硬幣; (2 送出“可樂飲料; (3 送出“雪碧飲料; (4 送出“紅 茶飲料。 根據(jù)原因和結(jié)果,可以設(shè)計這樣一個因果圖如下:轉(zhuǎn)換為測試用例,如下表所示,每一列可作為確定測試用例的依據(jù)5. 組合測試方法 用在兩個方面：1.程序輸入；2.配置空間 正交設(shè)計試驗：假定有一個3因子3水平的測試問題，其中三個因素分別記為A、B和C，三個 水平那么分別用1、2、3表示。 如果取三因子所有水平的組合，那么可以得到： 簡單比照法： 首先固定B、C

28、于B1、C1，使A變化： 如得出結(jié)果A3最好，那么固定A于A3，C還是C1，使B變化： 得出結(jié)果以B2為最好，那么固定B于B2，A于A3，使C變化： 28. 測試用例：就是事先設(shè)計的程序的一種執(zhí)行情形，主要由測試數(shù)據(jù)與期望結(jié)果構(gòu)成。看 程序在測試數(shù)據(jù)的輸入下，能否正常運行并且到達所設(shè)計的預(yù)期執(zhí)行結(jié)果。 29. 程序插裝就是向程序中插入一條或是多條語句， 以便監(jiān)視程序的某方面的執(zhí)行特征或行 為。 分類：語句覆蓋插裝；邊覆蓋插裝；斷言插裝 30. 控制流分析(Control Flow Analysis, CFA就是發(fā)現(xiàn)一個過程(方法中的控制流，并用 適當?shù)男问奖磉_出來，可擴展到過程(方法間。 常見

29、的控制流表示方式有兩種： (1 抽象語法樹AST，主要用于程序編譯處理階段，進行程序控制邏輯的存儲與優(yōu)化； (2 控制流圖CFG，是在AST根底上更高層的抽象表示，能較好地可視化表示程序中語句、 模塊之間的執(zhí)行順序和相互調(diào)用關(guān)系，被公認是當今程序分析、理解與測試的根底。此外， 還有一些基于形式語義的分析與表示方法。 31. 控制流圖CFG是一有向圖G = (N, E, nentry, nexit. 其中， N是節(jié)點集，程序中的每 個語句都對應(yīng)圖中的一個節(jié)點；邊集E = < n1,n2 > | n1, n2 N且n1執(zhí)行后，可能立即 執(zhí)行n2； nentry和nexi分別為程序的入口和出口節(jié)點。 程序控制流圖的繪制： 程序語句格式化、標準化處理； 識別程序的邏輯行； 根據(jù)程序邏輯