軟件測試-課程筆記

軟件測試-課程筆記

.第1章軟件測試概述

?軟件測試的背景

?軟件的缺陷及其影響

?什么是軟件缺陷

?軟件缺陷就是軟件產品中所存在的問題，最終表現為用戶所需要的功能沒有完全實現，

不能滿足或不能全部滿足用戶的需求。

?從產品內部看，軟件缺陷是軟件產品開發(fā)或維護過程中所存在的錯誤、誤差等各種問題。

?從外部看，軟件缺陷是系統所需要實現的某種功能的失效或違背。

?軟件缺陷的類型:

?(1)軟件未實現產品說明書要求的功能。

?(2)軟件出現了產品說明書不應該出現的錯誤。

?(3)軟件實現了產品說明書未提到的功能。

?(4)軟件未實現產品說明書雖未明確提及但應該實現的功能。

?(5)軟件難以理解、不易使用、運行緩慢—從測試員的角度看—最終用戶會

認為不好。

?存在軟件缺陷的案例及影響

?(1)千年蟲問題(產生約1974年)

?(2)愛國者導彈防御系統(1991年)

?(3)英特爾奔騰浮點除法缺陷(1994年)

?(4)"沖擊波"病毒(2003年)

?(5)諾基亞手機平臺缺陷(2008年)

?軟件測試的產生與發(fā)展

?軟件測試的產生

?軟件缺陷產生的主要原因：

?(1)需求解釋有錯誤；

?(2)用戶定義錯誤；

?(3)需求記錄錯誤；

?(4)設計說明錯誤；

?(5)編碼說明有誤；

?(6)程序代碼有誤；

?(7)其他有誤，如：數據輸入等。

?軟件測試的發(fā)展

?(1)初級階段(1957-1971年)

?(2)發(fā)展階段(1972-1982年)

?(3)成熟階段(1983年至今)

?修復軟件缺陷的成本

?軟件開發(fā)過程是使用軟件工程的方法，在整個過程中，都有可能出現各種各樣的軟件缺

陷。

?隨著開發(fā)時間的推移，軟件缺陷修復成本呈倍數的增長。假如早在進行分析時發(fā)現相關

功能缺失，立即補上就可了，可以說付出的代價小得幾乎忽略不計.

?如果在發(fā)布時發(fā)現缺失某個功能，那么此時加上一個功能，相當于重新開發(fā)一樣，這時

的修補費用可以說高許多。

?因此要盡早進行測試。

?軟件測試的基本概念

?軟件測試的定義

?軟件測試專家GJ.Myers早在1979年給軟件測試下定義

?軟件測試是為了發(fā)現錯誤而針對某個程序或系統的執(zhí)行過程。

?GJ.Myers給出與測試相關的三個要點

?(1)測試是為了證明程序有錯，而不是證明程序無錯誤；

?(2)一個好的測試用例是在于它能發(fā)現至今未發(fā)現的錯誤；

?(3)一個成功的測試是發(fā)現了至今未發(fā)現的錯誤的測試。

?1990年，IEEE再次給出軟件測試的定義

?(1)在特定的條件下運行系統或構件，觀察或記錄結果，對系統的某個方面做出評價；

?(2)分析某個軟件項以發(fā)現現存的和要求的條件之差別并評價此軟件項的特性。

?軟件測試用例

?軟件測試用例定義

?IEEE標準610(1990)給出的定義：

?測試用例是一組測試輸入、執(zhí)行條件和預期結果的集合,目的是要滿足一個特定的目標，

比如執(zhí)行一條特定的程序路徑或檢驗是否符合一個特定的需求。

?測試用例的元素

?軟件測試設計的關鍵問題可以概括為5W1H

?Why

?為什么測試？對功能、性能、可用性、容錯性、安全性等測試，檢驗是否符合

相關要求。

?What

?測什么？測試的對象可以是文檔，代碼，圖表等。

?Where

?在哪里測？測試用例的環(huán)境，包括系統的硬件、軟件和網絡環(huán)境等。

?When

?什么時候測？測試用例所需的前提條件，盡早開始。

?Which

?什么數據？測試用例設計的各種數據。

?How

?如何執(zhí)行？結果怎樣？要據測試用例設計的步驟來執(zhí)行，最后進行結果比較，

確定是否一致。若一致才能通過測試。

?測試用例設計的基本原則

?從兩個層次考慮測試用例

?（1）低層次

?從單個測試用例看，衡量其描述的規(guī)范性、可理解性及可維護性條等

?（2）高層次

?以滿足某一個測試目標或測試任務來衡量一組測試用例的結構、設計思路和覆

蓋率等；

?測試用例的基本原則

?（1）代表性

?測試用例能代表并覆蓋各種合法的或不合法、邊界內的或越界的以及極限的輸

入數據、操作和環(huán)境的設置。

?（2）可判定性

?測試執(zhí)行的結果的正確性是可以判定的。每一個測試用例都應有相應的預期結

果。

?（3）可再現性

?對于同樣的測試用例，系統執(zhí)行的結果應當相同的，并且相同的測試的執(zhí)行過

