TESTUM1.4

理解

測試測試是質量保證的重要測試:Software

TestingTEST來源于拉丁語“TESTUM”，古羅馬的一種陶罐，用于評估象稀有金屬礦石等材料。可見，測試與產品質量密不可分。1測試測試在

開發中占有重要地位測試成本占有開發成本的近一半2開發成本分布類型開發成本按階段分布%需求與設計實現測試控制462034航空航天342046操作系統331750科技計算442630商業應用4428283開發中，在需求、設計、編碼階段都有可能發生錯誤。測試就是為了發現

中的錯誤或缺陷而分析或執行程序的過程。具體說，

測試是根據

開發各階段結構而精心設計的一組試用例以發現

錯誤的過的規格說明及程序的測試用例，并執程。測試是

質量保證的重要

。測試有兩個基本的功能：驗證（Verification）和確認（Validation）驗證：指保證

正確實現了特定功能的一系列活動確認：指保證最終的產品滿足系統的需求1.4.1

基本概念4測試的目的：測試的目的在于發現錯誤或缺陷好的測試用例能有效地發現別的測試用例未發現的錯誤或缺陷成功的測試是發現了未曾發現的錯誤或缺陷5測試的對象測試數據程序P結果數據程序測試：發現程序中的錯誤或缺陷6測試的對象測試數據程序P比較結果數據預期數據相符不符追查缺陷程序測試：發現程序中的錯誤或缺陷程序正確性的各種情況程序編寫無語法錯誤程序執行中未發現明顯的運行錯誤程序中無不適當語句7需求規格說明設計規格說明程序測試的對象測試：發現程序及前期開發過程的錯誤/缺陷測試的對象8“zero-bug”指 沒有任何bug,是理想狀態“good

enough”是指只要 達到一定的質量要求,就可以停止測試了。但是，不充分的測試是不負責任的，過分的測試是一種資源浪費，

同樣也是不負責任。別試圖窮舉測試例如，一個程序需3個整型的輸入數據，若計算機的字長為32位，則每個數據可能取的值有232個，3個數的排練組合共有232*232*232

=

296（種）,若每執行一次需1毫秒，則需2萬年。開發

不能既是運動員又是裁判員測試的基本原則9測試要盡早進行測試應該追溯到需求80-20原則(即缺陷的二八定理、集群現象或蟲子窩現象、

pareto原則)：80％的錯誤在20％的模塊中，經常出錯的模塊改錯后還會經常出錯。缺陷具有免疫性(“殺蟲劑”怪事)程序員修改完缺陷，測試

根據相同的測試用例對新版本進行測試，其效果會大打折扣另外，每修復3~4個bug，一般會產生1個新的bug,因此要充分注意修改所產生的影響。并非所有bug都需要修復保存測試文檔(測試計劃、測試用例、缺陷統計、最終分析報告等)測試的基本原則10注意：測試能提高

的質量，但是提高質量不能依賴測試測試只能證明錯誤存在，不能證明錯誤不存在測試的主要

是不知道如何進行有效地測試，也不知道什么時候可以放心地結束測試每個程序員都應當測試自己的程序（份內之

事），但是不能作為該程序已經通過測試的依據（所以項目需要獨立測試

）測試是

質量的重要保證，但不能100%地保證。11測試用例的實例

P11如何測試一個

？假定測試一個數碼相機的拍照功能，進行如下活動：檢查相機電源、

卡空間、將相機工作模式設置為“拍攝”按下快門進行拍攝在取景框中所看到的內容應該被拍下來將相機工作模式設置為“

”，檢查拍攝的前提條件操作步驟預期結果和實際結果（對比）12測試用例測試用例(Test

Case,TC)？指在測試執行之前設計的一套詳細的測試方案，包括三要素:前提條件(測試數據)、操作步驟、預期結果和實際結果。即：測試用例=輸入+輸出輸入：前提條件/測試數據,操作步驟輸出：預期結果測試環境：系統環境設置測試是一個或多個測試用例的集合。13用例前提條件/輸入數據操作步驟預期結果實際結果123………………….基本測試用例表:14在對

進試時，需要：構造測試用例執

試用例，檢查實際結果是否與期望的輸出一致需求為依需求中找在編寫測試用例時，需要以據。測試用例的三要素都需要在到相應的依據。15典型的bug產生的原因一般為：用戶需求定義有誤需求記錄有誤設計說明有誤編碼說明有誤程序代碼有誤數據輸入有誤測試錯誤問題修正不正確由其他bug產生的不正確結果1.4.3錯誤產生原因：16信息傳遞的誤差用戶想要的用戶所說的需求分析理解的《系統需求規格說明書》實際系統需求規格說明書不完全等同于用戶的需求17典型的

錯誤或缺陷產生的原因產品說明書（需求分析）56%其他10%編寫代碼7%設

計27%缺陷產生的原因分布作為bug的大來源，對需求規格說明書和設計------隨意、易變更、開發小組溝通不足，與用戶溝通不足代碼錯誤：的復雜性、文檔不足、進度壓力或普通低級錯誤其他：把誤解當成bug、bug反復出現、測試錯誤等18修復缺陷的代價測試員的目標是盡可能早地找出bug，并應力求完美，但千萬不能在無法達到的完美上糾纏和繞圈子191.5測試的分類P13對于

測試，可以從不同的角度加以分類：基于是否關注黑盒測試白盒測試結構與算法基于是否執行被測試靜態測試動態測試基于測試的不同階段(每個階段有不同的測試目標、測試對象、測試方法)單元測試集成測試系統測試驗收測試請看P13表1-420功能測試

性能測試

負載測試

壓力測試

易用性測試界面測試安裝與卸載測試兼容性測試常見的測試的內容恢復測試安全性測試內存

測試比較測試Alpha

測試Beta測試回歸測試……請看P14基本概念21不同測試分類間的關系221.5.1

黑盒測試和白盒測試黑盒測試白盒測試兩種測試方法從不同的角度出發，反映了

的不同側面，也適用于不同的開發環境23輸入輸出黑盒測試方法以程序的功能為重點，把程序看成一個黑盒子，不依據程序的

結構，而依據程序的外部功能---輸入和輸出，通過分析程序的輸入和輸出來設計測試用例。輸入輸出黑盒測試又稱功能測試、數據驅動測試或基于規格說明的測試，也可稱為用戶測試，主要測試依據是

需求。25應用程序白盒測試需要完全了解程序結構和處理過程，它按照程序邏輯測試程序，檢驗程序中每條通路是否按預定要求正確工作。26白盒測試又稱結構測試、邏輯驅動測試、基于程序本身的測試、玻璃盒測試，也可稱為程序員測試，主要依據是設計。應用程序27檢查一個163郵箱的登錄界面，這使用黑盒測試方法，因為不需要知道其代碼的編寫內容，只需要根據輸入的數據來判斷是否能登錄,是否出錯檢查一段代碼例如一個函數的編寫和代碼的結構，則需要進行白盒測試，因為涉及到代碼的結構例子：281.5.2

靜態測試和動態測試靜態測試不執行被測試的。類似于汽車檢查。29動態測試是在測試過程中執行被測試，類似于試車。30例子void

main(void){int

a[5];int

i=0;printf(“please

input

5

datas\n”);for(i=0;i<5;i++){scanf(“%d”,&a[i]);iszero(a[i]);}#include

<stdio.h>void

iszero(int

m){

if(m!=0)printf(“%d”,m)