《軟件測試技術》全套教學課件

軟件測試技術第1章概論

第1章概論第2章基于結構的測試第3章基于規(guī)格說明的測試第4章基于軟件產品質量特性的測試第5章測試管理第6章軟件測試的挑戰(zhàn)全套可編輯PPT課件概述本章從軟件質量出發(fā),對軟件質量內涵進行剖析。全面介紹與軟件測試相關的概念,包括軟件測試的分類、測試的不同階段、測試工作的具體內容和范疇,分析了軟件失效原因及傳播模型,指出了軟件測試的核心問題。目錄1.1軟件驗證與確認

1.2軟件V&V與軟件測試的關系

1.3軟件缺陷的應對方法1.4軟件失效模型1.5RIPR模型1.6軟件質量1.7軟件測試的形式化定義1.8軟件測試基本術語1.9軟件測試用例執(zhí)行過程1.10軟件測試方法1.11軟件測試與其他開發(fā)活動的關系1.12軟件測試階段1.13軟件測試技術1.14軟件測試過程1.15軟件測試原則1.16軟件質量度量1.1軟件驗證與確認全套可編輯PPT課件依據(jù)國家標準GB/T32423—2015《系統(tǒng)與軟件工程驗證與確認》,驗證(Verification)是提供客觀證據(jù)證明產品是否滿足需求與標準(正確地生產產品)的過程,確認(Validation)是提供客觀證據(jù)證明產品是否滿足預期用途和用戶需求(生產正確的產品)的過程。前者關注產品是否符合需求與標準,多以過程為導向,后者聚焦產品是否滿足預期用途,往往以結果為導向。兩者簡稱為V&V。例如科學計算軟件的驗證與確認，驗證過程檢驗代碼與數(shù)學物理模型、數(shù)值計算模型、程序規(guī)格說明是否一致,開發(fā)過程是否符合軟件過程能力成熟度規(guī)范,如數(shù)學物理模型的質量守恒、數(shù)值計算模型的離散格式、測試驅動開發(fā)、測試過程改進等;確認過程則是評價最終結果是否符合預期用途,如結果數(shù)值精度、收斂階次、數(shù)值誤差等。1.2軟件V&V與軟件測試的關系根據(jù)GB/T32423—2015《系統(tǒng)與軟件工程驗證與確認》,驗證與確認活動層次結構如圖所示。驗證主要采用測試testing、調試debug和形式化證明formalproof技術,軟件測試是驗證與確認的主要活動1.3軟件缺陷的應對方法什么是缺陷？01要了解什么是缺陷(defect)，就必須清楚“質量(Quality)”概念，因為缺陷是相對質量而存在的，違背了質量、違背了客戶的意愿，不能滿足客戶的要求，就會引起缺陷或產生缺陷。02軟件缺陷020304050601設計不合理，存在缺陷功能、特性沒有實現(xiàn)或部分實現(xiàn)實際結果和預期結果不一致用戶不能接受的其他問題，如存取時間過長、界面不美觀運行出錯，包括運行中斷、系統(tǒng)崩潰、界面混亂數(shù)據(jù)結果不正確、精度不夠缺陷具體的體現(xiàn)單擊此處編輯母版標題樣式軟件錯誤無法完全消除,處理軟件缺陷的方法主要包括:避免缺陷、檢測缺陷、容忍缺陷,其中軟件測試是檢測缺陷的主要技術,詳情如圖所示.1.4軟件失效模型錯誤Error:人為因素產生不正確結果的行為。缺陷Fault:工作產品中不符合要求或規(guī)格的缺陷或不足。失效Failure:組件或系統(tǒng)在指定范圍內未執(zhí)行所需功能的事件。軟件失效模型如圖所示；軟件本身03文檔錯誤、用戶使用場合(userscenario)，時間上不協(xié)調、或不一致性所帶來的問題系統(tǒng)的自我恢復或數(shù)據(jù)的異地備份、災難性恢復等問題團隊工作02溝通不充分，誤解技術問題01算法錯誤、計算和精度問題接口參數(shù)傳遞不匹配產生軟件缺陷的原因1.5RIPR模型RIPR模型：Reachability(R)為可達性,Infection(I)為感染性,Propagation(P)為傳播性,Revealability(R)為可揭示性,RIPR模型揭示了軟件測試識別缺陷的基本原理。通過測試揭示錯誤是一個充滿挑戰(zhàn)的過程。待測項目眾多,其中少部分存在缺陷,雖然系統(tǒng)性的測試理論、方法和技術能顯著提高發(fā)現(xiàn)缺陷的可能性、提高測試效率,然而,測試資源有限,即使測試沒有報告缺陷,也不能認為軟件不存在錯誤。1.6軟件質量軟件測試是保證軟件質量的一個關鍵步驟。要討論軟件測試,首先需要了解軟件質量的基本內涵。1983年,ASNI/IEEESTD729給出了軟件質量定義,軟件質量是軟件產品滿足規(guī)定的和隱含的與需求能力有關的全部特征和特性。(1)軟件產品質量滿足用戶要求的程度;(2)軟件各種屬性的組合程度;(3)用戶對軟件產品的綜合反應程度;(4)軟件在使用過程中滿足用戶要求的程度。根據(jù)GB/T25000.10—2016《系統(tǒng)與軟件質量模型》,軟件質量是指在規(guī)定條件下使用時,軟件產品滿足明確和隱含要求的能力。ISO/IEC2501n質量模型分別定義了系統(tǒng)與軟件的產品質量、使用質量和數(shù)據(jù)質量共3個模型,它們分別由8個、5個和15個質量特性組成。軟件質量可以通過測量被測軟件滿足這些質量特性的程度來獲取。產品質量的八大特性:功能性、性能效率、兼容性、易用性、可靠性、信息安全性、維護性、可移植性。每個特性都有其對應的子特性集。(1)功能性:是指當軟件在指定條件下使用,軟件產品滿足明確和隱含要求功能的能力。(2)性能效率:是指在規(guī)定條件下,相對于所用資源的數(shù)量,軟件產品可提供適當?shù)男阅艿哪芰Α?3)兼容性:整個軟件或其中一部分能作為軟件包而再利用的程度。(4)易用性:在指定條件下使用時,軟件產品被理解、學習、使用和吸引用戶的能力。(5)可靠性:在指定條件下使用時,軟件產品維持規(guī)定的性能級別的能力。(6)信息安全性:為了防止意外和人為破壞,軟件應具備的自身保護能力。(7)維護性:是指軟件產品可被修改的能力,修改可能包括修正、改進或軟件適應環(huán)境、需求和功能規(guī)格說明中的變化。(8)可移植性:是指軟件產品從一種環(huán)境遷移到另一種環(huán)境的能力。1.7軟件測試的形式化定義設程序P的輸入域范圍為Domain和Range,P是D→R的函數(shù),OR表示期望輸出值ORacle,對于所有d∈D,如果P(d)滿足OR,則稱P是正確的,測試用例由輸入值d和期望輸出值OR組成,后者指給定d時P的輸出。否則,P存在失效Failure。測試充分性準則Criterion是指以D的大小為目標的測試集。定義程序模型M的準則C如下:M:函數(shù)的控制流圖ControlFlowGraph,CFGC:CFG所有邊的集合形式化定義:測試充分性準則C是PD的子集,其中PD是D的所有有限子集的集合,以PD為目標來設計測試集。測試集T的覆蓋率是C所定義的M中的元素被給定測試集T覆蓋的比例。對于準則C,當覆蓋率達到100%時,稱測試集T對于C來說是充分的,或者簡稱為C-充分的。理想測試集:每當P不正確時,總存在一個d∈T,使得P對于d而言是不正確的,即P(d)不滿足OR,則稱T為理想測試集。如果T是一個理想測試集,并且T對P而言是成功的,那么P是正確的。如果T的輸入值屬于C,則T滿足測試充分性準則C。1.8軟件測試基本術語測試用例testcase:測試數(shù)據(jù)、測試程序(測試腳本)和期望結果的集合。一個測試用例驗證一個或多個系統(tǒng)需求,并生成通過pass或失敗fail的結論。測試集T是測試用例的有限集合,又名測試套件testsuite。測試套件testsuite:為達成同一測試目標,相關的或相互協(xié)作的測試用例的集合測試預言testoracle:決定被測軟件是否正確的判定機制。測試預言通常采用實際結果與預期結果直接對比的方式,也可采用模型或算法屬性間接檢驗程序正確性,如對于求解組合數(shù)程序C(n,k),可使用屬性C(n,k)≥1作為測試預言,還可采用模型或算法基本理論作為測試預言,如能量守恒、質量守恒、動量守恒、周期性、單調性、旋轉不變性等,仍以C(n,k)為例,通過檢查多次運行結果C(n,k)與C(n,n-k)是否相等來檢驗其正確性。單擊此處編輯母版標題樣式斷言assert:測試預言的實現(xiàn)手段之一,是程序中的一階邏輯,目的是驗證被測程序正確性,當實際輸出與預期結果一致時斷言為“真”,測試通過pass,否則,斷言為“假”,測試失敗fail。測試樁teststub:用于隔離被測單元與其他組件之間的依賴關系,是被依賴組件的替身。測試驅動器testdriver:依賴被測單元的組件的部分實現(xiàn)。通常用于驅動被測單元執(zhí)行,以獲取實際結果或觀察程序行為。1測試庫都實現(xiàn)了測試驅動器,如單元測試庫Java的JUnit、C/C++的gtest、C#的MSTest,系統(tǒng)測試庫web應用的Selenium、PlayWright,性能測試庫JMeter、LoadRunner、K6等。2測試夾具testfixture:前置條件與后置條件,如JUnit的Setup與Teardown,前者會先于測試用例執(zhí)行,通常用于初始化測試環(huán)境;后者會在測試用例結束后執(zhí)行,一般用于清理現(xiàn)場。測試庫都實現(xiàn)了測試夾具,如Python的pytest與unittest、Java的JUnit等。3測試用具testharness:自動測試環(huán)境,不僅具備測試庫,通常還包括測試管理、輸入輸出、比較器、報表生成器。41.9軟件測試基本術語軟件測試用例執(zhí)行過程如圖所示。首先,依據(jù)軟件描述,如模型、需求等,獲取預期結果或屬性,設計測試預言testoracle,同時,根據(jù)描述生成測試用例testcase,使用測試用例驅動被測程序執(zhí)行得到測試結果,再對比測試預言與測試結果,最終,給出測試結論。軟件測試的核心活動包括生成測試用例、執(zhí)行測試用例、判定程序正確性。讀者往往以為自動化測試就是將上述測試活動自動完成,事實上,大部分測試用具只實現(xiàn)了測試用例的自動執(zhí)行,少數(shù)支持測試用例自動生成。主要原因是這些用具提供的是通用功能,測試用例生成、選取,以及程序正確性判定機制不僅與采用的測試充分性準則、測試方法、測試技術密切相關,而且與被測程序的業(yè)務場景有關,不存在一般意義上的通用方法。因此,根據(jù)被測程序、測試預言、業(yè)務背景等約束條件,基于通用測試用具的二次開發(fā)是有可能構建專用自動化測試用具的,如高德的TestPG、字節(jié)跳動的Rhino,以及阿里巴巴的AMAZON、PTS和JVM-SANDBOX平臺。1.10軟件測試方法國際軟件測試認證委員會ISTQB將測試方法分為七類,如表1-4所示。1.11軟件測試與其他開發(fā)活動的關系