程可以反復操作。

?測試用例模板

表1-1測試用例模板

項目名稱程序版本

測試環(huán)境硬件：

軟件:

編制人編制時間

功能模塊名

功能特性

測試目的

預置條件

參考信息特殊規(guī)程說

明

用例編號輸入數據執(zhí)行步驟預期結果測試結果

1

2

表1-2XX測試安裝用例

編號測試內容安裝測試是否通過

1執(zhí)行典型安裝：執(zhí)行安裝步驟，按功能測試方法確認功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息等

2執(zhí)行自定義安裝：執(zhí)行安裝步驟，按功能測試方法確認功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息

等。選擇與典型安裝不同的安裝路徑和功能組件

3執(zhí)行網絡安裝：執(zhí)行安裝步驟，按功能測試方法確認功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息等

4取消或關閉安裝過程，程序沒有安裝，檢查注冊表、安裝路徑

中是否存在程序的任何信息

5按界面和易用性測試規(guī)則，檢查安裝中的所有界面

6按文檔測試規(guī)則，檢查安裝中的所有文檔（幫助、許可協議

等）

7突然中斷安裝過程（網絡安裝還要考慮網絡中斷）

8安裝過程中介質處于忙碌狀態(tài)

?軟件測試環(huán)境

?什么是測試環(huán)境

?軟件測試環(huán)境就是軟件測試運行的平臺。包括系統的硬件、軟件和網絡等。

?可以用一公式來表示

?測試環(huán)境=硬件+軟件+網絡+數據

?測試環(huán)境的搭建和維護

?（1）機房環(huán)境的建立

?（2）硬件環(huán)境的建立

?（3）軟件環(huán)境的建立

?（4）網絡環(huán)境的建立

?(5)安全措施的實施

?軟件測試人員的要求

?軟件測試人員的角色與職責

?測試人員的角色主要有四類

?(1)測試經理

?主要負責測試隊伍的內部管理以及與外部人員、客戶的交流工作，包括進度管理、

風險管理、資金管理、人力資源管理、交流管理等。

?還有測試計劃書的編寫、測試總結報告的歸納等。必須具有項目經理的知識和技能。

?(2)測試設計師

?主要根據軟件開發(fā)各階段產生的設計文檔來設計各階段的測試用例。

?(3)測試文檔審核師

?主要負責前置測試，包括對各個階段的分析與設計文檔進行審核，如：需求說明書、

概要與詳細設計說明書等。

?(4)測試工程師

?對測試設計師設計的測試用例分階段完成測試工作。

?軟件測試人員的基本素質要求

?基本素質要求如下：

?(1)具備計算機軟件測試的基本理論知識

?(2)熟悉開發(fā)工野口平臺

?(3)掌握測試工具的使用

?(4)善于學習，理解與歸納

?(5)耐心、細致、工作態(tài)度好

.第2章軟件開發(fā)過程與軟件測試

?軟件開發(fā)過程概述

?軟件開發(fā)的階段、活動及角色

?軟件工程的階段

?軟件工程的三個階段：

?定義階段

?可行性研究初步項目計劃、需求分析

?圖示

圖2-1軟件工程的定義階段

?開發(fā)階段

?概要設計、詳細設計、實現、測試

?圖示

圖2-2軟件工程的開發(fā)階段

?檢驗交付與維護階段

?運行、維護、廢棄

?圖示

圖2-3軟件工程的檢驗交付與維護階段

?軟件開發(fā)過程的活動

?通常包括四種基本過程活動：

?(1)軟件規(guī)格說明

?規(guī)定軟件的功能、性能及其運行限制。

?(2)軟件開發(fā)

?產生滿足規(guī)格說明的軟件,包括設計與編碼等工作。

?(3)軟件確認

?確認軟件能夠滿足客戶提出的要求，對應于軟件測試。

?(4)軟件演進

?為滿足客戶的變更要求，軟件必須在使用過程中演進，以求盡量延長軟件的生命周

期。

?開發(fā)過程中的角色

?(1)項目經理

?負責管理業(yè)務應用開發(fā)和系統開發(fā)項目。

?(2)業(yè)務分析人員

?理螭口描繪客戶的要求,引導用］協調用戶和業(yè)務需求的收集和確認，并使文檔化。

?(3)架構師

?負責理解系統的業(yè)務需求，并創(chuàng)建合理、完善的系統體系架構。

?并決定相關技術的選擇。

?(4)數據設計人員

?負責定義詳細的數據庫設計。

?(5)程序員

?設計、編寫程序代碼及內部設計規(guī)格說明。

?(6)測試人員

?負責制定測試計劃，并根據計劃進行相關測試，找出產品中的問題。

?(7)產品經理

?負責產品的交付和發(fā)布，以及銷售產品。

?(8)技術支持代表

?負責處理客戶的投訴，以及售后服務問題。

?軟件開發(fā)的過程模型

?線性III頁序模型

?(1)各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；

?(2)由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而

增加了開發(fā)的風險；

