軟件測試技術完整教程(一)精編版

1、 本章要點本章要點 l 軟件測試的發(fā)展歷史； l 軟件測試技術的分類方法； l 軟件測試原則； l 軟件測試的定義； l 軟件測試同軟件開發(fā)之間的關系； l 軟件測試與開發(fā)模型； l 軟件測試工作流程。 本章目標本章目標 u 了解軟件測試的發(fā)展歷程和行業(yè)現(xiàn)狀； u 掌握軟件測試技術的分類； u 理解軟件測試的目的和軟件測試原則，以及了解 人們對軟件測試行業(yè)的錯誤認識； u 掌握軟件測試中的基本定義、基本知識; u 理解軟件開發(fā)與軟件測試的關系。 1.1軟件測試的發(fā)展歷程及現(xiàn)狀軟件測試的發(fā)展歷程及現(xiàn)狀 1.1.1軟件測試的發(fā)展歷程軟件測試的發(fā)展歷程 20世紀50-60年代，軟件仍然處于次要位置,

2、測 試理論和方法的發(fā)展比較緩慢。 70年代以后，軟件技術的成熟和完善使得軟件 測試的規(guī)模和復雜度加大，軟件測試也逐漸形成 了一套完整的體系，逐漸走向規(guī)范化。 1.1.2軟件測試的現(xiàn)狀軟件測試的現(xiàn)狀 與一些發(fā)達國家相比，國內測試工作還存在一 定的差距。國內測試人員所占比例小，但是，在 軟件測試實現(xiàn)方面都是相當?shù)?，而且向產業(yè)化方 向發(fā)展。 1.2 1.2 什么是軟件測試什么是軟件測試 1.2.11.2.1軟件測試的定義軟件測試的定義 根據(jù)側重點的不同，主要有以下三種觀點： 1）1983年IEEE將軟件測試定義為：“使用人 工或自動手段運行或測定某個系統(tǒng)的過程，其目的 在于檢驗它是否滿足規(guī)定的需求或

3、是弄清預期結果 與實際結果之間的差別”，該定義明確地提出了軟 件測試以檢驗是否滿足需求為目標。 2）Myers認為：“是為了發(fā)現(xiàn)錯誤而執(zhí)行程序 的過程”，明確提出了“尋找錯誤”是測試目的。 3）從軟件質量保證的角度看：是一種重要的軟 件質量保證活動，其動機是通過一些經濟、高效的 方法，捕捉軟件中的錯誤，從而達到保證軟件內在 質量的目的。 測試過程中的活動包括“分析”軟件（靜態(tài)測 試）和“運行”軟件（動態(tài)測試）。 也有人認為軟件測試（software testing）就 是在軟件投入運行前，對軟件需求分析、設計規(guī)格 說明和編碼的最終復審，是軟件質量保證的關鍵步 驟。 軟件測試有兩個基本職責：即驗

4、證和確認。 注意：區(qū)分軟件測試和軟件調試。 1.2.21.2.2軟件測試生命周期軟件測試生命周期 測試的生命周期（software testing life cycle） 分為幾個階段（如圖1-1所示 ）。 前三個階段就是引入程序錯誤階段； 后三個階段就是清除程序錯誤的階段。 需求規(guī)格說明 設計 編碼 測試缺陷分類缺陷分離 缺陷 排除 修復 錯誤 錯誤 錯誤 錯誤 錯誤 錯誤 錯誤 錯誤 3(失效) 圖1-1 測試生命周期 1.2.3 1.2.3軟件開發(fā)與測試模型軟件開發(fā)與測試模型 下面我們將介紹幾種典型的軟件開發(fā)與測試模型。 一、軟件開發(fā)與測試一、軟件開發(fā)與測試V V模型模型 在傳統(tǒng)開發(fā)過程

5、中測試不受重視，僅把它作為在 需求分析、概要設計、詳細設計及編碼之后的一個 階段。尤其在瀑布模型中。 如圖1-2所示，在V模型中，描述了一些不同的測 試級別，并說明了這些級別所對應的生命周期中不 同的階段，清楚地描述了這些測試階段和開發(fā)過程 期間的對應關系。 用戶 需求獲取 需求定義 需求分析 需求分析書 概要設計 概要設計書 詳細設計 詳細設計書 編碼 程序 軟件產品 可交付軟件 系統(tǒng)測試 已確認軟件 確認測試 已集成軟件 集成測試 已測試模塊 單元測試 需 求 分 析 評審 評審 評審 評審 評審 評審 評審 評審 圖1-2 V模型示意圖 V模型適用于所有類型的開發(fā)過程，但并不一 定適用于

6、開發(fā)和測試過程的所有方面。 二、軟件開發(fā)與測試二、軟件開發(fā)與測試WW模型模型 由于各種原因，開發(fā)的每一個環(huán)節(jié)都可能產 生錯誤，如果堅持各個階段的技術評審,就能夠盡 早發(fā)現(xiàn)和預防錯誤。 圖1-3為軟件開發(fā)與測試的W 模型，形象地說 明了軟件測試與開發(fā)的這種同步性。 需求測試需求分析 功能測試概要設計 設計測試詳細設計 單元測試編碼 系統(tǒng)測試驗收 確認測試確認 集成測試 集成 圖1-3 W模型示意圖 應用該模型的優(yōu)點在于，每個軟件開發(fā)活動 結束后就可以執(zhí)行相應的測試，如：在需求分析結 束后，就可以進行需求分析測試。 三、軟件開發(fā)與測試三、軟件開發(fā)與測試HH模型模型 與前兩種模型相比，H模型充分地體

7、現(xiàn)了測試 過程。如圖1-4所示的H 模型揭示了: 1、 軟件測試不僅僅指測試的執(zhí)行, 還包括很多其 他的活動。 2、軟件測試是一個獨立的流程, 貫穿產品的整個開 發(fā)周期, 與其它流程并發(fā)進行。 3、軟件測試要盡早準備, 盡早執(zhí)行。 測試準備測試執(zhí)行 測試流程 其他流程 測試就緒點 圖1-4 H模型示意圖 4、軟件測試根據(jù)被測物的不同是分層次的. 不同 層次的測試活動可以是按照某個次序先后進行的, 但也可能是反復的。 1.2.4 1.2.4與軟件測試相關的術語與軟件測試相關的術語 1.錯誤（Error） 程序員在編寫代碼時會出錯，我們把這種錯誤稱之 為bug。隨著開發(fā)過程的進行，錯誤會不斷的放大