需求階段,測試人員通過對需求定義的閱讀、討論和審查,發(fā)現(xiàn)需求定義的問題,同時通過需求了解產品的設計特性、用戶的真實需求,從而確定測試目標,準備驗收測試標準并策劃測試活動。

軟件設計階段,軟件測試人員可以了解系統(tǒng)實現(xiàn)過程、構建平臺等各方面的問題,從而衡量系統(tǒng)的可測試性,檢查系統(tǒng)的設計是否符合系統(tǒng)的可靠性要求。

軟件測試和軟件開發(fā)在整個軟件開發(fā)生命周期中交互協(xié)作,共同致力于能夠按時并且高質量地完成項目的目標。W模型說明軟件測試活動和項目是同時啟動的,軟件測試的工作很早就開始了,并不是等到代碼完成以后才進行。在W模型中可以相對準確反映測試與開發(fā)之間的關系。1.12軟件測試階段06通過對大量工程項目的觀察發(fā)現(xiàn):(1)缺陷在軟件研發(fā)初期就已經產生,而且修復越晚,成本越高;(2)需求、設計階段的缺陷數(shù)量比編碼階段更多。因此,軟件測試應盡早介入,測試應采用系統(tǒng)方法指導。從軟件生命周期視角,測試可分為單元測試、集成測試、系統(tǒng)測試和驗收測試等階段。每個測試階段相對獨立,又相互影響,如充分的單元測試是良好集成測試的前提。這些測試階段并非僵化、固定不變,根據(jù)實踐條件,可以進行裁剪、合并或拆分、細化。集成測試也稱為組裝測試、聯(lián)合測試,是在單元測試的基礎上,將模塊按照設計要求組裝起來同時進行測試,主要目標是發(fā)現(xiàn)與接口有關的模塊之間的問題。集成測試單元測試單元測試是針對程序系統(tǒng)中的最小單元———模塊或組件進行測試,一般和編碼同步進行。主要采用白盒測試方法,從程序的內部結構出發(fā)設計測試用例,檢查程序模塊或組件的已實現(xiàn)的功能與定義的功能是否一致,以及編碼中是否存在錯誤。

系統(tǒng)測試一般在完成集成測試后進行,是針對應用系統(tǒng)進行測試。包括系統(tǒng)功能測試和非功能測試。系統(tǒng)功能測試是基于產品功能說明書,針對產品所實現(xiàn)的功能,從用戶角度來進行功能驗證,以確認每個功能是否都能正常使用。

驗收測試的目的是業(yè)務用戶表明系統(tǒng)能夠像預訂要求那樣工作,驗證軟件的功能和性能如同用戶所合理期待的那樣。基于需求規(guī)格說明書和用戶信息,驗證軟件的功能和性能及其他特性。驗收測試一般要求在實際的用戶環(huán)境上進行,并和用戶共同完成。系統(tǒng)測試驗收測試1.13軟件測試技術依據(jù)國家標準GB/T38634.4—2020《系統(tǒng)與軟件工程軟件測試第4部分:測試技術》,測試技術分類為基于結構的測試、基于規(guī)格說明的測試、基于經驗的測試,例的首要信息來源?；诮Y構的測試技術是利用代碼結構信息來設計測試用例,基于規(guī)格說明的測試技術則是運用規(guī)格說明信息來設計測試用例。兩者對比如圖所示。1.14軟件測試過程軟件測試是一個反復迭代的過程,不同測試階段、不同質量特性的測試都遵循著相似的測試過程。根據(jù)ISTQB的定義,軟件測試流程如圖所示。(1)測試計劃測試計劃是為了高效、高質量地完成測試任務而做的準備工作,內容主要包括測試項目的背景、測試目標和范圍、測試方式、資源配置、人員分工、進度安排,以及與測試有關的測試風險識別與分析。(2)測試分析測試分析是解決“測什么”的問題,需要完成明確測試范圍,界定項目的測試邊界,針對測試范圍進行分解,分解成為測試項、測試點等任務。確定哪些測試項要測試、哪些測試項不需要測試,要完成哪些相應的測試任務才能確保目標的實現(xiàn)。此外還需要分析測試項的測試風險,測試目標優(yōu)先級等問題。(3)測試設計測試設計是解決“如何測”的問題,可以分為測試總體設計和測試詳細設計。測試總體設計主要指測試方案的設計、測試結構的設計;測試詳細設計主要指測試用例和測試數(shù)據(jù)的設計。(4)測試實施測試實施是處理“怎么做”的問題。根據(jù)測試用例規(guī)格說明書,搭建測試環(huán)境,編寫測試腳本,創(chuàng)建測試數(shù)據(jù),滿足進入測試執(zhí)行前的各項要求。(5)測試執(zhí)行測試執(zhí)行是執(zhí)行測試規(guī)程、收集測試數(shù)據(jù)的過程。測試執(zhí)行一般分為人工執(zhí)行和自動化執(zhí)行。人工執(zhí)行是測試員執(zhí)行測試用例的各項操作步驟。自動化執(zhí)行是指采用測試工具來完成測試用例的操作步驟,一般需要自動化測試工具支持。(6)測試結果和過程評價收集的測試數(shù)據(jù)需要進行分析,如代碼的判定覆蓋率,用于評價測試是否充分;能夠分析缺陷的分布特征和可靠性趨勢,了解高嚴重等級缺陷是否得到有效遏制,評估被測對象的質量是否滿足測試需求。測試過程評估需要結合測試計劃來進行評審,相當于把計劃的測試活動作為基準,使用實際執(zhí)行的活動與之進行比較,了解測試計劃執(zhí)行的情況和效果是否與計劃一致,及早發(fā)現(xiàn)問題,及時制定措施加以糾正、改進。1.15軟件測試原則(1)無錯誤、謬論,任何一款軟件在開發(fā)時都存在錯誤。(2)即使測試沒有報告缺陷,也不能認為軟件不存在錯誤。(3)窮盡測試是不可能的,測試數(shù)據(jù)、計算選項、約束條件和業(yè)務場景的組合不可能全部列舉,并且,測試受限于成本。(4)測試應及早介入。缺陷修復成本與其發(fā)現(xiàn)時間成正比,缺陷發(fā)現(xiàn)的越晚其修復成本越高,通常以指數(shù)增長。(5)測試應持續(xù)進行。(6)殺蟲劑悖論,重復執(zhí)行同一個測試用例是不能識別“新”缺陷的。(7)缺陷具有集群性。某些模塊發(fā)現(xiàn)的缺陷越多,表明該模塊隱藏的錯誤越多,應增加測試強度。(8)測試是上下文相關的,對于同一功能的不同測試階段、不同質量特性,需采用不同的測試方法。(9)測試用例應通過評審。(10)缺陷應能復現(xiàn)。(11)避免測試自己編寫的程序,可采用結對編程、交叉檢查或第三方測試。(12)所有測試均應追溯到用戶需求,構建“測試需求———測試用例———缺陷”的關聯(lián)矩陣,做到需求不遺漏、缺陷不放過。(13)監(jiān)控測試過程,不僅收集被測軟件的測試結果,還要匯總測試過程信息,而且應對這些數(shù)據(jù)進行統(tǒng)計、分析及可視化,客觀公正評價被測軟件,持續(xù)有效改進測試過程。1.16軟件質量度量單擊此處添加標題