?(3)早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現，進而帶來嚴重的后果。

?圖示

圖2-4線性順序模型

?原型模型

?原型模型從需求收集開始，開發(fā)者與用戶在一起定義軟件的總體目標，標識出已知的需

求，并規(guī)劃出進一步定義的區(qū)域，然后快速地設計并進行編碼實現，建立好原型。在原

型模型的基礎上，運行、評估、修改，多次迭代進行，直到滿足用戶的需求為止。

?圖示

聽取用戶意見建造/修改原型

用戶測試運行

原型

圖2-5原型模型

?快速開發(fā)模型

?采用RAD模型時，系統的每一個主要功能部件都可由一個單獨的RAD工作組完成，

最后將所有的部件集成起來構成完整的軟件。

?RAD模型強調可復用程序構件的開發(fā)，并支持多小組并行工作。但若一個系統很難模

塊時，構件的復用和建造會出現許多問題，不適用于技術風險高、采用新技術的項目。

?圖示

第三業(yè)務

小組建模n

數據

第二

業(yè)務_,建模

小組建模F

處理

數據建模

第一業(yè)務建模

小蛆建模應用

口處理_.生成

數據建模J

測試

建模

口應用反復

處理—?生成

建模I

測試

應用_.反復

生成

測試

反復

今

60—90天

圖2-6快速開發(fā)模型

?演化軟件過程模型

?增量模型

?將線性模型與原型模型結合起來，隨著日程/時間的進展而交錯析線性序列集合

?圖示

開發(fā)日程

增

量

序

列

增量_I分析I—l設計I—>1編碼I_>I測試IJ發(fā)布I

增量三|分析|―乂設計?編碼|"-3測試|~T發(fā)布

圖2-7增量模型

?螺旋模型

?也是將線性模型與原型模型結合起來，并加入風險分析

?螺旋模型被劃分為若干框架活動：用戶通信、計劃、風險分析、工程、建造及發(fā)布、

用戶評估等。

?螺旋模型適應于計算機軟件產品的整個生命周期。對于大型系統的開發(fā)是一種模型

方法。

?圖示

圖2-8螺旋模型

?軟件測試與軟件開發(fā)的關系

.軟件測試在軟件開發(fā)過程中占有重要的地位，在傳統的瀑布模型中，軟件測試只成為其階

段性的一段工作一進行代碼的測試.而現代軟件工程思想將軟件測試認為是貫穿整個軟

件生命周期，并且是保證軟件質量的重要手段之一。

?有些研究數據顯示，在國外軟件開發(fā)的工作量中，軟件測試的工作量占有總工作量的40%

左右；軟件開發(fā)的總費用中軟件測試占有對于一些高科技開發(fā)系統，軟件測試

30%-50%o

占有的時間和費用可能更多更高。

?軟件測試的基本原則

?1、測試不是為了證明系統的正確性，而是為了證明系統存在缺陷；

?2、所有的測試都應該追溯到用戶的需求；

?3、測試應當盡早開始和不斷進行；

?4、窮舉測試是不可能的；

?5、第三方測試會更客觀、更有效；

?6、Pareto原則應用于軟件測試；

?7、軟件測試是有風險的行為；但并非所有的測試都要修復；

?8、測試應從小規(guī)模開始，逐步轉向大規(guī)模；

?9、軟件測試是一項講究條理的技術專業(yè)。

?軟件測試方法的分類

?靜態(tài)測試與動態(tài)測試

?靜態(tài)測試

?靜態(tài)測試，是不需要執(zhí)行被測軟件，而是采用分析和查看的方式，來發(fā)現軟件當中的缺

陷，包括需求文檔、源代碼、設計文檔、以及其他與軟件相關文檔中的二義性和錯誤。

最好由未參加代碼編寫的個人或小組來完成。測試小組還能夠使用一個或多個靜態(tài)測試

工具，以源程序代碼作為輸入，產生大量的在測試過程有用的數據。

?圖示

圖2-9靜態(tài)測試的要素

?靜態(tài)測試常用的方法

?(1)走查

?走查是個非正式的過程，檢查所有與源程序代碼相關的文檔。

?(2)審查

?審查比走查要求更加正規(guī)。

?(3)靜態(tài)代碼分析工具

?靜態(tài)結構分析主要是以圖形的方式表現程序的內部結構

?動態(tài)測試

?動態(tài)測試是指通過運行實際被測試軟件，通過觀察程序運行時所表現的狀態(tài)、行為等來

發(fā)現軟件的缺陷。并對被測程序的運行情況進行分析對比，以便發(fā)嵋序表現的行為與

設計規(guī)格或客戶需求不一致的地方。

?動態(tài)測試一般包括功能確認與接口測試，覆蓋率分析、性能分析、內存分析等。

?動態(tài)測試是一種經常運行的測試技術。但也有它的局限性：必須要借助測試用例完成；

需要搭建特定的測試環(huán)境；不能發(fā)現文檔中的問題。

?由于動態(tài)測試與靜態(tài)測試之間存在一定的協同性，又具有相對的獨立性。所以在程序執(zhí)