8、。 2.缺陷(Default) 缺陷是錯誤的結果，更精確的說是錯誤的表現(xiàn)。 3.失效（Failure） 在缺陷運行時，常常會發(fā)生失效的情況。一種是過 錯缺陷對應的失效；一種是遺漏缺陷對應的失效。 4.測試（Test） 測試是一項采用測試用例執(zhí)行軟件的活動，在這 項活動中某個系統(tǒng)或組成的部分將在特定的條件下 運行，然后要觀察并記錄結果，以便對系統(tǒng)或組成 部分進行評價。 5.測試用例(Test Case) 測試用例是為特定的目的而設計的一組測試輸 入、執(zhí)行條件和預期的結果。 6.回歸測試（Regression testing） 回歸測試的目的是為了測試由于修正缺陷而更 新的應用程序，以確保徹底修正

9、了上一個版本的缺 陷，并且沒有引入新的軟件缺陷。 1.31.3軟件測試技術分類軟件測試技術分類 從不同的角度，可以把軟件測試技術分成不同 種類，如： 一 、從是否需要執(zhí)行被測軟件的角度，可分為 靜態(tài)測試和動態(tài)測試。 那些不利用計算運行被測程序，而是通過其他 手段達到測試目的的方法稱作靜態(tài)測試。下面我們 對這幾種靜態(tài)測試分別加以介紹： 代碼檢查 代碼走查 桌面檢查 同行評分 下面我們將要介紹的黑盒測試和白盒測試就屬 于動態(tài)測試。 二、從軟件測試用例設計方法的角度，可分為黑 盒測試（Black-Box Testing）和白盒測試 （White-Box Testing）。 三、按照軟件測試的策略和過

10、程分類，軟件測 試可分為單元測試(Unit Testing)、集成測試 (Integration Testing)、確認測試(Validation Testing)、 系統(tǒng)測試(System Testing)和驗收測試(Verification Testing)。 1.41.4軟件測試的目的軟件測試的目的 測試真正的目的是使我們通過對軟件錯誤的原 因和分布進行歸納，來發(fā)現(xiàn)并排除當前軟件產品的 缺陷，對在需求和設計過程中存在的問題查缺補漏， 從而確保軟件產品的質量。 GMyers給出了關于測試的一些規(guī)則，我們 也可以把這些規(guī)則看作是測試的目標： 1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 2)

11、測試是為了證明程序有錯，而不是證明程序無 錯。 3)一個好的測試用例在于他能發(fā)現(xiàn)至今未發(fā)現(xiàn)的 錯誤。 4)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的 測試。 這里要強調的一點是，軟件測試不只是軟件測 試人員的工作，也是軟件開發(fā)人員和軟件使用者 的工作。 1.51.5軟件測試的原則軟件測試的原則 1.5.11.5.1盡早地和不斷地進行軟件測試盡早地和不斷地進行軟件測試 IBM的研究結果表明，缺陷存在放大趨勢。圖 1-5表示了缺陷放大模型大致狀況。 需求階段 缺陷 概要設計 階段缺陷 詳細設計 階段缺陷 代碼階段 缺陷 放大n1倍放大n2倍放大n3倍 圖1-5 缺陷放大模型 由此可見，問題發(fā)現(xiàn)越早，

12、解決問題的代價就越 小，這是軟件開發(fā)過程中的黃金法則。 1.5.21.5.2不可能完全的測試不可能完全的測試 對一個程序進行完全測試就是意味著在測試結 束之后，再也不會發(fā)現(xiàn)其它的軟件錯誤了。其實， 這是不可能的，主要原因有以下幾點： 一、不可能測試程序對所有可能輸入的響應。 二、不可能測試到程序每一條可能的執(zhí)行路徑 三、無法找出所有的設計錯誤 四、不能采用邏輯來證明程序的正確性 1.5.3 1.5.3增量測試，由小到大增量測試，由小到大 測 試 時 間 測 試 范 圍可 用 資 源 系 統(tǒng) 測 試 集 成 測 試 單 元 測 試單 元 測 試 圖1-7 測試資源關系圖 由小到大，指的是軟件測試

13、的粒度。無論是傳 統(tǒng)的軟件測試還是面向對象的軟件測試都要遵循這 樣的原則。如圖1-7所示，多個單元組合過渡到集 成測試階段，集成測試階段過渡到更高級別的系統(tǒng) 測試階段，虛線是各個測試階段的發(fā)布基線。隨著 測試的逐步深入，范圍的逐步擴大，測試時間、可 用資源也隨之增大。 1.5.41.5.4避免測試自己的程序避免測試自己的程序 避免程序員測試自己的代碼的主要原因歸納如 下： 1.程序員輕易不會承認自己寫的程序有錯誤。 2.程序員的測試思路有局限性，在做測試時很容易 受到編程思路的影響。 3.多數(shù)程序員沒有嚴格正規(guī)的職業(yè)訓練，缺乏專業(yè) 測試人員的意識。 4.程序員沒有養(yǎng)成錯誤跟蹤和回歸測試的習慣.

14、 1.5.5 1.5.5設計周密的測試用例設計周密的測試用例 軟件測試的本質就是針對要測試的內容確定一 組測試用例。測試用例至少應該包括如下幾個基本 信息： 1、在執(zhí)行測試用例之前，應滿足的前提條件。 2、輸入（合理的、不合理的）。 3、預期輸出（包括后果和實際輸出）。 圖1-8顯示了一個典型的測試用例所應該具有 的基本信息。 測試用例ID： 目的： 前提： 輸入： 預期輸出： 后果： 執(zhí)行歷史： 日期： 結果： 版本： 執(zhí)行人： 圖1-8 典型的測試用例信息 測試用例是測試工作的核心，應該盡量設計的 周密細致，這樣才能更好的保證測試工作的質量。 下面舉例來說明這一點。 以一個實現(xiàn)登錄功能的小

15、程序為例，它允許用 戶選擇城市和地區(qū)，輸入自己的賬號和密碼。 如圖1-9所示，通過Alt-F4組合鍵和“Exit”按 鈕來終止程序，Tab鍵在區(qū)域中間移動。 操操 作作 員員 登登 錄錄 選 擇 城 市 選 擇 地 區(qū) 城 市 地 區(qū) 操 作 員 密 碼 提 交退 出 圖1-9 登錄窗口 下面根據(jù)組成頁面的具體元素，分別從幾個方面做 了一些比較全面的測試用例： 1. 下拉框和輸入框測試用例 表1-1 下拉框和輸入框測試用例 測試內容測試內容輸入操作輸入操作預期輸出預期輸出實際結果實際結果 下拉框下拉框未和后臺數(shù)據(jù)庫綁定未和后臺數(shù)據(jù)庫綁定 （顯示列表元素固（顯示列表元素固 定）定） 不允許列表中