軟件質量的度量就是采集客觀證據(jù),運用定性和定量方法綜合評價軟件產品與質量特性的偏離程度。

度量指標不僅有定性項還有定量項,并且,通常還需綜合考慮應用場景、行業(yè)關切、軟件形態(tài)等因素,同時,還需結合當前測試階段及相關技術條件。

以能源行業(yè)為例,安全分析軟件用于驗證設計方案、分析事故影響,常用C/S架構,關注結果準確度、模型不確定性、參數(shù)敏感性;電廠工業(yè)控制系統(tǒng)DCS負責收集數(shù)據(jù)、控制生產工藝,多用組態(tài)軟件、工業(yè)控制總線,強調可靠性、性能效率;應急監(jiān)控軟件實現(xiàn)跨地理區(qū)域、多廠區(qū)可視化,采用B/S架構,重視兼容性與信息安全等。(1)靜態(tài)分析本階段主要檢查文檔與源代碼的規(guī)范性。文檔分析重點檢查需求是否清晰、無二義性并且具備可測試性,軟件設計是否覆蓋需求,術語是否統(tǒng)一規(guī)范,文檔是否自洽,文檔與代碼是否一致等;代碼分析主要檢查注釋率、命名規(guī)范、編碼規(guī)范、類繼承深度、循環(huán)迭代深度、函數(shù)圈復雜度、單個函數(shù)最大代碼數(shù)、冗余代碼、不可達路徑等。單擊此處添加標題（2）單元測試

本階段主要檢查程序行為,通常需要執(zhí)行被測代碼。求解過程是否會發(fā)散,數(shù)值解的誤差趨勢是否滿足理論收斂階,準確度與理論精度階是否一致,是否滿足理論邊界條件,程序對異常輸入是否給出明確清晰的提示信息、程序行為是否可預期等。

（3）集成測試

本階段重點檢查子模塊或求解器的正確性,是否符合守恒性、對稱性、坐標不變性等基本理論,網(wǎng)格劃分是否滿足計算精度要求,接口調用是否正常、報文格式與內容是否與設計一致,計算選項是否正常執(zhí)行、輸出結果是否符合設計文檔,數(shù)據(jù)庫HDF5、并行計算庫MPI或OpenMP、科學計算庫Blas或Lapack等中間件是否能正常調用,計算環(huán)境、網(wǎng)絡環(huán)境是否正常,是否具備容錯機制,對于異常輸入是否能給出準確的提示信息、崩潰后是否能自行恢復。單擊此處添加標題（4）系統(tǒng)測試

本階段關鍵評價軟件是否滿足業(yè)務需求,點源、平板、圓柱、球等幾何構型是否覆蓋計算范圍,邊界條件是否符合計算要求,輸入與輸出是否滿足閾值需求,當數(shù)值位數(shù)、格式、數(shù)據(jù)類型等有誤時是否給出提示、提示信息是否說明可能原因與排查措施,是否覆蓋全部計算選項,生成文件的命名、內部結構、格式、內容是否與設計一致,界面顯示與原始數(shù)據(jù)是否一致,界面風格是否統(tǒng)一,元素布局是否合理,操作動線是否能減少錯誤發(fā)生,是否覆蓋主要功能點等。

（5）驗收測試

本階段主要評估仿真生產環(huán)境下軟件是否能滿足用戶業(yè)務需求。如根據(jù)反應堆組件布置,輸出是否符合需求;根據(jù)堆芯組件布置及屏蔽設計,輸出是否符合需求;換料后計算結果是否符合需求;調節(jié)控制棒計算結果是否符合需求;出現(xiàn)破口后計算結果是否滿足需求等。通常測試對象越位于軟件底層,定量評價項占比越高,反之,定性項越多,越依賴測試人員的經驗,甚至所在行業(yè)的領域知識,如反應堆安全分析軟件需要核能行業(yè)的反應堆物理、輻射屏蔽、熱工水力等領域知識。軟件測試技術第2章基于結構的測試

匯報人：WPS

目錄01靜態(tài)測試02控制流分析03數(shù)據(jù)流分析04mock模擬對象06變異分析05數(shù)據(jù)驅動測試2.1靜態(tài)測試

靜態(tài)測試是不運行被測程序,而只是分析或檢查程序代碼、界面或文檔中可能存在的錯誤,收集度量數(shù)據(jù)的過程。

靜態(tài)測試包括對產品需求規(guī)格說明書和軟件設計說明書的評審,對源代碼做結構分析、流程圖分析、符號執(zhí)行等,找出欠缺和可疑之處，可以借助專用的軟件測試工具評審軟件文檔或程序,度量程序靜態(tài)復雜度,檢查軟件是否符合編程標準。

靜態(tài)測試的目的是糾正軟件系統(tǒng)的描述、表示和規(guī)格上的錯誤,也是進一步執(zhí)行其他測試的前提。2.1.1代碼檢查

代碼檢查能夠有效地發(fā)現(xiàn)代碼中的缺陷,而且能夠為缺陷預防獲取各種經驗。

代碼檢查包括桌面檢查、代碼審查和走查等,主要檢查代碼和設計的一致性,代碼對標準的遵循,代碼的可讀性,代碼邏輯表達的正確性,代碼結構的合理性等方面;發(fā)現(xiàn)違背程序編寫標準的問題,程序中不安全、不明確和模糊的部分;找出程序中不可移植部分,違背程序編程風格的問題,包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。（1）代碼檢查的方法：①桌面檢查桌面檢查可視為由單人進行的代碼檢查或代碼走查,由一個人閱讀程序,對照錯誤列表檢查程序,對程序推演測試數(shù)據(jù)。②代碼審查代碼審查是指由若干程序員和測試人員組成的一個審查小組,依照程序所使用的語言和編碼規(guī)范,對照經過評審和確認的檢查單,通過閱讀、討論等方式對程序進行靜態(tài)分析的過程。檢查程序,對程序推演測試數(shù)據(jù)。③代碼走查代碼走查與代碼審查類似,但是不同的地方在于,走查不是簡單地讀程序和對照錯誤檢查表進行檢查,而是需要讓測試組成員為所需程序準備一批有代表性的測試用例,集體扮演計算機的角色,沿程序的邏輯查找被測代碼的缺陷。（2）編碼規(guī)范

編碼規(guī)范是程序編寫過程中需要遵循的規(guī)則,主要是對代碼的語法規(guī)則、語法格式等進行規(guī)定。開發(fā)人員根據(jù)統(tǒng)一規(guī)范,統(tǒng)一代碼風格,可以方便代碼的閱讀、維護。

在代碼檢查中,需要根據(jù)被測軟件的特點,選用適當?shù)臉藴逝c規(guī)則規(guī)范。2.1.2靜態(tài)結構分析

程序的結構形態(tài)是對源代碼進行分析的主要依據(jù),靜態(tài)結構分析是通過引入多種形式的圖表(如函數(shù)調用關系圖、模塊控制流圖等),幫助人們快速了解程序設計和結構,更好地理解源代碼,以及找到程序設計缺陷和代碼優(yōu)化的方向。函數(shù)調用關系圖

函數(shù)調用關系圖能夠展示應用程序中各個函數(shù)之間的調用關系。函數(shù)調用關系圖能幫助分析人員了解系統(tǒng)的結構,重點分析函數(shù)之間的調用關系是否符合要求,是否存在遞歸調用,函數(shù)調用層次是否太深,是否存在孤立的函數(shù)。根據(jù)分析決定是優(yōu)先測試葉子節(jié)點還是優(yōu)先測試根節(jié)點,那些接口數(shù)量多的節(jié)點是否需要增加測試資源等。模塊控制流圖

模塊控制流圖,是與程序流程圖類似的由節(jié)點和連接節(jié)點的邊組成的圖形,圖形中的一個節(jié)點代表一條或數(shù)條執(zhí)行語句,邊表示節(jié)點之間的控制流向,它幫助分析人員了解函數(shù)內部的邏輯結構,重點分析函數(shù)是否存在多出口情況,是否存在孤立的語句,圈復雜度是否太大,是否存在非結構化的設計等方面的問題。程序控制流圖

圈復雜度(CyclomaticComplexity)是一種代碼復雜度的衡量標準,它可以用來衡量一個模塊控制結構的復雜程度,圈復雜度大說明程序代碼的判斷邏輯復雜,可能質量低且難于測試和維護。圈復雜度的計算是根據(jù)程序的控制流圖來進行分析，基本的控制流圖圖形符號如圖所示,圓圈稱為控制流圖的一個節(jié)點,它表示一個或多個無分支的語句或源程序語句。程序流程圖與程序控制流圖的映射。程序的圈復雜度V(G)的計算公式如下:V(G)=區(qū)域數(shù)量(由節(jié)點、連線包圍的區(qū)域,包括圖形外部區(qū)域)V(G)=連線數(shù)量-節(jié)點數(shù)量+2V(G)=謂詞節(jié)點數(shù)+1

