【正文】 進(jìn)行一系列的測試。9． 集成測試：在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成為系統(tǒng)，應(yīng)提交集成測試計劃、集成測試規(guī)格說明和集成測試分析報告。8． 單元測試（模塊測試）：針對每個模塊進(jìn)行的測試，可從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，多個模塊可以平行地對立地測試。6． 路徑覆蓋的含義是，選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。白盒測試是把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過程，由于白盒測試是一種結(jié)構(gòu)測試，所以被測對象基本上是源程序，以程序的內(nèi)部邏輯和指定的覆蓋標(biāo)準(zhǔn)確定測試數(shù)據(jù)。3． 動態(tài)測試 通過運(yùn)行軟件來檢驗軟件的動態(tài)行為和運(yùn)行結(jié)果的正確性。1． 缺陷報告是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟地集合。11． 軟件測試按照測試技術(shù)劃分性能測試、負(fù)載測試、壓力測試、恢復(fù)測試、安全測試、兼容測試12． 靜態(tài)測試基本特征是在對軟件進(jìn)行分析、檢查和審閱，不實際運(yùn)行被測試的軟件 13． 軟件測試項目周期是指需求階段、測試計劃、階段測試、設(shè)計階段測試、執(zhí)行階段 14． 軟件測試的角色分析人員、設(shè)計人員、開發(fā)人員、執(zhí)行人員 15． 軟件測試原則有制定嚴(yán)格的測試計劃、保留所有的測試文檔、功能測試中的缺陷確認(rèn)16． 測試工作的文檔主要有：測試計劃、測試模型和用例設(shè)計或規(guī)格說明、測試分析報告等17． 測試計劃的制定必須要注重測試策略、測試范圍、測試方法、測試安排、測試風(fēng)險、測試治理18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設(shè)計的缺陷、靜態(tài)文檔的缺陷、軟件開發(fā)引起的缺陷、短視將來的缺陷 19． 測試用例工作主要是如何添加測試用例、如何編寫測試用例、將測試用例和需求關(guān)聯(lián)20． 自動化測試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設(shè)計階段的BUG、實現(xiàn)階段的BUG、配置階段的BUG、靜態(tài)文檔的BUG。9． 軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種類型。7． 設(shè)計系統(tǒng)測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。5． 編寫測試用例的依據(jù)是單元測試計劃和詳細(xì)設(shè)計說明書。3． 軟件測試主要分為單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試四類測試。1． 測試階段的根本目標(biāo)是盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯誤，最終把一個高質(zhì)量的軟件系統(tǒng)交給用戶使用。白盒測試是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例,黑盒測試是根據(jù)軟件的規(guī)格說明來設(shè)計測試用例。14． 正式的技術(shù)評審FTR（Formal Technical Review）是軟件質(zhì)量保證活動，其相關(guān)的描述為： 15． 在進(jìn)行單元測試時，常用的方法是采用白盒測試，輔之以黑盒測試16． 側(cè)重于觀察資源耗盡情況下的軟件表現(xiàn)的系統(tǒng)測試被稱為壓力測試 17． 必須要求用戶參與的測試階段是驗收測試 18． 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。5． 軟件測試中常用的靜態(tài)分析方法是引用分析和接口分析。3． 白盒測試除了測試程序外，它也適用于對軟件具體設(shè)計階段的軟件文檔進(jìn)行測試。第三篇：軟件測試復(fù)習(xí)資料1． 黑盒測試法是通過分析程序的功能來設(shè)計測試用例的方法。系統(tǒng)測試經(jīng)過了單元測試和集成測試以后，我們要把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運(yùn)行是否存在漏洞，等。集成測試經(jīng)過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現(xiàn)情況，以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。軟件編碼按照詳細(xì)設(shè)計好的模塊功能表，編程人員編寫出實際的代碼。①繪制示意圖②闡述每個步驟是做什么 需求分析即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能概要設(shè)計主要是架構(gòu)的實現(xiàn)，指搭建架構(gòu)、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實現(xiàn)等項事務(wù)。開發(fā)流程不夠完善，存在太多的隨機(jī)性和缺乏嚴(yán)謹(jǐn)?shù)膬?nèi)審或評審機(jī)制，容易產(chǎn)生問題。系統(tǒng)分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問題。計算和精度問題：計算的結(jié)果沒有滿足所需要的精度。算法錯誤：在給定條件下沒能給出正確或準(zhǔn)確的結(jié)果。對于設(shè)計或編程上的一些假定或依賴性，相關(guān)人員沒有充分溝通。團(tuán)隊工作：系統(tǒng)需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。⑥系統(tǒng)運(yùn)行環(huán)境的復(fù)雜，不僅用戶使用的計算機(jī)環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實際應(yīng)用中，數(shù)據(jù)量很大。④對一些實時應(yīng)用，要進(jìn)行精心設(shè)計和技術(shù)處理，保證精確的時間同步，否則容易引起時間上不協(xié)調(diào)，不一致性帶來的問題。②系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計成一個很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護(hù)、擴(kuò)充上的困難；即使設(shè)計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的。–至今－預(yù)防為主 預(yù)防為主是當(dāng)下軟件測試的主流思想之一。1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發(fā)現(xiàn)問題。愛國者導(dǎo)彈防御系統(tǒng)把“槍口”對準(zhǔn)了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統(tǒng)性能問題 1957年之前－調(diào)試為主 20世紀(jì)50年代，計算機(jī)剛誕生不久，只有科學(xué)家級別的人才會去編程，需求和程序本身也遠(yuǎn)遠(yuǎn)沒有現(xiàn)在這么復(fù)雜多變，相當(dāng)于開發(fā)人員一人承擔(dān)需求分析，設(shè)計，開發(fā)，測試等所有工作，當(dāng)然也不會有人去區(qū)分調(diào)試和測試。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的回饋信息，為風(fēng)險評估所準(zhǔn)備的信息?？傊?，外