16、不允許列表中 出現(xiàn)出現(xiàn)NULL 現(xiàn)象，固定現(xiàn)象，固定 “請選擇請選擇- -” 已和后臺數(shù)據(jù)庫綁定已和后臺數(shù)據(jù)庫綁定 （顯示列表元素活（顯示列表元素活 動）動） 不允許列表中不允許列表中 出現(xiàn)出現(xiàn)NULL 現(xiàn)象，固定現(xiàn)象，固定 “請選擇請選擇- -” 輸輸 入入 框框 限定字符限定字符 型輸入型輸入 12、6無無 #，*等等錯誤提示錯誤提示 限定型數(shù)限定型數(shù) 字輸入字輸入 測試數(shù)據(jù)測試數(shù)據(jù)無無 12月、月、7*、0錯誤提示錯誤提示 2、功能測試 （表1-2 功能測試用例） 用 例應產生行為結果失敗原因 1.基本功能測試 1.1在輸入框內輸入資料 并且執(zhí)行存儲 程序必須能夠接受使用者的輸入并且將

17、輸入值存在登錄文件內 1.2在輸入框內不輸入資 料但執(zhí)行儲存 程序必須能夠檢查使用者輸入是否為空 白，同時必須能夠告知使用者原因 1.3檢查city字段儲存結果City字段輸入 后存入cookies 1.4檢查area字段儲存結果Area字段輸入 后存入cookies 儲存結果 1.5檢查ID 字段儲存結果ID字段輸入 后存入cookies 2.使用接口功能測試 2.1檢查輸入字段的輸入 值 必須組織使用者輸入空白，同時部分字 段只能輸入數(shù)字 2.2檢查使用者接口的Tab Order 所有的Tab Order必須按照正常順序 2.2檢查所有的Button所有的Button必須能夠起作用 3、各

18、種錯誤數(shù)據(jù)的測試 表1-3 錯誤數(shù)據(jù)的測試用例 測試內容測試內容輸入操作輸入操作預選測試數(shù)預選測試數(shù) 據(jù)據(jù) 預期輸出預期輸出實際結果實際結果 點擊登錄點擊登錄 按鈕按鈕 不完整的數(shù)不完整的數(shù) 據(jù)據(jù) CityCity， areaarea， IDID， pswdpswd 略略提示錯誤對話提示錯誤對話 框框 不正確的數(shù)不正確的數(shù) 據(jù)據(jù) CityCity， areaarea， IDID， pswdpswd 略略提示錯誤對話提示錯誤對話 框框 回車操作回車操作不完整的數(shù)不完整的數(shù) 據(jù)據(jù) CityCity， areaarea， IDID， pswdpswd 略略提示錯誤對話提示錯誤對話 框框 點擊點擊“退

19、退 出出” 按鈕按鈕 無無無無無無關閉當前應用關閉當前應用 系統(tǒng)系統(tǒng) 4、特殊測試 表1-4 特殊測試用例 測試內容測試內容輸入操作輸入操作預選測試數(shù)預選測試數(shù) 據(jù)據(jù) 預期輸出預期輸出 操作焦點逃操作焦點逃 逸逸 連續(xù)連續(xù)TabTab切換，察看異常切換，察看異常無無焦點可準確回歸焦點可準確回歸 當前操作窗口當前操作窗口 分配內存不分配內存不 足足 啟動多個應用程序或模擬啟動多個應用程序或模擬 多個程序運行多個程序運行 無無是否可以正常運是否可以正常運 行行 網(wǎng)絡斷線網(wǎng)絡斷線切斷網(wǎng)絡連接切斷網(wǎng)絡連接無無是否可正常拋出是否可正常拋出 異常異常 1.5.6 1.5.6注意錯誤集中的現(xiàn)象注意錯誤集中的

20、現(xiàn)象 軟件缺陷的“扎堆”現(xiàn)象的常見形式： 1、對話框的某個控件功能不起作用，可能其 他控件的功能也不起作用。 2、某個文本框不能正確顯示雙字節(jié)字符，則 其他文本框也可能不支持雙字節(jié)字符。 3、聯(lián)機幫助某段文字的翻譯包含了很多錯誤， 與其相鄰的上下段的文字可能也包含很多的語言 質量問題。 4、安裝文件某個對話框的“上一步”或“下 一步”按鈕被截斷，則這兩個按鈕在其他對話框 中也可能被截斷。 1.5.7 1.5.7確認確認BUGBUG的有效性的有效性 有時候測試人員提交的BUG并不是真正的BUG。 圖1-10具體地描述了無效BUG的來源。一般由A測 試人員發(fā)現(xiàn)的BUG，一定要由另外一個B測試人員

21、來進行確認，如果發(fā)現(xiàn)嚴重的BUG可以召開評審會 進行討論和分析。 圖1-10 無效BUG來源構成圖 1.5.8 1.5.8合理安排測試計劃合理安排測試計劃 合理的測試計劃有助于測試工作順利有序地進 行，因此要求在對軟件進行測試之前所作的測試計 劃中，應該結合了多種針對性強的測試方法、列出 所有可使用資源，建立一個正確的測試目標； 要本著嚴謹、準確的原則，周到細致地做好測 試前期的準備工作，避免測試的隨意性。尤其是要 盡量科學合理地安排測試時間。 A B A BC A BC D EF 基本結構 （a） （b） （c） 單純依賴 多重依賴 復合依賴 圖1-11 錯誤依賴關系 1.5.91.5.9回

22、歸測試回歸測試 這些錯誤之間存在單純的依賴或者復雜的多重依 賴關系，如圖1-11所示。 其中，（a）圖中的A、B 關系表達為：A錯誤依 賴于B錯誤的關閉而關閉。如果多了一條路徑（如 （b）圖中A、B、C關系），A錯誤依賴于B錯誤和 C錯誤的同時關閉而關閉。（c）圖是（a）和（b） 的復合方式，因程序中的錯誤存在著一對多，多對 多的復雜關系而變得難以處理，并且有些錯誤關聯(lián) 和依賴關系處于隱性狀態(tài)。 1.5.101.5.10測試結果的統(tǒng)計和分析測試結果的統(tǒng)計和分析 只有對這些輸出信息進行深入地統(tǒng)計、分析和比 較，才能夠正確的鑒別測試后輸出的數(shù)據(jù)，給出清 晰的錯誤原因分析報告。當輸出的信息很龐大時，

23、 我們可以借助專業(yè)的測試工具。 1.5.11 1.5.11及時更新測試及時更新測試 事實上，有可能導致測試失敗的原因還有很多， 可大致歸納為如下幾點： 1、測試團隊管理者失職； 2、測試團隊中溝通不好； 3、測試團隊和項目團隊溝通不良； 4、測試過程中，執(zhí)行角色無準確定義； 5、測試團隊缺乏良好的培訓。 1.6 1.6軟件測試工作流程軟件測試工作流程 一般的軟件測試總體工作流程如圖1-12所示： 立項階段 需求階段 設計階段 編碼單元測試階段 集成測試階段 系統(tǒng)測試階段 驗收測試階段 結項總結階段 圖1-12 軟件測試工作總體流程圖 1、需求階段 需求階段是軟件測試活動的前提。需求階段測試 工