測試實踐相關測試實例7.2靜態(tài)測試測試對象來自開源算法代碼庫Algorithm：下載地址：/TheAlgorithms/Java,2.2控制流分析

基于控制流設計用例,是通過對程序控制流所表達出來的邏輯結構的遍歷,實現(xiàn)對不同程序的覆蓋,并認為當所選擇的用例能達到對應程度的覆蓋時,執(zhí)行這些用例能夠達到的期望的測試效果。從覆蓋的源程序的詳盡程度分析,包括以下不同的覆蓋標準:語句覆蓋、判定覆蓋、條件覆蓋、條件/判定覆蓋、條件組合覆蓋、修正的條件/判定覆蓋和路徑覆蓋。示例分析分析該流程圖可以得到,該程序有兩個判斷語句:(A>1)∧(B=0)、(A=2)∨(X>1)和四個可執(zhí)行語句:(A>1)∧(B=0)、X=X/A、(A=2)∨(X>1)和X=X+1每個判斷語句有兩條分支,兩個判斷語句共產生四條路徑(后文中統(tǒng)一用P來代表路徑)。分別是(a→c→e)【P1】、(a→b→d)【P2】、(a→b→e)【P3】、(a→c→d)【P4】。2.2.1語句覆蓋定義：語句覆蓋是設計若干個測試用例,運行被測程序,使程序中每個可執(zhí)行語句至少執(zhí)行一次。測試用例的設計格式:【輸入的(A,B,x),輸出的(A,B,x)】

測試用例設計：

通過對示例程序的流程圖分析可知,所有的可執(zhí)行語句都在路徑P1上,所以選擇路徑P1來設計測試用例,就可以覆蓋所有的可執(zhí)行語句。語句覆蓋測試用例設計：為設計滿足覆蓋(a→c→e)【P1】路徑的語句覆蓋的測試用例是【(2,0,4),(2,0,3)】,使程序中四個可執(zhí)行語句(A>1)∧(B=0)、(X=X/A)、(A=2)∨(X>1)和(X=X+1)各執(zhí)行一次。2.2.2判定覆蓋定義：判定覆蓋又稱分支覆蓋,是設計若干個測試用例,運行所測程序,使得程序中每個判斷的取真分支和取假分支至少經歷一次。、

判定覆蓋是比語句覆蓋稍強的覆蓋準則,也是在單元測試中很常用的一類覆蓋。判定覆蓋測試用例設計

通過對示例程序的流程圖分析可知,要覆蓋示例程序的兩個判定①(A>1)∧(B=0)

②(A=2)∨(X>1)取真和取假的分支,可分別選擇路徑P1和P2或路徑P3和P4設計測試用例。測用例設計：（1）如果選擇路徑P1和P2,就可得滿足要求的測試用例:【(2,0,4),(2,0,3)】,覆蓋(a→c→e)【P1】①T②T【(1,1,1),(1,1,1)】,覆蓋(a→b→d)【P2】①F②F（2）如果選擇路徑P3和P4,還可得另一組可用的測試用例:【(2,1,1),(2,1,2)】,覆蓋(a→b→e)【P3】①F②T【(3,0,3),(3,1,1)】,覆蓋(a→c→d)【P4】①T②F2.2.3條件覆蓋定義：條件覆蓋就是設計若干個測試用例,運行所測程序,使得程序中每個判斷條件的可能取值至少執(zhí)行一次。完全的條件覆蓋不一定能保證代碼行被全覆蓋,也不一定能滿足完全的判定覆蓋,這說明條件覆蓋的測試不一定比語句覆蓋和判定覆蓋強。條件覆蓋測試用例設計通過對示例程序的分析,先對所有條件的取值加以標記。對于第一個判斷:條件A>1取真值為T1,取假值為F1;條件B=0取真值為T2,取假值為F2;對于第二個判斷:條件A=2取真值為T3,取假值為F3;條件x>1取真值為T4,取假值為F4。根據(jù)這8個條件取值,可分別設計如下兩組測試用例。2.2.4條件/判定覆蓋定義：條件/判定覆蓋實際上是判定覆蓋和條件覆蓋兩種方法結合起來的一種設計方法,設計若干測試用例,運行被測程序,使得每個條件的可能取值至少執(zhí)行一次,同時,每個判定的可能取值至少執(zhí)行一次。測試用例設計：

根據(jù)條件/判定覆蓋的定義,分析示例程序,只需設計下面兩個測試用例就可以覆蓋示例程序的8個條件取值以及4個判定分支。2.2.5條件組合覆蓋定義：條件組合覆蓋是設計足夠的測試用例,使得所有可能的條件取值組合至少執(zhí)行一次。測試用例設計：根據(jù)判定條件覆蓋的定義,對于示例程序,具有8種條件組合方式：設計4個具體的測試用例,就可覆蓋這8種條件組合方式2.2.6修正的判定/條件覆蓋

在滿足判定/條件覆蓋的基礎上，設計測試用例讓每個條件變量獨立改變判定語句的真假值,需滿足以下3個條件:(1)每個判定至少取所有可能的輸出值一次;(2)判定中的每個條件至少取所有可能的輸出一次;(3)判定中的每一個條件可以獨立影響判定的輸出。

修正的判定/條件覆蓋實質是利用簡單判定條件的獨立影響性來消除測試用例的冗余。修正的判定/條件覆蓋測試用例設計

考慮一個簡單的僅包含一個布爾操作符的布爾表達式“A

and

B”,其中A和B均為布爾變量,取值為{0,1}，完備的測試用例集為4個。

根據(jù)修正的判定/條件測試用例設計的步驟，分析后分別得到條件A在條件B不變的情況下獨立地影響判定的結果和條件B在條件A不變的情況下獨立地影響判定的結果。完備測試用例集的第4個用例在約減后不影響測試整體效果，因此得到約減后的測試用例集。2.2.7路徑覆蓋定義：路徑覆蓋是設計足夠的測試用例,覆蓋程序中所有可能的路徑。測試用例設計：根據(jù)路徑覆蓋的定義,分析示例程序,共有4條路徑。設計4個測試用例,就可覆蓋這4條路徑。測試實踐第7章7.3控制流測試2.2.8基本路徑測試

路徑測試是窮舉被測代碼中的所有路徑,在實際測試過程中存在很大難度?；韭窂綔y試法是在程序控制流圖的基礎上,通過分析控制構造的圈復雜性,導出基本可執(zhí)行路徑集合,設計足夠多的測試用例,覆蓋程序中所有可能的、獨立的執(zhí)行路徑?；韭窂礁采w設計的基本流程如下:(1)依據(jù)代碼繪制流程圖;(2)確定流程圖的圈復雜度V(G);(3)確定線性獨立路徑的基本集合;(4)設計測試用例覆蓋每條基本路徑?；韭窂綔y試用例設計第一步：根據(jù)示例代碼，示例代碼的程序流程圖，分析繪制程序控制流圖。第二步：計算圈復雜度。V(G)=區(qū)域數(shù)量(由節(jié)點、連線包圍的區(qū)域,包括圖形外部區(qū)域)V(G)=連線數(shù)量-節(jié)點數(shù)量+2V(G)=謂詞節(jié)點數(shù)+1示例程序的V(G)=3,也就是該程序有3條基本路徑。第三步：確定基本路徑。①P1:a-c-e②P2:a-b-c-e③P3:a-b-c-d-e

這3條路徑組成了一個基本路徑集。3(圈復雜度V(G))是構成這個基本路徑集的基本路徑數(shù)的上界，也是設計測試用例的數(shù)目。

在一個基本路徑集合里,每條路徑是唯一的,但是要注意的是基本路徑集并不是唯一的。第四步：準備測試用例,確?；韭窂浇M中的每一條路徑被執(zhí)行一次。①【(-1,-2,-3),(-1,-2,-5)】,覆蓋P1②【(1,1,-3),(1,1,-2)】,覆蓋P2③【(2,1,6),(2,1,5)】,覆蓋P32.3數(shù)據(jù)流分析數(shù)據(jù)流分析

基于數(shù)據(jù)流分析的測試設計用例方法是通過選擇的定義-使用的覆蓋率來導出測試用例集,以覆蓋測試項中變量定義和使用的路徑(就是對變量從定義到使用的相關子路徑的覆蓋進行測試)。

數(shù)據(jù)流分析是一組測試策略,用于檢查程序的控制流程,收集有關變量如何在程序中流動數(shù)據(jù)的過程,以便根據(jù)事件的順序探索變量的順序。它

數(shù)據(jù)流分析對應的測試方法主要包括:全定義測試、全計算使用測試、全謂詞使用測試、全使用測試、全定義-使用路徑測試。(1)數(shù)據(jù)定義,即變量賦值語句,也被稱為變量定義。給變量賦一次值,叫作定義一次,也就是說在程序的運行過程中對一個變量可能會進行多次定義,定義可能是給了變量一個新的值,也有可能等于原來的值。(2)使用,是指在程序中用到了這個變量,但并沒有給這個變量賦值的過程叫作使用。分為計算使用和謂詞使用。計算使用,是指一個變量作為其他變量定義或者輸出的計算輸入。謂詞使用,是指用變量作為判定條件(謂詞)的結果。(3)數(shù)據(jù)定義-使用對(datadefinition-usepair)

