第1章軟件測試概述一、選擇題1-5BCABA6-10DDBAB11-15DBCDC二、判斷題與填空題1-8√×√√×√√×9螺旋模型10需求獲取工作流程、測試工作流程、部署工作流程11測試需求分析、測試用例設(shè)計(jì)12可靠性13可維護(hù)性、可重用性14已定義級、已管理級15軟件開發(fā)、軟件維護(hù)16測試用例的邊際效應(yīng)17故障屏蔽18測試用例19測試用例集三、簡述題1.定義：軟件測試就是在軟件開發(fā)和投入運(yùn)行前的各階段，對軟件的需求分析、設(shè)計(jì)規(guī)格說明和程序編碼等過程的隱蔽錯(cuò)誤或缺陷的最終檢查，軟件測試是保證軟件質(zhì)量的關(guān)鍵過程。軟件測試的描述性定義：定義1：軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。定義2：軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測試用例（輸入數(shù)據(jù)及預(yù)期的輸出結(jié)果），并利用這些測試用例運(yùn)行程序及發(fā)現(xiàn)錯(cuò)誤的過程，即執(zhí)行測試步驟。意義：可以發(fā)現(xiàn)軟件中的缺陷，提高軟件的可靠性、穩(wěn)定性，降低軟件的維護(hù)成本，增強(qiáng)用戶對軟件的信任，保障軟件項(xiàng)目能夠順利交付并滿足用戶需求。2.（1）軟件未實(shí)現(xiàn)產(chǎn)品說明書中已標(biāo)明的功能。（2）軟件出現(xiàn)了產(chǎn)品說明書中標(biāo)明不應(yīng)該出現(xiàn)的錯(cuò)誤。（3）軟件未達(dá)到產(chǎn)品說明書中雖未標(biāo)明但應(yīng)（隱含）達(dá)到的目標(biāo)。（4）軟件功能超出了產(chǎn)品說明書中指明的范圍。（5）測試者認(rèn)為軟件難以理解、不易使用，或者最終用戶認(rèn)為軟件使用效果不佳。3.測試需求的確定，即明確要測試的內(nèi)容；測試用例的設(shè)計(jì)，設(shè)計(jì)出能有效發(fā)現(xiàn)缺陷的測試用例；測試環(huán)境的搭建，為測試提供合適的運(yùn)行環(huán)境；測試執(zhí)行過程的管理，確保測試按計(jì)劃進(jìn)行；缺陷的跟蹤和管理，對發(fā)現(xiàn)的缺陷進(jìn)行記錄、跟蹤和處理；測試結(jié)果的評估，判斷軟件是否滿足質(zhì)量要求等。4.瀑布模型、螺旋模型、RUP模型、IPD模型、敏捷模型。5.V模型：主要反映軟件從需求定義到實(shí)現(xiàn)與測試活動的關(guān)系，強(qiáng)調(diào)在整個(gè)軟件項(xiàng)目生命周期中需要經(jīng)歷的若干開發(fā)與測試的對應(yīng)級別。V模型從左到右、從上到下描述了開發(fā)過程和測試過程。X模型：左側(cè)描述的是針對單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測試，此后將進(jìn)行頻繁的交接，通過集成最終合成可執(zhí)行程序，對這些可執(zhí)行程序還需要進(jìn)行測試（見圖1-15右上方）。對已通過集成測試的成品進(jìn)行封版，并提交用戶，也可作為更大規(guī)模集成產(chǎn)品的一部分。多條并行的曲線表示變更可在各部分發(fā)生。前置測試模型：將測試和開發(fā)緊密結(jié)合的模型，代表測試的新思想和新理念。該模型提供了靈活的方式，可加快軟件開發(fā)進(jìn)度。6.（1）項(xiàng)目規(guī)劃階段。對從組件測試到系統(tǒng)測試的整個(gè)測試階段進(jìn)行監(jiān)控。（2）需求分析階段。確定測試需求分析、制訂系統(tǒng)測試計(jì)劃。其中，測試需求分析是對產(chǎn)品生命周期中測試所需的資源、配置、各階段評判通過的規(guī)約；系統(tǒng)測試計(jì)劃則是依據(jù)軟件的需求分析說明書，制訂測試計(jì)劃和設(shè)計(jì)相應(yīng)的測試用例。（3）詳細(xì)設(shè)計(jì)和概要設(shè)計(jì)階段。確保集成測試計(jì)劃和組件測試計(jì)劃完成。（4）編碼階段。由開發(fā)人員編寫自己負(fù)責(zé)部分的測試代碼。當(dāng)項(xiàng)目較大時(shí)，也可能由測試團(tuán)隊(duì)專人進(jìn)行編碼階段的測試工作。（5）測試階段（組件測試、集成測試、系統(tǒng)測試）。依據(jù)測試代碼進(jìn)行測試，并提交測試狀態(tài)報(bào)告和測試結(jié)果報(bào)告。7.質(zhì)量是一組固有特性滿足要求的程度。要確保產(chǎn)品質(zhì)量，必須保證生產(chǎn)過程和組織體系等實(shí)體的質(zhì)量。質(zhì)量管理體系是指為實(shí)施質(zhì)量管理所需的組織結(jié)構(gòu)、程序、過程和資源。8.略9.V模型優(yōu)點(diǎn)：從左到右、從上到下描述了開發(fā)過程和測試過程。開發(fā)活動分布在左邊向下分支，測試活動分布在右邊向上分支，按照測試階段的順序排列，明確標(biāo)明測試過程中存在的不同級別，清晰地描述了測試過程和開發(fā)過程中各階段的對應(yīng)關(guān)系。V模型的缺點(diǎn)：是需求、設(shè)計(jì)、編碼活動被視為串行的，同時(shí)，測試和開發(fā)活動也保持線性的前后關(guān)系，只有上一階段完成才能開始下一階段，因此該模式難以支持迭代方式，并且不適合在開發(fā)過程中做變更調(diào)整。第2章軟件測試概述一、選擇題1-5ACDDC6-10CBABB11-15ACDAB16-20DBABA21-25DADDB26-30CBDBC31-35ACDAD36-40BBCDD41-43CAC二、判斷題與填空題1-10√××××√×√√√11-20×××√√××√√×21-30√××√×√√×√×31-36√×√√√×37靜態(tài)測試；動態(tài)測試38系統(tǒng)測試；驗(yàn)收測試39.靜態(tài)；動態(tài)40.手工測試；自動測試41.不完備性42.測試設(shè)計(jì)；測試實(shí)現(xiàn)43.驅(qū)動；樁44.驅(qū)動模塊；樁模塊45.測試驅(qū)動程序；測試監(jiān)控程序46非增量式；增量式47功能性；適合性48平均無故障工作時(shí)間49失效率；基于執(zhí)行的三、簡述題1.軟件生命周期中的測試是貫穿于軟件開發(fā)全過程的活動，通過人工或自動化手段驗(yàn)證軟件功能、性能及質(zhì)量是否符合用戶需求，并識別缺陷和風(fēng)險(xiǎn)。2.測試級別：（1）組件測試。驗(yàn)證軟件組件是否按照組件規(guī)格說明來開發(fā)。（2）集成測試。檢查多個(gè)組件是否按照系統(tǒng)技術(shù)設(shè)計(jì)要求協(xié)同工作。（3）系統(tǒng)測試。驗(yàn)證整個(gè)系統(tǒng)是否滿足系統(tǒng)功能設(shè)計(jì)要求并將軟件搭建起來，通過與系統(tǒng)的需求定義比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或矛盾的地方。（4）驗(yàn)收測試（產(chǎn)品發(fā)布）。從用戶角度檢查系統(tǒng)是否滿足合同中定義的需求。特征：軟件開發(fā)活動和測試活動是分開的，且同等重要；V模型表明測試的驗(yàn)證和確認(rèn)思想；根據(jù)對應(yīng)的開發(fā)級別的不同來區(qū)分測試級別。3.常見的軟件模型有以下幾種。（1）故障模型：會引起軟件錯(cuò)誤或故障。（2）安全漏洞模型：為非法者攻擊軟件提供可能。（3）差性能模型：軟件動態(tài)運(yùn)行時(shí)效率低下。（4）并發(fā)故障模型：針對多線程編碼。（5）不良習(xí)慣模型：因編碼的不良習(xí)慣而造成錯(cuò)誤。（6）代碼國際化模型：存在于以不同語言進(jìn)行國際化的過程中。（7）誘騙代碼模型：容易引起歧義，令人感到困惑。4.測試思想通過模擬樁模塊/驅(qū)動模塊隔離依賴，確保組件在獨(dú)立環(huán)境中表現(xiàn)正確，確保每個(gè)函數(shù)、類或模塊的功能符合設(shè)計(jì)要求。?測試內(nèi)容涵蓋功能邏輯驗(yàn)證、接口規(guī)范測試、異常處理機(jī)制評估、性能基準(zhǔn)測試及邊界值場景覆蓋，確保組件在各種場景下的穩(wěn)定性。?技術(shù)特征采用自動化測試框架（如JUnit）提升效率，通過高覆蓋率測試用例確保缺陷發(fā)現(xiàn)；結(jié)合TDD（測試驅(qū)動開發(fā)）實(shí)現(xiàn)測試先行。?測試過程遵循需求分析、測試用例設(shè)計(jì)（等價(jià)類劃分等）、環(huán)境隔離、執(zhí)行測試到缺陷閉環(huán)管理，強(qiáng)調(diào)持續(xù)回歸測試以確保質(zhì)量穩(wěn)定。?主要任務(wù)?驗(yàn)證組件功能?：確保每個(gè)獨(dú)立單元完成預(yù)定功能。?隔離環(huán)境測試?：通過模擬底層依賴實(shí)現(xiàn)獨(dú)立驗(yàn)證。?性能與邊界測試?：評估組件在極限條件下的表現(xiàn)。?自動化覆蓋?：通過自動化框架提升測試效率與準(zhǔn)確性。5.非增量式測試和增量式測試非增量式測試采用一步到位的方法構(gòu)造測試。在對所有模塊進(jìn)行測試后，按照軟件結(jié)構(gòu)圖將各模塊連接起來，把連接后的模塊當(dāng)成一個(gè)整體進(jìn)行測試。特點(diǎn)?：一次性將所有模塊集成并進(jìn)行整體測試，不考慮組件間的相互依賴性。??優(yōu)點(diǎn)?：流程簡單，適合小規(guī)模系統(tǒng)或維護(hù)項(xiàng)目，可多人并行工作以提高效率。??缺點(diǎn)?：問題定位困難，接口錯(cuò)誤易被遺漏，風(fēng)險(xiǎn)集中導(dǎo)致調(diào)試成本高。?增量式測試與非增量式測試不同，集成是逐步實(shí)現(xiàn)的，測試也是逐步完成的，因此，可認(rèn)為是組件測試與集成測試結(jié)合進(jìn)行的。增量式集成測試可按照不同次序?qū)嵤?，由此產(chǎn)生了兩種不同的方法，即自頂向下的增量式測試和自底向上的增量式測試。特點(diǎn)?：分階段逐步集成模塊，每次僅添加一個(gè)模塊并進(jìn)行測試。??優(yōu)點(diǎn)?：問題暴露早、定位精準(zhǔn)，風(fēng)險(xiǎn)可控，適合復(fù)雜系統(tǒng)或需早期驗(yàn)證關(guān)鍵功能的項(xiàng)目。?缺點(diǎn)?：前期準(zhǔn)備耗時(shí)較長，需要額外開發(fā)樁模塊或驅(qū)動模塊。?6.系統(tǒng)測試的范圍涵蓋整個(gè)集成后的軟件系統(tǒng)，包括功能性和非功能性測試，旨在驗(yàn)證系統(tǒng)是否滿足需求規(guī)格。系統(tǒng)測試的內(nèi)容主要包含功能性測試、性能測試、安全性測試、恢復(fù)測試與兼容性測試等。功能性測試：驗(yàn)證系統(tǒng)是否滿足業(yè)務(wù)需求，如訂單處理、用戶認(rèn)證等核心功能。性能測試?：測量響應(yīng)時(shí)間、吞吐量和資源利用率，確保滿足預(yù)期負(fù)載要求。安全性測試?：評估防御安全威脅的能力，需模擬攻擊場景檢測漏洞。兼容性測試?：驗(yàn)證系統(tǒng)在不同硬件/軟件環(huán)境中的適配性。7.確認(rèn)測試的：（1）經(jīng)過檢驗(yàn)，軟件的功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，因而可被認(rèn)為是合格的軟件。（2）經(jīng)過檢驗(yàn)，發(fā)現(xiàn)與需求說明書有一定的偏離，得到各項(xiàng)缺陷的清單。對于這種情況，可能會在交付之前把發(fā)現(xiàn)的缺陷與問題修改與糾正過來。通常，確認(rèn)需要經(jīng)過開發(fā)者與用戶協(xié)商，以共同確定確認(rèn)測試的準(zhǔn)則。驗(yàn)收測試：安排通常由開發(fā)者與客戶協(xié)商，并在驗(yàn)收測試計(jì)劃中做出規(guī)定和說明。8.基于靜態(tài)測試測試特征測試環(huán)境相對穩(wěn)定，通常在專門的靜態(tài)測試平臺e上進(jìn)行，外界干擾因素較少被測對象處于靜止或相對靜止?fàn)顟B(tài)，便于對特定參數(shù)進(jìn)行精確測量和分析，可以對被測對象的各個(gè)部分進(jìn)行獨(dú)立、細(xì)致的檢測，不受動態(tài)運(yùn)行時(shí)的復(fù)雜工況影響，測試方法外觀檢查:通過直接觀察被測對象的外觀，檢查是否有明顯的損傷、變形、裂紋等缺陷。尺寸測量:使用各種測量工具，如卡尺、千分尺等，對被測對象的關(guān)鍵尺寸進(jìn)行精確測量，判斷其是否符合設(shè)計(jì)要求。電氣性能測試:利用電氣測試儀器，，如萬用表、示波器等，對被測對象的電氣參數(shù)，如電壓、電流、電阻、電容等進(jìn)行測量和分析，評估其電氣性能是否正常?；趧討B(tài)測試測試特征測試環(huán)境模擬實(shí)際運(yùn)行工況，具有動態(tài)變化的特點(diǎn)，能更真實(shí)地反映被測對象在實(shí)際使用中的性能。被測對象處于運(yùn)動狀態(tài)，會受到各種動態(tài)力的作用，測試過程中需要考慮這些動態(tài)因素對測試結(jié)果的影響?？梢詸z測被測對象在動態(tài)運(yùn)行過程中的整體性能和穩(wěn)定性，發(fā)現(xiàn)一些在靜態(tài)測試中難以發(fā)現(xiàn)的問題。測試方法振動測試:使用振動傳感器測量被測對象在運(yùn)行@過程中的振動情況，分析振動的頻率、幅值等參數(shù)，判斷是否存在異常振動，以評估被測對象的結(jié)構(gòu)穩(wěn)定性和運(yùn)行可靠性，噪聲測試:通過噪聲傳感器測量被測對象在運(yùn)行過程中產(chǎn)生的噪聲，分析噪聲的頻譜特性，判斷噪聲來源和是否符合相關(guān)標(biāo)準(zhǔn)要求。性能測試:在動態(tài)運(yùn)行條件下，對被測對象的名項(xiàng)性能指標(biāo)進(jìn)行測試，如發(fā)動機(jī)的動力性能、車輛的操控性能等，評估其在實(shí)際運(yùn)行中的性能表現(xiàn)。9.基于規(guī)格說明的測試：基本思想：任何程序都可看成是從輸入域映射到輸出值域的函數(shù)過程，被測程序可視為一個(gè)黑盒子，測試者在只知道軟件輸入和輸出之間的關(guān)系或軟件功能的情況下，依靠能反映這一關(guān)系和功能需求的規(guī)格說明，來確定測試用例和推斷測試結(jié)果的正確性。技術(shù)方法：等價(jià)類劃分/邊界值分析、配對測試、決策表測試、狀態(tài)轉(zhuǎn)換測試、用例測試等。適用范圍：主要針對軟件的各種功能、軟件界面、軟件性能、外部系統(tǒng)的條件和數(shù)據(jù)的訪問，以及軟件初始化等方面的測試。黑盒測試不破壞被測試對象的數(shù)據(jù)信息，在已知軟件產(chǎn)品應(yīng)具有的功能基礎(chǔ)上進(jìn)行檢測?；谲浖Y(jié)構(gòu)的測試：基本思想：通過測試全面了解程序內(nèi)部邏輯結(jié)構(gòu)，對所有程序的邏輯路徑進(jìn)行檢驗(yàn)，測試按照程序內(nèi)部結(jié)構(gòu)進(jìn)行，從檢查程序邏輯著手，獲得測試數(shù)據(jù)。技術(shù)方法：對程序的邏輯路徑進(jìn)行的遍歷性和響應(yīng)性的測試，通過在程序內(nèi)容的不同點(diǎn)去檢驗(yàn)程序的狀態(tài)，來判定其實(shí)際情況是否和預(yù)期狀態(tài)相一致適用范圍：控制流測試、基于路徑測試和元素比較測試。10.基本思想：相對于傳統(tǒng)軟件測試過程的“先設(shè)計(jì)，后執(zhí)行”而言，強(qiáng)調(diào)的測試策略是測試設(shè)計(jì)與測試執(zhí)行的同時(shí)性。技術(shù)方法：錯(cuò)誤猜測法、檢查表法、分類樹法等。適用范圍：產(chǎn)品、測試、問題。11.手工測試是主要的、經(jīng)典的軟件測試方法，其優(yōu)勢是人具有很強(qiáng)的邏輯判斷能力，可靈活地進(jìn)行測試。自動化測試是軟件測試的發(fā)展趨勢，是對手工測試的有力補(bǔ)充。很多數(shù)據(jù)的正確性、業(yè)務(wù)邏輯和軟件界面是否滿足用戶的要求等，都無法離開測試人員的直接判斷。12.基于風(fēng)險(xiǎn)的測試是指測試響應(yīng)及應(yīng)對軟件的風(fēng)險(xiǎn)。對軟件產(chǎn)品及項(xiàng)目的風(fēng)險(xiǎn)，可采用以下風(fēng)險(xiǎn)識別方法：由專家、業(yè)內(nèi)人士進(jìn)行訪談；對軟件產(chǎn)品或項(xiàng)目進(jìn)行獨(dú)立的評價(jià)與評估；使用風(fēng)險(xiǎn)的范本；對項(xiàng)目進(jìn)行回顧；召開風(fēng)險(xiǎn)研討會，運(yùn)用頭腦風(fēng)暴法尋找與分析；運(yùn)用檢查表法；總結(jié)過去的風(fēng)險(xiǎn)識別經(jīng)驗(yàn)。通過利益相關(guān)者對風(fēng)險(xiǎn)的識別，可以更加清楚風(fēng)險(xiǎn)在哪里。風(fēng)險(xiǎn)的級別?；诳赡苄耘c影響程度?？赡苄酝ǔ．a(chǎn)生于技術(shù)上的風(fēng)險(xiǎn)，而影響則產(chǎn)生于項(xiàng)目商業(yè)（或業(yè)務(wù)）上的風(fēng)險(xiǎn)?；陲L(fēng)險(xiǎn)的測試策略主要分為低級別風(fēng)險(xiǎn)測試策略和高級別風(fēng)險(xiǎn)測試策略。13.軟件開發(fā)項(xiàng)目通過驗(yàn)收測試后，即可交付客戶或者發(fā)布了。但產(chǎn)品運(yùn)行后，一般會使用數(shù)年或更長的時(shí)間。在此期間，軟件可能會發(fā)生多次對缺陷、故障的修正、版本升級或功能擴(kuò)展。每當(dāng)發(fā)生這些情況，原產(chǎn)品的新版本就會被開發(fā)出來。對新的軟件版本，自然也需要進(jìn)行測試。測試內(nèi)容：軟件維護(hù)測試、軟件版本開發(fā)的測試、軟件增量開發(fā)的測試。14.分類按測試階段分類?！卧獪y試:對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證，通常是函數(shù)、類等。集成測試:將多個(gè)單元組合在一起進(jìn)行測試檢查單元之間的接口和交互是否正確。系統(tǒng)測試:把整個(gè)系統(tǒng)作為一個(gè)整體進(jìn)行測試，驗(yàn)證系統(tǒng)是否滿足需求規(guī)格說明書的要求。驗(yàn)收測試:由用戶或客戶進(jìn)行的測試，確認(rèn)系.統(tǒng)是否可以交付使用。按測試方法分類黑盒測試:不考慮軟件內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)細(xì)節(jié)，只關(guān)注軟件的輸入和輸出，驗(yàn)證軟件是否符合功能需求。白盒測試:基于軟件的內(nèi)部結(jié)構(gòu)和邏輯，對程序的各個(gè)路徑和分支進(jìn)行測試，檢查代碼的正確性和完整性灰盒測試:結(jié)合了黑盒測試和白盒測試的特點(diǎn)，既關(guān)注軟件的功能，也考慮部分內(nèi)部結(jié)構(gòu)。關(guān)系這些分類方式相互關(guān)聯(lián)、相互補(bǔ)充。例如，在單元測試階段，既可以采用自盒測試方法對單個(gè)單元的代碼邏輯進(jìn)行詳細(xì)測試，也可以采用黑盒測試方法驗(yàn)證單元的功能;集成測試和系統(tǒng)測試階段，黑盒測試和灰盒測試更為常用，以確保系統(tǒng)整體的功能和性能;驗(yàn)收測試則主要側(cè)重于黑盒測試，從用戶的角度驗(yàn)證系統(tǒng)是否滿足業(yè)務(wù)需求。測試類別與技術(shù)方法所適用的解決測試問題的領(lǐng)域崧?局能臺溺鎦沺糜繳繚圍單元測試適用領(lǐng)域:適用于軟件開發(fā)的各個(gè)階段，尤其是編碼階段。在開發(fā)過程中，開發(fā)人員可以及時(shí)對編寫的代碼進(jìn)行單元測試，確保每個(gè)單元的功能正確。解決的問題:主要解決單元內(nèi)部的邏輯錯(cuò)誤、代碼實(shí)現(xiàn)與設(shè)計(jì)不符等問題，如函數(shù)的輸入輸出是否正確、類的方法是否正常工作等。集成測試適用領(lǐng)域:在單元測試完成后，多個(gè)單元集成在一起時(shí)進(jìn)行。常用于模塊化開發(fā)的項(xiàng)目，確保各個(gè)塊之間的接口和交互正常，解決的問題:解決模塊之間的接口不匹配、數(shù)據(jù)傳遞錯(cuò)誤、調(diào)用關(guān)系混亂等問題，保證系統(tǒng)各部分能夠協(xié)同工作。系統(tǒng)測試適用領(lǐng)域:在軟件系統(tǒng)集成完成后，進(jìn)行全面的測。試。適用于整個(gè)軟件系統(tǒng)的功能、性能、安全性等方面的驗(yàn)證。解決的問題:驗(yàn)證系統(tǒng)是否滿足需求規(guī)格說明書中訖槁可征的魎睽能鏨檻非功能需求，如系統(tǒng)的功能是否完整、性能是否達(dá)標(biāo)、是否具備足夠的安全性等。驗(yàn)收測試適用領(lǐng)域:在軟件系統(tǒng)開發(fā)完成后，由用戶或客戶心進(jìn)行的最終測試。適用于軟件交付前的確認(rèn)，確保系統(tǒng)可以滿足用戶的實(shí)際業(yè)務(wù)需求。解決的問題:解決系統(tǒng)是否符合用戶期望、是否能夠正常投入使用等問題，是軟件交付的重要環(huán)節(jié)。黑盒測試適用領(lǐng)域:適用于軟件的功能測試、用戶界面測試等。常用于軟件的后期測試階段，從用戶的角度驗(yàn)證軟件的功能是否正確。解決的問題:主要解決軟件的功能缺陷、用戶界面設(shè)計(jì)不合理等問題，確保軟件的功能符合用戶需求。白盒測試適用領(lǐng)域:適用于軟件的單元測試、代碼審查等，常用于軟件開發(fā)的早期階段，對代碼的內(nèi)部結(jié)構(gòu)和邏輯進(jìn)行詳細(xì)測試。解決的問題:解決代碼中的邏輯錯(cuò)誤、代碼覆蓋率不足、代碼效率低下等問題，保證代碼的質(zhì)量和可維護(hù)性?；液袦y試適用領(lǐng)域:適用于集成測試和系統(tǒng)測試階段。結(jié)合安了黑盒測試和白盒測試的優(yōu)點(diǎn)，既關(guān)注軟件的功能，也考慮部分內(nèi)部結(jié)構(gòu)。解決的問題:解決模塊之間的接口問題、系統(tǒng)整體的性能和穩(wěn)定性問題等，確保系統(tǒng)在動態(tài)運(yùn)行過程中的正常工作。第3章軟件靜態(tài)測試技術(shù)一、選擇題1-5ACDBD6-10ADCCB11-15ACDCC16-20CDA二、判斷題與填空題1-10××√××√√√×√11-13√√√14評審員；作者15評審；審計(jì)；審計(jì)16圓圈；箭頭17節(jié)點(diǎn)數(shù)；節(jié)點(diǎn)之間的連接關(guān)系18代碼審查19圈；Halstead20自動評審；走查；審計(jì)三、簡述題1.略2.語法檢查:檢查代碼是否符合編程語言的語法規(guī)則，如括號匹配、語句結(jié)束符等，數(shù)據(jù)流分析:跟蹤變量的定義、使用和賦值情況發(fā)現(xiàn)未初始化變量、變量使用前未定義等問題。控制流分析:分析程序的控制結(jié)構(gòu)，如循環(huán)、條件語句等，檢查是否存在死循環(huán)、不可達(dá)代碼等問題。代碼復(fù)雜度分析:計(jì)算代碼的復(fù)雜度指標(biāo)，如圈復(fù)雜度，評估代碼的可維護(hù)性和可測試性。過程（1）工具選擇與配置:選擇合適的靜態(tài)分析工具，并根據(jù)項(xiàng)目需求配置分析規(guī)則。（2）代碼掃描:運(yùn)行工具對代碼進(jìn)行掃描，收集分析數(shù)據(jù)。（3）結(jié)果分析:對掃描結(jié)果進(jìn)行分析，篩選出有意義的問題。（4）問題修復(fù):開發(fā)人員根據(jù)分析結(jié)果修復(fù)代碼中的問題。（5）復(fù)查:再次運(yùn)行工具進(jìn)行復(fù)查，確保問題已解決。3.略4.走查對象:主要是代碼，也可包括設(shè)計(jì)文檔等，方法:由開發(fā)人員帶領(lǐng)評審小組成員，逐行檢查代碼，解釋代碼的功能和邏輯。效果:能及時(shí)發(fā)現(xiàn)代碼中的錯(cuò)誤和問題，促進(jìn)團(tuán)隊(duì)成員之間的交流和學(xué)習(xí)。運(yùn)用范圍:適用于代碼的初步檢查和調(diào)試組織形式:通常由開發(fā)人員組織，邀請測試人員，設(shè)計(jì)人員等參與。評審對象:需求規(guī)格說明書、設(shè)計(jì)文檔、代碼等e方法:采用會議的形式，評審人員對評審對象進(jìn)行討論和分析，提出問題和建議。效果:能全面檢查評審對象的質(zhì)量，發(fā)現(xiàn)潛在的問題和風(fēng)險(xiǎn)。運(yùn)用范圍:適用于項(xiàng)目的各個(gè)階段，如需求分析設(shè)計(jì)、編碼等。組織形式:由項(xiàng)目負(fù)責(zé)人或質(zhì)量保證人員組織，邀0請相關(guān)人員參與。5.數(shù)據(jù)流分析是跟蹤變量在程序中的定義、使用和賦值情況的技術(shù)。它通過建立數(shù)據(jù)流圖，分析變量的生命周期，找出未初始化變量、變量使用前未定義、變量多次賦值等問題。適用的測試問題未初始化變量:變量在使用前未進(jìn)行初始化，可能e導(dǎo)致程序出現(xiàn)不可預(yù)期的結(jié)果，變量使用前未定義:使用了未定義的變量，會導(dǎo)致@編譯錯(cuò)誤或運(yùn)行時(shí)錯(cuò)誤，變量多次賦值:變量多次賦值可能會影響程序的邏輯和性能。6.控制流分析是分析程序的控制結(jié)構(gòu)，如循環(huán)、條件語句等的技術(shù)。它通過建立控制流圖，分析程序的執(zhí)行路徑，找出死循環(huán)、不可達(dá)代碼、路徑覆蓋不全等問題。適用的測試問題死循環(huán):程序中的循環(huán)無法正常退出，會導(dǎo)致程序陷入無限循環(huán)。不可達(dá)代碼:代碼中存在無法執(zhí)行到的語句，可能是由于邏輯錯(cuò)誤或代碼冗余導(dǎo)致的。路徑覆蓋不全:程序的某些執(zhí)行路徑未被測試到，可能導(dǎo)致潛在的錯(cuò)誤未被發(fā)現(xiàn)。7.略四、測試設(shè)計(jì)題略第4章軟件動態(tài)測試技術(shù)一、選擇題1-5DACDB6-10CBACD11-15CDADB16-20CDCDA21-25CADBD26-30BADCC31-35ACCAD36-40BCADC41-43BABCDABCE二、判斷題與填空題1-10××√×√√××√√11-20√×√√√×√√×√21-26×√√√√×27性能測試；異常處理測試；邊界測試28樁模塊；驅(qū)動模塊29黑盒測試；白盒測試三、項(xiàng)目實(shí)踐題略第5章軟件自動化測試一、選擇題1-5ABDABCDACDABCDEF6-9DBDB二、簡述題1.自動化測試是軟件測試的重要策略與技術(shù)手段。自動化測試能完成許多手工測試無法實(shí)現(xiàn)或難以實(shí)現(xiàn)的測試工作，甚至能更迅速地獲得比手工測試更好的測試質(zhì)量與效率，能提高整個(gè)軟件產(chǎn)品的開發(fā)質(zhì)量、縮短開發(fā)周期。2.使用一種自動化測試工具來驗(yàn)證各種測試需求，包括測試活動的實(shí)施與管理。自動化測試通過運(yùn)用自動化測試工具，并結(jié)合其他手段，按照測試管理的預(yù)定計(jì)劃自動進(jìn)行，以減輕手工測試的工作量或?qū)崿F(xiàn)手工測試無法完成的測試目標(biāo)。3.優(yōu)勢：可提高某些測試任務(wù)的執(zhí)行效率，如壓力測試。方便進(jìn)行回歸測試。特別是在程序修改頻繁時(shí)，自動化測試的效果非常明顯。由于回歸測試的動作和測試用例是設(shè)計(jì)好的，測試的結(jié)果完全可預(yù)料，因此，回歸測試的自動化可極大提高測試效率。在較少時(shí)間內(nèi)運(yùn)行更多的測試，如對運(yùn)行煩瑣的測試、系統(tǒng)的每日構(gòu)建等?？蓤?zhí)行某些手工測試難以或不可能實(shí)現(xiàn)的測試，如對大量（如幾百或上千、上萬個(gè)）用戶進(jìn)行并發(fā)測試。更好地利用人力資源。為煩瑣且重復(fù)的測試工作賦予自動化的方式，可提高測試的準(zhǔn)確性和效率，將測試人員從繁重的工作中解脫出來，將更多的精力放在測試的分析、設(shè)計(jì)及規(guī)劃工作上。測試具有一致性與可重復(fù)性。因?yàn)槊看螠y試的執(zhí)行內(nèi)容及過程的一致性得到了保障，故可達(dá)到測試可重復(fù)的效果。例如，回歸測試、重復(fù)單一數(shù)據(jù)錄入或擊鍵等操作測試；又如，測試用例具有極大相似性且測試步驟基本相同，只是輸入?yún)?shù)不同，如等價(jià)類在很多情形下就是這樣。測試腳本具有復(fù)用性。自動化測試通常采用腳本技術(shù)，以實(shí)現(xiàn)在不同測試過程中使用相同的測試用例。只需要對腳本做少量修改甚至不做修改，就可以實(shí)現(xiàn)測試的復(fù)用。可讓軟件盡早發(fā)布、投入市場。自動化測試可縮短測試的時(shí)間，縮短產(chǎn)品開發(fā)周期，令軟件產(chǎn)品盡早投入市場。增強(qiáng)軟件的可信度。由于測試是自動執(zhí)行的，所以不存在手工執(zhí)行過程中由于疏忽而出現(xiàn)的錯(cuò)誤。通過自動化測試，軟件產(chǎn)品的可信度（質(zhì)量）會增強(qiáng)。適用于非常重要的測試和涉及范圍很廣的測試，如針對系統(tǒng)的GUI測試、功能與性能的測試等。可較快或?qū)崟r(shí)地獲得測試結(jié)果。如路徑測試、邏輯流程與控制流的覆蓋測試。測試執(zhí)行與控制可實(shí)現(xiàn)自動化。例如，單機(jī)運(yùn)行或網(wǎng)絡(luò)分布式運(yùn)行的測試，在節(jié)假日或工作日夜間可運(yùn)行的測試?？勺詣油瓿蓪y試用例的調(diào)用控制，如對測試對象、測試范圍、測試報(bào)告及文檔生成，以及對測試版本的管理控制的測試。對測試結(jié)果與標(biāo)準(zhǔn)輸出需進(jìn)行大量或精確的比對。例如，對不符合預(yù)期的測試結(jié)果的分析、記錄、分類及報(bào)告，以及總體測試狀況的統(tǒng)計(jì)及報(bào)表的分析。若測試運(yùn)行時(shí)間只占總體測試時(shí)間的10%，而需花費(fèi)90%的總體測試時(shí)間進(jìn)行準(zhǔn)備，則可考慮實(shí)施自動化測試。風(fēng)險(xiǎn)：不現(xiàn)實(shí)的期望。自動化測試工具不能解決面臨的所有問題。事實(shí)上，當(dāng)期望不現(xiàn)實(shí)或過高時(shí)，自動化測試將難以滿足這種期望。缺乏自動化測試的經(jīng)驗(yàn)。例如，缺乏自動化測試的實(shí)踐經(jīng)驗(yàn)，測試的組織協(xié)調(diào)較差，軟件開發(fā)和測試的相關(guān)文檔較少或兩者不一致時(shí)，自動化測試發(fā)現(xiàn)缺陷或錯(cuò)誤的能力將大大降低。此時(shí)，首先要考慮和改進(jìn)測試的有效性，而非測試的效率。期望自動化測試能夠發(fā)現(xiàn)大量新的缺陷。自動化測試在首次運(yùn)行時(shí)最有可能發(fā)現(xiàn)缺陷，若測試已運(yùn)行過，再次運(yùn)行相同的測試，發(fā)現(xiàn)新缺陷的概率很小。例如回歸測試，再次運(yùn)行相同測試，并不能發(fā)現(xiàn)新問題。錯(cuò)誤地認(rèn)為自動化測試的可靠性一定高。例如，在自動化測試過程中沒有發(fā)現(xiàn)任何軟件缺陷，并不能說明軟件缺陷或錯(cuò)誤不存在，此時(shí)不應(yīng)產(chǎn)生軟件的可靠性就一定高的錯(cuò)覺。錯(cuò)誤地認(rèn)為自動化測試無須維護(hù)。實(shí)際上，在軟件被修改后，通常對測試也需做相應(yīng)的調(diào)整、修正工作，即自動化測試通常是需要不斷維護(hù)的，因此，這可能會帶來自動化測試維護(hù)的高成本。技術(shù)問題的影響因素。商業(yè)測試工具屬于軟件產(chǎn)品，有其適用范圍，并不能包羅所有測試。實(shí)際上，測試工具本身就可能存在不足或問題。雖然測試工具能處理某些測試中的異常事件，但對實(shí)時(shí)突發(fā)事件的處理可能無能為力。因此，從技術(shù)層面將無法做到完美無缺和無所不能，完全替代所有手工測試。另外，在自動化測試工具充分地利用發(fā)揮其作用方面，使用者的專業(yè)能力和技術(shù)水平的影響也十分顯著。4.測試工具能夠模擬實(shí)際用戶操作，自動執(zhí)行大量的重復(fù)性測試任務(wù)。例如在功能測試中，對于一些常規(guī)的o登錄、數(shù)據(jù)錄入等操作，手動測試需要測試人員反復(fù)進(jìn)行，不僅耗時(shí)而且容易出錯(cuò)。而使用自動化測試工具，如LoadRunner、JMeter等，可以編寫腳本讓工具自動完成這些操作，大大提高了測試效率。它還可以支持?jǐn)?shù)據(jù)驅(qū)動腳本和關(guān)鍵字驅(qū)動腳本等多種腳本類型。以數(shù)據(jù)驅(qū)動腳本為例，在一個(gè)電商網(wǎng)站的測試中，需要測試不同用戶信息(用戶名、密碼、地址等)的登錄功能，通過數(shù)據(jù)驅(qū)動腳本，只需編寫-個(gè)測試腳本，然后從外部數(shù)據(jù)源(如Excel表格)讀取不同的測試數(shù)據(jù)，就可以自動完成對多種用戶信息的登錄測試，減少了腳本編寫的重復(fù)工作，提高了測試的準(zhǔn)確性。5.（1）自動化測試的決策（2）測試工具的獲?。?）自動化測試的引入（4）確認(rèn)測試計(jì)劃、進(jìn)行測試設(shè)計(jì)（5）測試執(zhí)行與管理（6）測試評審與評估6.（1）測試的自動執(zhí)行。（2）對狀態(tài)的自動識別。（3）自動的邏輯處理。7.結(jié)構(gòu)化腳本：健壯性好，可通過循環(huán)和調(diào)用減少工作量，但腳本較復(fù)雜，而且測試用例“捆綁”在腳本中。共享腳本：以較少的開銷實(shí)現(xiàn)類似的測試；維護(hù)開銷低于線性腳本；可以在腳本中增加更智能的功能。但需要跟蹤更多的腳本，給配置管理帶來一定的困難；對于每個(gè)測試，仍然需要特定的測試腳本，因此維護(hù)費(fèi)用較高；共享腳本通常是針對被測軟件的某部分的，部分腳本不能被直接運(yùn)行。數(shù)據(jù)驅(qū)動腳本：可以快速地增加類似的測試；測試者增加新測試不必掌握工具腳本語言；對第二個(gè)及以后類似的測試無額外的維護(hù)開銷。但初始建立的開銷較大，需要專業(yè)編程軟件的支持。關(guān)鍵字驅(qū)動腳本：關(guān)鍵字驅(qū)動腳本的數(shù)量不隨測試用例的數(shù)量而變化，僅隨軟件規(guī)模而變化。這種腳本還可實(shí)現(xiàn)跨平臺測試用例共享，只需更改支持腳本即可。線性腳本：可加快自動化；可審計(jì)跟蹤實(shí)際執(zhí)行操作；測試用戶不必是編程人員；可進(jìn)行良好（軟件或工具）的演示。但過程煩瑣，一切依賴于每次捕獲的內(nèi)容；測試輸入和比較是“捆綁”在腳本中的；無共享或重用腳本；容易受軟件的影響；修改代價(jià)大，維護(hù)成本高；容易受意外事件影響，從而導(dǎo)致整個(gè)測試失敗。8.自動化測試的專項(xiàng)工具，主要解決某一專項(xiàng)測試的問題。自動化測試的專項(xiàng)工具包括測試Web應(yīng)用軟件的功能特性、性能特性和安全特性的工具，進(jìn)行覆蓋率測試的工具，以及對內(nèi)存分析、腳本設(shè)計(jì)、測試管理等專項(xiàng)進(jìn)行測試的工具等。三、項(xiàng)目實(shí)踐題略第6章軟件項(xiàng)目的組件測試一、簡述題1.（1）功能檢查：檢測程序模塊的邏輯功能能否實(shí)現(xiàn)。（2）模塊接口測試：對通過被測模塊的數(shù)據(jù)流進(jìn)行測試。即對模塊接口，包括參數(shù)表、調(diào)用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入/輸出操作進(jìn)行檢測。（3）局部數(shù)據(jù)結(jié)構(gòu)測試：設(shè)計(jì)測試用例，檢查數(shù)據(jù)類型的說明、初始化、默認(rèn)值等方面是否存在問題。（4）路徑覆蓋測試：對模塊執(zhí)行路徑測試。即對基本路徑與循環(huán)進(jìn)行測試。（5）錯(cuò)誤處理測試：檢查錯(cuò)誤處理功能。例如，是否拒絕不合理輸入，出錯(cuò)描述是否難以理解，對錯(cuò)誤的定位是否有誤，出錯(cuò)原因報(bào)告是否有誤，對錯(cuò)誤的處理是否不正確。（6）規(guī)范性測試：對程序模塊的規(guī)范性和程序質(zhì)量進(jìn)行度量及評審。2.組件測試通?？煞譃殪o態(tài)檢查和動態(tài)執(zhí)行跟蹤，可采用手工或自動化測試的策略。具體的測試解決方案需要根據(jù)實(shí)際情況確定，可采用單一技術(shù)或綜合應(yīng)用各種技術(shù)。3.頁面元素測試、對窗體操作的測試、面向?qū)ο筌浖惖臏y試、對數(shù)據(jù)項(xiàng)操作的測試4.類測試等價(jià)于對面向過程軟件的組件測試，傳統(tǒng)組件測試主要關(guān)注模塊算法和模塊接口間數(shù)據(jù)的流動，即輸入和輸出。而面向?qū)ο蟮念悳y試主要測試封裝在類中的操作及類的狀態(tài)行為。5.基礎(chǔ)斷言、數(shù)字?jǐn)嘌?、字符斷言、布爾斷言、對象斷言?.Audit：主要功能是定位錯(cuò)誤代碼模塊。RuleChecker：靜態(tài)測試工具，用來檢查代碼書寫是否規(guī)范。TestChecker：統(tǒng)計(jì)被測程序的測試覆蓋率，其重點(diǎn)統(tǒng)計(jì)的是DDP覆蓋率。二、項(xiàng)目實(shí)踐題略第7章軟件系統(tǒng)功能測試一、簡述題1.（1）針對一般的軟件系統(tǒng)針對一般的軟件項(xiàng)目，軟件系統(tǒng)功能測試的范圍及內(nèi)容主要是檢測軟件的各項(xiàng)業(yè)務(wù)功能能否正確實(shí)現(xiàn)。（2）針對Web應(yīng)用軟件系統(tǒng)對于Web應(yīng)用軟件系統(tǒng)（簡稱Web應(yīng)用系統(tǒng)）的測試，除上述針對一般軟件需要檢測的內(nèi)容外，還應(yīng)增加鏈接測試、表單測試、數(shù)據(jù)校驗(yàn)測試、Cookies測試、Web設(shè)計(jì)語言的測試、數(shù)據(jù)庫測試、應(yīng)用系統(tǒng)特定功能測試等內(nèi)容。2.（1）功能測試的策略（2）功能測試的流程（3）功能測試的測試用例或測試腳本3.錄制過程：（1）啟動錄制（2）開始錄制（3）結(jié)束錄制回放過程：（1）打開腳本（2）設(shè)置回放參數(shù)（3）開始回放（4）觀察結(jié)果（5）分析報(bào)告二、項(xiàng)目實(shí)踐題略第8章軟件系統(tǒng)性能測試一、簡述題1.并發(fā)。嚴(yán)格意義上的并發(fā)是指所有的客戶端在同一時(shí)刻做同一件事情或執(zhí)行同一項(xiàng)操作。這種操作一般是指同一種業(yè)務(wù)。廣義的并發(fā)中客戶端的請求或操作可以是相同的，也可以是不同的。響應(yīng)時(shí)間主要是針對用戶而言，屬于宏觀的概念，是為了向用戶說明業(yè)務(wù)響應(yīng)時(shí)間而提出的。2.略3.C/S系統(tǒng)適用協(xié)議:根據(jù)后臺數(shù)據(jù)庫類型選擇協(xié)議:若客戶端程序以ADO、OLEDB方式連接后臺數(shù)據(jù)庫，當(dāng)后臺數(shù)據(jù)庫是DOracle時(shí)，錄制選擇Oracle協(xié)議;若以O(shè)DBC方式連接后臺數(shù)據(jù)庫，則選擇ODBC協(xié)議。自定義Socket協(xié)議:當(dāng)客戶端和服務(wù)端之間通過白定義的Socket協(xié)議進(jìn)行通信時(shí)，錄制選擇Socket協(xié)議.2適用系統(tǒng)舉例:一些傳統(tǒng)的企業(yè)級管理軟件，如早期的財(cái)務(wù)管理軟件，采用C/S架構(gòu)，客戶端通過特定方式連接后臺數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲和處理，就需要根據(jù)數(shù)據(jù)庫連接方式選擇相應(yīng)協(xié)議錄制腳本。還有一些自定義通信協(xié)議的工業(yè)控制軟件，其客戶端與服務(wù)端通過白定義Socket協(xié)議交互，錄制性能測試腳本時(shí)需選擇Socket協(xié)議。Web應(yīng)用系統(tǒng)適用協(xié)議:HTTP/HTTPS協(xié)議。不過，有些借助客戶端運(yùn)行的組件擴(kuò)展功能的Web應(yīng)用，其客戶端組件采用自定義Socket或是其他協(xié)議與服務(wù)器進(jìn)行通信，此時(shí)需要在錄制時(shí)選擇多種協(xié)議。適用系統(tǒng)舉例:常見的電子商務(wù)網(wǎng)站、在線教育平臺等Web應(yīng)用，一般采用ASP結(jié)構(gòu)、J2EE或是.NET架構(gòu)，通過HTTP/HTTPS協(xié)議與服務(wù)器交互，錄制性能測試腳本時(shí)通常選擇HTTP/HTTPS協(xié)議。而一些具有客戶端插件的Web游戲應(yīng)用，插件可能通過白定義協(xié)議與服務(wù)器通信，錄制腳本時(shí)就需要同時(shí)選擇HTTP/HTTPS協(xié)議和相應(yīng)的自定義協(xié)議。組件適用協(xié)議:COM/DCOM協(xié)議。商業(yè)性能測試工具一般提供直接測試組件接口性能的方法。適用系統(tǒng)舉例:在Windows系統(tǒng)中，一些基于COM/DCOM組件開發(fā)的軟件系統(tǒng)，如某些辦公軟件的插件系統(tǒng)，通過COMDCOM協(xié)議實(shí)現(xiàn)組件間的通信和功能調(diào)用，對這類組件進(jìn)行性能測試時(shí)，錄制腳本需選擇COM/DCOM協(xié)議?；ヂ?lián)網(wǎng)基礎(chǔ)服務(wù)MaiI服務(wù)器:適用SMTP和POP協(xié)議。SMTP用于郵件的發(fā)送，POP用于郵件的接收，對Mai服務(wù)器進(jìn)行性能測試時(shí)，錄制腳本選擇這兩種協(xié)議。FTP服務(wù)器:適用FTP協(xié)議。FTP協(xié)議用于文件的上傳和下載，對FTP服務(wù)器進(jìn)行性能測試，如測試其文件傳輸?shù)男屎头€(wěn)定性，錄制腳本選擇FTP協(xié)議。適用系統(tǒng)舉例:企業(yè)內(nèi)部的郵件服務(wù)器，為用戶提供郵件收發(fā)服務(wù)，對其進(jìn)行性能測試時(shí)，根據(jù)郵件發(fā)送和接收功能，分別選擇SMTP和POP協(xié)議錄制腳本。一些提供文件存儲和共享服務(wù)的FTP服務(wù)器，測試其文件上傳下載性能時(shí)，選擇FTP協(xié)議錄制腳本。應(yīng)用服務(wù)器適用協(xié)議:根據(jù)具體的應(yīng)用服務(wù)器類型選擇相應(yīng)協(xié)議，如OracleApplicationServer協(xié)辦議、SAP協(xié)議、Tuxedo協(xié)議等。適用系統(tǒng)舉例:使用OracleApplicationServer部署的企業(yè)級應(yīng)用系統(tǒng)，如一些大型的金融交易系統(tǒng)，對其進(jìn)行性能測試時(shí)，錄制腳本選擇OracleApplicationServer協(xié)議。采用SAP系統(tǒng)進(jìn)行企業(yè)資源管理的企業(yè)，對SAP應(yīng)用服務(wù)器進(jìn)行性能測試，錄制腳本選擇SAP協(xié)議。一些基于Tuxedo中間件開發(fā)的電信業(yè)務(wù)系統(tǒng)，對Tuxedo應(yīng)用服務(wù)器進(jìn)行性能測試，錄制腳本選擇Tuxedo協(xié)議。ERP系統(tǒng)適用協(xié)議:ERP系統(tǒng)可能基于不同的架構(gòu)和技術(shù)，若為Web架構(gòu)的ERP系統(tǒng)，一般適用HTTP/HTTPS協(xié)議;若涉及數(shù)據(jù)庫連接，可能根據(jù)數(shù)據(jù)庫類型選擇Oracle、ODBC等協(xié)議;若有自定義通信協(xié)議，還需選擇相應(yīng)協(xié)議。適用系統(tǒng)舉例:一些基于Web的云端ERP系統(tǒng)，用戶通過瀏覽器訪問和使用，錄制其性能測試腳本時(shí)選擇HTTP/HTTPS協(xié)議。而一些企業(yè)內(nèi)部部署的傳統(tǒng)ERP系統(tǒng)，客戶端通過特定方式連接后臺數(shù)據(jù)庫，如使用Oracle數(shù)據(jù)庫，錄制腳本時(shí)可能選擇Oracle協(xié)議;若通過ODBC連接其他數(shù)據(jù)庫，則選擇ODBC協(xié)議。4.（1）性能測試需求分析（2）測試計(jì)劃的制訂與評審（3）測試用例的設(shè)計(jì)與開發(fā)（4）測試執(zhí)行與監(jiān)控（5）測試性能分析（6）編寫性能測試報(bào)告（7）測試經(jīng)驗(yàn)總結(jié)二、項(xiàng)目實(shí)踐題略第9章軟件系統(tǒng)安全性測試一、簡述題1.略2.（1）軟件安全策略的組成軟件安全策略由物理安全策略、網(wǎng)絡(luò)安全策略、數(shù)據(jù)加密策略、數(shù)據(jù)備份策略、病毒防范策略、系統(tǒng)安全策略、身份認(rèn)證及授權(quán)策略、災(zāi)難恢復(fù)策略、故障處理緊急響應(yīng)策略、口令管理策略、補(bǔ)丁管理策略、變更策略、審計(jì)策略等組成。（2）安全系統(tǒng)測試策略安全系統(tǒng)測試策略包括基本安全防護(hù)系統(tǒng)測試與安全系統(tǒng)防護(hù)體系測試兩個(gè)部分?；景踩雷o(hù)系統(tǒng)測試由一系列測試點(diǎn)構(gòu)成，這些測試點(diǎn)有防火墻、入侵檢測系統(tǒng)、漏洞掃描系統(tǒng)、防病毒系統(tǒng)、安全審計(jì)系統(tǒng)、Web信息防篡改系統(tǒng)。安全性測試將綜合運(yùn)用靜態(tài)測試與動態(tài)測試技術(shù)，實(shí)施安全性模糊測試，選用適合于特定安全問題的測試工具，完成安全性測試的七個(gè)接觸點(diǎn)。3.（1）用戶管理與訪問控制測試用戶管理與訪問控制測試主要有用戶權(quán)限管理測試、操作系統(tǒng)安全性測試、數(shù)據(jù)庫權(quán)限測試。（2）通信加密測試通信加密測試主要有VPN加密技術(shù)、對稱加密算法、非對稱加密算法、Hash算法。（3）Web應(yīng)用系統(tǒng)的安全性測試Web應(yīng)用系統(tǒng)的安全性測試主要采用靜態(tài)測試與滲透測試的方法。測試主要包含下列內(nèi)容。1）注入攻擊。2）跨站點(diǎn)腳本工具（XSS）。3）跨站點(diǎn)請求偽造（CSRF）。4）未能限制URL訪問。5）后臺服務(wù)器安全測試。6）認(rèn)證保護(hù)與會話管理測試。7）通信層保護(hù)不充分測試。8）系統(tǒng)配置不安全測試。9）信息隱藏與完整性測試。10）代碼安全性測試。11）異常處理安全性測試。4.AppScan系列產(chǎn)品使用戶能在熟悉的技術(shù)環(huán)境中工作，并能與QA模塊和集成的開發(fā)環(huán)境無縫集成；允許進(jìn)行連續(xù)安全審核，幫助軟件開發(fā)團(tuán)隊(duì)逐步在Web應(yīng)用中構(gòu)建安全體系，在部署應(yīng)用之前轉(zhuǎn)移業(yè)務(wù)風(fēng)險(xiǎn)。5.略二、項(xiàng)目實(shí)踐題略第10章軟件測試管理一、選擇題1-5DCDBC6-10DADBB11-15DACDA16-20DADDA21-22CC二、簡述題1.軟件測試管理著眼于對軟件測試的流程進(jìn)行策劃與組織，是對測試全過程實(shí)施的管理與控制，并通過管理提高測試活動的可視性和可控性。測試管理的內(nèi)容主要有測試組織（機(jī)構(gòu)）的管理、測試需求的管理、測試事件的管理、測試用例的管理、測試過程的管理、缺陷跟蹤的管理、軟件配置管理與測試環(huán)境的搭建，以及測試報(bào)告管理等。2.（1）目的：明確每個(gè)階段的測試目的。（2）測試策略：用于測試的方法。（3）資源配置：測試所需的硬件設(shè)備。（4）任務(wù)明確：明確所有參加測試工作的人員角色和職責(zé)。（5）進(jìn)度安排：指每個(gè)測試階段的進(jìn)度安排。（6）風(fēng)險(xiǎn)分析：指明項(xiàng)目中潛在的問題和風(fēng)險(xiǎn)區(qū)域。（7）停測標(biāo)準(zhǔn)：判斷每個(gè)測試階段停止測試的標(biāo)準(zhǔn)。（8）測試用例庫：決定測試用例的編寫方法，保存、使用和維護(hù)測試用例。（9）組裝方式：確定子程序、分系統(tǒng)組裝的次序，確定是按自頂向下還是按自底向上的增量式集成方式進(jìn)行測試，確定系統(tǒng)在各種組裝方式下的功能特性及樁模塊或驅(qū)動模塊的設(shè)計(jì)。（10）記錄手段：明確在測試中對問題、進(jìn)度等記錄的方法。（11）測試工具：明確測試所需的工具并制訂相應(yīng)的計(jì)劃。（12）回歸測試：確定故障修復(fù)對其他方面造成的影響，制訂回歸測試計(jì)劃。3.略4.試計(jì)劃文檔、測試方案文檔、測試用例文檔、測試規(guī)程文檔和測試報(bào)告文檔。5.（1）計(jì)劃和控制階段。本階段是整個(gè)測試過程中最重要的階段，為實(shí)現(xiàn)可管理且高質(zhì)量的測試過程提供基礎(chǔ)。本階段的主要內(nèi)容：擬訂測試計(jì)劃；論證使開發(fā)過程難以管理和控制的因素；明確軟件產(chǎn)品的最重要部分（風(fēng)險(xiǎn)評估）。（2）準(zhǔn)備階段。開始本階段的前提條件是完成了測試計(jì)劃的擬定和需求規(guī)格說明書（通常為第一版）的確定。本階段的主要內(nèi)容：仔細(xì)研究需求規(guī)格說明書；將要測試的產(chǎn)品分解成可獨(dú)立測試的單元；為每個(gè)測試單元確定測試技術(shù)；為測試的下一個(gè)階段的活動制訂計(jì)劃。（3）規(guī)范階段。本階段的主要內(nèi)容：編寫測試用例、測試腳本，搭建測試環(huán)境（測試的數(shù)據(jù)庫和軟件、硬件環(huán)境）。（4）實(shí)施階段。本階段的主要內(nèi)容：根據(jù)測試綱要/測試用例/測試腳本進(jìn)行測試，找出預(yù)期測試結(jié)果和實(shí)際測試結(jié)