24、作流程如圖1-13所示： 需 求 工 作 培 訓 編 寫 需 求 業(yè) 務 、 用 戶 、 功 能 需 求 評 審 需 求 規(guī) 格 說 明 書 需 求 變 更 需 求 變 更 記 錄 需 求 報 警 總 體 測 試 計 劃 系 統(tǒng) 測 試 方 案 需 求 報 警 信 號 需 求 跟 蹤 矩 陣 進 入 下 一 階 段 需需求求階階段段測測試試工工作作流流程程 圖1-13 需求階段測試活動流程圖 2、設計防止帶地線合刀閘 2、防止帶負荷拉合隔離開關; 3、防止帶電掛接地線或接地刀閘; 4、防止帶接地線或合接地刀閘送電; 5、防止誤入帶電間隔 1.8.21.8.2系統(tǒng)運行環(huán)境系統(tǒng)運行環(huán)境 客戶端平臺

25、：windows98/2000、 windows NT workstation、Linux等所有具有支 持JAVA的瀏覽器系統(tǒng)； 服務器端平臺：windows2000 server、 windows NT Server、Linux、UNIX等所有支持 JAVA Bean的系統(tǒng)平臺； 數(shù)據(jù)庫服務器：Oracle數(shù)據(jù)庫或SQL Server 2000數(shù)據(jù)庫或ACCESS數(shù)據(jù)庫。 Web服務器：Tomcat 5.0 1.8.31.8.3系統(tǒng)總體結構系統(tǒng)總體結構 兩票系統(tǒng)主要由兩部分構成，即：操作 票子系統(tǒng)和工作票子系統(tǒng)。整個系統(tǒng)的總體 結構如圖1-16所示： 1.8.41.8.4系統(tǒng)功能系統(tǒng)功能(

26、(略略) ) 兩票系統(tǒng) 工作票系統(tǒng)功能模塊操作票系統(tǒng)功能模塊 操 作 票 檔 案 管 理 模 塊 電 氣 操 作 票 模 塊 熱 機 操 作 票 模 塊 操 作 票 打 印 操 作 票 存 檔 熱 力 工 作 票 模 塊 電 氣 第 一 種 工 作 票 模 塊 電 氣 第 二 種 工 作 票 模 塊 工 作 票 打 印 工 作 票 回 填 及 存 檔 圖1-16 兩票系統(tǒng)總體結構圖 本章小結本章小結 本章介紹了軟件測試發(fā)展的歷程，以及其在 國內的發(fā)展狀況。隨著軟件開發(fā)過程和開發(fā)技術的 不斷改進，軟件測試理論和方法也在不斷完善，測 試工具也在蓬勃發(fā)展。 通過本章的論述，可以了解到軟件測試已經 不

27、再只是進行簡單的程序邏輯檢查，而是一個伴隨 著整個軟件開發(fā)過程的活動。 測試對象也不僅僅是程序代碼，而開發(fā)過程中 產生的所有軟件產品，甚至是產品使用說明也包括 在內。 測試過程中為了更好的保證軟件測試的質量， 首先要遵循一定的測試原則，最為重要的就是應該 盡早的進行測試。 其次，正確處理開發(fā)與測試之間的關系，更好的把 開發(fā)與測試過程集成到一起。從而提高測試效率， 節(jié)約測試成本。 本章所介紹的幾種軟件開發(fā)與測試模型，如： V模型、W模型和H模型，三種模型在不同程度上 反映了軟件開發(fā)與軟件測試的關系。 其中，V模型非常明確地標明了測試過程中存 在的不同級別，并且清楚地描述了測試和開發(fā)過程 中各階段

28、的對應關系。而W模型作為V模型的改進， 更好地體現(xiàn)了軟件開發(fā)與軟件測試工作的同步性， 更為明確地指出測試的對象不僅僅是程序本身，而 且包括需求分析、概要設計和詳細設計說明書，強 調了軟件測試是軟件開發(fā)過程中的一項重要的工作， 貫穿于整個軟件開發(fā)過程。 H模型則從微觀的角度來看待軟件測試過程。 最后一個做好測試工作的關鍵因素就是精心的 組織和安排軟件測試的工作流程，本章把測試工 作分為幾個階段，分別闡述了通用的測試工作流 程，但要求讀者在工作中，根據(jù)每個項目的具體 情況制定可行的測試流程。 各種測試技術是軟件測試工作的敲門磚，本章 從不同的角度介紹了軟件測試技術的分類。 從是否需要執(zhí)行被測軟件的

29、角度，可分為靜態(tài) 測試（Static Testing）和動態(tài)測試（Dynamic Testing）； 從測試用例設計的角度，可分為黑盒測試和 白盒測試；按照軟件測試過程和測試策略，可分 為單元測試、集成測試和系統(tǒng)測試。 另外，本章還專門介紹了目前在實際工作中 對軟件測試的錯誤認識，希望讀者能夠明確軟件 測試的目的，正確的認識軟件測試工作的必要性 和重要性。 習題習題 名詞解釋： 軟件測試 錯誤 缺陷 失效 測試用例 回歸測試 靜態(tài)測試 動態(tài)測試 黑盒測試 白盒測試 單元測試 集成測試 系統(tǒng)測 試 簡述軟件測試發(fā)展的過程。從不同角度描述軟件測 試的現(xiàn)狀。 測試的生命周期可以分為幾個階段？簡單描述

30、各階 段需要完成的任務。 1. 什么是V模型？簡述V模型在軟件測試過程中的作 用，以及在V模型中各個測試階段和開發(fā)過程的對 應關系。 請概括一下靜態(tài)測試和動態(tài)測試，以及黑盒測 試與白盒測試的不同點。 分別描述一下，需求階段、設計退卡 不正確的PIN 顯示屏幕S3 不正確的PIN 顯示屏幕S3 正確PIN顯示屏幕S5 圖2-2 用于PIN嘗試的有限狀態(tài)機 3、狀態(tài)圖 狀態(tài)圖現(xiàn)在被Rational公司選為統(tǒng)一建模語 言，即UML的控制模型。 圖2-3 狀態(tài)圖的團點 Harel使用與方法無關的術語“團點”表示狀態(tài) 圖的基本構建塊。在圖2-3中，團點A包含兩個團點 B和C，通過邊連接。團點A通過邊與團