數(shù)據(jù)定義和后續(xù)的數(shù)據(jù)使用,其中數(shù)據(jù)使用是使用數(shù)據(jù)定義中定義的值。測試條件是代碼中的定義-使用對。測試實例以二進制數(shù)轉換為八進制字符串的程序convertBinarToOctal為例,如1010=>12,輸入二進制整型數(shù)據(jù)1010,輸出為八進制字符串12。測試實例convertBinaryToOctal程序中出現(xiàn)的變量及其分類表續(xù)上表convertBinaryToOctal程序的定義-使用對2.3.1全定義使用定義：全定義測試(AllDefinitionsTesting)是一種測試軟件程序的方法,其目的是執(zhí)行程序中所有可能的數(shù)據(jù)使用情況,從而發(fā)現(xiàn)潛在的程序錯誤。它通過識別程序中所有定義(Def)和使用(Use)變量的數(shù)據(jù)流,并將其組合成所有可能的路徑來實現(xiàn)測試。全定義測試的基本流程是:(1)定義:首先識別程序中的所有變量,并標識它們的定義和使用;(2)數(shù)據(jù)流分析:數(shù)據(jù)流分析用于分析程序中變量的使用情況,并確定所有的數(shù)據(jù)流。

這一步需要檢查所有的變量定義,找出變量在程序中的使用情況,識別數(shù)據(jù)流和所有可能的數(shù)據(jù)路徑;(3)路徑識別:通過所有可能的數(shù)據(jù)路徑來識別程序中的所有可能執(zhí)行路徑,這是全定義測試的關鍵步驟;(4)測試用例生成:根據(jù)上一步驟中識別的所有可能路徑,生成測試用例,以覆蓋程序中的所有可能情況;(5)執(zhí)行測試:執(zhí)行測試用例并記錄測試結果;(6)檢查結果:檢查測試結果,如果發(fā)現(xiàn)錯誤,就需要修復程序,并重新執(zhí)行測試,直到程序達到預期的質量要求為止。分析convertBinaryToOctal程序,運用全定義測試方法得到具體用例設計。2.3.2全計算使用測試定義：全計算使用測試(AllCalculateUsesTesting)是一種測試技術,它基于程序中數(shù)據(jù)的流向和使用情況,通過遍歷程序的所有執(zhí)行路徑來測試程序的正確性。全計算使用測試的基本流程如下:(1)收集程序的數(shù)據(jù)流信息:從程序源代碼中分析出變量和常量的定義、賦值和使用情況,形成程序的數(shù)據(jù)流信息;(2)構建數(shù)據(jù)流圖:根據(jù)程序的數(shù)據(jù)流信息,構建數(shù)據(jù)流圖。數(shù)據(jù)流圖是一個有向圖,節(jié)點表示變量或常量的定義或使用,邊表示數(shù)據(jù)流的流向,即從一個節(jié)點到另一個節(jié)點的路徑上存在數(shù)據(jù)流;(3)確定測試用例:在數(shù)據(jù)流圖上執(zhí)行全路徑遍歷,生成所有可能的執(zhí)行路徑。然后針對每個路徑設計相應的測試用例,以覆蓋所有程序的執(zhí)行路徑;(4)執(zhí)行測試用例:執(zhí)行測試用例,檢查程序的輸出是否符合預期結果。分析convertBinaryToOctal程序,運用全計算使用測試方法得到的具體用例設計。2.3.3全謂詞使用測試定義：全謂詞使用測試(AllPredicateUsesTesting)其目標是驗證程序中所有謂詞的正確性,以發(fā)現(xiàn)潛在的錯誤和缺陷。謂詞是程序中的邏輯表達式,包含關系運算符和邏輯運算符,用全謂詞使用測試的具體流程如下:(1)確定程序中所有謂詞;(2)根據(jù)謂詞生成測試用例,使得每個謂詞的取值至少被測試一次;(3)執(zhí)行測試用例,檢查程序是否正確執(zhí)行。

分析convertBinaryToOctal程序,運用全謂詞使用測試方法得到的具體用例設計2.3.4全使用測試定義：全使用測試(AllUsesTesting)技術旨在檢測軟件程序中所有對于數(shù)據(jù)變量的使用情況,以此提高測試用例的覆蓋率和代碼質量。全使用測試分析的流程如下:(1)分析程序中的數(shù)據(jù)流:分析程序的源代碼,確定程序中的數(shù)據(jù)流,包括變量的定義、賦值和使用等情況;(2)生成測試用例:根據(jù)數(shù)據(jù)流分析結果,生成測試用例,覆蓋所有的數(shù)據(jù)使用情況,包括變量定義、賦值和使用等情況。為了覆蓋所有的數(shù)據(jù)使用情況,測試用例需要包括所有分支情況和邊界情況;(3)執(zhí)行測試用例:執(zhí)行測試用例,并記錄測試結果;(4)檢查測試結果:檢查測試結果,驗證程序的正確性和穩(wěn)定性。2.3.5全定義-使用路徑測試定義：全定義-使用路徑測試(AllDefinitionUsesPathsTesting)其目的是在測試程序中的每個數(shù)據(jù)定義和使用關系路徑。它的主要思想是找出所有程序中定義和使用變量的路徑,然后測試每個路徑以確保程序可以按照預期工作。該全定義-使用路徑測試的流程是:(1)確定程序中的所有數(shù)據(jù)定義和使用關系;(2)根據(jù)數(shù)據(jù)定義和使用關系,確定程序中所有可能的路徑;(3)對于每個路徑,構造測試用例以檢查程序是否按照預期工作;(4)運行測試用例,并記錄測試結果;(5)分析測試結果以確定程序中存在的錯誤和缺陷。

分析convertBinaryToOctal程序,運用全使用和全定義-使用路徑測試方法得到的具體用例設計。測試實踐第7章7.5數(shù)據(jù)流測試2.4Mock模擬對象模擬對象MockObject

模擬對象(MockObject)是以可控的方式模擬真實對象行為的假的對象。在面向對象程序設計中,模擬對象通常用于單元測試,以隔離待測試的單元并對其進行獨立的、可重復的測試。通過將待測試單元所依賴的其他組件替換為模擬對象,可以專注于待測試單元的行為,而不必擔心其依賴的其他組件。

模擬對象是一種強大的測試工具,可以幫助開發(fā)人員提高代碼的質量和可靠性,減少測試的時間和成本。樁函數(shù)(Stub)和模擬對象(Mock)

樁函數(shù)(Stub)和模擬對象(Mock)是兩種常用的隔離技術,Stub主要驗證狀態(tài),而Mock不僅可驗證狀態(tài),還可驗證行為。相同點:兩者都是為了在測試過程中替換真實的依賴對象,以實現(xiàn)對被測試功能的隔離測試。兩者都是通過替換的方式來實現(xiàn),被測試的函數(shù)中的依賴關系。不同點：（1）實現(xiàn)方式不同:Stub是采用函數(shù)替代的方式,而Mock則是采用接口替換的方式。（2）對代碼的影響不同:Stub的侵入性比較強,Mock的侵入性相對較小。（3）應用場景不同:Stub通常用于具有返回值的方法，Mock還可用于無返回值的方法,測試程序的交互行為。（4）使用范圍不同:Stub通常適用于一些比較簡單、獨立的功能模塊,常用于單元測試、集成測試階段。而Mock則可以適用于更復雜、集成度更高的系統(tǒng)，與Stub比較,Mock使用范圍更廣。（5）性能影響不同:由于Stub需要在被測試代碼中加入一些額外的代碼,可能會對性能產生一定的影響。而Mock則因為不需要對被測試代碼進行修改,因此對性能的影響較小。示例1：設定返回值示例2：拋出異常2.5數(shù)據(jù)驅動測試數(shù)據(jù)驅動測試

測試時有些測試腳本非常類似,僅僅測試輸入與預期值不同,其他內容完全一致。對于這種情況,可采用數(shù)據(jù)驅動測試技術,將測試執(zhí)行腳本與測試數(shù)據(jù)分離,測試數(shù)據(jù)較多時,可存儲于單獨數(shù)據(jù)文件。使用向上取整函數(shù)ceil為例,將測試集編碼為逗號分隔的鍵值對,如“4.0,4.0”“3.5,4”“-3.5,-3”,每對數(shù)據(jù)對應測試輸入與預期結果測試實踐第7章7.4數(shù)據(jù)驅動測試2.6變異分析變異分析變異分析是一種評價測試用例集合有效性的技術。該方法基于大量軟件錯誤的歸因分析,即程序員難免犯錯,但是不會出現(xiàn)原則性大錯誤,通常只是微小錯誤。通過修改源代碼模擬人為錯誤,如果測試用例集未能識別該錯誤,則設計“新的”測試用例,直到檢出錯誤。變2.6.1變異算子變異算子是指應用于原始程序以生成變異體的操作,常用分類包括:常量替代(CRP)、變量替代(SVR)、算術運算符替代(AOR)、關系運算符替代(ROR)、語句刪除(SDL)、變量替代常量(SCR)和插入絕對值符號(ABS)等。2.6.2變異體分析一階變異體:在原有程序p上執(zhí)行單一變異算子并形成變異體p',則稱p'為p的一階變異體。高階變異體:在原有程序p上依次執(zhí)行多次變異算子并形成變異p',則稱p'為p的階變異體?？纱婊钭儺愺w:若不存在任何測試用例t,在變異體p'和原有程序p上的執(zhí)行結果不一致,則稱該變異體p'相對于測試用例集T是可存活變異體。等價變異體:若變異體p'與原有程序p在語法上存在差異，但是在語義上與p保持一致，則稱p'是p的等價變異體。2.6.3變異得分變異得分(MutationScore)是一種評價測試用例集錯誤檢測的有效指標。Score=殺死的變異體數(shù)量/(總的變異體數(shù)量-等價變異體數(shù)量)。變異得分的值介于0與1之間,數(shù)值越高,表明被殺死的變異程序越多,測試用例集的錯誤檢測能力越強,反之則越低。測試實踐第7章