行前進行靜態(tài)測試，盡可能多地發(fā)現代碼中隱含的缺陷；執(zhí)行動態(tài)測試檢查程序實時的

行為，發(fā)現程序在運行時存在的缺陷。

?黑盒測試與白盒測試

?黑盒測試

?黑盒測試又稱功能測試或數據驅動測試；是將被測試軟件看做一個黑盒子，完全不考慮

程序的內部結構和處理過程，只考慮系統的輸入和輸出，在程序的接口進行測試，檢查

系統功能是否符合需求規(guī)格說明書的要求。

?常用的測試方法

?等價類劃分、邊界值法、決策表法、因果圖法、錯誤推測試法等。

?黑盒測試的優(yōu)點

?黑盒測試用例與程序如何實現無關；

?測試用例的設計與程序開發(fā)可并行設計；

?沒有編程經驗的人也可以設計測試用例。

?黑盒測試的局限性

?不可能做到窮舉測試

?可能存在漏洞。

?白盒測試

?白盒測試又稱結構測試或邏輯驅動測試；是根據被測試程序源代碼的內部結構來設計測

試用例的方法。

?常用的測試方法

?邏輯覆蓋、基本路徑和數據流測試等。

?白盒測試的優(yōu)點

?可以利用不同的覆蓋準則測試程序代碼的各個分支，發(fā)現程序內部的編碼錯誤；

?可以直接發(fā)現內存泄露問題；

?可以充當黑盒測試的檢查手段等。

?白盒測試的局限性

?因程序路徑組合太多，同樣不能做到窮舉測試；

?由于設計測試用例不是根據客戶需求說明進行的測試，可能存需求方面的漏洞。

?灰盒測試

?灰盒測試結合了白盒測試和黑盒測試的要素，關注輸入的正確性，同時了關注內部的表

現；考慮了用戶端、特定的系統知識和操作環(huán)境。它在系統組件的協同環(huán)境中評價應用

軟件的設計。

?人工測試與自動化測試

?按照測試執(zhí)行時是否需要人工干預進行分類，可分為人工測試與自動測試。

?人工測試

?人工測試是人為測試和手工測試的統稱。

?人為測試的主要方法有桌前檢查、代碼審查和走直。

?用于軟件開發(fā)各階段的審查或評審都是人為測試。

?手工測試主要指在測試過程中，按照測試計劃一步一步執(zhí)行程序，得出測試結果并進行

分析的測試行為。

?自動測試

?自動化測試指的是利用測試工具對各種測試活動的管理與執(zhí)行，并對測試結果自動進行

分析。

?在測試的執(zhí)行過程中，一般不需要人工干預。

?常用在功能測試、回歸測試和性能測試等。

?自動化測試的優(yōu)點

?提高測試效率

?降低測試成本

?具有一致性和可重復性

?降低風險，增加軟件的質量等

?自動化測試的局限性

?自動化測試軟件本身的問題

?測試人員期望過高

?有些人工測試是不能用自動化測試替代等。

?其他測試分類

?基于模型的測試與模型檢測

?基于模型的測試，是指對軟件行為進行建模以及根據軟件的形式化模型設計測試的活動。

?模型檢測是指，用來驗證軟件特定模型中的一個或多個特性的一類技術。

?模型通常是有限狀態(tài)的，是從一些原始材料中提取出來的，這些原始材料可能是需求文

檔，也可能是系統源代碼本身。有窮狀態(tài)模型中的每一個狀態(tài)前都有一個或多個前置條

件，當軟件處于該狀態(tài)時，這些特性必須滿足。見圖2-10所示說明模型檢測過程。

?圖示

原始材料:模型——

需求

以往經驗）模型檢測器

源程序特性一

特性滿足嗎？

修改模型或原

始材料

圖2-10模型檢測的要素

?冒煙測試

?冒煙測試是指在測試中發(fā)現問題，也就是說找到了一個缺陷，由開發(fā)人員來修復這個缺

陷，當修復完成后，是否真的解決了這個缺陷，或對其他模塊是否存在影響，因此要針

對這個問題進行專門的測試，這個測試過程稱為冒煙測試。

?在許多情況下，經過測試后，發(fā)現修復某個問題會引起其他功能模塊一系列的反應，導

致產生新的缺陷。冒煙測試的優(yōu)點是節(jié)省測試時間，防止創(chuàng)建失敗。缺點是覆蓋率較低。

?隨機測試

?隨機測試是根據測試說明書執(zhí)行樣例測試的一種重要補充手段，是保證測試覆蓋完整性

的有效閱和過程。

?隨機測試主要針對系統的一些重要功能進行復測。

?還對軟件更新和新增的功能要進行重點測試。常與回歸測試一起進行。

?軟件測試方法在軟件開發(fā)過程的運用

?L在軟件需求分析與建模階段中

?主要進行軟件目標的定義，可行性研究和軟件需求分析工作。

?這時測試的對象是相關文檔資料，

?如：需求規(guī)格說明書等。從需求的完備、可實現、是否合理、是否可測試等方面進行評審，