31、點D連接。 根據(jù)Harel的意圖，我們可以把團點解釋為狀 態(tài)，把邊解釋為轉移。 在圖2-4中，狀態(tài)A是初始狀態(tài)，當進入到這 個狀態(tài)時，也進入低層狀態(tài)B。當進入某個狀態(tài)時， 我們可以認為該狀態(tài)是活動的，這可與Petri網(wǎng)中 的被標記地點類比。狀態(tài)圖工具采用色彩表示哪個 狀態(tài)活動的，并等效于Petri網(wǎng)中的標記地點。 圖2-4中有一些微妙的地方，從狀態(tài)A轉移到 狀態(tài)D初看起來是有歧義的，因為它沒有區(qū)分狀態(tài) B和C。約定是，邊必須開始和結束于狀態(tài)的周圍。 如果狀態(tài)包含子狀態(tài)，就像圖中的A一樣，邊會 “引用”所有的子狀態(tài)。 因此，從A到D的邊意味著轉移可以從狀態(tài)B 或從狀態(tài)C發(fā)生。如果有從狀態(tài)D到狀態(tài)

32、A的邊， 如圖2-5所示，則用B來表示初始狀態(tài)這個事實， 意味著轉移實際上是從狀態(tài)D到狀態(tài)B。這種約 定可以大大減緩有限狀態(tài)機向“空心代碼”發(fā)展 的趨勢。 圖2-4 狀態(tài)圖中的初始狀態(tài) 圖2-5 進入自狀態(tài)的默認入口 我們最后要討論的一個狀態(tài)圖的特性就是并 發(fā)狀態(tài)圖概念。圖2-6中狀態(tài)D的虛線用于表示狀 態(tài)D實際上引用兩個并發(fā)狀態(tài)E和F。 圖2-6 并發(fā)狀態(tài) 2.2 2.2白盒測試白盒測試 白盒測試是一種可視的測試軟件的方法，即它 把測試對象看作一個透明的盒子，測試人員要了解 程序結構和處理過程，按照程序內部邏輯測試程序， 檢查程序中的每條通路是否按照預定要求正確工作。 白盒測試的過程如圖2-

33、7所示： 源程序 測試用例 被測程序 執(zhí)行路徑 分析 覆蓋情況分析 圖2-7 白盒測試過程示意圖 那么，在對被測軟件進行白盒測試時，主要對 程序進行哪些方面的檢查呢？有如下幾點： （）保證一個模塊中的所有獨立執(zhí)行路徑至少測 試一次； （）對所有邏輯判定取值“true”和“false”的 兩種情況都至少測試一次； （）在循環(huán)邊界和運行界限內執(zhí)行循環(huán)體； （）測試內部數(shù)據(jù)結構的有效性。 在軟件測試領域，有六種基本的測試類型：單 元測試，集成測試，功能測試/系統(tǒng)測試，可接受 性測試，回歸測試和Beta測試。白盒測試可以用 在其中的三種測試類型中： 1、單元測試 2、集成測試 3、回歸測試 2.2.1

34、2.2.1白盒測試與調試的異同白盒測試與調試的異同 白盒測試和調試有哪些不同點呢？ 1、從承擔的任務來看，白盒測試同其他類型 測試一樣，它的任務是發(fā)現(xiàn)所開發(fā)的項目中的缺陷； 但是，調試不屬于測試，其任務是糾正軟件中的缺 陷。 2、從最終的結果來看，白盒測試有預知的結 果，不可預知的只是程序是否通過測試，并且成功 測試的結果是發(fā)現(xiàn)錯誤的癥狀，從而引起調試的進 行；而調試的結果是消除項目中的錯誤。 3、從執(zhí)行的過程來看，測試是一個發(fā)現(xiàn)錯誤、 改正錯誤、重新測試的過程；而調試是一個推理 過程。 4、從準備工作來看，測試從已知的條件開始， 使用預先定義的程序；調試一般是以不可知的內 部條件開始，做統(tǒng)一

35、性調試 。 5、從執(zhí)行的計劃性來看，測試是有計劃的并 要進行測試設計；而調試則不受時間約束。 6、從執(zhí)行的人員來看，測試經常是由獨立的 測試組在不了解軟件設計的條件下完成的，而調 試必須由程序員來完成。 7、從所使用的工具來看，大多數(shù)白盒測試的 執(zhí)行和設計可有工具支持，而調試程序員能利用 的工具主要是調試器。 2.2.22.2.2白盒測試的用例設計白盒測試的用例設計 白盒測試用例設計技術就是研究如何用最少 的測試用例最大限度地發(fā)現(xiàn)軟件中的錯誤，目前 主要有基本路徑測試、等價類劃分/邊界值分析測 試、覆蓋測試、循環(huán)測試、數(shù)據(jù)流測試、程序插 樁測試、變異測試等等方法。下面主要對幾種常 見的方法加以

36、介紹： 一、基本路徑測試 二、等價類劃分/邊界值分析（Equivalence partitioning/boundary value analysis） 三、控制流/覆蓋測試（Control-flow/Coverage Testing） 方法覆蓋 方法覆蓋可用于衡量測試用例所覆蓋的方法的 百分比。 語句覆蓋（Statement Coverage） 語句覆蓋是一種衡量測試所覆蓋的程序語句百 分比的措施。通過測試應該達到100%程序語句覆 蓋的目標，可以標識圈數(shù)，然后執(zhí)行最少的一組測 試用例就可以達到語句覆蓋的目標。 判斷/分支覆蓋 判斷/分支覆蓋是為了衡量在測試過程中覆蓋 了多少個程序中的布爾表

37、達式。 簡單循環(huán) 嵌套循環(huán)串接循環(huán)無結構循環(huán) 圖2-11 各種循環(huán)圖 四、循環(huán)測試是一種白盒測試技術，注重于循 環(huán)構造的有效性。n 循環(huán)結構測試用例的設計循環(huán)可 以劃分為以下幾種模式，如圖2-11： 可以使用如下方法設計循環(huán)測試用例： 一、簡單循環(huán)： 二、嵌套循環(huán)： 三、串接循環(huán)： 四、無結構循環(huán)： 五、數(shù)據(jù)流測試： 六、程序插裝： 程序插裝（Program Instrumentation） 是指在程序中設置斷點或打印語句，在執(zhí)行過程 中了解程序的一些動態(tài)特性。 七、變異測試 變異測試（Mutation Testing）的提出始于 70年代末期，是一種錯誤驅動測試，即針對某類 特定程序錯誤而進

