天天看點

《軟體測試的有效方法(第2版)》筆記(二)

版權聲明:本文為部落客chszs的原創文章,未經部落客允許不得轉載。 https://blog.csdn.net/chszs/article/details/1362850

《軟體測試的有效方法(第2版)》筆記2

第四章 确定軟體測試技術

測試是用來确定應用系統屬性的存在、品質及其真實性的一種手段。

測試過程盡量做到結構化。

1、應用程式的有效性取決于該應用程式與其所在環境的适應性。

适應性:指應用程式在幫助使用者執行其日常工作方面的使用、幫助合意義的程度。适應性有如下所述的四個要素:

(1)資料:資料的可靠性、及時性、一緻性、可用性;

(2)人員:良好技能、相應教育訓練、悟性、興趣;

(3)結構:提高技術、滿足需求的恰當的開發方法;

(4)規則:按照一定規程處理資料。

應用系統必須與業務環境中的這四個要素相适應。

2、測試技術/工具的選擇過程

2.1、結構測試與功能測試

基于結構分析的測試,其目的是為了發現程式“編碼”過程中的錯誤;基于功能分析的測試是為了發現實作需求或者設計規格說明時的錯誤。

功能測試確定應用系統恰當地滿足了需求;結構測試用于保證對各功能實作進行了充分的測試。

2.2、動态測試與靜态測試

動态測試基于測試用例運作程式,執行的結果與期望結果值進行比較,看是否一緻。

靜态測試不需要執行程式,其手段如文法檢查等。

靜态測試主要用于需求和設計階段,動态測試主要用于測試階段。

2.3、人工測試與自動測試

由人所執行的測試稱為人工測試,由機器執行的測試稱為自動測試。

開發過程越是自動化,測試過程的自動化也就越容易。

3、測試技術/工具的選擇

過程:選擇測試因素-->确定SDLC階段-->明确測試标準-->選擇測試類型-

(系統結構或功能)->選擇技術-->選擇測試方法-->動态或靜态

->單元測試技術-->選擇測試方法-->動态或靜态

4、測試技術與測試工具的差別

測試工具是執行測試過程的一個裝置;測試技術是確定應用系統某方面或單元的功能正确的過程。

5、結構化系統測試技術:用于驗證所開發的系統及程式的運作情況。目标是要確定産品設計在結構上合理,功能上正确。為确定實作的配置及其各功能共同作用以完成特定任務提供了一種機制。結構化測試技術由以下幾種:

(1)壓力測試:确定系統以期望的容量執行。

舉例:配置設定了足夠的磁盤空間;有充分的通信管道。

壓力測試技術用于檢查系統面對意外情況下的大資料量時是否可以正常運作。所涉及的方面包括輸入事務、内部表、磁盤空間、輸出、通信、計算機容量以及人機互動等。

當應用系統所能正常處理的工作量并不确定時需要使用壓力測試。壓力測試意圖通過對系統施加超負載事務量來達到破壞系統的目的。弱點在于準備測試的時間與在測試的實際執行過程中所消耗的資源數量都非常之大,通常在應用程式投入使用之前這種技術是無法進行的。

(2)執行測試:系統能達到期望的熟練性。

舉例:事務輪轉時間充分;軟硬體使用良好。

執行測試技術用于檢查系統是否達到了預期在産品狀态下的成熟度。執行測試可以驗證系統的響應時間、輪轉時間及設計性能。

在開發過程的早期就應該進行執行測試,盡早制定已經完成的系統沒有達到性能名額是非常有價值的。在關鍵時間點進行。關鍵時間點指的是目前的結果會影響甚至改變系統結構的時間點。

(3)恢複測試:系統失效之後可以恢複到可操作狀态。

舉例:引入失敗;評估備份資料的充分性。

恢複測試技術用于確定系統在經曆災難後可以繼續正常運作,它不僅可以驗證恢複過程,而且可以驗證過程各元件的有效性。

當使用者認為系統操作的連續性對于其所涉及領域的某些功能至關重要時,需要進行恢複測試。

(4)操作測試:系統以正常操作狀态執行。

舉例:确定系統可以依據文檔進行運作;JCL(工作控制語言)充分。

操作測試技術主要用于檢查系統在正常的操作狀态下是否可以執行。操作測試可以與其它測試聯合執行。

任何應用程式在成為産品之前都應進行操作測試。

(5)(與過程的)一緻性測試:系統的開發與标準和規程相一緻。

舉例:按标準執行;文檔完整。

