




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
1、-作者xxxx-日期xxxx軟件測試技術(shù)復(fù)習(xí)題(含答案)【精品文檔】注釋:黃色表示重復(fù)或相似一、選擇題1. 軟件測試的目的是( B )A. 避免軟件開發(fā)中出現(xiàn)的錯誤B. 發(fā)現(xiàn)軟件中出現(xiàn)的錯誤C. 容忍軟件中出現(xiàn)的錯誤D. 修改軟件中出現(xiàn)的錯誤2. 對于邏輯表達(dá)式(a&b)| |c),需要( C )個測試用例才能完成條件組合覆蓋。A 2B 3C 4D 53. 邏輯覆蓋法不包括( C )。A 分支覆蓋B 語句覆蓋C 需求覆蓋D 修正條件判定覆蓋4. 如果某測試用例集實(shí)現(xiàn)了某軟件的路徑覆蓋,那么它一定同事實(shí)現(xiàn)了該軟件的( A )。A. 判定覆蓋B. 條件覆蓋C. 判定/條件覆蓋D. 組合覆蓋
2、5. 使用白盒測試方法時,確定測試數(shù)據(jù)的依據(jù)是指定覆蓋標(biāo)準(zhǔn)和( B )。A 程序的注釋B 程序的內(nèi)部邏輯C 用戶使用說明書D 程序的需求說明6. 劃分軟件測試屬于白盒測試還是黑盒測試的依據(jù)是( C )。A 是否執(zhí)行程序代碼B 是否能看到軟件設(shè)計(jì)文檔C 是否能看到被測源程序D 運(yùn)行結(jié)果是否確定7. 單元測試中用來模擬被測模塊調(diào)用者的模塊是( C )A 父模塊B 子模塊C 驅(qū)動模塊D 樁模塊8. 不屬于單元測試內(nèi)容的是( A )A 模塊接口測試B 局部數(shù)據(jù)結(jié)構(gòu)測試C 路經(jīng)測試D 用戶界面測試9. 客戶端交易處理性能指標(biāo)是一類重要的負(fù)載壓力測試指標(biāo),以下不屬于客戶端交易處理性能指標(biāo)的是( C )A
3、負(fù)載測試B 壓力測試C 疲勞強(qiáng)度測試D 大數(shù)據(jù)量測試10. 以下不屬于易用性而的是( D )A 功能易用性測試B 用戶界面測試C 輔助功能測試D 可靠性測試11. 軟件測試的目的是( F )E. 避免軟件開發(fā)中出現(xiàn)的錯誤F. 發(fā)現(xiàn)軟件中出現(xiàn)的錯誤G. 容忍軟件中出現(xiàn)的錯誤H. 修改軟件中出現(xiàn)的錯誤12. 軟件的測試對象包括( D )。A 軟件代碼B 文檔C 數(shù)據(jù)D 以上全選13. 對于邏輯表達(dá)式(a&b)| |c),需要( G )個測試用例才能完成條件組合覆蓋。E 2F 3G 4H 514. 如果某測試用例集實(shí)現(xiàn)了某軟件的路徑覆蓋,那么它一定同事實(shí)現(xiàn)了該軟件的( E )。E. 判定覆蓋
4、F. 條件覆蓋G. 判定/條件覆蓋H. 組合覆蓋15. 以下不屬于黑盒測試方法的是( D )A 等價類劃分法B 邊界值分析法C 錯誤推測法D 靜態(tài)結(jié)構(gòu)分析法16. 劃分軟件測試屬于白盒測試還是黑盒測試的依據(jù)是( G )。E 是否執(zhí)行程序代碼F 是否能看到軟件設(shè)計(jì)文檔G 是否能看到被測源程序H 運(yùn)行結(jié)果是否確定17. 單元測試中用來模擬被測模塊調(diào)用者的模塊是( G )E 父模塊F 子模塊G 驅(qū)動模塊H 樁模塊18. 不屬于單元測試內(nèi)容的是( E )E 模塊接口測試F 局部數(shù)據(jù)結(jié)構(gòu)測試G 路經(jīng)測試H 用戶界面測試19. 在進(jìn)行單元測試時,常用的方法是( B )A 采用黑盒測試,輔之以白盒測試B 采
5、用白盒測試,輔之以黑盒測試C 只是用黑盒測試D 只是用白盒測試20. 客戶端交易處理性能指標(biāo)是一類重要的負(fù)載壓力測試指標(biāo),以下不屬于客戶端交易處理性能指標(biāo)的是( G )E 負(fù)載測試F 壓力測試G 疲勞強(qiáng)度測試H 大數(shù)據(jù)量測試21. 實(shí)際的邏輯覆蓋測試中,一般以( J )為主設(shè)計(jì)測試用例。I. 條件覆蓋J. 判定覆蓋K. 條件組合覆蓋L. 路徑覆蓋22. 單元測試所使用的主要測試方法是( D )A. 黑盒測試B. 靜態(tài)測試C. 動態(tài)測試D. 白盒測試23. 集成測試所使用的主要測試方法是( A )。A. 黑盒測試B. 靜態(tài)測試C. 動態(tài)測試D. 白盒測試24. 系統(tǒng)集成測試常見的有哪幾種不同模式
6、(AB )。A 非漸增式測試模式B 漸增式測試模式C 獨(dú)立測試模式D 非獨(dú)立測試模式25. 在集成測試中,主要的集成方法有( )。E 自頂向下F 自底向上G 大棒H 三明治26. 文檔測試主要檢查文檔的( ABCD )。A 正確性B 完備性C 易理解性D 一致性27. 驗(yàn)收測試完成后還需要提交( AC ),才可交付用戶使用。A 驗(yàn)收報告B 項(xiàng)目完成報告C 交付報告D 無需提供任何報告28. 軟件產(chǎn)品的質(zhì)量中的非功能需求包括( ABCD )等。A 適用性B 有效性C 可靠性D 性能29. 對于整個軟件的本地化過程來說,需要解決的技術(shù)問題主要有( AC )。A 數(shù)據(jù)格式B 頁面顯示和布局C 配置和
7、兼容性問題D 翻譯問題30. 測試團(tuán)隊(duì)的基本責(zé)任應(yīng)該是(ABCD )。A 發(fā)現(xiàn)軟件程序、系統(tǒng)或產(chǎn)品中的所有問題B 盡早地發(fā)現(xiàn)問題C 督促開發(fā)人員盡快地解決程序中的缺陷D 幫助團(tuán)隊(duì)解決資金問題31. 軟件缺陷是由很多方面造成的,以下哪個方面是造成軟件缺陷的最多的地方( A )a) 規(guī)格說明書b) 系統(tǒng)設(shè)計(jì)結(jié)果c) 編寫代碼d) 其他32. 單元測試所使用的主要測試方法是( H )E. 黑盒測試F. 靜態(tài)測試G. 動態(tài)測試H. 白盒測試33. 系統(tǒng)集成測試常見的有哪幾種不同模式( EF )。E 非漸增式測試模式F 漸增式測試模式G 獨(dú)立測試模式H 非獨(dú)立測試模式34. 對于一些關(guān)鍵代碼或新人寫的代
8、碼,主要采?。?B )方式。A. 走查B. 會議審查C. 代碼互評D. 自查35. 在集成測試中,主要的集成方法有( )。I 自頂向下J 自底向上K 大棒L 三明治36. 造成軟件的主要原因可從( ABC )方面來查找。A 技術(shù)問題B 軟件本身C 團(tuán)隊(duì)工作D 資金問題37. 代碼評審有哪些方法( EFGH )。E 代碼走查F 正式會議審查G 代碼會審H 代碼咨詢38. 驅(qū)動程序,用以模擬被測模塊的(A )模塊。A 上級模塊B 下級模塊C 同級模塊D 其他39. 整體測試用例的質(zhì)量要求包括(ABCD )。A 覆蓋率B 易用性C 易維護(hù)性D 粒度適中40. 易用性、兼容性、安裝、文檔測試等主要在(
9、 A )階段完成。 A 單元測試B 集成測試C 功能測試D 驗(yàn)收測試41. 實(shí)際的邏輯覆蓋測試中,一般以( C )為主設(shè)計(jì)測試用例。A. 條件覆蓋B. 判定覆蓋C. 條件組合覆蓋D. 路徑覆蓋42. 軟件的缺陷通常集中在( AB )階段。A. 需求分析B. 系統(tǒng)設(shè)計(jì)C. 編寫代碼D. 軟件測試43. 對于一些關(guān)鍵代碼或新人寫的代碼,主要采?。?B )方式。A. 走查B. 會議審查C. 代碼互評D. 自查44. 軟件本地化工作中除了翻譯之外還應(yīng)該( BD )。A 處理字符集問題B 數(shù)據(jù)格式C 頁面顯示和布局D 配置和兼容性等問題45. 代碼評審有哪些方法( ABCD )。A 代碼走查B 正式會議
10、審查C 代碼會審D 代碼咨詢46. 易用性、兼容性、安裝、文檔測試等主要在( A )階段完成。 A 單元測試B 集成測試C 功能測試D 驗(yàn)收測試47. 系統(tǒng)集成測試常見的有哪幾種不同模式( IJ )。I 非漸增式測試模式J 漸增式測試模式K 獨(dú)立測試模式L 非獨(dú)立測試模式48. 驗(yàn)收測試完成后還需要提交( EG ),才可交付用戶使用。E 驗(yàn)收報告F 項(xiàng)目完成報告G 交付報告H 無需提供任何報告49. 系統(tǒng)集成測試常見的有哪幾種不同模式( AB )。A 非漸增式測試模式B 漸增式測試模式C 獨(dú)立測試模式D 非獨(dú)立測試模式50. 單元測試的主要任務(wù)是完成單元中所有( ABCD )等測試。A. 獨(dú)立
11、路徑B. 數(shù)據(jù)結(jié)構(gòu)C. 邊界條件D. 容錯性 二、判斷題 1. 測試應(yīng)該盡可能早地進(jìn)行測試。( Y )2. 應(yīng)該在代碼編寫完成后開始測試。( X )3. 需求分析和設(shè)計(jì)階段不需要測試人員參與。( X )4. 白盒測試僅與程序的內(nèi)部結(jié)構(gòu)有關(guān),完全可以不考慮程序的功能需求。( X )5. 黑盒測試容易知道用戶會用到那些功能,會遇到哪些問題( Y )6. 靜態(tài)測試通過對執(zhí)行程序,找到程序中的錯誤或者是可疑之處。( X )7. 在軟件的開發(fā)中,每次回歸測試都要重新運(yùn)行完整的測試包。( )8. 在對軟件缺陷的描述中,測試人員可以對有個人的觀點(diǎn),也可以對開發(fā)人員進(jìn)行評價,有利于開發(fā)人員提高開發(fā)質(zhì)量。( X
12、 )9. 驗(yàn)收測試是由用戶完成的。( X )10. 集成測試就是系統(tǒng)測試。( X )11. 能夠盡可能早的有的時候因?yàn)闀r間緊迫,可以臨時安排幾個程序員或者行業(yè)新手做測試工作。( X )12. 在實(shí)際的運(yùn)用中,無論對于白盒測試和黑盒測試,通常使用其中一種方法就可以完成對某一軟件的測試工作。( X )13. 發(fā)現(xiàn)軟件缺陷,就能夠盡可能地節(jié)約修復(fù)缺陷的成本,因此,因此在軟件的設(shè)計(jì)階段修復(fù)缺陷的費(fèi)用最低。( X )14. 每一種測試方法都必須執(zhí)行程序,才能得到最好的效果。( X )15. 在整個軟件團(tuán)隊(duì)中,對軟件測試人員的要求比較低,會操作計(jì)算機(jī)、有一定的軟件使用經(jīng)驗(yàn)就可以。( X )16. 在對軟件
13、缺陷的描述中,測試人員可以對有個人的觀點(diǎn),也可以對開發(fā)人員進(jìn)行評價,有利于開發(fā)人員提高開發(fā)質(zhì)量。( X )17. 驗(yàn)收測試是由用戶完成的。(X )18. 在一個規(guī)范的軟件的開發(fā)中,開發(fā)人員的人數(shù)一般大于測試人員的人數(shù)。( X )19. 在整個開發(fā)周期中要對測試用例進(jìn)行有效的跟蹤和維護(hù)。( Y )20. 功能測試也可以采用白盒測試的方法。( X )21. 根據(jù)著名的瀑布模型,軟件測試應(yīng)該處在“編程”的下游、在“軟件維護(hù)”的上游,先有編程,后有測試,測試的位置很清楚。( Y )22. 因?yàn)檐浖_發(fā)人員不止一人,因此在測試時候,只能進(jìn)行松散地實(shí)施測試。( X )23. 單元測試的主要人員構(gòu)成是開發(fā)人
14、員。( Y )24. 在進(jìn)行系統(tǒng)測試的時候,當(dāng)發(fā)現(xiàn)有錯誤時候,應(yīng)該及時修正,緊接著修正下一個錯誤。( Y )25. 有的時候因?yàn)闀r間緊迫,可以臨時安排幾個程序員或者行業(yè)新手做測試工作。( X )26. 軟件質(zhì)量的要求是要滿足軟件的功能性需求。( X )27. 在整個軟件團(tuán)隊(duì)中,對軟件測試人員的要求比較低,會操作計(jì)算機(jī)、有一定的軟件使用經(jīng)驗(yàn)就可以。( X )28. 在整個軟件生命周期中的每個階段、每個時刻都存在著軟件測試活動,軟件測試伴隨著軟件開發(fā)。( Y )29. 在整個開發(fā)周期中要對測試用例進(jìn)行有效的跟蹤和維護(hù)。( Y )30. 功能測試也可以采用白盒測試的方法。(X )31. 能夠盡可能早
15、的有的時候因?yàn)闀r間緊迫,可以臨時安排幾個程序員或者行業(yè)新手做測試工作。( X )32. 在實(shí)際的運(yùn)用中,無論對于白盒測試和黑盒測試,通常使用其中一種方法就可以完成對某一軟件的測試工作。( X )33. 發(fā)現(xiàn)軟件缺陷,就能夠盡可能地節(jié)約修復(fù)缺陷的成本,因此,因此在軟件的設(shè)計(jì)階段修復(fù)缺陷的費(fèi)用最低。( X )34. 每一種測試方法都必須執(zhí)行程序,才能得到最好的效果。( X )35. 在整個軟件團(tuán)隊(duì)中,對軟件測試人員的要求比較低,會操作計(jì)算機(jī)、有一定的軟件使用經(jīng)驗(yàn)就可以。( X )36. 在對軟件缺陷的描述中,測試人員可以對有個人的觀點(diǎn),也可以對開發(fā)人員進(jìn)行評價,有利于開發(fā)人員提高開發(fā)質(zhì)量。( X
16、)37. 驗(yàn)收測試是由用戶完成的。( X )38. 在一個規(guī)范的軟件的開發(fā)中,開發(fā)人員的人數(shù)一般大于測試人員的人數(shù)。( X )39. 在整個開發(fā)周期中要對測試用例進(jìn)行有效的跟蹤和維護(hù)。( Y )40. 功能測試也可以采用白盒測試的方法。( X )41. 測試應(yīng)該盡可能早地進(jìn)行測試。( Y )42. 若能推遲暴露軟件中的錯誤,則修復(fù)和改正錯誤所花費(fèi)的代價就會降低。( X )43. 白盒測試僅與程序的內(nèi)部結(jié)構(gòu)有關(guān),完全可以不考慮程序的功能需求。( X )44. 黑盒測試容易知道用戶會用到那些功能,會遇到哪些問題( Y )45. 黑盒測試基于軟件開發(fā)文檔,所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能( Y
17、 )46. 邏輯覆蓋法是一種常用的白盒測試方法。( Y )47. 程序中存在很多判定和條件,不可能實(shí)現(xiàn)100%的條件覆蓋。( Y )48. 靜態(tài)測試通過對執(zhí)行程序,找到程序中的錯誤或者是可疑之處。( X )49. 在整個開發(fā)周期中要對測試用例進(jìn)行有效的跟蹤和維護(hù)。( Y )50. 在進(jìn)行系統(tǒng)測試的時候,當(dāng)發(fā)現(xiàn)有錯誤時候,應(yīng)該及時修正,緊接著修正下一個錯誤。( Y )三、簡答題1. 健壯等價類測試與標(biāo)準(zhǔn)等價類測試的主要區(qū)別是什么?解:主要區(qū)別在于健壯等價類測試在標(biāo)準(zhǔn)等價類的基礎(chǔ)上還要進(jìn)行有效取值范圍之外的輸入(無效輸入)的測試。2. 單元測試有哪些步驟?各個步驟有哪些實(shí)施內(nèi)容?單元測試的步驟通常
18、單元測試在編碼階段進(jìn)行。在源程序代碼編制完成,經(jīng)過評審和驗(yàn)證,確認(rèn)沒有語法錯誤之后,就開始進(jìn)行單元測試的測試用例設(shè)計(jì)。利用設(shè)計(jì)文檔,設(shè)計(jì)可以驗(yàn)證程序功能、找出程序錯誤的多個測試用例。對于每一組輸入,應(yīng)有預(yù)期的正確結(jié)果。模塊并不是一個獨(dú)立的程序,在考慮測試模塊時,同時要考慮它和外界的聯(lián)系,用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。這些輔助模塊分為兩種:驅(qū)動模塊:相當(dāng)于被測模塊的主程序。它接收測試數(shù)據(jù),把這些數(shù)據(jù)傳送給被測模塊,最后輸出實(shí)測結(jié)果。樁模塊:用以代替被測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作,不需要把子模塊所有功能都帶進(jìn)來,但不允許什么事情也不做。如果一個模塊要完成多種功能
19、,且以程序包或?qū)ο箢惖男问匠霈F(xiàn),例如Ada中的包,Modula中的模塊,C+中的類。這時可以將這個模塊看成由幾個小程序組成。對其中的每個小程序先進(jìn)行單元測試要做的工作,對關(guān)鍵模塊還要做性能測試。對支持某些標(biāo)準(zhǔn)規(guī)程的程序,更要著手進(jìn)行互聯(lián)測試。有人把這種情況特別稱為模塊測試,以區(qū)別單元測試。單元測試的內(nèi)容模塊接口測試:對通過被測模塊的數(shù)據(jù)流進(jìn)行測試。為此,對模塊接口,包括參數(shù)表、調(diào)用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入/輸出操作都必須檢查。局部數(shù)據(jù)結(jié)構(gòu)測試:設(shè)計(jì)測試用例檢查數(shù)據(jù)類型說明、初始化、缺省值等方面的問題,還要查清全程數(shù)據(jù)對模塊的影響。路徑測試:選擇適當(dāng)?shù)臏y試用例,對模塊中重要的執(zhí)行路徑進(jìn)行
20、測試。對基本執(zhí)行路徑和循環(huán)進(jìn)行測試可以發(fā)現(xiàn)大量路徑錯誤。錯誤處理測試:檢查模塊的錯誤處理功能是否包含有錯誤或缺陷。例如,是否拒絕不合理的輸入;出錯的描述是否難以理解、是否對錯誤定位有誤、是否出錯原因報告有誤、是否對錯誤條件的處理不正確;在對錯誤處理之前錯誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等。邊界測試:要特別注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細(xì)地選擇測試用例,認(rèn)真加以測試。此外,如果對模塊運(yùn)行時間有要求的話,還要專門進(jìn)行關(guān)鍵路徑測試,以確定最壞情況下和平均意義下影響模塊運(yùn)行時間的因素。這類信息對進(jìn)行性能評價是十分有用的。3. 單元測試的策略主要有哪些,并
21、簡述這些策略。單元測試策略主要有三種方式: 1.自頂向下的單元測試策略:從頂層調(diào)用的單元做成樁模塊;對第二層測試,使用上面已測試的單元做驅(qū)動模塊;依次類推,直到全部單元測試結(jié)束。 2.自底向上的單元測試策略:先對模塊調(diào)用的最底層模塊進(jìn)行測試,模擬調(diào)用該模塊的模塊為驅(qū)動模塊;其次,對上一層模塊進(jìn)行單元測試,用已經(jīng)被測試過的模塊做樁模塊,依次類推,直到全部單元測試結(jié)束。 3.孤立測試的單元測試策略:無需考慮每個模塊與其他模塊之間的關(guān)系,分別為每個模塊單獨(dú)設(shè)計(jì)樁模塊和驅(qū)動模塊,逐一完成所有單元模塊的測試。4. 集成測試有哪些不同的集成方法?簡述不同方法的特點(diǎn)。解:集成測
22、試通常有一次性集成、自頂向下集成、自底向上集成和混合集成4種集成方法。 一次性集成方法需要的測試用例數(shù)目少,測試方法簡單、易行。但是由于不可避免存在模塊間接口、全局?jǐn)?shù)據(jù)結(jié)構(gòu)等方面的問題,所以一次運(yùn)行成功的可能性不大;如果一次集成的模塊數(shù)量多,集成測試后可能會出現(xiàn)大量的錯誤,給程序的錯誤定位與修改帶來很大的麻煩;即使集成測試通過,也會遺漏很多錯誤進(jìn)入系統(tǒng)測試。 自頂向下集成在測試的過程中,可以較早地驗(yàn)證主要的控制和判斷點(diǎn);一般不需要驅(qū)動程序,減少了測試驅(qū)動程序開發(fā)和維護(hù)的費(fèi)用;可以和開發(fā)設(shè)計(jì)工作一起并行執(zhí)行集成測試,能夠靈活的適應(yīng)目標(biāo)環(huán)境;容易進(jìn)行故障隔離和錯誤定位。但是在測
23、試時需要為每個模塊的下層模塊提供樁模塊,樁模塊的開發(fā)和維護(hù)費(fèi)用大;樁模塊不能反映真實(shí)情況,重要數(shù)據(jù)不能及時回送到上層模塊,導(dǎo)致測試不充分;涉及復(fù)雜算法和真正I/O的底層模塊最易出問題,在后期才遇到導(dǎo)致過多的回歸測試。 自底向上集成可以盡早的驗(yàn)證底層模塊的行為;提高了測試效率;一般不需要樁模塊;容易對錯誤進(jìn)行定位。但是直到最后一個模塊加進(jìn)去之后才能看到整個系統(tǒng)的框架;驅(qū)動模塊的設(shè)計(jì)工作量大;不能及時發(fā)現(xiàn)高層模塊設(shè)計(jì)上的錯誤。 混合集成具有自頂向下和自底向上兩種集成策略的優(yōu)點(diǎn),但是在被集成之前,中間層不能盡早得到充分的測試。5. 簡述基于功能分解的集成的特點(diǎn),并分析其適用的應(yīng)用
24、場景。6. 系統(tǒng)測試主要包括哪些內(nèi)容?解:系統(tǒng)測試主要包括強(qiáng)度測試、性能測試、恢復(fù)測試、安全測試、可靠性測試、安裝測試、容量測試和文檔測試。7. 針對某論壇,考慮其重要測試的內(nèi)容。8. 簡述黑盒測試方法的特點(diǎn)黑盒測試用例設(shè)計(jì)方法主要有以下幾種:等價類劃分法、邊界值分析法、因果圖法、決策表法、錯誤推測法等方法。等價類劃分法的特點(diǎn):等價類劃分法的優(yōu)點(diǎn)是考慮了單個輸入域的各類情況,避免了盲目或隨機(jī)選取輸入數(shù)據(jù)的布完整性和覆蓋的不穩(wěn)定性。 等價類劃分法雖然簡單易用,但是沒有對組合情況進(jìn)行充分的考慮。需要結(jié)合其他測試用例設(shè)計(jì)的方法進(jìn)行補(bǔ)充。邊界值分析法的特點(diǎn):1)邊界值分析不是從某等價類中隨便
25、挑一個作為代表,而是使這個等價類的每個邊界都要作為測試條件。 2)邊界值分析不僅考慮輸入條件,還要考慮輸出空間產(chǎn)生的測試情況。因果圖法的特點(diǎn):1、考慮輸入條件間的組合關(guān)系。2、考慮輸出條件對輸入條件的信賴關(guān)系,即因果關(guān)系。3、測試用例發(fā)現(xiàn)錯誤的效率高。4、能檢查出功能說明書中的某些不一致或遺漏。決策表法的特點(diǎn):在一個程序中,如果輸入輸出比較多,輸入之間,輸出之間相互制約的條件比較多,在這種情況下使用決策表更合適,它可以清楚地表達(dá)它們之間的各種復(fù)雜關(guān)系。錯誤推測法的特點(diǎn):沒有確定的步驟,很大程度上是憑經(jīng)驗(yàn)進(jìn)行的。9. 健壯等價類測試與標(biāo)準(zhǔn)等價類測試的主要區(qū)別是什么?主要區(qū)
26、別在于健壯等價類測試在標(biāo)準(zhǔn)等價類的基礎(chǔ)上還要進(jìn)行有效取值范圍之外的輸入(無效輸入)的測試。10. 簡述單元測試的目的和意義。目的:是暴漏出失敗和錯誤。失敗的可能性是可預(yù)期的,并且可以使用斷言來進(jìn)行檢查。而錯誤則是不可預(yù)期的問題意義:(1)提前發(fā)現(xiàn)問題并解決可以節(jié)約時間(2)是測試階段的基礎(chǔ),為后期的集成測試和系統(tǒng)測試做好準(zhǔn)備;(3)對單元獨(dú)立測試,容易發(fā)現(xiàn)問題,減少成本。11. 單元測試的策略主要有哪些,并簡述這些策略。12. 簡述基于調(diào)用圖的集成的特點(diǎn),并分析其適用的應(yīng)用場景。13. 什么是系統(tǒng)測試?系統(tǒng)測試是指測試整個系統(tǒng)已確定其是否能夠提供應(yīng)用的所有需求行為,包含了多種測試活動,主要分為
27、功能性測試和非功能測試。14. 針對某殺毒軟件(如360殺毒),考慮其需要測試的內(nèi)容。主要是采用黑盒測試的方法,包括程序各功能性測試、界面友好性測試、時效性測試、安裝/卸載測試、用戶說明書測試、與其他軟件的兼容性、與特定硬件的兼容性、可靠性(如長時間運(yùn)行,休眠/喚醒等)、合法性(版權(quán)標(biāo)示驗(yàn)證)等。15. 什么是軟件測試計(jì)劃?是指導(dǎo)測試過程的綱領(lǐng)性文件,包含產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流和風(fēng)險分析等內(nèi)容。16. 制定軟件測試的計(jì)劃的原則有?(1)制定測試計(jì)劃應(yīng)盡早開始;(2)保持測試計(jì)劃的靈活性;(3)保持測試計(jì)劃簡潔和易讀;(4)盡量爭取多渠道評
28、審測試計(jì)劃;(5)計(jì)算測試計(jì)劃的投入。17. 單元測試的原則有哪些?(1)單元測試越早進(jìn)行越好;(2)單元測試應(yīng)該根據(jù)軟件詳細(xì)設(shè)計(jì)規(guī)格說明進(jìn)行;(3)對于修改過的代碼應(yīng)該重做單元測試,以保證對已發(fā)現(xiàn)錯誤的修改沒有引入新的錯誤;(4)當(dāng)測試用例的測試結(jié)果與設(shè)計(jì)規(guī)格說明書的預(yù)期結(jié)果不一致時,測試人員應(yīng)該如實(shí)記錄實(shí)際的測試結(jié)果;(5)單元測試應(yīng)注意選擇好被測試軟件單元的大?。唬?)一個完整的單元測試說明應(yīng)該包含軟件證明測試和負(fù)面測試;(7)注意使用單元測試工具。18. 單元測試的重要性及目的是什么?19. 系統(tǒng)測試與用戶測試有何不同?系統(tǒng)測試是測試整個系統(tǒng)已確定其是否能夠提供應(yīng)用的所有需求行為;用戶
29、測試分為體驗(yàn)、界面、驗(yàn)收、用戶測試報告組成 20. 制定軟件測試的計(jì)劃的步驟有?(1)產(chǎn)品基本情況調(diào)研;(2)測試需求說明;(3)測試的策略和記錄;(4)測試資源配置;(5)計(jì)劃表;(6)問題跟蹤報告;(7)測試計(jì)劃的評審21. 什么是靜態(tài)測試、動態(tài)測試?靜態(tài)測試:是一種不通過執(zhí)行程序而進(jìn)行測試的技術(shù),只是檢測和評審。動態(tài)測試:直接執(zhí)行被測試程序以提供測試支持。22. 簡述單元測試的過程.(1)準(zhǔn)備階段;(2)編制階段(3)代碼審查階段;(4)單元測試階段;(5)評審、提交階段。23. 什么是插樁程序設(shè)計(jì)?是在保證被測程序原有邏輯完整性的基礎(chǔ)上在程序中插于一些探針,通過探針的執(zhí)行拋出
30、程序運(yùn)行的特征數(shù)據(jù),通過這些數(shù)據(jù)的分析,可以獲得程序的控制流和數(shù)據(jù)信息,進(jìn)而得到邏輯覆蓋等動態(tài)信息,從而實(shí)現(xiàn)測試目標(biāo)的方法。 24. 簡述系統(tǒng)測試的主要內(nèi)容?(1)功能測試。即測試軟件系統(tǒng)的功能是否正確,其依據(jù)是需求文檔,如產(chǎn)品需求規(guī)格說明書。(2)健壯性測試。即測試軟件系統(tǒng)在異常情況下能否正常運(yùn)行的能力。健壯性有兩層含義:一是容錯能力,二是恢復(fù)能力 25. 容量測試與壓力測試的區(qū)別有哪些?(1)壓力測試是在給系統(tǒng)不斷加壓,增加并發(fā)量,直到崩潰,找到系統(tǒng)所能承受的極限值。(2)容量測試是在預(yù)先分析的極限值下,系統(tǒng)能否正常運(yùn)行。26. 如何組織軟件測試團(tuán)隊(duì)(1)建立合理、高效
31、的組織結(jié)構(gòu)(2)建立正確的分工體系,即角色與職責(zé);(3)培養(yǎng)合格的測試人員。27. 什么是軟件測試計(jì)劃?是指導(dǎo)測試過程的綱領(lǐng)性文件,包含產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流和風(fēng)險分析等內(nèi)容。28. 制定軟件測試的計(jì)劃的原則有?(1)制定測試計(jì)劃應(yīng)盡早開始;(2)保持測試計(jì)劃的靈活性;(3)保持測試計(jì)劃簡潔和易讀;(4)盡量爭取多渠道評審測試計(jì)劃;(5)計(jì)算測試計(jì)劃的投入。29. 單元測試的原則有哪些?(1)單元測試越早進(jìn)行越好;(2)單元測試應(yīng)該根據(jù)軟件詳細(xì)設(shè)計(jì)規(guī)格說明進(jìn)行;(3)對于修改過的代碼應(yīng)該重做單元測試,以保證對已發(fā)現(xiàn)錯誤的修改沒有引入新的錯
32、誤;(4)當(dāng)測試用例的測試結(jié)果與設(shè)計(jì)規(guī)格說明書的預(yù)期結(jié)果不一致時,測試人員應(yīng)該如實(shí)記錄實(shí)際的測試結(jié)果;(5)單元測試應(yīng)注意選擇好被測試軟件單元的大??;(6)一個完整的單元測試說明應(yīng)該包含軟件證明測試和負(fù)面測試;(7)注意使用單元測試工具。30. 單元測試的重要性及目的是什么?重要性:1、提前發(fā)現(xiàn)問題并解決可以節(jié)約時間2、是測試階段的基礎(chǔ),為后期的集成測試和系統(tǒng)測試做好準(zhǔn)備;3、對單元獨(dú)立測試,容易發(fā)現(xiàn)問題,減少成本。目的:是暴漏出失敗和錯誤。失敗的可能性是可預(yù)期的,并且可以使用斷言來進(jìn)行檢查。而錯誤則是不可預(yù)期的問題31. 測試和測試有什么不同?a 測試是在公司內(nèi)部由用戶組織與的測試
33、;a 測試對發(fā)現(xiàn)缺陷是可控的,但缺陷是人數(shù)有限、地域限制。b測試是在外部有用戶進(jìn)行的測試;b測試不會認(rèn)真地去發(fā)現(xiàn)缺陷,有時僅僅是為了搶占市場。 四、綜合應(yīng)用題1. 白盒測試方法的綜合應(yīng)用(1) 簡述白盒測試用例的設(shè)計(jì)方法。解:白盒測試用例設(shè)計(jì)方法主要有邏輯覆蓋和獨(dú)立路徑測試。 從覆蓋源程序語句的詳盡程度分析,邏輯覆蓋主要有以下不同的覆蓋標(biāo)準(zhǔn):語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。實(shí)際項(xiàng)目中,由于程序內(nèi)部的邏輯存在不確定性和無窮性,尤其對于大規(guī)模復(fù)雜軟件,不必采用所有的覆蓋指標(biāo),而應(yīng)根據(jù)實(shí)際情況選擇合適的覆蓋指標(biāo)。 獨(dú)立路徑測試是在程
34、序控制流圖的基礎(chǔ)上,通過分析控制結(jié)構(gòu)的環(huán)路復(fù)雜性,導(dǎo)出可執(zhí)行的獨(dú)立路徑集合,從而設(shè)計(jì)出相應(yīng)的測試用例。設(shè)計(jì)出的測試用例要保證被測程序的每條可執(zhí)行的獨(dú)立路徑至少被執(zhí)行一次。獨(dú)立路徑測試給出了滿足路徑覆蓋指標(biāo)所需測試用例的下限,同時給出了語句覆蓋的上限,它可以確保對所有相互獨(dú)立的決策結(jié)果進(jìn)行測試。(2) 分析歸納邏輯覆蓋的各種策略,并比較每種覆蓋的特點(diǎn),分析在怎樣的情況下采用何種覆蓋方式。解:語句覆蓋是選擇足夠多的測試數(shù)據(jù),使被測程序中每個語句至少執(zhí)行一次。語句覆蓋是最弱的邏輯覆蓋標(biāo)準(zhǔn)。 判定覆蓋又叫分支覆蓋,它不僅每個語句必須至少執(zhí)行一次,而且每個判定表達(dá)式的每種可能的結(jié)果都應(yīng)該至少執(zhí)
35、行一次。判定條件覆蓋比語句覆蓋強(qiáng),但是對程序邏輯的覆蓋程度仍然不高。 條件覆蓋的含義是,使判定表達(dá)式中的每個條件都取到各種可能的結(jié)果。條件覆蓋通常比判定覆蓋強(qiáng),但是也可能有相反的情況:雖然每個條件都取到了兩個不同的結(jié)果,判定表達(dá)式卻始終只取一個值。 判定/條件覆蓋的含義是,選取足夠多的測試數(shù)據(jù),使得判定表達(dá)式中的每個條件都取到各種可能的值,而且每個判定表達(dá)式也都取到各種可能的結(jié)果。但有時判定/條件覆蓋也并不比條件覆蓋更強(qiáng)。 條件組合覆蓋是更強(qiáng)的邏輯覆蓋標(biāo)準(zhǔn),它要求選取足夠的測試數(shù)據(jù),使得每個判定表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次。滿足條件組合覆蓋標(biāo)準(zhǔn)的測試數(shù)
36、據(jù),也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋標(biāo)準(zhǔn)。因此,條件組合覆蓋是前述幾種覆蓋標(biāo)準(zhǔn)中最強(qiáng)的。但是,滿足條件組合覆蓋標(biāo)準(zhǔn)的測試數(shù)據(jù)并不一定能使程序中的每一條路徑都執(zhí)行到。 路徑覆蓋的定義是選取足夠多測試數(shù)據(jù),使程序的每一條可能路徑都至少執(zhí)行一次。但在實(shí)際問題中,一個不太復(fù)雜的程序,其路徑數(shù)都可能是一個龐大的數(shù)字,以致要在測試中覆蓋所有的路徑是不可能實(shí)現(xiàn)的。即使對于路徑數(shù)有限的程序做到了路徑覆蓋,也不能保證被測程序的正確性。(3)請按照各種覆蓋方法為下述語句設(shè)計(jì)測試用例,并寫出測試過程if(a>1) and (b=0) thenx=x/aif(a=2) or (x>1
37、) thenx=x+1語句覆蓋:CASE 1:a=2,b=0,x=3。則程序按路徑ace執(zhí)行,這樣該程序段的4個語句均得到執(zhí)行,從而達(dá)到了語句覆蓋。斷定覆蓋:CASE2:a=2,b=0,x=3。CASE3:a=1,b=0,x=1。則可分別執(zhí)行路徑ace和abd。從而使兩個判斷的4個分支c、e和b、d分別得到覆蓋。條件覆蓋:在上述程序段中,第一個判斷應(yīng)考慮到:a>1取真值,記為Ta1;a>1取價值,即a<=1時,記為Ta2;b=0取真值,記為Tb1;b=0取假值,即b!=0時,記為Tb2;第二個判斷應(yīng)考慮到:a=2取真值,記為Ta3;a=2取假值,即a!=2,記為Ta4;x&g
38、t;1取真值,記為Tx1;x>1取假值,即x<=1,記為Tx2;條件覆蓋測試用例測試用例abx路徑覆蓋條件CASE4203aceTa1,Tb1,Ta3,Tx1CASE5111abdTa2,Tb2,Ta4,Tx2以上兩個測試用例把4個條件的8種情況均做了覆蓋。判斷-條件覆蓋:語句中兩個判斷各包含兩個條件,這四個條件在兩個判斷中可能有八種組合:1號、a>1,b=0記為Ta,Tb;2號、a>1,b!=0記為Ta,F(xiàn)b;3號、a<=1,b=0記為Fa,Tb;4號、a<=1,b!=0 記為Fa,F(xiàn)b;5號、a=2,x>1記為Ya,Yx;6號、a=2,x<=
39、1記為Ya,Nx;7號、a!=2,x>1記為Na,Yx;8號、a!=2,x<=1記為Na,Nx;判定-條件覆蓋測試用例abx覆蓋組合號路徑覆蓋條件CASE62031號,5號aceTa,Tb,Ya,YxCASE72112號,6號abeTa,F(xiàn)b,Ya,NxCASE81033號,7號abeFa,Tb,Na,YxCASE91114號,8號abdFa,F(xiàn)b,Na,Nx路徑覆蓋:根據(jù)題目語句有4條可能路徑ace記為L1;abd記為L2;abe記為L3;acd記為L4;路徑覆蓋測試用例abx覆蓋路徑CASE10203aceCASE11101abdCASE12211abeCASE13301acd
40、2. 黑盒測試方法的綜合應(yīng)用3. 案例:某保險公司的人壽保險的保費(fèi)計(jì)算方式為:保費(fèi)=投保額×保險費(fèi)率其中保險費(fèi)率依點(diǎn)數(shù)不同而有別,10點(diǎn)幾10點(diǎn)以上保費(fèi)率為0.6%,10點(diǎn)一下保險費(fèi)率為0.1%;而點(diǎn)數(shù)又是投保人的年齡,性別,混應(yīng)狀況和撫養(yǎng)人數(shù)來決定,具體規(guī)則如下表所示。年齡性別婚姻撫養(yǎng)人數(shù)20-3940-59其他MF已婚未婚1人扣0.5點(diǎn),最多扣3點(diǎn)(四舍五入取整)6點(diǎn)4點(diǎn)2點(diǎn)5點(diǎn)3點(diǎn)3點(diǎn)5點(diǎn)年齡:一位或者兩位非零整數(shù),值得有效范圍是1-99性別:一位應(yīng)為字符,只能去M或者F婚姻:字符,只能取已婚或者未婚撫養(yǎng)人數(shù):空白或一位非零整數(shù)(1-9)點(diǎn)數(shù):一位或兩位非零整數(shù),值得范圍是1-
41、99要求:根據(jù)以上的案例描述,設(shè)計(jì)出能否改所有等價類的測試用例。并寫出測試過程。4. 白盒測試方法的綜合應(yīng)用示例源碼Dim a,b as IntegerDim c as DoubleIf(a>0 and b>0) Thenc = c/aEnd ifIf(a>1 OR c >1) Thenc = c +1End ifc = b+c 要求:根據(jù)以上的示例源碼,采用兩種以上的白盒測試方法進(jìn)行測試,要求寫出詳細(xì)的測試用例及測試過程,并比較你所采用的測試方法的優(yōu)點(diǎn)和缺點(diǎn)。5. 黑盒測試方法的綜合應(yīng)用以“打印機(jī)打印文件”為例,用黑盒測試中的判定表法來對其進(jìn)行測試。要求:寫出詳細(xì)的要求寫出詳細(xì)的測試步驟,測試用例以及詳細(xì)的測試過程。1、 列出所有的條件樁和動作樁條件樁:C1:有驅(qū)動程序嗎?C2:有紙張嗎?C3:有墨粉嗎?動作樁:A1:安裝驅(qū)動程序A2:加入紙張A3:加入墨粉A4:打印紙張2、 確定規(guī)則個數(shù)輸入條件個數(shù):3每個條件的取值:”是“或”否“規(guī)則個數(shù):2*2*2=83、 填入條件項(xiàng)和動作項(xiàng)12345678條件C1YYYYNNNNC2YYNNYYNNC3
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 軍品訂購項(xiàng)目管理辦法
- 北京車位產(chǎn)權(quán)管理辦法
- 資本驅(qū)動下人工智能產(chǎn)業(yè)化的倫理挑戰(zhàn)與應(yīng)對策略
- 睡眠剝奪對小鼠色氨酸代謝及行為影響機(jī)制研究
- 體檢機(jī)構(gòu)備案管理辦法
- 佛山酒店宿舍管理辦法
- 西部地區(qū)經(jīng)濟(jì)韌性對經(jīng)濟(jì)高質(zhì)量發(fā)展的影響研究
- 基于機(jī)器視覺的鋼板表面缺陷自動檢測系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
- 未發(fā)生較大及以上生產(chǎn)安全事故
- 智慧醫(yī)院建設(shè)管理辦法
- 低壓培訓(xùn)課件
- 教師團(tuán)隊(duì)協(xié)作與溝通能力
- 保安公司薪酬管理制度
- 井蓋巡查管理制度
- GB/T 33490-2025展覽展示工程服務(wù)基本要求
- 2024年國能榆林化工有限公司招聘真題
- 消防總隊(duì)面試題目及答案
- 《低鈉血癥中國專家共識(2023年版)》解讀課件
- GB/T 45604-2025船舶與海洋技術(shù)大抓力平衡錨
- 國家中小學(xué)智慧教育平臺與人工智能融合應(yīng)用指南(試行)
- 混凝土攪拌站企業(yè)管理規(guī)范與要求
評論
0/150
提交評論