38、行的測試，也是一種比較成熟 的排錯性測試方法（排錯性測試方法的基本思想 是通過檢驗測試數(shù)據(jù)集的排錯能力來判斷軟件測 試的充分性）。 2.2.32.2.3白盒測試舉例（略）白盒測試舉例（略） 2.32.3黑盒測試黑盒測試 黑盒測試也稱作功能測試和行為測試，主要 是根據(jù)功能需求來測試程序是否按照預期工作。 黑盒測試的目的是盡量發(fā)現(xiàn)代碼所表現(xiàn)的外部 行為的錯誤，主要有以下幾類： 功能不正確或不完整； 接口錯誤； 接口所使用的數(shù)據(jù)結構錯誤； 行為或性能錯誤； 初始化和終止錯誤。 黑盒測試的示意圖如圖2-14 所示。從圖2-14 中，我們可以看出黑盒測試只考慮程序的輸入和輸 出，無須考慮程序的內部代碼。

39、 圖2-14 黑盒測試示意圖 2.3.12.3.1黑盒測試和白盒測試的異同黑盒測試和白盒測試的異同 本書歸納出以下幾點： 執(zhí)行測試人員不同 黑盒測試通常由用戶以及非開發(fā)人員來進行； 而白盒測試通常要有了解軟件內部結構的開發(fā)人 員來做。 測試覆蓋目標不同 如果我們用一個盒子來代替整個軟件系統(tǒng)， 那么黑盒測試可以看成是一種系統(tǒng)測試。而對盒 子內部的多個單元的測試就可以稱作為白盒測試。 另外一種區(qū)別就是，二者的覆蓋目標不同。 黑盒測試的目標是覆蓋所有的用戶需求；而白盒 測試的目標是覆蓋所有的代碼。 3、測試動機不同 有效的安全測試有時也需要詳細了解代碼以 及系統(tǒng)結構，此時把這些技術稱作白盒測試。 另

40、外一種風險測試的目標可能就只是測試軟 件是否能夠為用戶提供預期輸出?？捎眯詼y試就 是如此，所以被稱作黑盒測試。 4、測試方法不同 一個最普通的區(qū)別就是行為測試設計是基于 功能需求來定義測試，而結構測試則是基于代碼 本身來定義測試的。這就是兩種設計測試的方法。 因為行為測試是基于外部功能定義的，所以稱作 黑盒測試；結構測試則是基于代碼內部結構來定 義的，所以稱作白盒測試。 5、評估測試方法不同 一些技術是使用代碼工具來跟蹤軟件內部的 工作過程，因此稱為白盒測試技術。與之相比， 黑盒測試技術只是簡單的觀察程序的正常輸出。 2.3.22.3.2黑盒測試的用例設計黑盒測試的用例設計 常用的黑盒測試用例

41、設計方法主要有以下 幾種：功能圖分析方法，等價類劃分方法，邊界 值分析方法，錯誤推測方法，因果圖方法，判定 表驅動分析方法，正交實驗設計方法和功能圖分 析方法等。 下面對上述方法分別作以簡要介紹。 一、基于用戶需求的測試 黑盒測試用例就是基于用戶需求的，也是從研 究客戶需求工作開始的。 二、對等區(qū)間劃分 對等區(qū)間劃分是一種黑盒測試方法，該方法也 稱為等價類劃分，是一種設計測試用例的非常形式 化的方法。 三、邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。 長期的測試工作經驗告訴我們,大量的錯誤是發(fā)生 在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸 出范圍的內部。 四、狀態(tài)轉換測試 狀態(tài)轉換

42、測試適用于軟件被設計成一個狀態(tài)機 或實現(xiàn)了一種被建模成一種狀態(tài)機的情況?？梢栽O 計測試用例測試狀態(tài)間轉換，測試用例創(chuàng)建引起轉 換的事件。可以設計負面測試的測試用例用于測試 狀態(tài)與事件的非法組合。 五、分支測試 在分支測試中，測試用例用于測試單元的控制 流分支或決策點。通常用于實現(xiàn)決策覆蓋 （Decision Coverage）的測試目標。 六、錯誤推測法 錯誤推測法就是根據(jù)經驗和直覺推測程序中所 有可能存在的各種錯誤，借助邊界值分析等方法有 針對性的設計測試用例的方法。 七、因果圖方法 因果圖方法適合于檢查程序輸入條件的各種組 合情況。使用該方法首先要理解軟件所表示的對象 及其關系，然后，定義

43、一組保證“所有對象與其他 對象都具有所期望的關系”的測試序列。 2.3.32.3.3黑盒測試舉例（略）黑盒測試舉例（略） 2.42.4白盒測試和黑盒測試的比較白盒測試和黑盒測試的比較 1、白盒測試只關注軟件產品的測試，不能夠確 保產品已經實現(xiàn)了規(guī)格說明中的所有功能。黑盒測 試則只關注規(guī)格說明中的功能測試，不能夠保證已 經實現(xiàn)的各個部分都被測試到。 2、與黑盒測試相比，白盒測試的成本要高一些。 3、黑盒測試故意不考慮控制結構，而只注意 信息域。白盒測試只考慮測試軟件產品，它不保 證完整的需求規(guī)格是否被滿足。黑盒測試是一種 確認技術，回答“我們在構造一個正確的系統(tǒng)嗎？ 白盒測試是一種驗證技術，回答

44、“我們在正確地 構造一個系統(tǒng)嗎？” 總之，建議測試人員在進行測試的過程中，可 以考慮先使用黑盒測試，然后統(tǒng)計相應的覆蓋率， 再設計適當?shù)陌缀袦y試用例作為補充以保證測試 的完整性。 2.4.12.4.1白盒測試的優(yōu)缺點白盒測試的優(yōu)缺點 1）優(yōu)點 可構成測試數(shù)據(jù)對特定程序部分測試，可以檢測 代碼中的每條分支和路徑； 揭示隱藏在代碼中的錯誤； 對代碼的測試比較徹底； 有較多工具支持； 有一定的充分性度量手段。 2）缺點 工作量大, 成本高。通常只用于單元測試，有應 用局限； 無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤； 不能驗證規(guī)格說明的正確性； 無法對規(guī)格說明中未實現(xiàn)的部分進行測試； 不易生成測試數(shù)

45、據(jù)(通常)。 2.4.22.4.2黑盒測試的優(yōu)缺點黑盒測試的優(yōu)缺點 優(yōu)點 對于較大的代碼單元來說，效率高； 測試人員不需要了解實現(xiàn)的細節(jié)，包括具體的編 程語言； 測試員和程序員可以由不同的人員來擔任； 從用戶的角度進行測試，容易被理解和接受； 有助于暴露任何規(guī)格不一致或有歧義的問題； 測試用例的設計可以在規(guī)格說明完成之后馬上進 行； 容易入手生成測試數(shù)據(jù)； 1. 適用于各階段測試。 缺點 實際上，只有一小部分可能的輸入被測試到，某 些代碼得不到測試； 如果沒有清晰、簡潔的規(guī)格說明，難以設計測試 用例； 如果測試人員不知道開發(fā)人員已經執(zhí)行過該測試 用例，會存在不必要的重復測試； 會有很多程序路徑

