劉-《軟件測(cè)試技術(shù)》復(fù)習(xí)題

一、 概念判斷發(fā)現(xiàn)錯(cuò)誤多的模塊，殘留在模塊中的錯(cuò)誤也多。思想：某處發(fā)現(xiàn)了缺陷，則可能會(huì)隱藏更多的缺陷。目前在進(jìn)行集成測(cè)試時(shí)普遍采用非漸增式測(cè)試方法。（×）非漸增式測(cè)試容易出現(xiàn)混亂，為每個(gè)錯(cuò)誤定位和糾正非常困難，并且在改正一個(gè)錯(cuò)誤的同時(shí)又可能引入新的錯(cuò)誤，新舊錯(cuò)誤混雜，更難斷定出錯(cuò)的原因和位置。常采用漸增式測(cè)試方法。a測(cè)試在一個(gè)或多個(gè)客戶場(chǎng)所進(jìn)行a測(cè)試由用戶在開發(fā)者的場(chǎng)所進(jìn)行。（×）Alpha測(cè)試、Beta測(cè)試，Alpha測(cè)試在開發(fā)者的場(chǎng)所進(jìn)行，Beta測(cè)試在一個(gè)或多個(gè)客戶場(chǎng)所進(jìn)行。說(shuō)反了態(tài)測(cè)試。（√）在單元測(cè)試或集成測(cè)試中主要采用白盒測(cè)試方法，包括對(duì)代碼的評(píng)審、靜態(tài)分析和結(jié)合測(cè)試工具進(jìn)行動(dòng)態(tài)測(cè)試。.（×）成功的測(cè)試是沒(méi)有發(fā)現(xiàn)錯(cuò)誤的測(cè)試（×）一個(gè)成功的測(cè)試是發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。畢竟測(cè)試的目的之一是盡可能多的發(fā)現(xiàn)軟件中的錯(cuò)誤/缺陷。確認(rèn)測(cè)試也稱為驗(yàn)收測(cè)試，它的目的是驗(yàn)證軟件的有效性。（√）軟件測(cè)試是通過(guò)運(yùn)行程序來(lái)查看錯(cuò)誤。靜態(tài)測(cè)試是不運(yùn)行程序來(lái)進(jìn)行測(cè)試。類的私有方法可以測(cè)試。（√）源程序代碼的邏輯簡(jiǎn)單明晰，易讀易懂是好程序的一個(gè)重要標(biāo)準(zhǔn)。（√）邊界測(cè)試中所選擇的輸入測(cè)試數(shù)據(jù)一定是有效數(shù)據(jù)。（×）不僅要用有效數(shù)據(jù)測(cè)試軟件，還要用無(wú)效數(shù)據(jù)測(cè)試軟件的容錯(cuò)性、對(duì)錯(cuò)誤數(shù)據(jù)的處理。抽象類可以測(cè)試。（×）()法為宜.（√）結(jié)構(gòu)化程序設(shè)計(jì)是一種設(shè)計(jì)程序的技術(shù)（√）16（√）16程序流程圖本質(zhì)上不是逐步求精的好工具，它誘使程序員過(guò)早地考慮程序的控制流程，而不去考慮程序的全局結(jié)構(gòu)。（√）1817 良好的單元測(cè)試可以代替集成測(cè)試。（×）18（×）對(duì)于類的測(cè)試不能限定在子類中定義的成員變量和成員方法，還要考慮父類對(duì)子類的影響2019 等價(jià)劃分屬于白盒測(cè)試技術(shù)而控制結(jié)構(gòu)測(cè)試屬于黑盒測(cè)試。（×）20靜態(tài)分析工具可用于軟件測(cè)試中直接分析源代碼，輔助生成測(cè)試用例。（√）2122212223份分析報(bào)告。（√）良好的單元測(cè)試可以代替集成測(cè)試。（×）軟件測(cè)試的目的是盡可能多的找出軟件的缺陷。（√）Beta測(cè)試是驗(yàn)收測(cè)試的一種。（√）驗(yàn)收測(cè)試是由最終用戶來(lái)實(shí)施的。（×）項(xiàng)目立項(xiàng)前測(cè)試人員不需要提交任何工件。（√）項(xiàng)目立項(xiàng)：大概類似于項(xiàng)目建議書審批，項(xiàng)目建議書是初步選擇項(xiàng)目，其可以決定是否需要進(jìn)行下一步工作，主要考察建議的必要性和可行性。需求分析完成后，測(cè)試人員才參與進(jìn)來(lái)。單元測(cè)試能發(fā)現(xiàn)約80%的軟件缺陷。80/20原則有關(guān)代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（×）31通過(guò)軟件評(píng)審盡早地發(fā)現(xiàn)產(chǎn)品中的缺陷<通過(guò)軟件評(píng)審可以更早地發(fā)現(xiàn)需求工程、軟件設(shè)計(jì)等各個(gè)方面的問(wèn)題，減少后期返工，降低質(zhì)量成本>3132 負(fù)載測(cè)試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（×）自底向上集成需要測(cè)試員編寫驅(qū)動(dòng)程序。（√）32 負(fù)載測(cè)試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（×）33文老師：不一定非要到達(dá)極限，只要驗(yàn)證一下性能就好了負(fù)載測(cè)試不就是壓力測(cè)試嗎？33測(cè)試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過(guò)。（×）缺陷分兩種：1、完全影響軟件的正常運(yùn)行或者影響客戶的正常體驗(yàn)。這種當(dāng)然不能予以通過(guò)2、不影響產(chǎn)品運(yùn)行及客戶正常體驗(yàn)且此軟件急于使用。以公司利益為出發(fā)，應(yīng)予以通過(guò)。但在時(shí)間不緊急的情況下應(yīng)不予通過(guò)。一個(gè)好的測(cè)試人員應(yīng)該有很好的情況分析能力，并且要有擔(dān)當(dāng)。代碼評(píng)審員一般由測(cè)試員擔(dān)任。（×）代碼評(píng)審的工作，測(cè)試人員大多對(duì)代碼熟悉度和理解度不夠高，這一項(xiàng)工作更傾向代碼評(píng)審的工作，測(cè)試人員大多對(duì)代碼熟悉度和理解度不夠高，這一項(xiàng)工作更傾向于同組的其他開發(fā)人員擔(dān)任，效果更佳我們可以人為的使得軟件不存在配置問(wèn)題。（×）集成測(cè)試計(jì)劃在需求分析階段末提交。（×）參照W模型，在需求分析階段制定集成測(cè)試計(jì)劃是不可能，集成測(cè)試計(jì)劃要在概要設(shè)計(jì)階段末提交。（√）（×）軟件質(zhì)量管理即QM由QA和QC構(gòu)成，軟件測(cè)試屬于QC的核心工作內(nèi)容。我們有理由相信只要能夠設(shè)計(jì)出盡可能好的測(cè)試方案（×）（×）在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。（√）傳統(tǒng)測(cè)試是在開發(fā)的后期才介入，現(xiàn)在測(cè)試活動(dòng)已經(jīng)擴(kuò)展到了整個(gè)生命周期。（√）（√）45 個(gè)未知的條件開始，結(jié)束的過(guò)程不可預(yù)計(jì)。（×）45 個(gè)未知的條件開始，結(jié)束的過(guò)程不可預(yù)計(jì)。（×）46順序反了46白盒測(cè)試往往會(huì)造成測(cè)試用例之間可能存在嚴(yán)重的冗余和未測(cè)試的功能漏洞。（×）47 47 n7n個(gè)。（×）4n+1??軟件生存周期是從軟件開始開發(fā)到開發(fā)結(jié)束的整個(gè)時(shí)期。（×）軟件生存周期是從軟件開始開發(fā)到開發(fā)結(jié)束的整個(gè)時(shí)期。（×）軟件生命周期(SoftwareLife命周期。試方法。（√）50 50 （√）測(cè)試用例的數(shù)目越多，測(cè)試的效果越好。（×）53100％的邏輯覆蓋率，就可以保證程序的正確性。（×）535554 驗(yàn)收測(cè)試是以最終用戶為主的測(cè)試。沒(méi)有發(fā)現(xiàn)錯(cuò)誤的測(cè)試是沒(méi)有價(jià)值的。（√）55（×）移動(dòng)應(yīng)用測(cè)試面臨的一個(gè)困難是軟件運(yùn)行的硬件平臺(tái)太多。（√）眾測(cè)是解決移動(dòng)測(cè)試待測(cè)平臺(tái)太多困境的有效方法。（√）VoasPIE模型中，執(zhí)行了錯(cuò)誤語(yǔ)句程序不一定進(jìn)入錯(cuò)誤狀態(tài)（Error），并且即使進(jìn)入錯(cuò)誤狀態(tài)，程序最終也有可能不表現(xiàn)出失效（Failure），我們把這種情況稱之為偶然正確性。（√）回歸測(cè)試是用于驗(yàn)證改變了的系統(tǒng)或組件是否保持原有的特性。（√）二、 思考與辨析題1、軟件缺陷?2、黑盒測(cè)試用于檢測(cè)發(fā)現(xiàn)哪幾類錯(cuò)誤？3、正交類測(cè)試?4、靜態(tài)白盒測(cè)試？5、負(fù)載測(cè)試？6、軟件測(cè)試過(guò)程模型。7、缺陷管理的目標(biāo)？8、軟件測(cè)試的作用？11、測(cè)試用例設(shè)計(jì)的關(guān)鍵？9、Alpha測(cè)試與beta測(cè)試的區(qū)11、測(cè)試用例設(shè)計(jì)的關(guān)鍵？12、 黑盒測(cè)試用例的設(shè)計(jì)方法？13、 單元測(cè)試主要測(cè)試那幾方面的問(wèn)題？14、 移動(dòng)應(yīng)用測(cè)試存在的困難？1515、性能測(cè)試過(guò)程中測(cè)試腳本的編寫過(guò)程。16、 在線測(cè)試的原理？17、 軟件質(zhì)量的度量方法。18、 舉例說(shuō)明、Error的區(qū)別19、 灰盒測(cè)試與白盒測(cè)試及黑盒測(cè)試的區(qū)別。20、 Ad-hoc測(cè)試方法的基本原理。21、 錯(cuò)誤猜測(cè)方法的基本原理。22、 常見的組合測(cè)試技術(shù)23、 探索式測(cè)試？24、 列舉你日常使用軟件時(shí)碰到的5種性能問(wèn)題。25、 為什么要性能測(cè)試？26、 Fuzz測(cè)試？27、 SQL注入攻擊（SQL。28、 跨站