一緻性測試技術用于驗證應用程式的開發是否與資訊技術名額、過程及準則相一緻。一緻性測試最有效的方法是過程審查。

系統開發标準和過程的一緻性程度依賴于管理層對于所需遵循的特定過程和執行标準的重視程度。

(6)安全性測試:根據組織的重要性對系統進行保護。

舉例:通路拒絕;規程适當。

安全性測試技術用于評價保護性程式及安全對策的充分性。安全性缺陷不如其它類型的缺陷那麼明顯。安全性測試是測試過程中高度專業化的部分。分實體安全性(針對利用實體方法收集資訊的手段)和邏輯安全性(針對使用計算機處理和通信能力進行非法活動資訊的手段)。

當系統保護資訊和資産對于組織來說意義重大時,需要進行安全性測試。

6、功能性系統測試技術

功能性系統測試用于確定系統需求與定義都得到了滿足。該過程通常包含建立用于評價應用程式正确性的測試條件。

用于執行功能測試的幾種測試技術包括:

(1)需求測試:系統按制定方式執行。

舉例:證明系統需求;與政策、規則相一緻。

需求測試技術驗證系統是否正确執行其功能,并且能保證在相當長的一段時間内保持其正确性。需求測試的執行主要通過執行建立的測試條件以及功能檢查單來完成,通過需求得到測試條件,然後以類似于SDLC這種特定的方式表現,生成用于評價實作的應用系統的測試資料。

任何應用程式都應該對需求進行測試,此過程應該開始于需求階段,并一直持續到系統運作和維護階段。

(2)回歸測試:驗證系統中沒有改變的部分仍能正确運作。

舉例:未變更的部分正常運作;未變更的人工規程正确。

回歸測試技術對已經測試過的部分進行重新測試,以保證它們在應用程式其它部分發生變更之後仍能正常運作。

當變更會對應用程式中沒有變更的部分産生高風險的影響時需要進行回歸測試。

(3)錯誤處理測試:錯誤可以得到防止或檢測,并被修複。

舉例:将錯誤引入測試;錯誤的再次注入。

人工系統與自動系統之間差别的特點之一就是預定義的錯誤處理特性。錯誤處理測試技術用于檢查應用系統正确處理發生異常的能力。錯誤處理測試需要一組知識豐富的人員來預見應用系統可能發生的錯誤。它是測試錯誤的引入、錯誤的處理,控制條件以及條件的再次正确輸入。

在系統整個生命周期中都應該進行錯誤測試。在開發過程中,應該識别錯誤帶來的問題并且采取相應的措施将錯誤減少到可以接受的程度。

(4)人工支援測試:人機互動有效。

舉例:具備人工規程;人員接受過教育訓練。

人工支援測試技術主要包括人員在準備資料以及使用來源于自動程式資料的過程中執行所有功能。

在生命周期的全過程都應該驗證人工系統功能的正确性。

(5)系統間測試:資料可以正确地在系統間傳遞。

舉例:系統間參數變化;系統間文檔更新。

系統間測試技術用于保證應用程式間互相管理的正确性。系統間測試的一個最好的工具是內建測試工具,它允許在産品環境下進行測試,可以以最小的代價測試系統間的耦合性。

在應用系統間的參數發生變更時需要進行系統間的測試。測試的程度和類型依賴于與出錯的參數相關聯的風險情況。

(6)控制測試:将系統風險控制降低到可以接受的級别。

舉例:檔案一緻性規程正常;人工控制正确。

控制測試技術包括資料确認、檔案完整性控制、評審追蹤、備份和恢複、文檔,以及與系統完整性相關的其它方面。主要用于確定對系統特定功能的檢查。可以用于控制測試的一個方法是生成風險矩陣。

控制測試是系統測試中的一個完整的部分,占測試時間的很大比例。

(7)平行測試:發現原系統與新系統之間的意外差異。

舉例:原系統與新系統一緻;原系統仍然可以工作。

平行測試技術用于檢查新應用程式的結果是否與原來的應用程式或者上一版本應用程式的處理相一緻。它執行備援處理以保證新版本或者新應用程式執行的正确性;給出同一應用程式不同版本之間一緻的和不一緻的地方。平行測試可以對整個應用程式進行,也可對應用程式的一部分進行。

當不能确定新應用程式處理的正确性,或者當新舊版本的應用程式非常類似時,需要進行平行測試。

7、單元測試技術

程式的測試和分析是驗證程式具有其規格說明所要求的特性的最實際的手段。