46、沒有被測試到； 不能直接針對可能隱蔽了許多問題的特定程序段 進行測試，； 如果規(guī)格說明有誤，則無法發(fā)現(xiàn)； 不易進行充分性測試。 2.4.32.4.3灰盒測試灰盒測試 灰盒測試介于白盒測試和黑盒測試之間，是 現(xiàn)代測試的一種理念。就是指，在白盒測試中交叉 使用黑盒測試的方法；在黑盒測試中交叉使用白盒 測試的方法。 2.52.5測試方法的選擇測試方法的選擇 一、單元測試 測試方法：白盒測試 參考規(guī)范：詳細設計說明和代碼結構 二、集成測試 測試方法：黑盒和白盒測試 參考規(guī)范：詳細設計說明和概要設計說明 2.6 2.6測試計劃與測試文檔測試計劃與測試文檔 最常見的測試文檔包括測試計劃，測試規(guī)范， 測試用

47、例和測試時發(fā)現(xiàn)缺陷后要寫的缺陷報告 等。 那么，測試計劃和測試文檔在測試過程中能 夠發(fā)揮什么樣的作用呢？ 1、測試文檔有助于測試任務的完成。 2、使用測試文檔可以更好的協(xié)調測試任務與 測試過程。 3、測試文檔為測試項目的組織、規(guī)劃與管理 提供了一個架構。 2.6.1 2.6.1測試計劃的制定測試計劃的制定為了給讀者一個宏觀的認 識，首先請看測試計劃活動圖，如圖2-20所示。 在制定測試計劃過程中，核心活動就是： 一、確定測試策略 通常，可以采用以下幾個方法來制定測試策略： 1、確定測試的范圍 2、確定測試的方法 3、確定測試標準和質量檢查點 4、確定自動化測試策略 二、確定測試系統(tǒng)（硬件和軟件

48、） 1、測試架構 測試架構指的就是測試用例的組織結構。 取得需求文檔：需求定義文檔 需求規(guī)格說明文檔 需求追蹤矩陣 確定測試策略：測試的范圍 測試方法 測試入口 自動化測試策略 確定測試系統(tǒng)：測試架構 測試環(huán)境 測試配置 預估測試工作量：確定任務 按人天和工作周來預估工作量 得到時間進度計劃和里程碑 評估進度風險并制定風險化解計劃 準備并復查測試計劃：編寫策略、系統(tǒng)、工作量和時間進度 文檔與項目團隊一起復查測試計劃 圖 2-20 測試 計劃 活動 2、測試工具 3、測試環(huán)境 測試環(huán)境的組成包括物理測試設施，產品運行 的操作系統(tǒng)、產品運行的計算平臺等。 4、測試配置情況 需要排列配置的優(yōu)先級，然

49、后決定哪些配置 需要全面測試，哪些可以進行部分測試。 三、預估測試工作量（資源和時間進度計劃） 對項目進行預估有5個準備步驟： 1、確定要完成的任務。 2、確定每項任務所需的工作量和整個測試生命周 期的工作量。 3、確定完成每項任務以及整個測試生命周期所 需的時間。 4、為測試工作建立詳細的時間進度計劃和里程 碑表。 5、評估時間進度風險并準備緩解風險計劃。 四、準備并復查測試計劃文檔。 1、測試計劃格式 2、測試計劃復查 2.6.22.6.2測試報告測試報告 測試報告是測試階段最后的文檔產出物，優(yōu) 秀的測試經理應該具備良好的文檔編寫能力，一 份詳細的測試報告包含足夠的信息，包括產品質 量和測

50、試過程的評價，測試報告基于測試中的數(shù) 據(jù)采集以及對最終測試結果的分析。 2.6.32.6.3測試用例的編制測試用例的編制 本節(jié)我們首先討論幾個和測試用例相關的幾 個問題，然后探討如何編制一個有效的測試用例。 一、為什么做測試用例 主要原因有如下幾點：完全測試是不可 能的；輸入量太大；輸出結果太多；軟件 實現(xiàn)途徑太多；軟件說明書沒有客觀標準。從 不同角度看，軟件缺陷的標準不同。 二、什么是測試用例 比較通常的說法是：為達到最佳的測試效果或高效 的揭露隱藏的錯誤而精心設計的少量測試數(shù)據(jù)，稱 之為測試用例。 三、使用測試用例的好處 在開始實施測試之前設計好測試用例，可以避免 盲目測試并提高測試效率。

51、 測試用例的使用令軟件測試的實施重點突出、目 的明確。 在軟件版本更新后只需修正少部分的測試用例便 可展開測試工作，降低工作強度、縮短項目周期。 功能模塊的通用化和復用化使軟件易于開發(fā)，而 用于功能模塊測試的測試用例的通用化和復用化則 會使軟件測試易于開展，并隨著測試用例的不斷精 化其效率也不斷攀升。 四、測試用例在軟件測試中的作用 指導測試的實施 規(guī)劃測試數(shù)據(jù)的準備 評估測試結果的度量基準 分析缺陷的標準 編寫測試腳本的設計規(guī)格說明書 五、測試用例文檔的編制 首先，在編寫測試用例之前需要準備以下幾個編 寫的依據(jù)： 需求說明以及相關文檔； 相關的設計說明（概要設計，詳細設計等）； 與開發(fā)組交流

52、對需求理解的記錄（可以是開發(fā)人 員的一個解釋）； 已經基本成型的UI（可以有針對性地補充一些用 例）。 其次，編寫測試用例文檔應有文檔模板，須符合內 部的規(guī)范要求。 最后一點就是，測試用例文檔應該由簡介和測試 用例兩部分組成。那么，下面從測試用例的設置、 設計、評審、修改以及管理等幾方面來詳細討論測 試用例文檔的編制問題： 1、測試用例的設置 2、測試用例的設計 測試用例可以分為基本事件、備選事件和異 常事件。軟件測試常用的設計測試用例的基本方法 有：等價類劃分法、邊界值分析法、錯誤推測法、 因果圖法、邏輯覆蓋法等。視軟件的不同性質采用 不同的方法。如何靈活運用各種基本方法來設計完 整的測試用

53、 例，并最終實現(xiàn)暴露隱藏的缺陷，則要憑測試設計 人員的豐富經驗和精心設計。 3、測試用例的評審 4、測試用例的修改更新 5、測試用例的管理 測試管理軟件的主要功能有三個： 能將測試用例文檔的關鍵內容； 可供測試實施時及時輸入測試情況； 最終實現(xiàn)自動生成測試結果文檔。 本章小結本章小結 在功能性測試中，我們通常使用離散數(shù)學， 而涉及到結構性測試的領域，我們則會用到關于 圖論的知識。使用這兩方面的知識，有助于我們 更精確的描述軟件測試，減少對測試過程的誤解。 白盒測試與黑盒測試則是軟件測試工作中設計 測試用例的兩個主要的方法。在實際測試過程中， 如果黑盒測試是足夠充分的，那么白盒測試就沒 有必要，