采用的靜態(tài)測試方法。

?2、在概要設計與詳細設計階段

?概要設計描述總體系統架構中各個模塊的劃分及相互之間的關系；詳細設計則描述各個模

塊具體的算法和數據結構。

?這些都是用文字、圖表的形式進行描述的，測試時也是用靜態(tài)測試的方法，對文字、圖表

進行評審。

?3、在編碼工作階段，

?主要是采用高級語言對已詳細設計的模塊進行編程。

?這時的測試工作主要是對已有的程序代碼進行白盒測試，可以是靜態(tài)與動態(tài)相結合，采用

各種覆蓋方法進行測試，此時主要由程序員進行測試。

?4、在測試階段中

?此時進行的集成與系統測試。

?集成測試采用灰盒測試方法（白盒測試與黑盒測試相結合），主要測試產品的接口以及各

模塊之間的關系。

?而系統測試一般采用黑盒測試方法，主要測試系統的功能、性能等；由測試人員來完成測

試。

?5、在檢驗交付與維護階段

?模擬或實際客戶環(huán)境，對系統進行驗收測試。

?大多采用自動化測試工具進行測試驗收。

?包括功能測試、性能測試、回歸測試、發(fā)布測試等。

?軟件測試的過程模型

?V-model

?v-model模型是最早的軟件生存期模型，在20世紀80年代由PaulRook提出的。

?v-model包含了三個等級，分別是生存期模型，分配模型，功能性工具需求模型，闡述了

應當實施哪些活動，應當產生哪些結果，諸如此類。

?圖示

圖2-11v-model

?V-model指出，單元測試所檢測代碼的開發(fā)是否符合詳細設計的要求。集成測試所檢測此

前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測已集成在一起的產品是

否符合系統規(guī)格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。所以V-

model模型軟件測試的策略既包括低層測試又包括高層測試，底層測試是為了驗證系統源

代碼的正確性，高層是為了測試整個系統是否滿足用戶的需求。

?V-model的缺陷

?僅僅把測試過程作為在需求分析、系統設計及編碼之后的一個階段忽視了測試對需求分

析，系統設計的驗證，一直到后期的驗收測試才被發(fā)現。

?W-model

?W模型由Evolutif公司提出，相對于V-model,W-model更科學,W-model是V-

model的發(fā)展。由于V-model的局限性，沒有明確地說明早期的測試，無法體現"盡早地

和不斷地進行軟件測試”的原則。在V-model中增加軟件各開發(fā)階段應同步進行的測試，

演化為W-modeL如圖2-12所示。

?圖示

圖2-12W-model

?W-model,強調的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、

功能和設計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現問題。以需求

為例，需求分析一完成，我們就可以對需求進行測試，而不是等到最后才進行針對需求的

驗收測試。

?W-model的局限性

?W模型和V模型都把軟件的開發(fā)視為需求、設計、編碼等一系列串行的活動，軟件開

發(fā)和測試保持一種線性的前后關系，需要有嚴格的指令表示上一階段完全結束，才可以

正式開始下一個階段。這樣就無法支持迭代、自發(fā)性以及變更調整。對于當前很多文檔

需要事后補充，或者根本沒有文檔的做法下，開發(fā)人員和測試人員都面臨同樣的困惑。

?H-model

?H-model,它將測試活動完全獨立出來，形成一個完全獨立的流程，將測試準備活動和測

試執(zhí)行活動清晰地體現出來。如圖2-13所示:

?圖示

圖2-13H-model

?H-model揭示了：

?(1)軟件測試不僅僅指測試的執(zhí)行，還包括很多其他的活動；

?(2)軟件測試是f獨立的流程，貫穿產品整個生命周期，與其他流程并發(fā)地進行；

?(3)軟件測試要盡早準備，盡早執(zhí)行；

?(4)軟件測試是根據被測物的不同而分層次進行的。不同層次的測試活動可以是按照

某個次序先后進行的，但也可能是反復的。

?X-model

?X-model的基本思想是由Marick提出的，他認為一個模型必須能處理開發(fā)的所有方面,

包括交接，頻繁重復的集成，以及需求文檔的缺乏等等。而X-model填補了V-model的

缺陷，并可為測試人員和開發(fā)人員帶來明顯的幫助。如圖2-14所示。

?圖示

圖2-14X-model

?pretest-model

?pretest-model,它是將測鹿口開發(fā)緊密結合的模型，該模型提供了輕松的方式，可以使你

的項目加快速度。如圖2-15所示。

?圖示

?Pretest-model體現了以下的要點

?(1)開發(fā)和測試相結合

?(2)對每T交付內容進行測試

?(3)在設計階段進行測試計劃和測試設計

?(4)測試和開發(fā)結合在一起

?(5)讓驗收測試和技術測試保持相對獨立

?測試模型的使用

?V-model強調了在整個軟件項目開發(fā)中需要經歷的若干個測試級別，而且每一個級別都與

一個開發(fā)級別相對應，但它忽略了測試的對象不應該僅僅包括程序，或者說它沒有明確地

