第四章 軟件測試過程,4.1 軟件測試階段 4.2 軟件測試生命周期和軟件測試的流程 4.3 軟件測試步驟 4.4 單元測試(模塊測試、邏輯測試、結構測試) 4.5 集成測試(組裝測試、聯合測試) 4.6 系統測試本章小結,軟件測試貫穿于整個軟件生命周期，是對軟件產品(包括階段性產品)進行驗證和確認的全過程。測試工作滲透到從分析、設計、編程、使用等生命周期的各個階段中。本章簡單介紹軟件測試的過程和步驟。,軟件開發經過制定計劃、需求分析、設計階段之后，就進入編程階段。程序中的Bug，并不一定由編碼所引起，很可能是由詳細設計、概要設計階段，甚至是由需求分析階段的問題引起，即使針對源程序進行測試，所發現Bug的根源也可能在軟件開發前期的各個階段。定位、解決、排除Bug也可能需要追溯到前期的工作。因此，測試應貫穿于軟件定義和開發的整個生命周期中。,4.1 軟件測試階段,1軟件測試的工作流程 測試的工作流程與公司的整體工作流程、項目的測試要求等因素相關。圖4.1為軟件測試的一般工作流程。從圖4.1可以看出軟件測試經歷了5個過程。,圖4.1 軟件測試的工作流程,2測試過程中的數據 測試過程中所用的數據可分為正常數據、錯誤數據和邊緣數據： (1) 正常數據：在測試中所用的正常數據的量是最大的，而且也是最關鍵的。人們要從中提取出一些具有高度代表性的數據作為測試數據，以減少測試時間。 (2) 錯誤數據：錯誤數據是編寫與程序輸入規范不符的數據，從而檢測程序輸入、篩選、錯誤處理等程序的分支。,(3) 邊緣數據：介于正常數據和錯誤數據之間的一種數據。它可以針對某一種編程語言、編程環境或特定的數據庫而專門設定。如若使用SQL Server數據庫，則可把SQL Server關鍵字(如：; AS;Join等)設為邊緣數據。其他邊緣數據如：HTML的HTML ; 等關鍵字以及空格、負數、超長字符等。邊緣數據要靠測試人員的豐富經驗來制訂。,3測試過程中的信息流 圖4.2為測試過程中的信息流。其中， 軟件配置：軟件需求規格說明、軟件設計規格說明、源代碼等。 測試配置：測試計劃、測試用例、測試程序等。 測試工具：測試數據自動生成程序、靜態分析程序、動態分析程序、測試結果分析程序以及驅動測試的測試數據庫等。 測試結果分析：比較實測結果與預期結果，評價Bug是否發生。,排錯(調試)：對已經發現的Bug進行Bug定位和確定出錯性質，并改正這些Bug，同時修改相關的文檔。 回歸測試：修正Bug后再測試，直到通過測試為止。 可靠性：通過收集和分析測試結果數據，對軟件建立可靠性模型。利用可靠性分析評價軟件質量，即軟件的質量和可靠性達到可以接受的程度。 如果測試發現不了Bug，就可以肯定測試配置考慮得不夠細致充分，Bug仍然潛伏在軟件中，則所做的測試不足以發現嚴重的Bug。,圖4.2 測試信息流,4測試階段劃分 按照測試流程，將測試工作劃分為計劃(指進行測試計劃)、設計(指進行測試設計)和執行(含評價、執行測試并判別結果、評價測試效果和被測試軟件)等幾個階段。 可以從三個不同的角度將測試劃分為多個階段： (1) 面向測試操作類型的劃分：調試、集成、確認、驗證、組裝、驗收、操作等。 (2) 面向測試對象粒度的劃分：語句、結構、單元、部件、配置項、子系統、系統、大系統等。 (3) 面向測試實施者的劃分：開發者、測試者、驗收者、使用者等。,每個測試階段一般都要經歷以下步驟：測試需求分析、測試過程設計、測試實現和實施、測試評價、測試維護。詳細敘述如下： 測試需求分析：測試需求是整個測試過程的基礎，主要確定測試對象以及測試工作的范圍和作用。 測試過程設計：包括測試計劃、測試策略制定、測試時間安排、測試用例編寫等。 測試實現：包括配置環境、制作新的版本、培訓測試人員等。, 測試實施：已經按照測試計劃進行展開，如手工測試、自動化測試等。 測試評價：對版本測試覆蓋率、測試質量、人員測試工作以及前期的一些工作制定情況進行評價、評估。 測試維護：對測試用例庫、測試腳本、Bug庫等進行維護、保證延續性等。 測試工作的組織與管理：制定測試策略、測試計劃，確認所采用的測試方法與規范、控制測試進度、管理測試資源。 測試工作的實施：編制符合標準的測試文檔，搭建測試環境，開發測試腳本，與開發組織協作實現各階段的測試活動。,5角色和職責 1) 測試設計員 制定和維護測試計劃。 設計測試用例及測試過程。 評估測試，生成測試分析報告。 2) 測試員 執行集成測試和系統測試。 記錄測試結果。,3) 設計員：設計測試需要的驅動程序和穩定樁。 4) 編碼員 編寫測試驅動程序和穩定樁。 執行單元測試。 6軟件測試的基本活動 軟件測試是一個極為復雜的工作，通常包括以下基本測試活動： 擬定測試計劃和編制測試大綱。, 確定和建立必要的測試環境。 設計和生成測試用例，按照所寫的測試用例，編寫測試腳本。 根據測試對象和目的，構造測試用例集合。 運行測試腳本或手工按測試用例進行。 記錄測試結果。 結果比較分析，找出軟件Bug。 跟蹤和管理軟件Bug。 將軟件Bug記錄到Bug數據庫，清楚描述該Bug。 驗證被處理的軟件Bug，并進行回歸測試。, 對測試過程進行管理，保證測試工作執行的準確性，實現資源調撥和相關合作方的協調，對測試中的問題進行全程跟蹤。 生成測試報告。,7軟件測試的主要過程 一般軟件測試的主要過程為計劃配置開發測試執行。其中， 配置：指軟、硬件資源的設置。 開發：指構造或配置測試工具、創建測試套件和測試方案庫、準備適當的報告工具并記錄測試系統如何運行。 測試執行：指進行測試、記錄測試條件和Bug以及報告結果。,8動態測試的一般過程 軟件動態測試的一般過程如圖4.3。其中，測試過程有兩類輸入：軟件配置和測試配置。 軟件配置包括軟件需求規約、設計規約、源代碼等。 測試配置包括測試計劃、測試用例、測試工具等。最核心的過程是生成測試用例、運行程序(測試)和驗證程序的運行結果(評估)。,圖4.3 軟件動態測試過程示意圖,一般而言，軟件測試的全過程指測試工作從項目確立時就開始，貫穿于軟件生命周期，前后要經過以下主要過程： 需求分析測試計劃測試設計測試場景設計測試執行測試報告Bug管理評估RTM軟件系統組成總結和維護 說明： (1) 以上流程各過程并未包含測試過程的全部，如根據實際情況還可以實施一些測試計劃評審、用例評審、測試培訓等。在軟件正式發行后，還需要進行一些后續維護測試等。當遇到一些嚴重Bug時，需要召開審查會等。,(2) 以上各過程并不是獨立的，實際工作千變萬化，各過程之間有一些交織、重疊在所難免，如編寫測試用例的同時就可以進行測試環境的搭建工作，當然也可能由于一些需求不清楚而重新進行需求分析等。在實際測試過程中要做到具體問題具體分析、具體解決。 (3) 一般而言，需求分析、測試用例編寫、測試環境搭建、測試執行等屬于測試開發人員工作范疇，而測試執行以及Bug提交等屬于普通測試人員的工作范疇，測試負責人負責整個測試各個過程的Bug的跟蹤、測試實施和管理等。,下面詳細介紹軟件測試的全過程。 1) 需求調研、分析 一般而言，需求分析包括軟件功能需求分析、測試環境需求分析、測試資源需求分析等，其中最基本的是軟件功能需求分析。經過需求調研分析后編寫需求規格說明書，它是整個開發過程的基線。當系統分析員完成了需求分析，他將提交需求規格說明書。測試人員根據在需求調研階段獲取的對需求的理解審查整個文檔，檢查文檔是否覆蓋了所有需求。,2) 測試計劃 測試計劃一般由測試負責人來編寫。測試計劃的依據主要由項目開發計劃和測試需求分析結果而制定。測試過程與整個軟件開發過程基本上是平行進行。測試計劃早在需求分析階段就應開始制定。其他相關工作，包括測試大綱的制定、測試數據的生成、測試工具的選擇和開發等也應在測試階段之前進行。充分的準備工作可以有效克服測試的盲目性，縮短測試周期，提高測試效率，并且可以起到開發文檔與測試文檔互查的作用。,3) 測試設計 測試設計主要包括測試大綱、審查設計文檔、測試用例編寫： (1) 測試大綱。測試大綱是測試的依據，它明確、詳盡規定了在測試中針對系統的每一項功能或特性所必須完成的基本測試項目和測試完成的標準。無論是自動測試還是手動測試，都必須滿足測試大綱的要求。 (2) 審查設計文檔。在系統設計階段，測試人員要理解系統是怎樣實現的。這個階段的開發文檔包括概要設計、數據庫設計、功能說明以及詳細設計等。測試人員審查這些文檔，檢查這些計劃與設計是否合理。如果不合理，問題在哪里、怎樣改進等。,(3) 設計和生成測試用例。在計劃測試時，需要將整個系統分解。正確劃分子系統可以降低測試的復雜性，減少重復與冗余，更加方便設計測試用例。 設計測試用例是一件非常細致的工作。通常每個用例需要包括：序號和標題、用例說明、測試優先級、測試輸入及測試步驟、期望輸出與實際輸出(當執行測試時，它被用來記錄測試的結果)。測試用例設計要考慮以下幾點：覆蓋率(要達到最大覆蓋軟件系統功能的功能點)、數量(一個多于半年的開發周期，用例不得少于4000個)、使用管理工具軟件等。,4) 測試場景設計 測試場景設計主要是測試環境問題。測試環境對測試很重要，為了測試軟件，人們可能根據不同的需求使用很多不同的測試環境。有些測試環境人們可以搭建，有些環境人們無法搭建或者搭建的成本很高。不同軟件產品對測試環境有著不同的要求，符合要求的測試環境能夠幫助人們準確的找出軟件Bug，并且做出正確的判斷。 測試環境是一個確定、可以明確說明的條件，不同的測試環境可以得出對同一軟件的不同測試結果，這說明測試并不完全是客觀的行為，任何一個測試的結果都是建立在一定的測試環境之上。,測試環境中特別需要明確說明的是測試人員的水平，包括專業上、計算機操作的能力以及與被測試程序的關系，這種說明還要在評測人員對評測對象做出的判斷的權值上有所體現。這就要求測試機構建立測試人員檔案庫，并對其參與測試的工作業績不斷做出評價。 測試計劃是可以變動的。一份計劃做得再好，當實際實施時就會發現往往很難按照原有計劃開展。如在軟件開發過程中資源匱乏、人員流動等都會對測試過程和測試結果造成一定的影響。所以，就要求測試負責人能夠從宏觀上來實時調控和修改測試計劃。,5) 測試實施、執行 當以上的準備工作完成后，系統開發也進入到尾期。測試人員可以根據前面的測試計劃和測試用例逐個實施測試。每一個獨立的軟件部分要接受單元測試，若干個部分組合起來接受集成測試。當所有的軟件產品完成后要接受系統測試，系統測試是保證整個系統符合用戶需求。而性能測試也是必不可少的，保證軟件的各個部分滿足需求的性能標準。 測試執行階段是由一系列不同的測試類型的執行過程組成，每種測試類型都有其具體的測試目標和支持技術，,每種測試類型都只側重于對測試目標的一個或多個特征、或屬性進行測試，準確的測試類型可以給測試帶來事半功倍的效果。具體的測試實施過程分為四個階段：單元測試集成測試系統測試出廠測試，其中每個階段還要進行回歸測試等。 從測試的角度而言，實施測試包括一個量和度的問題，也就是測試范圍和測試程度的問題。比如一個版本需要測試哪些方面？每個方面要測試到什么程度等？,從管理的角度而言，在有限的時間、有限人員甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來開展測試。還要考慮以下問題： 當測試人員執行測試不到位、測試不認真時該如何解決？ 怎樣提高測試效率； 根據版本的不同特點是只做驗證測試還是采取冒煙測試，或是系統全面測試？ 當測試過程中遇到一些偶然性、隨機性問題該怎樣處理？ 當版本中出現很多新問題時該怎樣對待？ 測試停止標準是什么？,總之，測試執行過程中可能會遇到很多復雜的問題，要具體問題具體解決。 6) 測試記錄 生成測試報告，即Bug記錄，分為軟件Bug報告和測試結果報告。一般測試Bug報告中要包含對項目的概述、測試的功能點(可以目錄形式列出)、Bug在功能點的分布(可用柱狀或餅狀圖表示)、Bug按嚴重等級劃分的百分比，以及是否通過本次測試的結論。,Bug記錄一般包括兩方面：由誰提交和Bug描述。一般而言，Bug都是誰測試誰提交。當然有些公司為了保證所提交Bug的質量，還會在提交前進行Bug評估，以確保所提交的Bug的準確性。Bug記錄格式見表4.1。,表4.1 Bug記錄格式,在實際提交Bug時可以根據實際情況進行補充，如可以附上圖片、log文件等。另外，一個版本測試完畢還要根據測試情況給出測試報告。,7) Bug管理、測試維護和軟件評估 (1) Bug管理：很多公司都利用Bug管理工具來進行管理。常見Bug管理工具有Test Director、Bugfree等。 (2) 測試維護。由于實際測試的不完全性，當軟件正式發布后，客戶發現的問題需要修改，修改后需要進行回歸測試，再次對軟件進行測試、評估、發布。 (3) 軟件評估。軟件評估指軟件經過一輪又一輪測試后，確認軟件無重大問題或者問題很少的情況下，,對準備發給客戶的軟件進行評估，以確定是否能夠發行給客戶或投放市場。軟件評估小組一般由項目負責人、營銷人員、部門經理等組成，也可能由客戶指定的第三方人員組成。 主要的三類評估： 測試工作估計。測試工作估計包括對工作量、資源和成本的估計。估計一般使用類比法、經驗法、模型法等。項目負責人可以根據被測試軟件的需求規格說明或者詳細設計計劃，進行工作量估計。也可以根據選用的測試方法、測試環境、被測試軟件的工作特性以及對工作量的估計提出資源需求。, 設計評審。從測試的視角看，設計評審非常重要，通過全面評審軟件設計內容，可以在軟件開發的早期發現一些潛在與性能和安全性有關的Bug。如果這些Bug在編程階段才被發現，則修正Bug耗費的時間將比設計階段修改Bug長得多。 實現代碼評審。在實現代碼評審階段，從詳細測試計劃文檔中執行測試用例，對軟件的代碼進行審閱，這是單元測試的重要步驟。通過代碼評審，可以在軟件開發的早期發現Bug。,(4) 測試系統組成。讓軟件測試趨于規范建立測試管理體系。測試系統主要由下面六個相互關聯、相互作用的過程組成：測試規劃、測試設計、測試實施、配置管理、資源管理、測試管理。測試實施階段是由一系列的測試周期組成。在每個測試周期中，測 試工程師將依據預先編制好的測試方案和準備好的測試用例，對被測試軟件進行完整測試。 (5) 測試總結。每個版本有各自的測試總結，每個階段有各自的測試總結。,當項目完成后，一般要對整個項目作回顧總結，檢查有哪些做得不足的地方，有哪些經驗可以對今后的測試工作起借鑒作用等。測試總結沒有嚴格格式和字數限制等。 (6) 測試維護。由于測試的不完全性，當軟件正式發布后，客戶在使用過程中，難免遇到一些問題，有的甚至是嚴重性的問題，這就需要修改有關問題，修改后需要再次對軟件進行測試、評估、發布，這個過程就是測試維護。,9. 測試與軟件開發各階段的關系 軟件開發過程是一個自頂向下、逐步細化的過程。軟件計劃階段定義軟件作用域。軟件需求分析建立軟件信息域、功能和性能需求、約束等。軟件設計是把設計結果用某種程序設計語言轉換成程序代碼。測試過程是依相反順序安排的自底向上，逐步集成的過程(見圖4.4)。,圖4.4 軟件測試與軟件開發各階段之間的關系,軟件測試在軟件生存周期中橫跨兩個階段： (1) 通常在編寫完成每一個模塊之后就對它進行必要的軟件測試(即單元測試)，編碼和單元測試屬于軟件生存期中的同一個階段；,4.2 軟件測試生命周期和軟件測試的流程,(2) 在結束這個階段后對軟件系統還要進行各種綜合測試，這是軟件生存期的另一個獨立階段，即軟件測試階段。,4.2.1 軟件測試的生命周期 軟件測試生命周期歸納為7個階段：計劃、分析、設計、構建、周期測試、測試與實施以及實施后期。 1計劃(即產品定義階段) 高層次的測試計劃(包含多重測試周期)。 質量保證計劃(質量目標，測試標準等)。 確定計劃評審的時間。 報告問題過程。 確定問題的分類。 確定項目質量度量。, 確定驗收標準提供給質量保證員和用戶。 確定衡量標準，如Bug數量/嚴重程度和Bug起源等。 建立應用程序測試數據庫。 開始制定項目整體測試時間表(包括時間、資源等)。 評審產品定義文檔，在文檔中加入質量保證標準，作為工程改善進程的一部分。 數據庫管理所有測試用例，包括手工方面或自動化方面。 大約每月要花費510小時。,2分析(外部文檔階段) 根據業務需求開發功能驗證矩陣。 制定測試用例格式，包括估計時間和分配優先級等。 制定測試周期矩陣與時間線。 根據功能驗證矩陣開始編寫測試用例。 根據業務需求，計劃測試用例基準數據。 確定用于自動化測試的測試用例。 自動化團隊開始在測試工具中創建變量文件和高層次的測試腳本。 為自動化系統中的跟蹤組件設置路徑和自動化引導。, 界定壓力和性能測試的范疇。 按照每個測試用例的數據，要求開始建立基準數據庫。 定義維護基準數據庫的過程，即備份、恢復、驗證。 建立反饋機制并錄入文檔。 規劃項目所需的測試周期數和回歸測試次數。 文檔復查，如功能設計文檔、業務需求文檔、產品規格說明書、產品外部文檔等。, 審查測試環境和實驗室，前端與后端系統都要審查。 準備使用McCabe工具，以支持白盒測試中代碼的研發和復雜性分析。 必需階段審查外部文件。 該文檔中加入質量保證標準，作為工程改善進程的一部分。 根據群體執行反饋編寫測試用例。 開始研制測試用例估計數目、每個用例的執行時間和用例是否自動化這些方面度量。, 為每個測試用例確定基準數據。 大約每月要花25小時。,3設計(即文檔架構階段) 根據變更修改測試計劃。 修改測試周期矩陣和時間線。 核實測試計劃和用例用到的數據并輸入到數據庫。 修改功能驗證矩陣。 繼續編寫測試用例，根據變化添加新的用例。 規范自動化測試和多用戶測試的細節。 挑選出一套用于自動化測試的測試用例，并且把這些用例腳本化。, 規范壓力測試和性能測試的細節。 最終確定測試周期。根據測試用例的估計時間和優先權確定每個周期所用的測試用例數。 制定風險評估標準。 最終確定的測試計劃。 估計單元測試所需資源。 必需階段，審查架構文件。 該文檔中加入質量保證標準，作為工程改善進程的一部分。, 確定要進行編碼的實際組件或模塊。 定義單元測試標準，通過/失敗準則等。 列出所有要進行單元測試的模塊。 單元測試報告，報告進行單元測試后的模塊質量如何，白盒測試和黑盒測試都要包括輸入/輸出數據和所有決定點。,4構建(單元測試階段) 完成所有計劃。 完成測試周期矩陣和時間線。 完成所有測試用例。 完成第一套自動化測試用例的測試腳本。 完成壓力和性能測試的計劃。 開始壓力和性能測試。 McCabe工具支持：提供度量。 測試自動化測試系統，并修復Bug。 運行質量保證驗收測試套件，以確保軟件已經可以交給中心測試。,5周期測試/Bug修正(重復/系統測試階段) 測試周期一，執行第一套的測試用例(包括前端和后端)。 報告Bug。 Bug審核。 根據需求修改、增加測試用例。 測試周期二、測試周期三等。,6測試和實施(代碼凍結階段) 執行所有前端測試用例：人工和自動化。 執行所有后端測試用例：人工和自動化。 執行所有壓力和性能測試。 提供對正在進行的Bug跟蹤度量。 提供對正在進行的復雜性和設計的度量。 更新測試用例和測試計劃的估計時間。 文件測試周期，回歸測試，并更新相應文檔。,7實施后期 召開實施后評估會議以回顧整項工程。 準備最終的Bug報告和相關度量。 制定戰略以防止類似的問題在今后的項目中重復出現。 創建如何改進流程的計劃目標和里程碑，使用McCabe工具制作最后的報道和分析。自動化測試組： 審查測試用例以評估其他可用于自動化回歸測試的用例； 清理自動化測試用例和變量； 審查自動化測試和手工測試結果的整合過程； 測試實驗室和測試環境-清理測試環境，標記和存檔用過測試用例和數據，恢復測試儀器到原始狀態等。,4.2.2 軟件測試的流程 軟件測試是一個涉及軟件開發周期各階段的很多活動，其過程是循環的、周而復始的，并不是單一、有順次的。它的大致流程如下： 測試之初(原始狀態)測試需求測試設計測試設計故障管理測試計劃測試復查測試執行測試報告單元測試自動化測試性能測試提高測試技能總結回到起點。 為了詳細說明軟件的測試過程，圖4.5給出了軟件開發和處理整個流程。,圖4.5 軟件開發和處理流程,在軟件測試的整個流程中，每個階段都很重要。 下面3個圖都是描述軟件測試的生命周期流程圖。其中，圖4.6(a)為傳統的軟件測試生命周期，直到編碼結束以后才開始測試活動；圖4.6(b)為傳統并行的軟件測試生命周期，執行測試在編碼之后開始，測試計劃和設計與開發同步；圖4.7為軟件測試生命周期的全過程。,圖4.6 測試生命周期,圖4.7 軟件測試生命周期的全過程,測試時，每執行一次“輸入”，就要根據軟件的可靠性需求，對被測系統所表現出的“狀態”是否符合預期的“狀態”做出判斷。 軟件測試可以分為若干步驟(或階段)。,4.3 軟件測試步驟,1按流程順序將其分為6個步驟 (1) 文檔、代碼測試：由項目小組完成； (2) 單元測試：由項目小組完成； (3) 集成測試：由項目小組完成； (4) 系統測試：由專業測試小組完成； (5) 驗收測試：由用戶和開發商共同完成； (6) 安裝維護：由用戶和開發商共同完成。 這幾個步驟完全逆向檢測了軟件開發的各個階段。文檔代碼測試是對軟件文檔和代碼進行檢查和審閱，,此測試應貫穿于整個軟件開發生命周期中，尤其在開發早期，其作用比較顯著。單元測試主要測試程序代碼；集成測試主要對設計檢測；系統測試主要測試軟件功能；驗收測試主要對用戶需求檢測。但是，每個測試階段仍要對其他測試階段的測試內容加以測試，只是測試重點不同。 軟件項目一開始，測試就開始了，從產品的需求分析審查到最后的驗收測試、安裝測試結束，整個測試過程的步驟如圖4.8所示。,圖4.8 軟件測試步驟,2測試過程的螺旋圖表示 由于測試貫穿于軟件整個開發生命周期中，而且測試的各個階段是交叉的，為了說明測試過程，可以把軟件開發與測試過程表示成一個螺旋圖，如圖4.9所示。,圖4.9 軟件開發與測試全過程,3測試過程的一般表示 從螺旋線圖上可以把測試階段從系統中分離開來分析研究。用螺旋線表明的測試過程可以分成4個階段：單元測試、集成測試、確認測試和系統測試，見圖4.10。,圖4.10 軟件測試的4個階段,首先分別完成每個單元(模塊)的測試任務，以確保每個模塊能正常工作。單元測試大量地采用白盒測試方法，盡可能發現模塊內部的程序Bug。 然后，把已測試過的模塊組裝起來，進行集成測試。其目的在于檢驗與軟件設計相關的程序結構問題。這時較多的采用黑盒測試方法來設計測試用例。 完成集成測試后，要對開發工作初期制定的確認準則進行檢驗。確認測試是檢驗所開發的軟件能否滿足所有功能和性能需求的最后手段，通常均采用黑盒測試方法。,完成確認測試后，給出合格的軟件產品。但為了檢驗它能否與系統的其他部分(如硬件、數據庫及操作人員)協調工作，還需要進行系統測試。,4不同測試過程的代價 很多研究成果表明，無論何時做出修改都要進行完整的回歸軟件測試，在軟件生命周期中盡早地對軟件產品進行軟件測試將使效率和質量得到最好的保證。Bug發現的越晚，修改它所需的費用就越高，因此應該盡可能早的查找和修改Bug。美國質量保證研究所對軟件測試的研究結果表明，越早發現軟件中存在的Bug，開發費用就越低；在編碼后修改軟件Bug的成本是編碼前的10倍；在產品交付后修改軟件Bug的成本是交付前的10倍。圖4.11為不同測試階段軟件測試的代價。,圖4.11 不同測試階段的軟件測試費用,圖4.11摘自實用軟件度量，1991，它列出了準備軟件測試、執行軟件測試和修改Bug所花費的時間(以一個功能點為基準)，這些數據顯示：單元測試的成本效率大約是集成測試的兩倍，是系統測試的三倍(參見條形圖)。域軟件測試意思是在軟件投入使用后，針對某個領域所作的所有軟件測試活動。圖4.11說明盡可能早的排除盡可能多的Bug可以減少后期階段軟件測試的費用。,5測試過程的總體流程圖及不同階段的流程圖 按測試執行階段劃分主要包括：單元測試、集成測試、確認測試、系統測試、業務測試、壓力測試、性能測試、安裝測試、驗收測試等。其中，單元測試著重于軟件以源代碼形式實現的各個單元；集成測試著重于對軟件的體系結構的設計和構造；系統測試著重于把軟件、硬件和其他的系統元素集成在一起，根據軟件需求說明對已經建造好的系統進行測試；回歸測試著重于軟件的更改、更新后的測試。這四種測試是軟件全生命周期持續不斷的事情，而不是一個階段性的事情，并且要把測試概念的外延進一步擴大。,圖4.12為測試執行階段總體流程圖，特別集成測試和系統測試的反饋意見可能導致設計文檔(需求或數據庫)的修改。圖4.13為需求階段流程圖，圖4.14為設計編碼階段流程圖。其他階段的流程圖類似，這里就不介紹了。,圖4.12 軟件測試工作總體流程,圖4.13 需求階段流程圖,圖4.14 設計編碼階段工作流程,下面按照軟件測試步驟，對單元測試、集成測試、確認測試和系統測試作進一步說明。,單元測試的要點是進行單元模塊所有數據項的正確性、完善性測試，主要關注模塊的算法細節和模塊接口間流動的數據。單元測試可看作是編碼工作的一部分，應該由程序員完成。一般以白盒測試為主，輔以黑盒測試。單元級測試易于發現程序的Bug，易于達到完全代碼覆蓋率，減少測試費用與開發時間。,4.4 單元測試(模塊測試、邏輯測試、結構測試),單元測試需求所確定的是單元測試的內容，根據概要設計、詳細設計和軟件單元獲取。進行單元測試主要采用編程人員之間相互交叉測試，因為通常編程人員比較容易發現其他人員編寫代碼中的Bug，所以必須采用交叉測試。,1測試單元 測試單元定義是一個包括一個或多個計算機程序模塊及相應控制數據(如表格)、調用過程、操作過程的模塊集合，且該集合成員滿足下面條件： 所有模塊屬于同一個計算機程序系統。 集合中至少有一個模塊(新的或改變過的模塊)尚未完成單元測試。 所有模塊及相應數據和過程的集合是一個測試過程的唯一對象。,2單元測試定義 為了更清晰的了解單元測試，在單元測試前，先要明白以下幾個問題： 單元測試的目標：確保模塊被正確地編碼。 由誰去做：通常由程序人員測試。 怎樣去測試：功能測試可以用黑盒測試方法，代碼測試可用白盒測試方法。 什么時候可以停止：當程序員感到代碼沒有Bug時。 記錄：通常沒有記錄，人們在清楚以上問題后就可以編寫測試用例了。,單元測試是針對軟件設計中用源代碼實現的每一個基本單元程序模塊，進行正確性檢驗的測試工作，檢查各個程序模塊是否正確地實現了規定的功能，它所測試的內容包括單元的內部結構(如邏輯和數據流)以及單元的功能和行為。目的在于發現各個模塊內部可能存在的各種Bug。單元測試需要從程序內部結構出發設計測試用例，多個模塊可以平行、獨立地進行測試。,3單元測試采取的方法 單元測試一般運用白盒測試(控制流、數據流測試)，以路徑覆蓋為最佳測試準則，驗證單元實現的功能，而不需要知道程序是如何實現它們；有時也采用黑盒測試(等價類劃分、因果圖、邊值分析)等多種測試技術。黑盒測試關注的是單元的輸入與輸出，不是白盒測試的替代品，而是輔助白盒測試發現其他類型的Bug。,4單元測試要解決的問題 進行單元測試是為了證明這段代碼的行為和人們期望是否一致。單元測試在程序編碼中就已經進行。其內容包括：設計測試用例要測試哪幾方面的問題，針對這幾方面問題各自測試什么內容、測試的具體步驟、實用測試策略。,圖4.15 單元測試,通常單元測試由編碼人員自己來完成，因而有人認為編碼與單元測試合為一個開發階段。單元測試大多從程序的內部結構出發設計測試用例，即多采用白盒測試。多個程序單元可以并行地獨立開展測試工作。下面介紹單元測試要解決的問題和單元測試的步驟。 單元測試是要針對每個模塊的程序，解決以下五個問題，見圖4.15。,(1) 模塊接口測試：模塊接口測試是單元測試的基礎，只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。在開始單元測試時，應對通過被測試模塊的數據流進行測試。在模塊接口測試時，進行內外存交換時要考慮下列問題： 文件屬性是否正確。 OPEN與CLOSE語句是否正確。 緩沖區容量與記錄長度是否匹配。 在進行讀寫操作之前是否打開了文件。 在結束文件處理時是否關閉了文件。, 正文書寫/輸入錯誤。 I/O的Bug是否檢查并做了處理。 (2) 局部數據結構測試：在模塊工作過程中，其內部的數據能否保持其完整性，包括內部數據的內容、形式及相互關系不發生錯誤。主要檢查： 不正確或不一致的數據類型說明。 使用尚未賦值或尚未初始化的變量。 上、下溢出或地址Bug。 錯誤的初始值或錯誤的缺省值。 變量名拼寫Bug或書寫Bug。 全局數據對模塊的影響。,(3) 路徑測試：路徑條件指模塊的運行能否做到滿足特定的邏輯覆蓋。 在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發現由于計算錯誤、不正確的判定或不正常的控制流等產生的Bug。單元測試中常見的Bug有： 誤解的或不正確的算術優先級。 混合模式的運算Bug。 錯誤的初始化。 精確度不夠精確。 表達式的不正確符號表示。,針對判定和條件覆蓋，設計測試用例要能夠發現如下Bug： 不同數據類型的比較。 不正確的邏輯操作或優先級。 應當相等的地方由于精確度的Bug而不能相等。 正確的判定或不正確的變量。 不正確或不存在的循環終止。 當遇到分支循環時不能退出。 不適當的修改循環變量。 給出三點建議： 選擇適當的測試用例，對模塊中重要的執行路徑進行測試。, 應設計測試用例查找由錯誤的計算、不正確的比較或不正常的控制流而導致的Bug。 對基本執行路徑和循環進行測試可以發現大量的路徑Bug。 (4) Bug處理：在測試中，Bug處理的重點是模塊在工作中發生了Bug，其中的Bug處理方法是否有效。檢驗程序中的Bug處理可能面對的情況有： 對運行發生的Bug描述難以理解。 所報告的Bug與實際遇到的Bug不一致。 出錯后，在Bug處理之前就引起系統的干預。 對錯誤條件的處理正確與否。, 提供的Bug信息不足，以至于無法找到Bug的原因。 出錯的描述是否能夠對Bug定位。 (5) 邊界測試：邊界測試是單元測試的最后一步，采用邊界值分析法來設計測試用例，認真仔細地在為限制數據處理而設置的邊界處進行測試，看模塊是否能夠正常工作。 一些可能與邊界有關的數據類型，如數值、字符、位置、數量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低、等于、大于或小于確定的比較值。對這些地方要仔細地選擇測試用例，認真加以測試。,在邊界條件測試中，應設計測試用例檢查以下情況： 在n次循環的第0次、第1次、第n次是否有Bug。 運算或判斷中取最大值、最小值時是否有Bug。 數據流、控制流中等于、大于、小于確定的比較值是否出現Bug。 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。,5單元測試環境 由于被測模塊并不是一個獨立可運行的程序，因此需要構造該模塊的測試環境，要考慮它和外界的聯系，用一些輔助模塊去模擬與所測模塊相聯系的其他模塊。這些輔助模塊分為兩種: (1) 驅動模塊：用以模擬被測模塊的上級模塊。相當于被測模塊的主程序，它接收測試數據，把這些數據傳送給所測模塊，最后再輸出實測結果。 (2) 樁模塊(存根模塊)：用以代替所測模塊工作過程中調用的子模塊，,由被測模塊調用，它們僅作很少的數據處理，例如打印入口和返回，以便檢驗被測模塊與其下級模塊的接口。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不允許什么事情也不做。被測模塊、與它相關的驅動模塊和樁模塊共同構成了一個“測試環境”，如圖4.16所示。 圖4.16中設置了一個驅動模塊和3個樁模塊。驅動模塊在單元測試中接受測試數據，把相關數據傳送給被測模塊，啟動被測模塊，并打印出相應的結果。,圖4.16 單元測試工作環境,6單元測試步驟 單元測試步驟見圖4.17和表4.2。其中圖4.17(b)是采用白盒測試時的工作流程圖。,圖4.17 單元測試步驟,表4.2 單元測試步驟描述,7單元測試階段的主要數據流 在每個階段，每個基本活動都有其自身的輸入集和輸出集，其內容由一系列任務組成。所有活動的輸出集應當包含足夠的信息來創建至少以下兩個文件：測試設計說明和測試總結報告。圖4.18為單元測試階段的數據流。,圖4.18 單元測試階段的主要數據流,8執行單元測試 編程人員進行單元測試主要采用程序員之間交叉測試，因為通常編碼人員比較容易發現其他人員編寫代碼中的Bug，所以必須采用交叉測試。軟件測試工作由產品評測部擔任，需要項目組相關人員配合完成。 在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的Bug。此時基本路徑測試和循環測試是最常用且最有效的測試技術。,在單元測試過程中，一般認為單元測試應緊接在編碼后，當源程序編制完成并通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現各類Bug的可能性。在確定測試用例的同時，應給出期望結果。,9單元測試產生的工件清單 工件清單包括：軟件單元測試計劃、單元測試用例、測試過程、測試腳本、測試日志、測試評估摘要等。,10單元測試人員職責 軟件測試工作由產品評測部擔任，需要項目組相關人員配合完成。測試人員及其職責見表4.3。,表4.3 測試人員職責,11單元測試中測試工具的選擇 在結構化程序編程中，測試的對象主要是函數或者子程序過程；在面向對象的編程中，如Java/C+等語言，測試的對象可能是類，也可能是類的成員函數，或者是被典型定義的一個菜單、屏幕顯示界面或者對話框等等。由于單元測試的本質是針對代碼進行測試，所以，不同語言的程序需要選擇適合本身的單元測試工具。其實，有很多測試工具都支持單元測試。,如果能借助這些工具，可以極大地減少工作量，減少測試的盲目性，提高單元測試的覆蓋率和準確度。例如針對C和C+ 代碼，Logiscope、C+ Test、QA C+ 及Klocwork等測試工具可以很好地滿足測試要求；對于匯編語言，可以用AsmTester單元測試工具；對于Java 語言的單元測試過程，可以借助Junit單元測試包來完成。,在實際中，軟件的每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是模塊相互調用時接口會引入許多新問題。如數據經過接口可能丟失；一個模塊對另一模塊可能造成不應有的影響；,4.5 集成測試(組裝測試、聯合測試),幾個子功能組合起來不能實現主功能；誤差不斷積累達到不可接受的程度；全局數據結構出現Bug等。解決的辦法是在每個模塊完成單元測試后，需要按照設計時做出的結構圖，把它們連接起來，將所有模塊按照設計要求組裝成系統，進行集成測試。,1集成測試概念 集成測試是將已測試過的所有模塊按設計要求(如根據結構圖)集成為子系統或系統，主要對與設計相關的軟件體系結構的構造進行測試，以檢驗總體設計中各模塊之間的接口設計問題、模塊之間的相互影響、上層模塊存在的各種差錯及全局數據結構對系統的影響等方面，發現并排除在模塊連接中可能出現的Bug，最終構成要求的軟件系統。由于單元測試不能窮盡，單元測試又會引入新Bug，單元測試后肯定會隱藏Bug，集成一般不可能一次成功，必須經測試后才能成功。,實踐表明，一些模塊雖然能夠單獨的工作，但并不能保證集成起來也能正常工作。程序在某些局部反映不出來的Bug，在全局上很可能暴露出來，影響功能的實現。 在集成測試中需要考慮的問題是： (1) 在把各個模塊連接起來時，穿越模塊接口的數據是否會丟失； (2) 一個模塊的功能是否會對另一個模塊的功能產生不利的影響；,(3) 各個子功能組合起來，能否達到預期要求的父功能； (4) 全局數據結構是否有問題； (5) 單個模塊的誤差累積起來，是否會放大，是否到了不能接受的程度。 在單元測試的同時可進行集成測試，發現并排除在模塊連接中可能出現的Bug，最終構成要求的軟件系統。,2所采取的方法 集成測試主要采用黑盒測試中的等價類劃分、邊值分析，白盒測試中的數據流測試、域測試、調用、覆蓋等測試技術。集成測試的策略指進行單元組裝的方法和步驟。集成測試的策略分為一次集成測試和漸增式集成測試。 1) 一次性集成方式 一次性集成方式是一種非增式組裝方式(又稱為整體拼裝)。在配備輔助模塊的條件下，對所有模塊進行單元測試。然后，把所有模塊組裝在一起進行測試，最終得到滿足要求的軟件系統。一次性集成過程見圖4.19。,圖4.19 一次性集成測試過程示意圖,2) 漸增式集成方式(也稱為增式集成) 增式集成測試與一次性集成測試方式有所不同。它的集成是逐步實現的，集成測試也是逐步完成的。首先對每個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統。在集成的過程中邊連接邊測試，以發現連接過程中產生的Bug，通過增量逐步組裝成為要求的軟件系統。 一次性集成測試方法是先分散測試，再集中起來一次完成集成測試。如果在模塊的接口處存在差錯，只會在最后的集成時一下子暴露出來。,與此相反，增式集成測試的逐步集成和逐步測試的辦法，把可能出現的差錯分散暴露出來，便于找出問題和修改。其次，增式集成測試使用了較少的輔助模塊，也就減少了輔助性測試工作。并且一些模塊在逐步集成的測試中，得到了較為頻繁的考驗，因而可能取得較好的測試效果。總的說來，增式集成測試比一次性集成測試具有一定的優越性。 漸增式集成測試可按不同的次序實施，分為自底向上、自頂向下和混合漸增式測試。,3) 自頂向下測試 自頂向下增式測試表示逐步集成和逐步測試是按結構圖自上而下進行的。這種集成方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件 功能。圖4.20為按深度方向組裝的例子。,圖4.20 按深度方向組裝測試示意圖,4) 自底向上的漸增式 這種集成方式是從程序模塊結構的最底層的模塊開始集成和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以通過直接運行子模塊得到(見圖4.21)。,圖4.21 自底向上漸增式測試示意圖,自頂向下增量的方式和自底向上增量的方式各有優缺點。一般來說，一種方式的優點可能是另一種方式的缺點。,5) 混合漸增式測試 即衍變的自頂向下的增量測試：首先對輸入/輸出模塊和引入新算法模塊進行測試；然后自底向上組裝成功能相當完整且相對獨立的子系統；再由主模塊開始自頂向下進行增量測試。,3集成測試需求 集成測試需求所確定的是對某一集成測試版本的測試內容，即測試的具體對象。集成測試需求主要來源于設計模型和集成構件計劃，歸納如下： (1) 集成測試版本應分析其類協作與消息序列，從而找出該測試版本的外部接口。 (2) 由集成測試版本的外部接口確定集成測試用例。 (3) 測試用例應覆蓋工作版本每一外部接口的所有消息流序列。 集成測試著重于集成版本的外部接口的行為。因此，測試需求應具有可觀測、可測評性。,注意：一個外部接口和測試用例的關系是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可采用重用系統測試用例技術。,4集成測試步驟 集成測試步驟見表4.4。,表4.4 集成測試步驟,5集成測試全過程和流程圖 集成測試用圖來描述：圖4.22和圖4.23分別為集成測試的全過程和流程圖。,圖4.22 集成測試全過程,圖4.23 集成測試流程圖,6集成測試產生的工件清單 軟件集成測試計劃； 集成測試用例； 測試過程； 測試腳本和測試日志； 測試評估摘要。,系統測試是在實際使用環境下，對計算機系統進行一系列綜合全面的組裝測試和確認測試，對系統的準確性及完整性等方面進行測試。具體來說就是把已經經過確認的軟件產品放入整個實際的計算機系統中，與其他系統成分，包括計算機硬件、外設、網絡、支持軟件、數據、使用人員等其他元素，甚至還可能包括受計算機控制的執行機構結合在一起，進行系統的各種安裝測試、功能測試、確認測試等相結合的綜合測試。,4.6 系 統 測 試,下面給出系統測試進入條件。 (1) 具有軟件技術規格書、軟件需求規格說明、軟件設計文檔、用戶手冊、操作手冊及單元測試、軟部件測試、配置項測試的測試用例、測試報告和全部軟件問題報告。 (2) 配置項必須通過測試，所有軟件配置項納入配置管理。 (3) 有經過審批并納入系統試驗大綱的測試用例。 系統測試的測試人員由測試組成員(質量保證人員)或測試組成員與用戶共同組成。,系統測試在整個系統開發完成，即將交付用戶使用前進行。在這一階段，完全采用黑盒法對整個系統進行測試。軟件在系統中畢竟占有相當重要的位置，軟件的質量如何，軟件的測試工作進行得是否扎實與能否順利、成功地完成系統測試密切相關。系統測試實際上是針對系統中各個小的組成部分進行的綜合性檢驗。盡管每一個檢驗有著特定的目標，然而所有的檢測工作都要驗證系統中每個部分均已得到正確集成，并能完成指定的功能。 系統測試過程如下： 制訂系統測試計劃設計系統