54、但是“足夠充分”只是一種理想狀態(tài)， 例如：真的是所有功能點都測試了嗎？程序的功 能點是人為的定義，常常是不全面的； 各個輸入數(shù)據(jù)之間，有些組合可能會產生問題，怎 樣保證這些組合都經過了測試？難于衡量測試的完 整性是黑盒測試的主要缺陷，而白盒測試恰恰具有 易于衡量測試完整性的優(yōu)點，兩者之間具有極好的 互補性。 白盒測試主要是針對程序的邏輯結構設計測試 用例，用邏輯覆蓋率來衡量測試的完整性。邏輯單 位主要有：語句、分支、條件、條件值、條件值組 合、路徑。語句覆蓋就是覆蓋所有的語句，其他類 推。 另外還有一種判定條件覆蓋，其實是分支覆蓋 與條件覆蓋的組合，在此不作討論。跟條件有關的 覆蓋就有三種：

55、條件覆蓋是指覆蓋所有的條件表達，即所有的 條件表達式都計算了，不考慮計算結果；條件值 覆蓋是指覆蓋條件的所有可能取值，即每個條件 的取真值和取假值都要計算一次；條件值組合覆 蓋是指覆蓋所有條件取值的所有可能組合。 效率比較高且完整性也足夠的測試要求一般 是這樣的：完成功能測試，完成語句覆蓋、條件 覆蓋、分支覆蓋、路徑覆蓋。讀者可能認為這似 乎是不可能的要求，要達到這種測試完整性，其 測試成本是不可想象的，但是通過使用一些工具， 可以在較低的成本下達到這種測試要求。 精心的測試計劃是做好軟件測試的關鍵步驟， 因此應該根據(jù)需求的變更隨時修改測試計劃。全 面地測試文檔，能夠為測試工作提供更好的支持，

56、 因此在測試的過程中應該給測試計劃的制定和測 試文檔的編寫工作以足夠的重視。 習習 題題 請列出下列集合的所有元素： （1）大于4并小于28的所有素數(shù)的集合； （2）大于38并小于70的所有素數(shù)的集合； 調試會遇到哪些困難？白盒測試與調試有哪些 相同點和不同點？ 請闡述白盒測試用例設計的各種方法。 請闡述黑盒測試用例設計的各種方法。 1. 比較白盒測試與黑盒測試各自的優(yōu)缺點。 制定測試計劃的主要步驟有哪些？如何確定測試 范圍？ 為什么要提交測試報告？ 編寫測試用例的依據(jù)有哪些？ 第三章第三章 單元測試單元測試 本章要點本章要點 單元測試的定義； 單元測試同集成測試和系統(tǒng)測試的區(qū)別； 單元測試環(huán)

57、境的組成； 單元測試的分析方法； 單元測試的用例設計方法； 單元測試的過程； 單元測試舉例。 本章目標本章目標 u掌握單元測試的概念； u了解單元測試的誤區(qū)； u了解單元測試與集成測試和系統(tǒng)測試的區(qū)別； u掌握單元測試的策略； u掌握單元測試分析的方法； u掌握單元測試用例設計方法。 3.13.1單元測試概述單元測試概述 通常而言，單元測試是在軟件開發(fā)過程中要 進行的最低級別的測試活動，或者說是針對軟件 設計的最小單位程序模塊，進行正確性檢驗 的測試工作。其目的在于發(fā)現(xiàn)每個程序模塊內部 可能存在的差錯。 在單元測試活動中，軟件的獨立單元將在與 程序的其他部分相隔離的情況下進行測試，主要 工作分

58、為兩個步驟：人工靜態(tài)檢查和動態(tài)執(zhí)行跟 蹤。 單元測試的分工大致如下：一般由開發(fā)組在 一般由開發(fā)組在開發(fā)組組長監(jiān)督下進行，保證使 用合適的測試技術，根據(jù)單元測試計劃和測試說 明文檔中制定的要求，執(zhí)行充分的測試；由編寫 該單元的開發(fā)組中的成員設計所需要的測試用例， 測試該單元并修改缺陷。 3.1.13.1.1單元測試誤區(qū)單元測試誤區(qū) 1、單元測試是一種浪費時間的工作 2、單元測試只能證明代碼做了什么 3、我是個很棒的程序員， 我是不是可以不進行 單元測試？ 4、集成測試能捕捉到所有的Bug 5、單元測試的成本效率不高 其實，在經過了單元測試之后，系統(tǒng)集成過程 將會大大地簡化。 3.1.23.1.2

59、單元測試與集成測試區(qū)別單元測試與集成測試區(qū)別 單元測試與集成測試的主要區(qū)別在于測試的對 象不同。單元測試對象是實現(xiàn)具體功能的單元，一 般對應詳細設計中所描述的設計單元。集成測試是 針對概要設計所包含的模塊以及模塊組合進行的測 試。 單元測試所使用的主要測試方法是基于代碼的 白盒測試。而集成測試所使用的主要測試方法是基 于功能的黑盒測試。 因為集成測試要在所有要集成的模塊都通過 了單元測試之后才能進行，也就是說在測試時間 上，集成測試要晚于單元測試，所以單元測試的 好壞直接影響著集成測試。 單元測試的工作內容包括模塊內程序的邏輯、 功能、參數(shù)傳遞、變量引用、出錯處理、需求和 設計中有具體的要求等

60、方面測試。集成測試的工 作內容主要是驗證各個接口、接口之間的數(shù)據(jù)傳 遞關系、模塊組合后能否達到預期效果。 雖然單元測試和集成測試有一些區(qū)別，但是 二者之間也有著千絲萬縷的聯(lián)系。目前集成測試 和單元測試的界限趨向模糊。 3.1.33.1.3單元測試與系統(tǒng)測試區(qū)別單元測試與系統(tǒng)測試區(qū)別 單元測試與系統(tǒng)測試的區(qū)別不僅僅在于測試 的對象和測試的層次的不同，最重要的區(qū)別是測 試性質不同。在單元測試過程中，單元測試的執(zhí) 行早于系統(tǒng)測試，測試的是軟件單元的具體實現(xiàn)、 內部邏輯結構以及數(shù)據(jù)流向等。系統(tǒng)測試屬于后 期測試，主要是根據(jù)需求規(guī)格說明書進行的，是 從用戶角度來進行的功能測試和性能測試等等， 證明系統(tǒng)是