測試是一種動态驗證方法,它使用測試資料運作代碼來評估程式對需求的滿足程度。

分析是一種靜态驗證方法,通過分析代碼而不是執行代碼來檢測需求的滿足度。

“單元”可能小到一條語句,也可能大到是許多子例程的組合。單元最本質的特點是可以被看作一個整體。

8、功能測試和分析

功能測試和分析確定包含了主要的代碼特征。

面向錯誤的功能測試和分析確定包含了常見的錯誤。

單元測試的分析和管理應該是系統化的,它由兩步組成。第一,必須選擇适合于項目的技術;第二,這些技術必須得到系統化的應用。

9、獨立于規格說明技術的測試

規格說明細化了可能施加于給定的軟體單元的那些假設,它們必須描述通路給定單元的接口以及該通路的具體行為。

1)基于接口的測試:在子產品輸入輸出域特性及其互相關系的基礎上選擇測試資料。

(1)輸入域測試:選擇覆寫輸入域邊界的測試資料。

(2)等價劃分:規格說明通常将所有可能的輸入集合劃分未幾個等效的類。

(3)文法檢查:對輸入資料進行分析,對不正确的資料格式進行處理。

2)基于功能的測試

(1)特殊值測試:基于所要計算的功能的特點來選擇測試資料稱為特殊值測試。

(2)輸出域覆寫:對于每個由等價劃分所确定的功能都有其相關的一個輸出域。

3)基于規格說明技術的測試

(1)代數學:在代數規格說明中,用公理或者規則來表示抽象資料的屬性。在一個測試系統中,代數規則說明與實作的一緻性是通過測試來檢查的。每條公理都可以編譯成與測試功能點集相關聯的程式。驅動程式将這些測試功能點作為公理所對應的程式的輸入資料,程式的回報又說明了其對應的公理是否合适。

(2)公理:盡管斷言計算作為一種規格說明語言具有廣泛使用的可能,但是關于從這種規格說明生成測試資料方面尚未有公布的資料。

(3)狀态機:許多程式可以用狀态機描述,這又提供了另一種測試資料的選擇方式。

(4)判定表:是一種表示等價劃分的簡潔方法,表的行表示輸入滿足的條件,表的清單示相應的輸入所可能引發的動作集。

10、結構測試和分析

1)結構化分析

(1)複雜性度量

(2)資料流分析

用流程圖來表示。通過它,推導出資料流的相關資訊可以用于代碼優化。異常檢查以及測試資料的生成。

(3)符号執行

一個符号執行系統有三個輸入參數:要解釋的程式、程式的符号輸入以及要執行的路徑。

2)結構化測試:是一種動态的測試技術,其中測試資料的選擇以及評價是依據測試過程中代碼的覆寫目标而定的。該方法用于追蹤在實際測試過程中所具體執行到的程式語句。

(1)語句測試

(2)分支測試

(3)條件測試

(4)表達式測試

(5)路徑測試

11、面向錯誤的測試和分析

關注程式進行中有無錯誤的評估技術稱為面向錯誤技術。分三大類:統計評估、基于錯誤的測試以及基于差錯的測試。

基于錯誤的測試意于說明過程中不存在某些錯誤。基于差錯的測試意于說明代碼中不存在某些差錯。

1)統計方法:利用統計技術來決定程式操作的可靠性。

2)基于錯誤的測試:可以由程式員的錯誤曆史、軟體複雜度、對易犯句法錯誤的結構的了解或者甚至是錯誤推測來驅動。

(1)錯誤估計:也叫錯誤種植法(Fault Seeding),是一種用于評估程式中錯誤的數目和特點的統計性方法。首先,将錯誤引入程式;然後,測試程式基于所發現的錯誤數目來估計尚未發現的錯誤數目。難點在于所引入的錯誤必須可以代表程式中尚未發現的錯誤。

(2)域測試:可以按照輸入是否執行相同的路徑來劃分程式的輸入域。這些劃分稱為路徑域。

(3)擾動測試:需要決定構成被測試路徑充分集的内容。

3)基于差錯的測試:對評估測試資料非常有用。可以在深度上和廣度上進行區分。在深度上,局部範圍的方法證明差錯對計算有局部作用,很可能該局部作用并不會引起程式失效,而全部範圍的方法證明會使得程式失效;廣度取決于所處理的差錯類是有限的還是無限的。

(1)局部有限型

(2)全局有限型

(3)局部無限型

(4)全局無限型

繼續閱讀