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