之處應該對軟件的需求、設計進行測試。

?W-model強調了測試計劃等工作的先行核對系統需求和系統設計的測試，但W-model

和V-model一樣也沒有專門對軟件測試流程予以說明，因為事實上，隨著軟件質量要求越

來越為大家所重視，軟件測試也逐步發(fā)展成為一個獨立于軟件開發(fā)部的組織，就每一個軟

件測試的細節(jié)而言，它都有一個獨立的操作流程。比如，現在的第三方測試，就包含了從

測試計劃和測試案例編寫，到測試實施以及測試報告編寫的全過程，

?H-model強調測試是獨立的，只要測試準備完成，就可以執(zhí)行測試了。

?X-model和Pretest-model又在此基礎上增加了許多不確定因素的處理情況，因為在真

實項目中，經常會有變更的發(fā)生，例如需要重新訪問前一階段的內容，或者跟蹤并糾正以

前提交的內容，修復錯誤，排除多余的成分，以及增加新發(fā)現的功能等。

.第3章白盒測試

?白盒測試基本概念

?白盒測試又稱為結構測試或邏輯驅動測試，是針對被測試程序單元內部如何工作的測試，特點

是基于被測試程序的源代碼，而不是軟件的需求規(guī)格說明。

?使用白盒測試方法時，測試者必須全面了解程序內部邏輯結構，檢查程序的內部結構，從檢查

程序的邏輯著手，對相關的邏輯路徑進行測試，最后得出測試結果。

?采用白盒測試方法必須遵循原則

?（1）保證一個模塊中的所有獨立路徑至少被測試一次。

?（2）所有邏輯值均需測試真值和假值兩種情況。

?（3）檢查程序的內部數據結構，保證其結構的有效性。

?（4）在上下邊界及可操作范圍內運行所有循環(huán)。

?靜態(tài)白盒測試方法

?靜態(tài)白盒測試主要通過審杳、走查、檢驗等方法，來查找代碼中的問題和缺陷。

?主要原因是為了盡早發(fā)現軟件缺陷，以找出黑盒測試難以發(fā)現或隔離的軟件缺陷。其次，為黑

盒測試員在接受軟件進行測試設計時，設計和應用測試用例提供思路。通過審查評論，可以確

定有問題或者容易產生軟件缺陷的特性范圍。

?檢查設計和代碼

?靜態(tài)白盒測試是在不執(zhí)行軟件的條件下有條理地仔細審查軟件設計、體系結構和代碼，從

而找出軟件缺陷的過程。

?有時又稱為結構化分析。

?正式審查

?正式審查有四個要素

?（1）確定問題

?（2）遵守規(guī)則

?（3）準備

?（4）編寫報告

?正式審查的效果

?正式審查的主要的目的是找出軟件中存在的缺陷，除此之外，還可以形成一些間接的效

果。

?如：程序員與程序、測試人員之間的交流，增強相互了解；程序員會更仔細的編程，提

高正確率等。正式審查是把大家聚在一起討論同一個項目問題的良機。

?正式審查幾種類型

?（1）同事審杳

?（2）走杳

?（3）檢驗

?編碼標準和規(guī)范

?在編程和審查程序代碼時，建立相關的規(guī)范和標準，并堅持標準或規(guī)范。

?三個重要的原因

?（1）可靠性

?堅持按照某種標準和規(guī)范編寫的代碼更加可靠和安全。

?（2）可讀性/維護性

?符合設備標準和規(guī)范的代碼易于閱讀、理瞬口維護。

?（3）移植性

?代碼符合設備標準，遷移到另一個平臺就會輕而易舉，甚至完全沒有障礙。

?編程標準和規(guī)范示例

?（1）編程標準的4個組成部分

?①標題

?描述標準包含的主題。

?②標準（或規(guī)范）

?描述標準或規(guī)范的內容。

?③解釋說明

?給出標準背后的原因，以使程序員理解為什么這樣是好的編程習慣。

?④示例

?給出如何使用標準的簡單程序示例。

?（2）示例

?如圖3-1所示，是一個針對C++中所用的（:語言特性的規(guī)范示例。說明在C++中

如何使用某些C語言特性的編程。

?圖示

TOPIC:7.02C_problems-ProblemareasfromC

GUIDELINE

TrytoavoidClanguagefeaturesifaconflictwithprogramminginC++

DonotuseandJpngjniAifthereareanyobjectswithdestructorswhich

could忱createdbetweentheexecutionofthe5的mpandthe

Donotusetheoffsetofmacroexceptwhenappliedtomembersofjust-a-struct.

DonotmixC-styleFILEl/O(usingstdio.h)withC++styleI/O(usingjostream.hor

stream.h)onthesamefile.

AvoidusingCfunctionslikememcpyormemcapforcopyingorcomparingobjects

ofatypeotherthanarray-of-charorjust-a-struct.

AvoidtheCmacroNULL;use0instead.

JUSTIFICATION

EachofthesefeaturesconcernsanareaoftraditionalCusagewhichcreatesome