7.6變異分析軟件測試技術第3章基于規(guī)格說明的測試

目錄3.1等價類劃分法3.2邊界值分析法3.3判定表方法3.4場景法3.5狀態(tài)轉換測試3.6隨機測試3.7基于屬性的測試3.8蛻變測試基于規(guī)格說明的測試

基于規(guī)格說明的測試技術可對應到軟件測試傳統(tǒng)分類中的黑盒測試,主要利用規(guī)格說明來指導測試用例的設計。

主要依據(jù)是軟件規(guī)格說明書,包括需求規(guī)格說明書、設計規(guī)格說明書等,分析測試目標,根據(jù)質量要求運用測試方法設計測試用例。

對于復雜軟件,僅僅采用一種測試方法是難以構建理想的測試用例集的,通常需要綜合運用多種設計技術來設計測試用例。3.1等價類劃分法等價類劃分的基本思想就是設想可以用一組有限的數(shù)據(jù)代表近似無限的數(shù)據(jù),將漫無邊際的隨機測試變?yōu)榫哂嗅槍π缘臏y試。等價類是指某個輸入域的特定的子集合,在該子集合中各個輸入數(shù)據(jù)對于暴露程序中的錯誤都是等效的。等價類劃分測試方法是把所有可能的輸入數(shù)據(jù),即程序的輸入域劃分成若干等價類,然后從每個等價類中選取少數(shù)有代表性的數(shù)據(jù)作為測試用例。針對軟件不同的規(guī)格說明可能使用不同的等價類劃分方法,測試用例的質量受到等價類劃分的影響,通常也跟測試人員的經驗相關。常用的等價類劃分規(guī)則①如果輸入條件規(guī)定了一個取值范圍,那么就應確定一個有效等價類,以及兩個無效等價類。②如果輸入條件規(guī)定了取值的個數(shù),那么就應確定一個有效等價類和兩個無效等價類。③如果輸入條件規(guī)定了一個輸入值的集合,而且程序會對每個值進行不同處理,那么就應為每個輸入值確定一個有效等價類和一個無效等價類。④如果存在輸入條件規(guī)定了“必須是”的情況,那么就應確定一個有效等價類和一個無效等價類。⑤如果存在輸入條件是一個布爾量,則可以確定一個有效等價類和一個無效等價類。等價類劃分測試用例設計流程①等價類劃分對每個輸入或外部條件進行等價類劃分,形成等價類表,為每一等價類規(guī)定一個唯一的編號。②為有效等價類設計測試用例設計一個測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價類,重復這一步驟,直到所有有效等價類均被測試用例所覆蓋。③為無效等價類設計測試用例設計一個新測試用例,使其只覆蓋一個無效等價類,重復這一步驟直到所有無效等價類均被覆蓋。

例如：學院要打印2018—2023年的學生成績表,其中打印日期為6位數(shù)字組成,前4位為年份,后2位為月份。根據(jù)上述測試用例設計流程?！さ谝徊竭M行等價類劃分,劃分的結果如表3-1所示?！さ诙綖橛行У葍r類設計測試用例,對表中編號①②③的3個有效等價類用一個測試用例覆蓋,如表3-2所示?！さ谌綖闊o效等價類設計測試用例,要為每一個無效等價類至少設計一個測試用例,如表3-3所示。3.2邊界值分析法實踐證明,考慮了邊界條件的測試用例與其他沒有考慮邊界條件的測試用例相比,具有更高的測試回報率。邊界值分析法可以和等價類劃分法結合起來使用,在劃分等價類的基礎上,選擇輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的數(shù)據(jù)。邊界值分析方法與等價劃分方法存在兩方面的不同:①與從等價類中挑選出任意一個元素作為代表不同,邊界值分析需要選擇一個或多個元素,以便等價類的每個邊界都經過一次測試。②與僅僅關注輸入條件(輸入空間)不同,還需要考慮從結果空間(輸出等價類)設計測試用例。常用邊界值分析原則邊界值不僅是指數(shù)據(jù)取值的邊界,還可以是數(shù)據(jù)的個數(shù)、文件的個數(shù)、記錄的條數(shù)等。軟件測試的邊界條件類型有很多種,比如數(shù)字、字符、位置、大小、速度、方位、尺寸、空間等,邊界值就可以對應為最大/最小、首位/末位、上/下、最大/最小、最快/最慢、最高/最低、最短/最長、空/滿等。常用原則：①如果輸入條件規(guī)定了一個輸入值范圍,那么應針對范圍的邊界設計測試用例,針對剛剛越界的情況設計無效輸入測試用例。②如果輸入條件規(guī)定了輸入值的數(shù)量,那么應針對最小數(shù)量輸入值、最大數(shù)量輸入值,以及比最小數(shù)量少一個、比最大數(shù)量多一個的情況設計測試用例。③如果輸出條件規(guī)定了取值范圍、輸出條件的數(shù)量,那么也要分別使用上述兩條原則。④如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例。⑤如果程序中使用了一個內部數(shù)據(jù)結構,則應當選擇這個內部數(shù)據(jù)結構的邊界上的值作為測試用例。⑥如果程序的輸入或輸出是一個有序序列(例如順序的文件、線性列表或表格),則應特別注意該序列的第一個和最后一個元素。邊界值分析法通常作為等價類方法的補充,方法本身是基于獨立性假設和單缺陷假設,同時邊界值測試關注的是系統(tǒng)邊界,并不關注系統(tǒng)對不同類型數(shù)據(jù)的處理規(guī)律,因此,使用該法設計的測試用例往往具有較大的系統(tǒng)冗余與漏洞,但這并不影響該法的有效性。

在之前的等價類劃分法設計例子中得到了表3-1等價類劃分結果,在等價類劃分結果中以報表日期長度來舉例,分析邊界值可以得到表3-4。

結合等價類分析法,根據(jù)表3-4邊界值分析表,可以得到部分邊界值測試用例,如表3-5所示。3.3判定表方法等價類劃分法和邊界值分析法是用于單因素和單變量的數(shù)據(jù)分析,但是在實際應用中,許多輸入由多個因素構成,而不是單一因素,這時就需要考慮多因素組合分析。檢驗各種輸入條件的組合并不是一件容易的事情,因為即使將所有的輸入條件劃分成等價類,它們之間的組合情況也是非常多的。常用的組合分析方法有判定表方法、因果圖法、兩兩組合測試法和正交試驗法。判定表是分析和表達多因輸入和輸出的工具,它借助表格方式完成對輸入條件的組合設計,因為判定表以輸入條件的完全組合來滿足測試的覆蓋率要求,所以它具有很嚴格的邏輯性,基于判定表的測試用例設計方法是最嚴格的組合設計方法之一,借助其產生的測試用例具有良好的完整性。判定表的構成構建判定表的5個要素：①條件樁

:

列出問題的所有條件。②動作樁

:

列出可能針對問題所采取的操作。③條件項

:

針對所列條件的具體賦值。④動作項

:

列出在條件項(各種取值)組合情況下應該采取的動作。⑤規(guī)則

:

任何一個條件組合的特定取值及其相應要執(zhí)行的操作。判斷三條邊是否能組合成三角形,可以構造如表3-6所列的判定表。判定表設計測試用例流程①列出條件樁。②列出動作樁。③輸入條件項及其組合。④輸入動作項,制定初始判定表。⑤簡化、合并相似規(guī)則或者相同動作。⑥根據(jù)判定表設計測試用例。

測試打印機打印業(yè)務執(zhí)行的功能。打印機執(zhí)行打印任務受到驅動程序、打印紙張、打印機墨粉三個條件的影響,打印機打印時可能會產生完成打印內容、提示驅動程序不對、提示沒有紙張、提示沒有墨粉四個結果。

