【正文】 分為 語(yǔ)句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋6種覆蓋技術(shù)。8計(jì)算機(jī)輔助靜態(tài)分析利用 靜態(tài)分析工具對(duì)測(cè)試程序進(jìn)行 特性分析。7動(dòng)態(tài)測(cè)試通過(guò) 運(yùn)行程序發(fā)現(xiàn)錯(cuò)誤。7軟件測(cè)試的目的是盡可能多地發(fā)現(xiàn)軟件中存在的 錯(cuò)誤，將測(cè)試 測(cè)試結(jié)果作為糾錯(cuò)的依據(jù)。6在任何機(jī)構(gòu)中，CAPA要正確發(fā)揮作用需要CAPA記錄流的跟蹤、CAPA執(zhí)行的跟蹤和CAPA執(zhí)行結(jié)果的跟蹤三個(gè)要的跟蹤任務(wù)。6軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過(guò)程的軟件維護(hù)兩大方面。6軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。5典型的版本方針包括嚴(yán)格單一活動(dòng)版本方針、多版本方針。5軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性、軟件缺陷的感染性。50、支持性質(zhì)量手段有模板和檢查表。4McCall模型產(chǎn)品修改緯度的質(zhì)量因素有可維護(hù)性、可測(cè)試性、靈活性。4常見(jiàn)的程序分析視角有句法視角，功能視角、文本視角和計(jì)算流視角4按照測(cè)試用例的設(shè)計(jì)方法，軟件測(cè)試可以分為白盒測(cè)試、黑盒測(cè)試和灰盒測(cè)試。3按照測(cè)試的層次和策略,軟件測(cè)試可以分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試 和 系統(tǒng)測(cè)試。3軟件缺陷打開/關(guān)閉圖表、根本原因圖表、軟件缺陷關(guān)閉周期表是常用的軟件缺陷跟蹤圖表。2從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成和評(píng)估標(biāo)準(zhǔn)兩種類型。2外部參與方可被分類為、COTS軟件和重用軟件模塊的供貨商和顧客自身三組。2CMM內(nèi)容包含初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、已管理級(jí)和可優(yōu)化級(jí)五個(gè)等級(jí)。1常見(jiàn)的軟件配置演化模型有線性演化模型和樹演化模型。1依據(jù)合同評(píng)審的目標(biāo)對(duì)合同評(píng)審主題進(jìn)行分類為建議草案評(píng)審主題和合同草案評(píng)審主題兩種類型。SQA標(biāo)準(zhǔn)被劃分成軟件質(zhì)量管理標(biāo)準(zhǔn)和軟件項(xiàng)目過(guò)程標(biāo)準(zhǔn)兩類。有兩種同行評(píng)審方法學(xué)：審查和走查。第一篇：軟件測(cè)試 填空題軟件質(zhì)量工程包括軟件質(zhì)量保證、軟件質(zhì)量規(guī)劃和軟件質(zhì)量控制三大方面。RMA可以劃分成三組類別 內(nèi)部風(fēng)險(xiǎn)管理措施，分包風(fēng)險(xiǎn)管理措施，顧客風(fēng)險(xiǎn)管理措施支持性質(zhì)量手段有模板和檢查表。軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性、軟件缺陷的感染性。1典型的版本方針包括嚴(yán)格單一活動(dòng)版本方針、多版本方針。1軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。2軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過(guò)程的軟件維護(hù)兩大方面。2在任何機(jī)構(gòu)中，CAPA要正確發(fā)揮作用需要蹤、CAPA執(zhí)行的跟蹤和CAPA執(zhí)行結(jié)果的跟蹤三個(gè)要的跟蹤任務(wù)。通常，軟件質(zhì)量的管理部件有項(xiàng)目進(jìn)展控制、軟件質(zhì)量度量、軟件質(zhì)量費(fèi)用和可用于控制軟件維護(hù)的工具SQA管理工具。3軟件測(cè)試規(guī)范可以分為行業(yè)規(guī)范和操作規(guī)范。3為了考察測(cè)試用例的重要性，我們可以從有效性、可重用性、易組織性、可評(píng)估性、可管理性五方面理解。4我們可以按照 編寫過(guò)程、執(zhí)行 過(guò)程和 組織過(guò)程三個(gè)緯度對(duì)測(cè)試用例屬性進(jìn)行歸類。、面向?qū)ο竽Ｐ筒煌谄渌Ｐ偷闹饕卣魇墙M件的密集重用。5依據(jù)軟件系統(tǒng)的生命周期和其他階段，軟件質(zhì)量度量劃分為軟件過(guò)程度量 和軟件產(chǎn)品度量。5McCall模型劃分了軟件運(yùn)行、軟件轉(zhuǎn)移、軟件修改三個(gè)緯度的11個(gè)軟件質(zhì)量因素。、軟件對(duì)屬于各種質(zhì)量因素的需求的符合性是由軟件質(zhì)量度量來(lái)測(cè)量的。6從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成認(rèn)證標(biāo)準(zhǔn)和評(píng)估標(biāo)準(zhǔn)兩種類型。6開發(fā)生命周期階段SQA部件可以劃分成三類：評(píng)審、專家觀點(diǎn)、軟件測(cè)試、軟件維護(hù)SQA部件和由第三方/分包商使用的SQA部件。70、軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。7測(cè)試階段的基本任務(wù)是根據(jù)軟件開發(fā)各階段的 文檔資料和程序的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)一組 測(cè)試用例，利用這些實(shí)例執(zhí)行程序，找出軟件中潛在的各種錯(cuò)誤和 缺陷。根據(jù) 測(cè)試用例的設(shè)計(jì)方法不同，動(dòng)態(tài)測(cè)試又分為 黑盒測(cè)試與白盒測(cè)試兩類。8黑盒法只在軟件的 接口處進(jìn)行測(cè)試，依據(jù) 需求規(guī)格說(shuō)明書，檢查程序是否滿足 功能要求。8實(shí)際的邏輯覆蓋測(cè)試中，一般以 條件組合覆蓋為主設(shè)計(jì)測(cè)試用例，然后再補(bǔ)充部分用例，以達(dá)到 路徑覆蓋測(cè)試標(biāo)準(zhǔn)。90、等價(jià)類劃分從程序的功能說(shuō)明，找出一個(gè)輸入條件（通常是一句話或一個(gè)短語(yǔ)），然后將每個(gè)輸入條件劃分成兩個(gè)或多個(gè) 等價(jià)類。9因果圖的基本原理是通過(guò)畫因果圖，把用自然語(yǔ)言描述的 功能說(shuō)明轉(zhuǎn)換為判定表，最后為判定表每一列設(shè)計(jì)一個(gè)測(cè)試用例。9單元測(cè)試 指對(duì)源程序中每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)模塊是否正確實(shí)現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法中的錯(cuò)誤，它涉及編碼和 詳細(xì)設(shè)計(jì)的文檔。9集成測(cè)試指在單元測(cè)試基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成一個(gè)完整的系統(tǒng)進(jìn)行的測(cè)試。10自頂向下漸增式測(cè)試不需要編寫驅(qū)動(dòng)模塊，只需要編寫樁模塊，其步驟是從模塊開始，沿著被測(cè)程序的頂層的控制路徑逐步向下測(cè)試，它有兩種組合策略：軟件結(jié)構(gòu)圖和深度優(yōu)先策略寬度優(yōu)先策略。10確認(rèn)測(cè)試開始前需要制定測(cè)試計(jì)劃，結(jié)束后要寫出測(cè)試分析報(bào)告。10調(diào)試技術(shù)包括簡(jiǎn)單調(diào)試歸納法調(diào)試演繹法調(diào)試回溯法調(diào)試10回溯法調(diào)試是從程序產(chǎn)生錯(cuò)誤的地方出發(fā)，而歸納法調(diào)試是從測(cè)試結(jié)果發(fā)現(xiàn)的線索入手。11在單元測(cè)試時(shí)，需要為被測(cè)模塊設(shè)計(jì)驅(qū)動(dòng)模塊與樁模塊。11動(dòng)態(tài)測(cè)試中，主要測(cè)試軟件功能的方法稱為黑盒法。12憑經(jīng)驗(yàn)或直覺(jué)推測(cè)程序中可能存在的錯(cuò)誤而設(shè)計(jì)測(cè)試用例的方法是錯(cuò)誤推測(cè)法。12軟件配置管理，簡(jiǎn)稱SCM，它用于整個(gè)軟件工程過(guò)程。第二篇：軟件測(cè)試（推薦）一、簡(jiǎn)答5*6’表面上看這體現(xiàn)了管理的效率和靈活性，但實(shí)際上也體現(xiàn)了管理者對(duì)測(cè)試的輕視。因此，我們要盡可能的選擇最合適的測(cè)試量，把風(fēng)險(xiǎn)降低到最小 從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒(méi)有必要修復(fù)所有的軟件缺陷。在任何一個(gè)項(xiàng)目中，通常情況下開發(fā)人員和測(cè)試人員都是不夠用的，而且在項(xiàng)目中沒(méi)有預(yù)算足夠的回歸測(cè)試時(shí)間，修改缺陷可能引入新的缺陷。缺陷是否修改要由軟件測(cè)試人員、項(xiàng)目經(jīng)理、程序員共同討論來(lái)決定是否修復(fù)，不同角色的人員從不同的角度來(lái)思考，以做出正確的決定。 測(cè)試要注意下面的事項(xiàng)：（1）用戶現(xiàn)場(chǎng)測(cè)試不可能測(cè)試全部功能，因此要測(cè)試核心功能。（2）如果某些模塊確實(shí)有問(wèn)題，我們可以演示其它重要的業(yè)務(wù)功能模塊，必要時(shí)要向用戶做成合理的解釋。主要有以下原因：完全測(cè)試比較耗時(shí)，時(shí)間上不允許；完全測(cè)試通常意味著較多資源投入，這在現(xiàn)實(shí)中往往是行不通的；輸入量太大，不能一一進(jìn)行測(cè)試；輸出結(jié)果太多，只能分類進(jìn)行驗(yàn)證；軟件實(shí)現(xiàn)途徑太多；軟件產(chǎn)品說(shuō)明書沒(méi)有客觀標(biāo)準(zhǔn)，從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同；因此測(cè)試的程度要根據(jù)實(shí)際情況確定 其中的原因主要如下：代碼復(fù)用、拷貝代碼導(dǎo)致程序員容易犯相同的錯(cuò)誤。如果軟件編寫的比較好，這種現(xiàn)象就不常見(jiàn)了。測(cè)試人員的主要工作是測(cè)試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評(píng)審，測(cè)試工作也是測(cè)試保證人員的工作對(duì)象。通常產(chǎn)品的質(zhì)量要高一些，修復(fù)發(fā)布后產(chǎn)品的缺陷成本較高，甚至?xí)?lái)很多負(fù)面的影響。同時(shí)由于質(zhì)量要求高，因此會(huì)投入較多的人力、物力資源。總之，外部測(cè)試報(bào)告要小心謹(jǐn)慎的編寫。如果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問(wèn)題，這說(shuō)明此軟件開發(fā)過(guò)程很可能是有缺陷的。1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒(méi)做不該做的事情，這會(huì)使測(cè)試更加全面，更容易發(fā)現(xiàn)問(wèn)題。軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過(guò)程決定的。④對(duì)一些實(shí)時(shí)應(yīng)用，要進(jìn)行精心設(shè)計(jì)和技術(shù)處理，保證精確的時(shí)間同步，否則容易引起時(shí)間上不協(xié)調(diào)，不一致性帶來(lái)的問(wèn)題。⑦由于通信端口多、存取和加密手段的矛盾性等，會(huì)造成系統(tǒng)的安全性或適用性等問(wèn)題。對(duì)于設(shè)計(jì)或編程上的一些假定或依賴性，相關(guān)人員沒(méi)有充分溝通。計(jì)算和精度問(wèn)題：計(jì)算的結(jié)果沒(méi)有滿足所需要的精度。系統(tǒng)分析時(shí)對(duì)客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。①繪制示意圖②闡述每個(gè)步驟是做什么 需求分析即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項(xiàng)功能概要設(shè)計(jì)主要是架構(gòu)的實(shí)現(xiàn)，指搭建架構(gòu)、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實(shí)現(xiàn)等項(xiàng)事務(wù)。集成測(cè)試經(jīng)過(guò)了單元測(cè)試后，將各單元組合成完整的體系，主要測(cè)試各模塊間組合后的功能實(shí)現(xiàn)情況，以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。第三篇：軟件測(cè)試復(fù)習(xí)資料1． 黑盒測(cè)試法是通過(guò)分析程序的功能來(lái)設(shè)計(jì)測(cè)試用例的方法。5． 軟件測(cè)試中常用的靜態(tài)分析方法是引用分析和接口分析。白盒測(cè)試是根據(jù)程序的內(nèi)部邏輯來(lái)設(shè)計(jì)測(cè)