probleminC++.

圖3-1C++中所用C語言特性的程序示例

?獲取標準

?國際標準化組織（ISO）:www.iso.ch

?電子電氣工程學會（IEEE）:

?美國國家標準學會（ANSI）:

?國際工程協會（正C）:

?信息技術標準國家委員會（NCITS）:

?美國計算機協會（ACM）:

?通用代碼審查清單

?1、數據引用錯誤

?數據引用錯誤是指使用未經正確聲明和初始化的變量、常量、數組、字符串或記錄而導

致的軟件缺陷。

?數據引用錯誤是緩沖區(qū)溢出的主要原因。

?2、數據聲明錯誤

?數據聲明缺陷產生的原因是不正確地聲明或使用變量和常量。

?3、計算錯誤

?計算或運算錯誤就是計算無法得到預期的結果。

?4、比較錯誤

?在使用比較和判斷運算時產生的比較和判斷錯誤，這種錯誤很可能是因為邊界條件問題。

?5、控制流程錯誤

?控制流程錯誤產生的原因是編程語言中循環(huán)等控制結構未按預期的方式工作。

?通常由計算或者比較錯誤直接或間接造成。

?6、子程序參數錯誤

?子程序參數錯誤的來源是軟件子程序不正確地傳遞數據。

?7、輸入/輸出錯誤

?輸入輸出錯誤包括文件讀取、接受鍵盤或鼠標輸入，以及向打印機或屏幕等輸出設備寫

入錯誤。

?8、其他檢查

?程序復雜度及度量方法

?在實際的軟件開發(fā)過程中，人們發(fā)現程序的復雜度不僅影響軟件的可維護性、可測試性及可靠

性等，而且與軟件中故障的數量、軟件的開發(fā)成本及軟件的效率有關。

?流圖的概念

?流圖又稱程序圖，實際上可以看作是一種簡化了的程序流程圖。在流圖中，只關注程序的

流程，不關心各個處理框的細節(jié)，因此，原來程序流程圖中的各個處理框（包括語句框、

判斷框、輸入/輸出框等）都被簡化為結點，一般用圓圈表示，而原來程序流程圖中的帶有

箭頭的控制流變成了程序圖中的有向邊。

?結構化程序設計中的幾種基本結構的流圖。如圖3-2所示。

?圖示

圖3-2流圖的幾種基本結構

（a）順序結構：（b）分支結構；（c）循環(huán)結構;

?簡化后的流圖只有兩種圖形符號：結點和控制流線。

?結點用帶標號的圓圈表示，可以代表一個或多個語句、一個處理框或一個判斷框。

?控制流線用帶箭頭的弧線表示，代表程序中控制流。

?從圖論的觀點來看，流圖是一個可表示為G=<N,E>的有向圖。

?其中，N表示圖中的結點，而E表示圖中的有向邊。

?流圖可以通過簡化程序流程圖得到，也可以由PAD圖或其他詳細設計表達工具變換得到。

?圖3-3是典型的程序流程圖轉換為相對應的流圖。對圖3-3中的(a)所示的程序流程圖進

行簡化，得到圖3-3(b)所示的流圖。

?圖示

(a)(b)

圖3-3程序流程圖及對應的流圖

(a)程序流程圖；(b)流圖

?環(huán)形復雜度

?環(huán)形復雜度又稱為圈復雜度，是一種為程序邏輯復雜度提供定量尺度的軟件度量。它可以

提供程序基本集的獨立路徑數量和確保所有語句至少執(zhí)行一次的過程。常用于基本路徑測

試法。

?環(huán)形復雜度的度量方法又稱為McCabe方法。一個強連通流圖中線性無關的有向環(huán)的個數

就是該程序的環(huán)形復雜度。而強連通圖，是指從圖中任意一個結點出發(fā)都能到達圖中其他

結點的有向圖。

?在圖論中可以通過以下公式來計算有向圖中線性無關的有向環(huán)的個數。

?V(G)=m-n+p①

.其中：V(G)表示有向圖G中的線性無關的環(huán)數；

?m表示有向圖G中有向邊的個數；

?n表示有向圖中的結點數；

?p表示有向圖G中可分離出的獨立連通區(qū)域數，為常數L

?流圖雖為連通圖，但不是強連通圖，可以在流圖中增加一條出口點到入口點的虛弧線，此

時，流圖就變成了一個強連通圖。如圖3-4所示，在圖3-3(b)流圖添加虛弧后得到的強

連通圖。

?圖示

圖3-4將圖3-3(b)變換后的強連通圖

?采用上面的公式①計算它的環(huán)形復雜度為：

?V(G)=13-10+1=4

?圖3-4強連通圖的復雜度是4,因此圖3-4中有4個線性獨立環(huán)路。此時刪除從結點E

到結點S的虛弧，則這4個環(huán)路就是結點S到結點E的線性獨立路徑。

?4條融獨立路徑：

?Pathl:S—a—>b-g-E

?Path2:S—a—b—g-h一E

?Path3:S—a—b—c—dTf—b—g—E