本示例中需求的條件的優(yōu)先級分別為最先檢查紙張條件,然后檢查墨粉條件,最后檢查驅動程序條件。同時,沒有紙張和沒有墨粉、沒有紙張和打印驅動程序有問題或者三個條件都不滿足時程序優(yōu)先提示沒有紙張。分析后得到初始判定表,如表3-7所示。判定表設計示例初始判定表對初始判定表進行簡化用例1:在驅動程序正確、有紙張、有墨粉的條件下打印。預期結果:打印成功。用例2:在驅動程序錯誤、有紙張、有墨粉的條件下打印。預期結果:提示驅動程序問題。用例3:在有紙張、沒有墨粉的條件下打印。預期結果:提示沒有墨粉。用例4:在沒有紙張的條件下打印。預期結果:提示沒有紙張。根據(jù)簡化后的判定表進行測試數(shù)據(jù)的設計3.4場景法場景法是通過分析軟件運用場景對系統(tǒng)功能點或業(yè)務流程進行覆蓋的測試用例設計方法。對于軟件中用事件來觸發(fā)控制流程的,場景法中把事件流分成基本流和備選流?；玖魇侵笍南到y(tǒng)的某個初始狀態(tài)開始,經過一系列狀態(tài)變化后到達終止狀態(tài)的過程中一個主要的業(yè)務流程;備選流是以基本流為基礎,在經過基本流上每個判定節(jié)點(包括條件判定和循環(huán)判定)處滿足不同的觸發(fā)條件,而導致的其他事件流。程序只有一個基本流,備選流可以有多個。從基本流開始,通過描述經過的路徑可以確定某個場景,場景是事件流的一個實例,一個場景對應一個用戶執(zhí)行的操作序列。場景描述的基本原則①最少的場景數(shù)等于事件流的總數(shù),即基本流與備選流的總數(shù)。②有且唯有一個場景僅包含基本流。③對應某個備選流,至少應有一個場景覆蓋該備選流,且在該場景中應盡量避免覆蓋其他的備選流。由右圖可得到如下場景:基本流、基本流+備選流1、基本流+備選流2、基本流+備選流2+備選流4、基本流+備選流2+備選流4+備選流5、基本流+備選流5……場景法測試用例設計的步驟①根據(jù)軟件需求規(guī)格說明,分析描述基本流和各項備選流。②根據(jù)基本流和備選流構建場景。③對每個場景設計測試用例。④對生成的測試用例進行復審,確定最終的測試用例,對每個測試用例確定測試數(shù)據(jù)。ETC收費系統(tǒng)場景法用例設計示例。

(1)詳細分析系統(tǒng)的需求規(guī)格說明,得到ETC收費系統(tǒng)基本流和ETC收費系統(tǒng)備選流。

(2)構建測試場景。

根據(jù)第一步對基本流和備選流分析的結果,測試場景最少需要5個,為了說明在實際測試場景構建過程中的難點,示例中會增加部分其他場景,場景構建沒有完全唯一的答案。(3)根據(jù)第(2)步中分析確定的每個測試場景設計測試用例,此時得到的測試用例表中不包含實際的測試數(shù)據(jù),而是測試執(zhí)行數(shù)據(jù)的設計依據(jù)。主要是分析輸入項(系統(tǒng)輸入或者系統(tǒng)狀態(tài))和預期結果對應關系,表中的V表示有效數(shù)據(jù)元素,I表示無效數(shù)據(jù)元素,n/a表示不適用。(4)復核并確定測試用例,設計最終執(zhí)行的測試數(shù)據(jù),每個測試場景中的輸入項測試數(shù)據(jù)選擇時還可以結合等價類、邊界值等方法。3.5狀態(tài)轉換測試狀態(tài)轉換測試是基于產品的規(guī)格分析,通過引入狀態(tài)圖來描述測試對象和測試數(shù)據(jù)、對象狀態(tài)之間的關系,對系統(tǒng)的每個狀態(tài)及與狀態(tài)相關的函數(shù)進行測試,通過不同的狀態(tài)驗證程序的邏輯流程。狀態(tài)轉換測試用于測試被測對象通過有效轉換,進入和退出已定義狀態(tài)的能力,以及嘗試進入無效狀態(tài)或覆蓋無效轉換的能力。事件導致測試對象從一個狀態(tài)轉換到另一個狀態(tài),并執(zhí)行操作。事件可以通過影響轉換路徑的條件(有時稱為守衛(wèi)條件或轉換監(jiān)控)來限定。該信息會在狀態(tài)轉換圖或狀態(tài)轉換表中顯示(也可能包括狀態(tài)之間潛在的無效轉換)。狀態(tài)轉換測試適用于任何有狀態(tài)定義并讓狀態(tài)之間因事件發(fā)生轉換的軟件(例如屏幕變化)。狀態(tài)轉換測試可以在任何測試級別上使用。嵌入式軟件、Web軟件和任何狀態(tài)轉換類軟件都適合進行此類測試。狀態(tài)轉換測試的基本單元是單個轉換。簡單地測試所有的單個轉換將發(fā)現(xiàn)一些狀態(tài)轉換缺陷,但是通過測試狀態(tài)轉換序列可能會發(fā)現(xiàn)更多的缺陷。單個轉換序列被稱為0-切換(0-switch),兩次連續(xù)的轉換序列稱為1-切換(1-switch),三次連續(xù)的轉換序列稱為2-切換(2-switch),依此類推。通常,N切換(N-switch)表示N+1次連續(xù)切換。隨著N的增大,N切換的數(shù)量增長非常快,從而難以通過合理的少量測試來實現(xiàn)N切換的覆蓋。與其他類型的測試技術一樣,狀態(tài)轉換覆蓋率有一個層次結構?？山邮艿淖畹透采w率是指到達過每個狀態(tài)和遍歷過每個狀態(tài)轉換至少一次。100%的轉換覆蓋(100%的0-切換覆蓋率)將保證到達過每個狀態(tài)和遍歷過每個狀態(tài)轉換,除非系統(tǒng)設計或狀態(tài)轉換模型(圖或表)有缺陷。根據(jù)狀態(tài)和轉換之間的關系,為了執(zhí)行某個轉換一次,可能需要多次遍歷某些轉換。術語“N-切換覆蓋率”是指長度為N+1的轉換所覆蓋的數(shù)量,占該長度的轉換總數(shù)的百分比。例如,要實現(xiàn)100%的1-切換覆蓋率,每個有效序列需要至少測試兩次連續(xù)的轉換?！巴蹈采w”適用于轉換序列形成循環(huán)的情況。實現(xiàn)100%往返覆蓋意味著已經測試了從任何狀態(tài)出發(fā)又回到原來相同狀態(tài)的所有循環(huán)。此循環(huán)不包含任何特定狀態(tài)(初始/最終狀態(tài))的多次出現(xiàn)。狀態(tài)轉換測試的用例設計流程①分析需求規(guī)格說明,提取狀態(tài)。②繪制狀態(tài)轉換圖,確定開始狀態(tài),輸入、輸出及結束狀態(tài)。③確定測試強度,通過狀態(tài)圖得到狀態(tài)樹。④選取測試數(shù)據(jù),設計測試用例。

以ISTQB(國際軟件測試認證委員會)高級測試分析師認證的練習題為例。繪制狀態(tài)圖①提取購物系統(tǒng)交易過程的需求。提取瀏覽商品、選擇、登錄、交易、已經確認、退出這6個用戶狀態(tài)。繪制狀態(tài)樹②將狀態(tài)圖轉換為狀態(tài)樹,如下圖所示。確定覆蓋強度到過每個狀態(tài)和遍歷過每個轉換至少一次,100%的0-切換覆蓋。選取測試數(shù)據(jù)

設計測試用例③從起始狀態(tài)“瀏覽商品”開始尋找它的下一個狀態(tài),確認0-切換是否已經覆蓋,如果沒有則繼續(xù)遍歷,得到測試路徑如下:路徑1:“瀏覽商品”→“退出”。路徑2:“瀏覽商品”→“瀏覽商品”。路徑3:“瀏覽商品”→“選擇”→“退出”。路徑4:“瀏覽商品”→“選擇”→“瀏覽商品”。路徑5:“瀏覽商品”→“選擇”→“登錄”→“退出”。路徑6:“瀏覽商品”→“選擇”→“登錄”→“登錄”。路徑7:“瀏覽商品”→“選擇”→“登錄”→“交易”→“退出”。路徑8:“瀏覽商品”→“選擇”→“登錄”→“交易”→“交易”。路徑9:“瀏覽商品”→“選擇”→“登錄”→“交易”→“已經確認”→“瀏覽商品”。路徑10:“瀏覽商品”→“選擇”→“登錄”→“交易”→“已經確認”→“退出”。④以上每條測試路徑為1條測試用例,對每條路徑進行覆蓋測試即可。測試實踐第8章8.6基于Selenium的Web功能測試8.7基于Playwright的Web功能測試3.6隨機測試

隨機測試(RandomTesting,RT)是一種選擇測試用例的策略。相對于人工設計的測試用例,RT客觀、公平。SUT

:

SoftwareUnderTest,被測軟件。S

:

用于SUT的全部可能測試用例的集合。|S|

:

集合S的基數(shù)。F

:

S的子集,測試失敗Failure的測試用例集合,測試失敗表明發(fā)現(xiàn)了軟件失效。FR

:

FailureRate,失敗比率,FR=|F|/|S|,表示在均勻選擇的情況下,隨機測試發(fā)現(xiàn)失效的可能性。RT的局限性RT不僅實現(xiàn)成本低廉,而且易于理解,得以在工業(yè)界實際應用。然而實踐中大多采用偽隨機數(shù)生成器。因為RT取樣采用均勻分布,所以每個測試用例被選中的機會是相同的,即P=1/|S|，能完美應用于數(shù)值型數(shù)據(jù)。但是,實踐中仍存在一些限制,例如:(1)對于樹、數(shù)組、圖等復雜數(shù)據(jù)結構,如何確保均勻采樣;(2)樣本空間很大時,如何限制內存/時間消耗;(3)如何獲得不同長度的測試數(shù)據(jù);RT主要應用場景(1)觸發(fā)失效以檢驗SUT是否具有缺陷;(2)提高某種覆蓋率,如語句覆蓋;(3)評估SUT的可靠性;RT

