軟體測試之實務講座,來自矽谷的技術經驗與心得分享,李幸超著作
目錄
第一章 軟體測試概述
第二章 軟體測試方案的制訂與測試計畫書的編寫
第三章 軟體測試技術簡介
3.1 白箱測試與黑箱測試
白箱其實是一種玻璃盒,可以看到裡面的一切,包括它的結構及各個組成部分,在操作白箱時,它的運作及過程等都可以看到.當把一樣東西放到黑箱裡,裡面的一切都看不到,在操作黑箱並讓它執行時,甚麼也看不到,只能知道它的執行結果.
3.2 白箱測試
一般是由開發工程師完成,當然也有專門做白箱測試的測試工程師.白箱測試人員必須對測試中的軟體有深入的認識,包括其結構,各組成部分及之間的關聯,以及其內部的執行原理,邏輯等等.白箱測試人員實際上是程式師和測試員的結合體.白箱測試是基於軟體系統的內部結構來設計軟體實例.白箱測試的主要依據是軟體的設計說明書.白箱測試技術包括以下幾種:
3.2.1 基本路徑測試以不同覆蓋率為依據來設計測試案例,在設計時需要考慮的覆蓋類型包括:
- 條件覆蓋---這類測試的覆蓋率是路徑測試中最高的
- 分支覆蓋---根據各條件陳述式設立測試案例,條件為真及條件為假各設一測試案例.
- 語句覆蓋---對每一語句進行至少一次的測試,測試覆蓋率太低.
3.2.2 漸進式測試分為縱向與橫向兩類:橫向即是單元測試及組合測試;縱向即由上至下與由下至上的測試.
- 單元測試與組合測試,單元測試就是對軟體的每一單元或模組進行獨立測試.在單元測試完成之後,把已經通過測試的幾個單元或模組進行組合(整合)測試.
- 由上至下與由下至上的測試:
- 由上至下的測試是指從軟體的最頂層開始測試,然後一層一層下移到最底層.由上至下測試需要編寫許多虛擬模組來輔助測試,所謂的虛擬模組的作用就在於代替未被測試的模組.讓上層正在測試的模組呼叫,並在呼叫完畢後將控制交回呼叫它的模組,並返回真正模組返回的值.
- 由下到上的測試是指從軟體的最下層開始測試,然後一層一層上移到最頂層.所謂的頂層是指軟體最接近使用者的那一層,也就是使用者介面及功能那一層.這種測試往往需要編寫測試驅動器,也就是很小的測試程式,專門用於呼叫被測試層面的模組或系統單元.
一般情況下,編寫虛擬模組比編寫測試驅動器要簡單,因而比較省時.測試驅動器和虛擬模組都可以用於迴歸測試.測試完會把它們放在一起,當新版本推出時,利用這些模組從頭再測試一遍.
除以上最常用的白箱測試技術以外,還有白箱測試的靜態測試和總體測試等.總體測試只是將整個系統整合之後再來進行總體測試.由於軟體各部分都沒有先通過測試,因而總體測試很難找出出錯的根源.
白箱的靜態測試也稱為程式檢驗,白箱的靜態測試包括:
- 找出原始程式碼的語法錯誤
- 找出原始程式碼的非語法錯誤,這包括:
- 檢測原始程式碼的完整性及一致性
- 檢查原始程式碼的邏輯設置是否正確
- 對照設計文件,檢查原始程式碼是否按照其中的描述來編寫
最常見的靜態測試是找出原始程式碼的語法錯誤,這類測試可由編譯器來完成,因為它可以逐行分析檢驗程式的語法,找出錯誤並報告.測試員也可用目測的方法來檢驗程式,有些地方存在著非語法方面的錯誤,只有透過目測來判斷.
3.3 黑箱測試
系統測試中黑箱測試的主要依據是規格說明書及使用者手冊,按照規格說明書中對軟體各功能的描述,對照軟體在測試過程中的表現,這類測試又稱為軟體驗證.以使用者手冊,系統要求等對外公布的檔案為依據進行的測試則稱為軟體審核.
黑箱測試分為功能測試以及非功能測試兩大類.
3.3.1 功能測試
功能測試主要針對軟體的各項功能及它們的組合,不需要像系統測試,整體測試那樣等到整個軟體都做好了才進行.功能測試可以和程式設計並進,只要某部分功能可以交付測試,測試員就可以按照規格說明對這部分的描述進行功能測試.
功能測試主要包括:
3.3.1.1 等價區域值與邊界值測試
在測試軟體某部分時,如該部分具有接收輸入資料的功能或具有輸出資料的功能,則我們應該對規格說明書中有關的輸入或輸出資料進行分析.將輸入資料分為若干等價區域,並找出邊界值,在編寫測試案例時,我們只需在邊界值之間的每一等價區域中抽出一個(或一組)資料來代表整個區域.所謂等價,就是在此區域中取任意資料登入,其結果都應相同.而所謂邊界值,往往是取規格說明書規定的資料範圍的極端或往外端移動一個位置.利用等價區域值的概念,可以找出以下幾組資料:
- 有效資料組
- 無效資料組
3.3.1.2 狀態轉移測試
軟體的執行是透過不同的狀態轉換實現的,在這個過程中,軟體的每一個功能都有各自不同的狀態,而最基本的就是初始狀態和終端狀態.
3.3.1.3 隨機測試
一般來講,隨機測試是在系統測試的基礎上進行的,而且一般都不會寫成測試案例,有豐富測試經驗的測試員通過觀察,可以估計那些地方出現毛病的可能性最大,用甚麼樣的測試手段最容易令軟體發生故障.隨機測試有許多都是非常規的測試.也就是終端使用者在正常情況下不會那樣去使用軟體,但是沒有人可以保證這種情況永遠不會發生.軟體測試就是要找出軟體裡盡可能多的缺陷,無論你使用的是甚麼樣的測試方法.
隨機測試一般比較難用自動測試來實現.隨機測試不可以代替常規的功能或非功能測試.因為它屬於隨意性大,沒有一套完整嚴格的方法且並非有章可循的測試技術.
3.3.2 非功能測試
黑箱測試也包括非功能測試部分.非功能測試中有不少是屬於系統測試.例如配置測試,安裝與移除測試,使用性能測試等.
3.3.2.1 使用性能測試
使用性能測試一般是由使用者實現的.通常由於使用者接觸該軟體的時間不長,因而需要在測試人員或技術支援人員的協助下進行.很多時候,該類測試是透過Alpha及Beta測試來實現的.軟體是為使用者設計的,所以使用者對軟體的使用性能最有發言權.他們在日常生活,工作中使用過許多軟體.對軟體的應用表現及反應已經生成了一套無形的規範.在使用性能測試的過程中,只要測試軟體的表現超出了他們的電腦軟體常識,那就說明這個軟體的使用性能有待改進.當然如果測試中的軟體有某些全新功能(前人沒有應用過此功能),使用者必須花點時間去學習,適應,則另當別論.
第四章 軟體測試的階段
4.1 V模型---軟體發展與測試進度的關聯
- 透過對V圖左邊的各項文件的評審,發現其中的不合理之處,以便於修正設計.若存在這類問題,那麼及時的修正可以給後面的設計帶來許多好處及大大節省時間.
- 透過各層次的測試準備工作,包括測試計畫的制訂,可以發現我們現有的測試工具是否完備,人員配置是否足夠,如果依據各時期的開發文件描述的功能測試是現在測試工具不能實現的,那麼就有充裕的時間去做這些準備,比如添置相關軟硬體(例如需要購入一批相關的電腦專門用於此測試);如果測試人員不夠,也可以計畫招聘,等到真正有軟體可以測試時就比較得心應手.
- 透過早期的測試計畫,可以做出測試風險的預測.在計畫的過程中,我們可以預計一些測試過程中的風險,例如可能會發現測試的費用很高,需時很長等.
V圖左右連接線的上面一條線用於描述測試進程的各個階段中測試對開發檔及軟體品質的回饋,透過這些回饋,軟體本身及其開發檔的品質就可以不斷提升,每一輪測試都將這一步驟重複,軟體的品質就是在這樣的過程中實現螺旋上升.
第五章 軟體測試案例的編寫
編寫測試案例是一項需要高技術水準的工作,此外測試工程師不但要掌握測試的全盤策略,還要對軟體具體各部分有足夠細緻的了解,稍有不慎就會顧此失彼,造成疏漏.
測試案例的編寫是一項繁瑣的工作,特別是對於大規模的商業用軟體.面對著一個龐大的,複雜的軟體,應該從哪裡下手編寫測試案例呢?
讓我們先從測試案例的歸類說起:在編寫實例之前,我們已經有了測試計畫書,在測試計畫書中,對所要測試的專案及測試的物件都有詳細的說明.因此我們對於那些部分應編寫設計實例就有了明確的目標.如果在比較大的公司裡,要求另編有測試案例設計書的,那就更方便了.在這種情況下,測試工程師就以此為指南,編寫每部分的測試案例.在一些小型公司裡,測試案例就直接寫進測試計畫書中.
5.1 測試案例分類
在編寫測試案例的時候,我們可以對測試案例進行分類,這樣不容易遺漏應選擇的測試案例.可以把測試案例歸為四大類:
- 使用者介面所有組成部分的檢驗測試案例,包括每個視窗裡的所有功能表及功能表裏的各項,每個按鈕,每個文字或數位輸入框的位置狀態是否正確,是否有遺漏.
- 軟體各項功能的功能測試案例,比如文字編輯器中的開新檔案功能,開啟舊檔功能及儲存,列印,編輯功能等.
- 軟體的各項非功能測試案例,這裡又可以分成許多類:
4. 對缺陷修正的確認測試案例
第六章 網路軟體測試
第七章 軟體自動化測試
第八章 軟體自動化測試實例
附錄A 軟體測試工程師面試題目
附錄B 軟體測試計劃書---範本---