?Path4:S—*aTb—c一e一f—?b一g一E

?除了采用上面的公式①可以計算環(huán)形復雜度外，還可以用其他的公式計算出流圖中的環(huán)

形復雜度。

?V(G)=強連通的流圖在平面上圍成的區(qū)域數②

?V(G)=判定結點數+1③

?圖3-4中，流圖中圍成的區(qū)域有(b,c,d,f,b),(c,d,f,e,c),(g,h,E,g)和

(S,a,b,g,E,S),因此公式②計算得到的流圖環(huán)形復雜度為4。

.在圖3-4中，判定結點分別為b,c和g,根據公式③可得環(huán)形復雜度為：3+1=4。

?圖矩陣

?圖矩陣是流圖的鄰接矩陣的表示形式，其階數等于流圖的結點數，矩陣的每列與每行都對

應于標識的某一結點，矩陣元素對應于結點之間的存在的邊；有邊取值為1,否則為0或

不填。

?如圖3-5和圖3-6所示，一個簡單流圖及對應的鄰接矩陣：

?圖示

結點1234

11

21

31

41

圖3-5一個流圖圖3-6對應的鄰接矩陣圖

?動態(tài)白盒測試方法

?動態(tài)白盒測試主要是按一定步驟和方法生成測試用例，并驅動相關模塊去執(zhí)行程序并發(fā)現軟件

中的錯誤和缺陷。測試人員要求對被測系統內的程序結構有深入的認識，清楚程序的結構、各

個組成部分及其之間的關聯，以及其內部的運行原理、邏輯等。

?內容包括的4部分

?（1）直接測試底層函數、過程、子程序和庫。

?（2）以完整程序的方式從頂層測試軟件，有時根據對軟件運行的了解調整測試用例。

?（3）從軟件獲得讀取變量和狀態(tài)信息的訪問權，以便確定測試結果與預期結果是否相符，

同時強制軟件以正常測試難以實現的方式運行。

?（4）估算執(zhí)行測試時"命中"的代碼量和具體代碼，然后調整測試，去掉多余的測試用例，

補充遺漏的測試用例.

?邏輯覆蓋法

?邏輯覆蓋法是動態(tài)白盒測試中常用的測試技術，是一系列測試過程的總稱。有選擇地執(zhí)行

程序中的某些最具有代表性的通路來對盡窮測試的唯一可行的替代方法。

?邏輯覆蓋法的覆蓋率是程序中一組被測試用例執(zhí)行到的百分比。

?覆蓋率=（至少被執(zhí)行一次的被測試項數）/被測試項總數

?根據測試覆蓋的目標不同，以及覆蓋的程度不同，可由弱到強分為：語句覆蓋、判定覆蓋、

條件覆蓋、判定/條件覆蓋、修正的判定/條件覆蓋、條件組合覆蓋、路徑覆蓋

?語句覆蓋和塊覆蓋

?語句覆蓋又稱為代碼行覆蓋，指選擇足夠多的測試用例，使得程序中的每一條可執(zhí)行語

句至少被執(zhí)行一次。

?程序的基本塊就是一個連續(xù)的語句序列，只有一個入口點和一個出口點。這些唯一的入

口點和出口點就是基本塊的第一條語句和最后一條語句。程序的控制總是從基本塊的入

口點進入，從出口點退出。除了其出口點，程序不可能在基本塊的其他任意點退出或中

止。

?例子

?圖

例3-1下面以一個簡單的小程

序段來說明怎樣設計測試用

例。

VoidtestexampleKintx,int

y,intz)

(

if(x>l)&&(y==0)

z=z+x;

if(x==2)||(z>l)

z=z+y;

圖3?7例3?1的模塊的流程圖

returnz;

圖中數字L2.3.4.5.6.7為邊。

)

對于這段testexamplel函數

相對應的程序控制流程圖見圖

3?7所示。

對于testexamplel函數，完全語句覆蓋是從第1行執(zhí)行到

最后一行。因此它的測試用例的設計見表3-1：

表3-1testexamplel語句沒盅測試川例

輸入數據返回值通過的路徑

ID

XyZZ

TE1-00120461-4-5-6-7

對于testexamplel函

數，其函數體可以分

為五個塊，第一塊為

第一個if語句；第二塊

為賦值語句z=z+x；

第三塊為第二個if語

句；第四塊是賦值語

句2=2+丫；第五塊是

returnz語句。將圖圖3-8testexamplel函數體的控制流圖

3-7換為圖3-8所示。

?塊覆蓋的測試用例的設計是要將這五塊都要遍歷，表3-1語句覆蓋的測試用例也就

是這個函數的塊覆蓋的測試用例。

?注意，語句覆蓋是覆蓋所測試程序段中的所有語句，塊覆蓋是測試程序段中的所有

基本塊。

?判定覆蓋

?判定覆蓋又叫分支覆蓋，即設計若干測試用例，使得程序中的每個判定表達式的每種可

能的結果值都應該至少執(zhí)行一次，也就是說每個判定的"真"值分