概率分布定義

:

隨機變量X為發(fā)現(xiàn)失效所需執(zhí)行測試的次數(shù),X取值范圍為{1,2,3,…},假設第k次發(fā)現(xiàn)失效,k≥1,之前的k-1次均未發(fā)現(xiàn)失效,所以如果k-1次未發(fā)現(xiàn)失效,那么第k次發(fā)現(xiàn)失效的概率P(X=k)=(1-FR)^(k-1)*FR,服從幾何分布,期望Mean=1/FR,方差Variance=(1-FR)/FR^2。FR分別取0.2與0.01時P(X=k)的概率分布如下圖所示。隨著未發(fā)現(xiàn)失效的測試次數(shù)增加,RT發(fā)現(xiàn)失效的概率快速下降。Mean次測試發(fā)現(xiàn)失效的概率P(X=1/FR)=(1-FR)^(1/FR-1)·FR,當FR=0.2,期望Mean=5,P(X=5)=0.08。綜上,k=1時發(fā)現(xiàn)失效的概率最高,因此,RT通常用于首次測試。RT

概率分布假設代碼存在一個缺陷,S中至少有一條測試用例能觸發(fā)失效,執(zhí)行k次測試觸發(fā)失效的概率為P(failure),因為未觸發(fā)失效的概率P(pass)=(1-FR)^k,那么P(failure)=1-P(pass)=1-(1-FR)^k。FR分別取0.2與0.01時的P(failure)概率分布如右圖所示,即RT累積概率。隨著測試次數(shù)不斷增加,發(fā)現(xiàn)失效的概率也隨之增大。該性質可用于估計RT所需測試用例的數(shù)量。通常測試之前,失效比率FR是未知的,可通過已有項目測試信息、文獻、被測軟件類型等進行評估,然后根據(jù)RT的數(shù)學性質估計測試用例數(shù)量。何時使用RT(1)自動測試預言測試用例由輸入與測試預言testoracle組成,因為RT只生成了輸入,所以執(zhí)行RT需要自動生成測試預言。(2)復雜問題系統(tǒng)測試比單元測試要復雜得多,可優(yōu)先考慮使用RT。(3)經驗分享首輪測試應用RT,監(jiān)控覆蓋指標或測試目標,然后運用更復雜或有針對性的技術。(4)可靠性評估根據(jù)用戶的操作習慣,建立使用模型,然后以此作為RT的概率分布,而不再使用均勻分布。改進RT某些測試用例可能更容易揭示缺陷。根據(jù)觀察,假設測試用例越具有多樣性,發(fā)現(xiàn)缺陷的可能性越高,當然,其他假設可能也是有效的。基于該假設,Y比X更具多樣性,所以,Y更有可能識別缺陷。軟件測試實踐發(fā)現(xiàn),觸發(fā)缺陷的測試用例通常具有聚集效應。假設下圖中陰影區(qū)域能觸發(fā)缺陷,同樣數(shù)量的測試用例,顯然在右側圖測試用例的分布比左側圖更具多樣性,因此具有更高的發(fā)現(xiàn)缺陷的可能性。改進RT常使用距離作為度量測試用例多樣性的指標。假設Distance(tc1,tc2)是測試用例tc1與tc2之間的距離,如果tc1==tc2,則Distance(tc1,tc2)=0。如果輸入數(shù)據(jù)恰好是整型,對于SUT:voidfoo(intx){…},Distance(tc1,tc2)=|x1-x2|,例如Distance(-3,4)=7,其中x1、x2是測試用例tc1與tc2的輸入數(shù)據(jù)。數(shù)據(jù)結構可能會比較復雜,如數(shù)組、集合、函數(shù)調用序列等。對于數(shù)值型數(shù)據(jù),多樣性指標常用歐幾里得距離EuclideanDistance,Distance(tc1,tc2)=∑(v1,v2)2,v是測試用例tc的取值。假設SUT:voidfoo(intx,inty,intz){…},測試用例tc1=(x1,y1,z1)和tc2=(x2,y2,z2),Distance(tc1,tc2)=(x1-x2)2+(y1-y2)2+(z1-z2)2。字符型數(shù)據(jù)可采用漢明距離HammingDistance。函數(shù)調用序列可先編碼為字符串,然后使用漢明距離度量多樣性。綜上,假設G是S的子集,多樣性度量函數(shù)diversity,G中的所有測試用例對(g1,g2)的多樣性可表示為Diversity(G)=∑diversity(g1,g2)。改進RT自適應隨機測試(AdaptiveRandomTesting,ART)是RT的一種改進。RT直接使用隨機生成樣本,

ART則是挑選相對于已有測試用例集G最多樣化的數(shù)據(jù)作為候選輸入。通用算法如下:①隨機生成一組輸入Z;②如果G為空,則將Z放入G;③如果G不為空,計算Z中每個數(shù)據(jù)與G的多樣性,挑選得分最高的數(shù)據(jù)作為候選項放入G。ART實現(xiàn)容易,關鍵問題是定義合適的多樣性度量函數(shù),如歐幾里得距離、漢明距離等,不僅限于距離。通常,ART顯著優(yōu)于RT。目前,ART工業(yè)應用較少。改進RT如圖所示ART過程,深色圓點為G的成員,淺色圓點為Z的成員,采用距離度量多樣性。(1)G中有兩個數(shù)據(jù);(2)隨機生成了三個數(shù)據(jù),計算它們到G中各點的距離,將距離最大的點放入G中;(3)重復(2)。假設需要k個測試用例,距離的計算次數(shù)N=0+|Z|+2|Z|+…+(k-1)|Z|=|Z|k(k-1)/2,如果|Z|是常數(shù),上式計算復雜度為O(k^2)。事實上,當k較大或輸入維度較高時,距離計算可能非常耗時?？傊?RT是有效的、實現(xiàn)成本低廉的測試技術,常用于首輪測試,因RT有效性容易鈍化,必須與其他測試技術一起使用以提高測試整體的有效性。如果打算在自動化測試使用RT作為測試輸入的生成器,那么需要考慮引入自動測試預言,如基于屬性的測試、蛻變測試等,否則難以自動執(zhí)行。測試實踐第8章8.2基于Randoop的隨機測試8.3基于EvoSuite的隨機測試3.7基于屬性的測試

基于屬性的測試(Property-BasedTesting,PBT)是一種RT的變體,屬性Property是指程序單次執(zhí)行過程中不變的輸出性質,PBT通過檢查屬性是否保持來判定程序正確性。PBT的一般步驟:①識別屬性;②隨機生成輸入值,執(zhí)行被測程序;③屬性保持,則測試通過;存在反例,則測試不通過。①減少編寫測試代碼的時間,一條PBT測試用例相當于多條人工編寫

的測試用例;②提高發(fā)現(xiàn)缺陷的可能性,PBT輸入樣本數(shù)量更多、范圍更廣,對于多

個輸入?yún)?shù),可

以產生多種參數(shù)組合;③評定錯誤耗時更短,如果存在違例,PBT將給出觸發(fā)反例的最小輸入值。PBT的優(yōu)點QuickCheckPBT比較經典的框架是QuickCheck,1999年由KoenClaessen和JohnHughes開發(fā),最初版本為Haskell語言。根據(jù)維基百科,如下圖所示,現(xiàn)在已經移植到許多其他編程語言中了。PBT

腳本示例即使在同一種編程語言環(huán)境中,也可能存在多種實現(xiàn)變體,如Java社區(qū)的JUnitQuickcheck、jqwik、QuickTheories、FunctionalJava、JCheck等。接下來,使用JUnitQuick

check展示PBT的工作過程,被測函數(shù)為組合數(shù)求解函數(shù)combinations,兩個輸入數(shù)據(jù)類型為int,假設樣本數(shù)量n與參與組合的樣本數(shù)量k的輸入域均為[1,30],屬性為C(n,k)≥1,測試腳本如圖所示。腳本標注具體含義①RunWith,測試運行器,此例使用JUnitQuickcheck。②Property,執(zhí)行選項,控制JUnitQuickcheck運行模式,默認為shrink=true,收縮模式,尋找反例的最小輸入集合。③InRange,生成器,在給定范圍內隨機抽樣。④assumeThat,參數(shù)約束,如參數(shù)k應小于參數(shù)n。測試腳本表明采用收縮模式,從輸入域[1,30]中隨機生成輸入值并賦值給變量n與k,并且k<n,調用被測函數(shù)combinations(n,k),得到結果actual_k,屬性actual_k≥1作為測試預言,當屬性成立則測試通過,否則測試失敗?？刂婆_輸出腳本使用System.out.print()向控制臺Console窗口輸出n、k和actual_k,如上圖所示。combinations執(zhí)行結果存在違反屬性的情況,如-553、-16924、-1等,當JUnitQuickcheck選用收縮模式時,會嘗試尋找違例的最小取值組合，如下圖所示。根據(jù)結果可知,存在多個違反屬性的輸