軟件測試（第2版）全套可編輯PPT課件1軟件測試基礎知識2黑盒測試3白盒測試4性能測試/CONTENT目錄5缺陷報告、分析及處理6API測試7自動化測試8軟件產品測試與驗收/CONTENT目錄9測試實例———黎明資產管理系統(tǒng)模塊1軟件測試基礎知識1.1軟件測試的起源與發(fā)展1.2軟件測試的定義和目標1.3軟件測試的方法和技術1.4常見的軟件測試模型1.5軟件測試的原則

1.6軟件測試的一般流程1.7企業(yè)測試舉例軟件是人們工作和學習的好助手,人們平時常用的軟件包括Windows操作系統(tǒng)、Office辦公軟件、QQ和微信等。軟件是通過軟件開發(fā)流程開發(fā)出來的產品,它是計算機系統(tǒng)運行的指令、數據和相關文檔的集合,即軟件等于程序、數據加上文檔。程序是事先按照預定功能、性能等要求設計和編寫的指令序列;數據是使程序正常處理信息的數據結構及信息表示;文檔是與程序開發(fā)、維護和使用有關的技術數據和圖文資料。軟件測試是伴隨著軟件的產生而產生的。早期的軟件規(guī)模都很小、復雜程度較低,軟件開發(fā)的過程混亂無序、相當隨意,測試的含義比較狹窄,開發(fā)人員將測試等同于“調試”,目的是糾正軟件中已知的錯誤經常常由開發(fā)人員自己完成這部分工作。對測試的投入極少,測試介入也較晚經常常是等到形成代碼,產品已經基本完成時才進行測試。1.1軟件測試的起源與發(fā)展到了20世紀80年代初期,IT行業(yè)進入了大發(fā)展時代,軟件趨向大型化、高復雜度,軟件的質量越來越重要。這時,一些軟件測試的基礎理論和實用技術開始形成,并且人們開始為軟件開發(fā)設計了各種流程和管理方法,軟件開發(fā)的方式也逐漸由混亂無序的開發(fā)過程過渡到結構化的開發(fā)過程,以結構化分析與設計、結構化評審、結構化程序設計及結構化測試為特征。1983年，電氣電子工程師學會（IEEE）提出的軟件工程術語中給軟件測試下的定義是：“使用人工或自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。它是幫助識別開發(fā)完成(中間或最終版本)的計算機軟件(整體或部分)的正確度、安全度和質量的軟件過程?！边@個定義明確指出:軟件測試的目的是檢驗軟件系統(tǒng)是否滿足需求。它是幫助識別開發(fā)完成(中間或最終版本)的計算機軟件(整體或部分)的正確度、安全度和質量的軟件過程?！?.1軟件測試的起源與發(fā)展1.2軟件測試的定義和目標1.2.1軟件測試的定義軟件測試是一種系統(tǒng)性的活動,它涉及運行軟件或系統(tǒng)的過程,以此來評估其功能、性能和質量,目的是發(fā)現(xiàn)潛在的問題或錯誤。作為軟件開發(fā)生命周期中的一個重要環(huán)節(jié),軟件測試旨在確保軟件能夠按照預期的方式正常運行。1.2軟件測試的定義和目標1.2.2軟件測試的目標軟件測試的主要目標包括以下幾點。(1)發(fā)現(xiàn)缺陷(2)驗證功能正確性(3)評估軟件質量(4)提高開發(fā)效率(5)驗證需求(6)提高可靠性(7)優(yōu)化用戶體驗(8)保障安全性1.3軟件測試的方法和技術

軟件測試發(fā)展至今,已經形成一個龐大的系統(tǒng)工程,有許多常用的測試方法,如黑盒測試、白盒測試和自動化測試等,其種類和名稱十分龐雜。因此需要對軟件測試的方法進行類型上的劃分,便于明確測試過程、完成哪些操作步驟以及需要達到的測試目標,盡量保證測試的完整性。按照不同的分類標準可以將軟件測試分為很多不同的種類,如圖1-1所示。圖1-1軟件測試分類1.3軟件測試的方法和技術

黑盒測試和白盒測試是軟件測試中常用的兩種方法,它們分別從不同的角度對軟件進行測試。它們的主要區(qū)別在于測試人員在測試過程中需要對軟件內部具體實現(xiàn)細節(jié)的了解程度不同,如圖1-2所示。圖1-2黑盒測試和白盒測試

1.3.1黑盒測試和白盒測試1.3軟件測試的方法和技術

1.黑盒測試黑盒測試是一種基于軟件外部行為和規(guī)格要求的測試方法。在這種測試中,測試人員不需要了解軟件內部的具體實現(xiàn)細節(jié),而是僅根據軟件規(guī)格或需求文檔來設計測試用例,通過輸入數據并觀察輸出結果來驗證軟件的正確性和功能完整性。黑盒測試的特點如下。1.3.1黑盒測試和白盒測試（1）聚焦于軟件的功能和規(guī)格要求,不關注其內部實現(xiàn)。（2）不需要程序員的專業(yè)知識,測試人員可以獨立進行測試。（3）測試用例的設計主要基于等價類劃分、邊界值分析和錯誤推測等技術。（4）旨在發(fā)現(xiàn)軟件的功能問題,如輸入驗證、功能邏輯錯誤等。（5）常用的技術和方法包括功能測試、界面測試、配置測試、性能測試和安全測試等。1.3軟件測試的方法和技術

2.白盒測試白盒測試是一種基于對軟件內部結構、邏輯和代碼的理解來設計測試用例并進行測試的方法。測試人員通過訪問和分析源代碼、控制流圖及路徑覆蓋等信息,從內部的角度來評估軟件的質量,從而揭示潛在的錯誤和缺陷。白盒測試的特點如下。1.3.1黑盒測試和白盒測試（1）需要測試人員具備一定的編程和代碼分析能力,能夠理解軟件的內部實現(xiàn)。（2）能夠深入軟件的內部邏輯,如發(fā)現(xiàn)隱藏的邊界條件、錯誤路徑和異常情況。（3）旨在檢測軟件的結構性問題,如邏輯錯誤、代碼覆蓋不全等。1.3軟件測試的方法和技術

1.功能測試功能測試旨在驗證軟件的各項功能是否均按照規(guī)格要求正確運行。這種測試通?；谲浖男枨笠?guī)格和功能規(guī)格文檔來設計測試用例。功能測試的主要目標如下。（1）驗證軟件的功能是否符合用戶需求和規(guī)格要求。（2）檢查軟件的輸入和輸出是否正確。（3）確保軟件的各項功能能夠穩(wěn)定、正常地工作。（4）發(fā)現(xiàn)并報告功能缺陷、邏輯錯誤和算法問題等。功能測試涵蓋以下方面的測試:基本功能、邊界條件、異常情況、用戶界面、數據輸入驗證、功能組合和功能交互等。1.3.2功能測試、性能測試和安全測試1.3軟件測試的方法和技術

2.性能測試性能測試旨在評估軟件在各種負載情況下的性能表現(xiàn)和可靠性。該類型的測試有助于確定軟件在正常和峰值負載下的響應時間、吞吐量、穩(wěn)定性和資源利用率等方面的表現(xiàn)。性能測試的關注點如下。1.3.2功能測試、性能測試和安全測試(1)測試軟件在不同負載情況下的響應時間和吞吐量。(2)確認軟件在長時間運行時的穩(wěn)定性和可靠性。(3)評估資源的利用率,如內存、CPU和網絡帶寬等。(4)進行負載均衡和容量規(guī)劃等。性能測試包括負載測試、壓力測試、容量測試、穩(wěn)定性測試和配置測試等。1.3軟件測試的方法和技術

3.安全測試安全測試旨在評估軟件系統(tǒng)的安全性,以發(fā)現(xiàn)潛在的安全漏洞和脆弱性,并確保軟件對潛在攻擊有足夠的抵御能力。安全測試的重點如下。(1)檢查軟件的認證和授權機制,以防止未經授權的訪問。(2)發(fā)現(xiàn)和修復潛在的漏洞,如輸入驗證、數據處理和訪問控制等。(3)評估軟件的加密和數據保護機制,以確保數據的機密性和完整性。(4)進行安全漏洞掃描和滲透測試等。安全測試包括網絡安全測試、應用程序安全測試、數據安全測試和身份驗證/授權測試等。1.3.2功能測試、性能測試和安全測試1631.3軟件測試的方法和技術

1.靜態(tài)測試靜態(tài)測試是在不運行實際軟件的情況下,對軟件的設計、文檔和代碼進行檢查和分析的方法。它主要關注軟件的靜態(tài)屬性,如結構、語法、規(guī)范和設計等,以發(fā)現(xiàn)潛在的問題和缺陷。靜態(tài)測試的特點如下。1.3.3靜態(tài)測試和動態(tài)測試(1)沒有實際去執(zhí)行軟件代碼。(2)靜態(tài)測試主要基于軟件文檔、源代碼和模型來進行驗證和評估。（3)目標是發(fā)現(xiàn)潛在的缺陷、錯誤和安全漏洞等。(4)靜態(tài)測試可以包括代碼審查、文檔審查、模型驗證、靜態(tài)分析等技術和方法。1.3軟件測試的方法和技術

1.靜態(tài)測試1.3.3靜態(tài)測試和動態(tài)測試靜態(tài)測試的優(yōu)勢在于可以盡早發(fā)現(xiàn)問題,從而有效降低缺陷修復的成本。它不僅能幫助我們發(fā)現(xiàn)設計的缺陷、邏輯錯誤、命名不規(guī)范和未使用的變量等問題,還能確保代碼遵循既定的標準和最佳實踐。靜態(tài)測試通常需要開發(fā)人員、質量保證團隊或專門的審查小組來執(zhí)行。1.3軟件測試的方法和技術

2.動態(tài)測試動態(tài)測試是一種在運行實際軟件時,對軟件的行為和功能進行驗證和評估的方法。該方法通過模擬用戶的實際操作和使用場景,來檢查軟件的實際執(zhí)行結果和輸出是否符合預期。動態(tài)測試的特點如下。1.3.3靜態(tài)測試和動態(tài)測試（1）需要執(zhí)行實際的軟件代碼。（2）動態(tài)測試基于輸入數據和操作流程來驗證軟件的功能和行為是否符合預期。（3）目標是發(fā)現(xiàn)實際運行中的錯誤、異常情況和功能問題。（4）動態(tài)測試可以包括單元測試、集成測試、系統(tǒng)測試和驗收測試等。1.3軟件測試的方法和技術

1.3.3靜態(tài)測試和動態(tài)測試靜態(tài)測試和動態(tài)測試是軟件測試過程中常用的兩種方法。靜態(tài)測試在不執(zhí)行實際軟件代碼的情況下,通過檢查和分析設計、文檔和代碼來發(fā)現(xiàn)問題;而動態(tài)測試是在執(zhí)行實際軟件代碼的情況下,通過驗證和評估軟件的行為和功能來發(fā)現(xiàn)問題。這兩種測試方法對于提高軟件質量、發(fā)現(xiàn)潛在錯誤和確保軟件符合預期都是至關重要的。在實際測試中,通常需要同時使用靜態(tài)測試和動態(tài)測試兩種方法,以提供更全面和有效的測試覆蓋。1.3軟件測試的方法和技術

1.3.4單元測試、集成測試、系統(tǒng)測試和驗收測試按照測試階段可以將軟件測試分為單元測試、集成測試、系統(tǒng)測試和驗收測試。這種分類方式與軟件開發(fā)過程相對應,目的是驗證軟件開發(fā)各個階段的成果是否符合預期要求。單元測試是軟件開發(fā)的第一步測試,目的是驗證軟件單元是否符合軟件需求與設計要求。單元測試大多是開發(fā)人員進行的自測。（1）單元測試集成測試是將已經被測試過的軟件單元組合在一起以測試它們之間的接口,用于驗證軟件是否滿足設計要求。在持續(xù)集成(continuous

integration,CI)的場景中,常見的測試方式包括冒煙測試和回歸測試。（2）集成測試1.3軟件測試的方法和技術

1.3.4單元測試、集成測試、系統(tǒng)測試和驗收測試系統(tǒng)測試是在完成集成測試之后,把軟件部分與系統(tǒng)的其他組成部分包括硬件、外部軟件、操作人員等結合起來,在實際運行或模擬環(huán)境下對計算機系統(tǒng)進行的一系列嚴格有效的測試,以發(fā)現(xiàn)潛在的問題。系統(tǒng)測試包括恢復測試、安全測試、壓力測試等類型。（3）系統(tǒng)測試驗收測試主要是對軟件產品說明進行驗證,逐行逐字地按照說明書的描述對軟件產品進行測試,確保其符合用戶的各項要求。（4）驗收測試1.3軟件測試的方法和技術

1.3.5手工測試與自動化測試

根據自動化程度的不同,可以將軟件測試分為手工測試與自動化測試。手工測試是指測試人員逐條執(zhí)行代碼來完成測試工作。然而,手工測試相對耗時費力,并且在測試人員處于疲憊狀態(tài)時很難保證測試的效果和準確性。相比之下,自動化測試是借助腳本、自動化測試工具等手段完成相應的測試工作,它也需要人工的參與。1.4常見的軟件測試模型1.瀑布模型傳統(tǒng)的瀑布模型包括項目計劃—需求分析—軟件設計—程序開發(fā)—軟件測試—集成維護這幾個階段。由于這個模型難以適應頻繁變化的需求,現(xiàn)在已經不常用,但是模型中這幾個階段都很有代表意義,對后面的模型有一定的參考價值。(1)項目計劃階段(2)需求分析階段主要是制訂項目總體研發(fā)計劃,樹立項目里程碑節(jié)點,輸出項目計劃書。明確用戶的需求定義,并對這個定義進行清晰地描述,是充分理解用戶需求,描述產品功能的重要階段,這個階段會輸出產品的需求規(guī)格說明書。(3)軟件設計階段會根據需求的定義來確定產品實現(xiàn)的方案,包括軟件和硬件的結構定義,組建模塊的實現(xiàn)方法,接口、界面和數據的組織方式,這個階段會輸出包括概要設計、詳細設計在內的多份說明書。1.4常見的軟件測試模型1.瀑布模型(4)程序開發(fā)階段(5)軟件測試階段這個階段是開發(fā)團隊根據需求定義和設計要求具體實現(xiàn)產品,根據編程規(guī)范,構建組件模塊,最后輸出產品版本。這個階段是通過獨立的測試小組或QA團隊評估產品是否滿足需求定義,最后輸出測試結果報告。(6)集成維護階段產品經過測試后,交付給用戶使用,開發(fā)人員根據用戶的使用情況,對產品進行維護,并進行必要的修改和升級等操作。1.4常見的軟件測試模型2.V模型V模型使用范圍最廣,它是從瀑布模型演化而來的,包括需求分析—概要設計—詳細設計—軟件編碼—單元測試—集成測試—系統(tǒng)測試—驗收測試這幾個階段,如圖1-3所示。圖1-3V模型

1.4常見的軟件測試模型2.V模型V模型按圖1-3中箭頭的方向指出了不同階段的順序和依賴性。每個階段的分工和解決的問題不同。01(1)單元測試和集成測試檢測程序是否滿足設計要求。02(2)系統(tǒng)測試03(3)驗收測試在功能、性能這些質量特性上是否滿足系統(tǒng)要求的指標。確定軟件是否滿足用戶的需求及合同的規(guī)定。1.4常見的軟件測試模型3.W模型W模型其實是雙V模型,它的設計思想是并發(fā)執(zhí)行軟件測試與軟件開發(fā)。開發(fā)與測試并行,有利于盡早發(fā)現(xiàn)問題,有利于及時了解項目的測試風險,及早地執(zhí)行相應的應對方案,加快項目的開發(fā)進度。W模型存在的缺點是整個開發(fā)階段仍然是串行的,上一階段未完全完成,無法進入下一階段,不支持敏捷模式的開發(fā)。W模型如圖1-4所示。圖1-4W模型

1.4常見的軟件測試模型4.X模型X模型的基本思路是分離出多個程序片段,并對各片段獨立地進行編碼和測試,此后進行頻繁的交接,再通過集成,最終合成可執(zhí)行的程序。已經通過測試的程序可以進行封版提交給用戶,也可以作為更大集成的一部分。X模型的右下方還定位了探索式測試,探索式測試是不進行事先計劃的特殊類型的測試,能夠幫助測試人員在測試計劃之外發(fā)現(xiàn)更多的錯誤。X模型如圖1-5所示。圖1-5X模型

1.4常見的軟件測試模型5.H模型H模型強調把測試分為測試準備和測試執(zhí)行兩個階段,如果其他流程的進展使測試點準備就緒,測試執(zhí)行活動就可以進行。在H模型中,測試是一個完全獨立的模型,因此可以與其他流程交叉進行,也便于盡早地執(zhí)行測試。H模型如圖1-6所示。圖1-6H模型

1.5軟件測試的原則1.測試應基于用戶需求所有的測試工作都應該建立在滿足用戶需求的基礎上,從用戶的角度來看,最嚴重的錯誤就是軟件無法滿足需求。應按照用戶的需求配置環(huán)境,按照用戶的使用習慣進行測試并評價結果。如果系統(tǒng)不能完成用戶的需求和期望,那么這個系統(tǒng)的研發(fā)就是失敗的。同時,在系統(tǒng)中發(fā)現(xiàn)和修改缺陷也是沒有任何意義的。在開發(fā)過程中用戶的早期介入和接觸原型系統(tǒng)就是為了避免這類問題發(fā)生的預防性措施。1.5軟件測試的原則2.測試要盡早進行并不斷迭代由于軟件的復雜性和抽象性,在軟件生命周期各階段都可能產生錯誤,所以不應把軟件測試僅僅看作軟件開發(fā)的一個獨立階段,而應當把它貫穿到軟件開發(fā)的各個階段中去。在需求分析和設計階段就應開始進行測試工作,編寫相應的測試計劃及測試設計文檔,同時堅持在開發(fā)各階段進行技術評審和驗證,這樣才能盡早發(fā)現(xiàn)和預防錯誤,杜絕某些缺陷和錯誤,提高軟件質量。盡早開展測試準備工作以使測試人員能夠在早期了解到測試的難度,預測測試的風險,有利于開發(fā)人員制訂出完善的計劃和方案,提高軟件測試及開發(fā)的效率,并規(guī)避測試中存在的風險。盡早開展測試工作有利于測試人員盡早發(fā)現(xiàn)軟件中的缺陷,大大降低錯誤修復的成本。測試工作進行得越早,越有利于提高軟件的質量,這是預防性測試的基本原則。1.5軟件測試的原則3.窮舉測試是不可能由于時間和資源的限制,窮舉測試(各種輸入和輸出的全部組合)是不可能的,測試人員可以根據測試的風險和優(yōu)先級控制測試的工作量,在測試成本、風險和收益之間取得平衡。此外,應避免冗余測試。1.5軟件測試的原則4.遵循GoodEnough原則GoodEnough原則是一種權衡投入/產出比的原則：不充分的測試是不負責任的，而過分的測試是一種資源的浪費，同樣也是一種不負責任的表現(xiàn)。測試不充分無法保證軟件產品的質量,但測試投入過多會造成資源的浪費。隨著測試資源投入的增加,測試的產出也是增加的,但當投入達到一定的比例后,測試的效果就不會明顯增強了。這個原則實施的困難之處在于如何界定什么樣的測試是不充分的,什么樣的測試是過分的。針對這種情況,測試人員最好制定最低測試通過標準和測試內容,然后具體問題具體分析。1.5軟件測試的原則5.缺陷要符合“二八”定理缺陷的“二八”定理就是在一般情況下,軟件80%的缺陷會集中在20%的模塊中,缺陷并不是平均分布的。存在這種現(xiàn)象的原因是:對一個程序模塊進行測試,已發(fā)現(xiàn)的錯誤數越多,其中存在的錯誤概率也就越大。錯誤集中發(fā)生的現(xiàn)象可能與程序員的編程水平和習慣有很大的關系。因此,在測試時要抓住主要矛盾,如果發(fā)現(xiàn)某些模塊比其他模塊具有更多的缺陷,那么要投入更多的人力重點測試這些模塊以提高測試效率。1.5軟件測試的原則6.殺蟲劑悖論殺蟲劑用得多了,害蟲就會產生免疫力,殺蟲劑就發(fā)揮不了效力。在測試中,同樣的測試用例被反復使用時,發(fā)現(xiàn)缺陷的能力就會越來越差。這種現(xiàn)象的主要原因在于測試人員沒有及時更新測試用例,同時對測試用例及測試對象過于熟悉,形成了思維定式。要想避免這種情況,就要不斷對測試用例進行修改和評審,不斷增加新的測試用例,這樣軟件中未被測試過的部分或先前沒有被使用過的輸入組合就會被重新執(zhí)行,從而發(fā)現(xiàn)更多的缺陷。1.6軟件測試的一般流1.6.1評測測試需求在軟件測試前需編寫一份軟件需求規(guī)格說明書檢查清單,目的是確保測試的全面性和準確性,以滿足軟件需求的驗證和評估。注意,評測測試需求并不是需求分析,而是測試人員在制訂測試計劃之前先對軟件需求規(guī)格說明書進行評測,按檢查項逐項檢查和判斷,從而得出前期需求分析的過程和結果的評價,活動產出的結果是一張檢查表,如表1-1所示。表1-1軟件需求規(guī)格說明書檢查列表1.6軟件測試的一般流1.6.1評測測試需求檢查表的設計可以從以下幾個方面考慮。（1）確保需求理解的一致性。（2）驗證需求可測性。（3）檢查需求的完整性和一致性。（4）確保需求追蹤和變更管理。1.6軟件測試的一般流1.6.2制訂測試計劃

測試計劃一般要包括以下內容。(1)確定測試內容(2)制定測試規(guī)則(3)設定測試環(huán)境(6)風險管理(5)計劃實施(4)安排測試任務1.6軟件測試的一般流1.6.3設計測試用例1.目的和作用編寫測試用例主要是為了進行軟件的測試,發(fā)現(xiàn)潛在的問題和缺陷,并評估系統(tǒng)的性能、功能和質量。這是測試過程中重要的一環(huán),對于確保系統(tǒng)的質量和穩(wěn)定性至關重要。1.6軟件測試的一般流1.6.3設計測試用例2.測試用例編寫規(guī)范1)常用字段(1)用例編號。由名稱和數字構成,具有唯一性。(2)用例標題。為測試用例賦予一個有意義的標題,并要簡潔明了。(3)前置條件。指明執(zhí)行測試用例所依賴的前置條件,在執(zhí)行用例之前需要滿足的環(huán)境或數據設置。(4)輸入。指明輸入參數和約束條件。(5)測試步驟。指明測試的具體步驟和操作,以及所需的輸入和預期輸出。(6)預期結果。明確用例執(zhí)行后預期得到的結果或期望的行為。(7)執(zhí)行結果。記錄實際執(zhí)行測試用例后的結果,包括實際輸出和實際行為是否符合預期。(8)是否通過。即測試是否通過的狀態(tài)標記,如“通過”“失敗”“跳過”等,以便于跟蹤和管理用例狀態(tài)。1.6軟件測試的一般流1.6.3設計測試用例2.測試用例編寫規(guī)范1)常用字段一般將測試用例設計成表格形式,如表1-2所示。以上測試用例字段并不是一成不變的,項目團隊可根據項目的實際需求和團隊的實踐經驗進行適當調整和補充。編寫規(guī)范的測試用例有助于跟蹤測試進度和結果。表1-2測試用例示例

1.6軟件測試的一般流1.6.3設計測試用例2.測試用例編寫規(guī)范2)自動化測試如果使用自動化測試工具或平臺,可將數據參數化,即針對需要多次重復執(zhí)行的用例,盡量使用參數化的方式來提高測試的覆蓋度。將測試數據和參數從測試用例中分離,減少用例的重復編寫。例如,要測試用戶登錄功能,可以在測試前準備好測試數據集,如表1-3所示。表1-3測試數據集

1.6軟件測試的一般流1.6.3設計測試用例2.測試用例編寫規(guī)范3)正確性和完整性（2)測試用例要滿足完整性,參照以下做法。首先,完整分析需求,對系統(tǒng)的每個功能點編寫相應的測試用例。確保每個功能都有一個或多個測試用例,覆蓋正常、異常和邊界條件。其次,關注功能的邊界條件,即輸入的上下限或邊界值。(1)測試用例要滿足正確性,參照以下做法。首先,應該基于清晰、詳細的需求規(guī)格來編寫。仔細分析和理解需求,確保所有功能需求和業(yè)務場景都有相應的測試用例覆蓋。其次,按照真實的業(yè)務場景設計測試用例。1.6軟件測試的一般流1.6.3設計測試用例2.測試用例編寫規(guī)范4)可讀性測試用例應具備良好的可讀性和可維護性,使得其他人能夠輕松理解和執(zhí)行這些用例。采用清晰的語言描述和良好的結構化,避免冗余和重復。5)持續(xù)更新隨著項目的進行和需求的演化,測試用例需要持續(xù)更新和維護,保持與實際系統(tǒng)的一致性。1.6軟件測試的一般流1.6.3設計測試用例3.測試用例的管理測試用例的管理是測試過程中非常重要的一環(huán),它可以幫助團隊有效組織、跟蹤和執(zhí)行測試工作。?？梢允褂肊xcel電子表格管理測試用例,在前面已經舉例說明。這類非專業(yè)的測試用例管理軟件存在一些優(yōu)點和缺點優(yōu)點是簡單易用,可批量操作數據。缺點為:基于文件形式存儲,分布零散;無法有效統(tǒng)一用例規(guī)范;版本管理混亂,可追溯性差;缺少對團隊協(xié)作支持。1.6軟件測試的一般流1.6.3設計測試用例3.測試用例的管理可以使用專門的測試用例管理工具,如TestRail、TestLink和Zephyr等,方便進行在線操作和版本管理,一些項目管理工具也具有類似功能。測試用例管理工具一般具有以下功能。(1)測試用例管理(2)用例庫和目錄結構(3)用例屬性和標簽(4)版本控制(5)用例批量導入和導出(6)用例執(zhí)行和跟蹤(7)用例評審和審查(8)用例維護和更新(9)用例復用和參數化(10)用例報告和統(tǒng)計1.6軟件測試的一般流1.6.4執(zhí)行測試執(zhí)行測試就是按照測試用例進行測試的過程,這是測試人員最主要的活動階段。在執(zhí)行測試時要根據測試用例的優(yōu)先級進行。執(zhí)行測試過程看似簡單,測試人員只要按照測試用例完成測試工作即可,但實際并非如此。測試用例的數目非常多,測試人員需要完成所有測試用例的執(zhí)行,每一個測試用例都可能會發(fā)現(xiàn)很多缺陷,測試人員要做好測試記錄與跟蹤,衡量缺陷的質量并編寫缺陷報告。當提交后的缺陷被開發(fā)人員修改后,測試人員需要對其進行回歸測試。如果系統(tǒng)對測試用例產生了缺陷免疫,測試人員則需要編寫新的測試用例。1.6軟件測試的一般流1.6.5編寫測試報告

測試報告是對一個測試活動的總結,對項目測試過程進行歸納,對測試數據進行統(tǒng)計,對項目的測試質量進行客觀評價。不同公司的測試報告模板不同,但測試報告的編寫要點都是一樣的,一般都是先對軟件進行簡單介紹,然后說明這份報告是對該產品的測試過程進總結,對測試質量進行評價。一份完整的測試報告必須包含以下幾個要點。(1)引言(2)測試概要(3)測試內容及執(zhí)行情(4)缺陷統(tǒng)計與分析(5)測試結論與建議1.7企業(yè)測試舉例

泉州銀行自成立至今已有二十多年歷史,是本書編寫過程中的合作企業(yè)。銀行軟件系統(tǒng)十分復雜,包含幾十個乃至上百個子系統(tǒng)。每個業(yè)務流程通常需要跨越多個子系統(tǒng)來完成,因此,確保各模塊功能的正確性以及系統(tǒng)整體的穩(wěn)定性顯得至關重要。隨著業(yè)務的不斷擴展和新功能的不斷開發(fā),泉州銀行對軟件測試領域的需求日益增長,同時對軟件測試的嚴格性要求也不斷提升。為了高效推進軟件測試工作,泉州銀行信息技術部下設需求與測試中心,專職負責軟件技術的測試工作。該中心下設系統(tǒng)集成測試組、性能測試組及自動化測試組等。各組的職責分別是:系統(tǒng)集成測試組負責測試需求的深入分析,通過等價類劃分、邊界值分析和判定表等技術測試手段,按照需求對軟件進行全面測試;性能測試組負責系統(tǒng)的性能評估與測試;自動化測試組負責開發(fā)與維護自動化測試腳本,旨在提高測試效率和覆蓋率。通過合理的部門劃分和科學規(guī)范的工作流程,泉州銀行能夠高效地進行系統(tǒng)集成測試、性能測試任務,確保系統(tǒng)穩(wěn)定、安全地運行。1.7企業(yè)測試舉例

圖1-7是在銀行現(xiàn)場拍攝的照片,可見員工統(tǒng)一著裝,十分整齊。圖1-7泉州銀行信息技術部的需求與測試中心工作現(xiàn)場小結本模塊主要介紹了軟件測試的基礎知識,首先介紹了軟件測試的發(fā)展過程;其次介紹了軟件測試的定義和目標;接著介紹了軟件測試的方法和技術,如黑盒白盒測試、常見的軟件測試模型及軟件測試原則;并比較詳細地講解了軟件測試的一般流程和編寫測試用例的規(guī)范做法。讀者在學習完本模塊的知識之后,能對軟件測試有比較直觀的認識,也能為其后續(xù)學習打下基礎。模塊2黑盒測試2.1等價類劃分法2.2邊界值分析法2.3因果圖法與決策表2.4正交實驗設計法2.1

等價類劃分法2.1.1使用等價類劃分法的步驟一個程序可以有多個輸入,等價類劃分法就是將這些輸入數據按照輸入需求進行分類,并將它們劃分為若干個子集,這些子集即為等價類,在每個等價類中選擇有代表性的數據設計測試用例。例如,將實數的平方根運算函數設計為y=sqrt(x),假設x的約束為(0≤x≤10),這樣x就可以分為3個等價類,包括x<0、0≤x≤10、x>10。2.1

等價類劃分法2.1.1使用等價類劃分法的步驟使用等價類劃分法測試程序需要經過劃分等價類和設計測試用例兩個步驟,具體介紹如下。1.劃分等價類軟件不可能只接收有效、合理的數據,還可能面臨意外情況,如用戶可能輸入無效和不合理的數據。軟件只有經受了這樣的考驗,才能說明它可靠。因此,等價類要區(qū)分有效等價類與無效等價類兩種情況。有效等價類是針對軟件規(guī)格說明而言的,是符合程序要求、合理且有意義的輸入數據。無效等價類是針對軟件規(guī)格說明而言的,是不符合程序要求、不合理或無意義的輸入數據。2.1

等價類劃分法2.1.1使用等價類劃分法的步驟1.劃分等價類如何確定等價類是等價類劃分法的重要問題,一般在劃分等價類時需要遵守以下原則。若規(guī)格說明要求輸入值是一個輸入取值范圍或有限數量的值,則可以將輸入數據劃分為一個有效等價類和兩個無效等價類,有效等價類為指定的取值區(qū)間,兩個無效等價類分別為有限區(qū)間兩邊的值。例如,某程序要求輸入值x的范圍為[1,100],則有效等價類為1≤x≤100,無效等價類為x<1和x>100。（1）按區(qū)間劃分若程序要求輸入值是一個“必須成立”的情況,則可以將輸入數據劃分為一個有效等價類和一個無效等價類。例如,某程序要求密碼包含字母、數字,長度大于8位,則正確的密碼為有效等價類,錯誤的密碼為無效等價類。（2）按限制條件或規(guī)則劃分2.1

等價類劃分法2.1.1使用等價類劃分法的步驟1.劃分等價類若程序要求輸入數據是一組可能的值,或要求輸入值必須符合某個條件,則可以將輸入數據劃分為一個有效等價類和一個無效等價類。例如,某程序要求輸入數據必須是以數字開頭的字符串,則以數字開頭的字符串是有效等價類,不是以數字開頭的字符串是無效等價類。（3）按數值劃分若等價類中每個輸入數據在程序中的處理方式各不相同,則可將該等價類劃分成更小的等價類。（4）細分等價類2.1

等價類劃分法2.1.1使用等價類劃分法的步驟2.設計測試用例根據測試用例的完整性分為四種:弱一般等價類測試、強一般等價類測試、弱健壯等價類測試、強健壯等價類測試。健壯是指要考慮無效值。強是指要考慮組合情況,使用笛卡兒積算出測試用例個數。下面以某城市電話號碼為例來說明:某城市電話號碼由三部分組成。區(qū)號:空白或四位數字;前綴:221~229開頭的3位數或231~239開頭的3位數;后綴:4位數字。根據上述信息劃分等價類,如表2-1所示。表2-1某城市電話號碼劃分等價類2.1

等價類劃分法2.1.1使用等價類劃分法的步驟2.設計測試用例1)弱一般等價類“弱”表示測試用例只需覆蓋3個輸入條件的所有有效等價類,不用考慮它們之間的組合,“一般”表示只考慮有效等價類,因此最少只需要2個測試用例即可滿足弱一般等價類測試的要求。上面例子弱一般等價類的用例為ace、bde,具體測試的數據如表2-2所示。表2-2弱一般等價類測試用例2.1

等價類劃分法2.1.1使用等價類劃分法的步驟2.設計測試用例2)強一般等價類“強”表示測試用例需覆蓋3個輸入條件的所有有效等價類的可能組合,“一般”表示只考慮有效等價類。區(qū)號有2個有效等價類,前綴有2個有效等價類,后綴有1個有效等價類,因此共需要2×2×1=4個測試用例才能滿足強一般等價類的測試要求。因為只有區(qū)號有兩個維度,其他都是一個維度,測試用例數量恰好跟弱一般等價類相同。上面例子弱一般等價類的用例為ace、ade、bce、bde,具體測試的數據如表2-3所示。表2-3強一般等價類測試用例

2.1

等價類劃分法2.1.1使用等價類劃分法的步驟2.設計測試用例3)弱健壯等價類“弱”表示測試用例只需覆蓋3個輸入條件的所有有效等價類,不用考慮它們之間的組合,“健壯”表示不僅要考慮有效類,還需考慮無效類。在弱一般等價類的基礎上,增加輸出為無效值的10種情況。注意在編寫測試用例時,每個用例輸出只覆蓋一個無效值,其余是有效值,具體測試的數據如表2-4所示表2-4弱健壯等價類測試用例

2.1

等價類劃分法2.1.1使用等價類劃分法的步驟2.設計測試用例4)強健壯等價類“強”表示測試用例需覆蓋3個輸入條件的所有有效等價類的可能組合,“健壯”表示不僅考慮有效類,還需考慮無效類。參考表2-1,其中區(qū)號有2個有效等價類、3個無效等價類;前綴有2個有效等價類、4個無效等價類;后綴有1個有效等價類、3個無效等價類,因此共需要(2+3)×(2+4)×(1+3)=5×6×4=120個測試用例才能滿足強一般等價類的測試要求。上述例子介紹了如何使用等價類劃分法設計測試用例,方法重點在于如何劃分有效等價類和無效等價類。等價類粒度劃分的粗細也很重要,粒度越粗,設計測試用例越少;粒度越細,設計測試用例越多。一般來說,粒度越細能發(fā)現(xiàn)更多問題,但是帶來了更多的測試用例。2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

三角形問題是測試中廣泛使用的一個經典案例,下面按照以下幾個步驟使用弱健壯等價類方法來設計測試用例。(1)按照輸入條件建立有效等價類和無效等價類,列出所有劃分出的等價類。(2)為每一個等價類設置一個唯一的編號。(3)設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋的有效等價類,重復這一步驟,直到所有的有效等價類都被覆蓋為止。(4)設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步驟,直到所有的無效等價類都被覆蓋為止。2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

1.劃分等價類它要求輸入a、b、c這3個正數作為三角形的三條邊,要判斷三角形的性質。三條邊長對應的3個數決定了三角形是一般三角形、等邊三角形、等腰三角形,還是無法構成三角形。如果使用等價類劃分法設計三角形程序的測試用例,首先需要將所有輸入數據劃分為不同的等價類。對該案例進行分析,程序要求輸入3個數且是正數,在輸入3個正數的基礎上判斷這3個數能否構成三角形,如果能構成三角形,那么再判斷它構成的是一般三角形、等腰三角形還是等邊三角形,如此可以按照下列步驟將輸入情況劃分為不同的等價類。2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

1.劃分等價類（1)判斷三個數是否是正數,可以將輸入情況劃分為1個有效等價類和3個無效等價類,下列表述中表達式中的||表示用例是并列關系,&&表示用例是同一用例關系。3個數都是正數,a>0&&b>0&&c>0。①有效等價類任意一個數小于等于0,a≤0||b≤0||c≤0。②無效等價類2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

1.劃分等價類（2)在輸入3個正數的基礎上,判斷3個數能否構成三角形,可以將輸入情況劃分為3個有效等價類和3個無效等價類,具體如下。任意兩個數之和大于第三個數,a+b>c||a+c>b||b+c>a。①有效等價類任意兩個數之和小于等于第三個數,a+b≤c||b+c≤a||c+a≤b。②無效等價類2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

1.劃分等價類(3)在3個數構成三角形的基礎上,判斷這3個數能否構成等腰三角形,可以將輸入情況劃分成3個有效等價類和1個無效等價類。其中有2個數相等,a=b||a=c||b=c。①有效等價類3個數均不相等,a!=b&&b!=c&&c!=a。②無效等價類2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

1.劃分等價類(4)判斷這3個數能否構成等邊三角形,有1個有效等價類和3個無效等價類,具體如下。3個數相等,a=b&&b=c&&a=c。①有效等價類3個數不相等,a!=b||b!=c||c!=a。②無效等價類2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

2.設置等價類編號上述分析一共將三角形輸入劃分成了18個等價類,給這些等價類確定編號并建立等價類表,如表2-5所示。表2-5三角形輸入等價類表2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

3.設計新用例不斷設計新的測試用例,使其盡可能多地覆蓋尚未被覆蓋的有效等價類,直到所有的有效等價類都被測試用例覆蓋為止。接下來設計測試用例,設計測試用例的原則是:用盡可能少的測試用例覆蓋盡可能多的等價類。既要考慮輸入情況的全面性,又要考慮對有效等價類的覆蓋情況。在設計新的有效等價類的測試數據時,增加等價類的覆蓋范圍,包括更多的有效等價類的編號,在這個例子中因為有效等價類存在遞進關系,所以使得測試數據變得更加特殊化。根據表2-1中的有效等價類設計測試用例,如表2-6所示。表2-6設計了6組測試用例覆蓋了全部有效等價類。表2-6覆蓋有效等價類的測試用例

2.1

等價類劃分法2.1.2實例:三角形問題的等價類劃分

4.覆蓋所有無效等價類不斷設計新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,直到所有無效等價類都被覆蓋為止。無效等價類測試用例的設計原則與有效等價類測試用例的設計原則相同,無效等價類的測試用例如表2-7所示。表2-7無效等價類的測試用例2.1

等價類劃分法2.1.3實例:銀行轉賬的等價類劃分銀行轉賬是人們經常進行的操作,現(xiàn)在可以通過個人計算機或手機App進行操作。但是每天轉賬金額有上限,即轉賬額度。假設某銀行已經開發(fā)了一款軟件實現(xiàn)用戶自助轉賬功能,要求轉賬筆數不限,但是每天轉賬上限為5萬元整。如果是當天的第1筆轉賬,那么只需考慮轉賬上限5萬元和賬戶余額;如果是第n筆轉賬,還需增加限制,即轉賬總額不能超過5萬元。因此,需要分別設計兩個情況的等價類。（1)第1筆轉賬,可將轉賬功能劃分為1個有效等價類和2個無效等價類,具體如下。①有效等價類:0<提現(xiàn)金額≤Min(50000,余額)。②無效等價類:提現(xiàn)金額≤0。③無效等價類:提現(xiàn)金額>Min(50000,余額)2.1

等價類劃分法2.1.3實例:銀行轉賬的等價類劃分(2)第n筆轉賬,可以將提現(xiàn)功能劃分為1個有效等價類和2個無效等價類,具體如下。①有效等價類:0<提現(xiàn)金額≤Min[(50000-已轉賬金額),余額]。②無效等價類:提現(xiàn)金額≤0。③無效等價類:提現(xiàn)金額>Min[(50000-已轉賬金額),余額]。根據上述分析,銀行轉賬功能一共可以劃分為6個等價類,如表2-8所示。表2-8銀行轉賬的等價類表

2.1

等價類劃分法2.1.3實例:銀行轉賬的等價類劃分建立了等價類表,接下來設計測試用例進行測試,假如現(xiàn)在銀行賬戶中有60000元余額,則覆蓋有效等價類的測試用例與覆蓋無效等價類的測試用例如表2-9和表2-10所示。表2-9和表2-10共設計了6個測試用例,這些測試用例覆蓋了全部等價類,基本可以檢測出轉賬功能所存在的缺陷。表2-9覆蓋有效等價類的測試用例

表2-10覆蓋無效等價類的測試用例2.2邊界值分析法邊界值分析法是對軟件的輸入或輸出邊界進行測試的一種方法,它通常作為等價類劃分法的一種補充,其理論基礎是假定大多數的錯誤是發(fā)生在各種輸入條件的邊界上的,如果邊界附近的取值不會導致程序出錯,那么其他取值導致程序出錯的可能性很小。邊界值分析法是在等價類的邊界上執(zhí)行軟件測試工作的,測試用例都是設計在等價類的邊界上。在等價類中選擇邊界值時,如果輸入條件規(guī)定了取值范圍或值的個數,則要對邊界值及其兩邊的數分別進行測試。例如,輸入姓名(1~20個字符),要求測試0、1、2個字符和19、20、21個字符;某商品信息查詢系統(tǒng),每頁最多顯示10條商品信息,就應該準備足夠的商品信息,使能夠查詢出9、10、11、1、0條商品記錄。邊界值和等價類的區(qū)別在于,邊界值分析不是從某等價類中隨便找一個作為代表,而是這個等價類的每個邊界都要作為測試條件。2.2.1邊界值分析法概述2.2邊界值分析法如果軟件要求輸入或輸出是一組有序集合,如數組、鏈表等,則可選取第一個和最后一個元素作為測試數據。如果被測試程序中有循環(huán),則可選取第0次、第1次與最后兩次循環(huán)作為測試數據。常見的邊界值如下。(1)文本框接收字符個數,如用戶名長度、密碼長度等。(2)報表的第1行和最后1行。(3)數值元素的第1個和最后1個。(4)循環(huán)的第1次、第2次和倒數第1次、倒數第2次。邊界值分析法只在邊界取值上考慮測試的有效性,相對于等價類劃分法來說,它執(zhí)行起來更加簡單易行,但缺乏充分性,不能整體、全面地測試軟件,因此它只能作為等價類劃分法的補充測試。2.2.1邊界值分析法概述2.2邊界值分析法在2.1.2節(jié)中,我們學習了三角形問題的等價類劃分,在等價類劃分中,除了要求輸入數據為3個正數外,沒有給出其他限制條件,如果要求三角形邊長取值范圍為1~10,則可以使用邊界值分析法對三角形邊界邊長進行測試,在設計測試用例時,分別選擇1、2、5、9、10作為測試數據,其中,選擇5作為取值范圍內的任意一點,三角形問題邊界值分析測試用例如表2-11所示。2.2.2實例:三角形問題的邊界值分析表2-11三角形問題邊界值分析測試用例

2.2邊界值分析法2.2.3實例:銀行轉賬的邊界值分析

在2.1.3節(jié)中,我們學習了銀行轉賬案例的等價類劃分,每天銀行轉賬筆數不限,轉賬上限為5萬元。分別設計兩種情況的等價類:如果是當天的第1筆轉賬,金額數介于0和Min(50000,余額)之間;如果是第n筆轉賬,金額數介于0和Min[(50000-已轉賬金額),余額]之間。假設銀行賬號中的余額為4萬元,在進行邊界值分析時,如果是第一次轉賬,邊界值為0和Min(50000,40000),即0和40000,則分別對0和40000兩個邊界值進行測試,分別取-1、0、1、20000、39999、40000、40001七個值作為測試數據;如果是第n次轉賬,已經轉出10000元,賬號余額為30000元,邊

界

值

為0和Min(50000-10000,30000),即0和30000,則分別對0和30000兩個邊界值進行測試,分別取-1、0、1、20000、29999、30000、30001七個值作為測試數據;如果銀行賬號的余額大于5萬元,就按上述方法設計測試用例。2.2邊界值分析法2.2.3實例:銀行轉賬的邊界值分析

根據上述分析,設計銀行轉賬邊界值分析測試用例,如表2-12所示。由表2-12可知,一共設計了21個測試用例來測試銀行轉賬金額的邊界值,這些測試用例基本覆蓋了全部邊界值,具備檢測邊界可能存在的缺陷的能力。表2-12銀行轉賬邊界值分析測試用例2.3因果圖法與決策表2.3.1因果圖法1.因果圖因為輸入、輸出之間的邏輯關系有時比較復雜,所以習慣用圖示的方式及因果圖來表達。通常,因果圖中使用了一些簡單的邏輯符號和直線將因(輸入)和果(輸出)連接起來,一般用ci

表示因,用ei表示果。各節(jié)點可以取“0”或“1”,其中“0”表示狀態(tài)不出現(xiàn),“1”表示狀態(tài)出現(xiàn)。ci

與ei之間有恒等、非(~)、或(∨)、與(∧)4種關系,如圖2-1所示。圖2-1因果圖2.3因果圖法與決策表2.3.1因果圖法1.因果圖圖2-1中展示了因果圖的4種關系,每種關系的具體含義如下。（1）（2）（3）（4）恒等非(~)或(∨）與(∧)若原因出現(xiàn),則結果出現(xiàn);若原因不出現(xiàn),則結果也不出現(xiàn)。若原因出現(xiàn),則結果不出現(xiàn);若原因不出現(xiàn),則結果出現(xiàn)。若幾個原因中有一個出現(xiàn),則結果出現(xiàn);若幾個原因都不出現(xiàn),則結果不出現(xiàn)。只有幾個原因都出現(xiàn),結果才出現(xiàn);若其中有一個原因不出現(xiàn),則結果不出現(xiàn)。2.3因果圖法與決策表2.3.1因果圖法1.因果圖為了表示原因與原因之間,結果與結果之間可能存在的約束條件,在因果圖中可以附加一些表示約束條件的符號。某一軟件用于統(tǒng)計體檢信息,在輸入個人信息時,性別只能輸入男或女,這兩種輸入不能同時存在,而且如果輸入性別為女,那么體檢項就會受到限制。這些依賴關系在軟件要求測試中被稱為“約束”,從輸入(原因)考慮,有4種約束,包括互斥(exclusiveor,E)、包含(in,I)、唯一(only,O)、要求(request,R);從輸出(結果)考慮,還有一種約束屏蔽(mask,M)。約束的類別可分為4種,在因果圖中,用特定的符號表明這些約束關系,如圖2-2所示。圖2-2多個輸入之間的約束符號

2.3因果圖法與決策表2.3.1因果圖法1.因果圖圖2-2展示了多個輸入之間的約束符號,這些約束關系的含義如下。（2）a、b和c中至少有一個必須是1,即a、b、c不能同時為0。E(互斥,異)（1）a和b中最多只能有一個為1,即a和b不能同時為1。I(包含,或）（3）a和b中有且僅有一個為1。O(唯一)（4）a和b必須保持一致,即a為1時,b也必須為1,a為0時,b也必須為0。R(要求)2.3因果圖法與決策表2.3.1因果圖法1.因果圖上面這4種都是關于輸入條件的約束,除了輸入條件,輸出條件也會相互約束,輸出條件的約束只有一種M(mask,屏蔽),在因果圖中,使用特定的符號表示輸出條件之間的屏蔽約束關系,如圖2-3所示。圖2-3輸出條件之間的屏蔽約束關系

2.3因果圖法與決策表2.3.1因果圖法2.使用因果圖法設計測試用例的步驟使用因果圖法設計測試用例需要經過以下幾個步驟。（1)分析程序規(guī)格說明書所描述的內容,哪些是原因(輸入條件或輸入條件的等價類),哪些是結果(輸出條件),并給每個原因和結果賦予一個標識符。（2)分析軟件規(guī)格說明描述中的語義,找出原因與結果之間,原因與原因之間的對應關系,并根據這些關系畫出因果圖。（3)由于語法與環(huán)境的限制,有些輸入與輸入之間、輸入與輸出之間的組合情況是不可能出現(xiàn)的,為表明這些特殊情況,在因果圖上用一些記號標明約束或限制條件（4)將因果圖轉換為決策表。決策表將在2.3.2小節(jié)中講述。(5)把決策表的每一列拿出來作為依據,根據決策表設計測試用例。2.3因果圖法與決策表2.3.2決策表決策表也稱為判定表,其實質就是一種邏輯表。在程序設計發(fā)展初期,決策表就已經被當作程序開發(fā)的輔助工具來幫助開發(fā)人員整理開發(fā)模式和流程,因為它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確,利用決策表可以設計出用例集合。為了讓讀者理解前面所述的因果圖和決策表的聯(lián)系,下面通過一個常見的自動售貨機的例子來說明。其規(guī)格說明如下:自動售貨機可以接收1元、5元、10元等類型的紙幣,投入金額不限。售貨機內現(xiàn)有可樂和橙汁兩種商品,價格均為3元,投入錢幣之后按下“可樂”或“橙汁”按鈕。若顧客投入的金額不足,則一個顯示“金額不足”的紅燈亮;若金額足夠,則相應的飲料就送出來。同時更新投入售貨機內金額的余額,顧客可繼續(xù)選購,直到按下“結束購買”按鈕。2.3因果圖法與決策表2.3.2決策表根據上述規(guī)格說明分析出原因和結果及中間過程(節(jié)點)。原因如下。(1)未投幣。(2)金額≥3元。(3)金額<3元。(4)按下“可樂”按鈕。(5)按下“橙汁”按鈕。(6)結束購買。結果如下。(1)“金額不足”燈亮。(2)送橙汁。(3)送可樂。(4)更新余額。(5)退錢。2.3因果圖法與決策表2.3.2決策表分析出原因和結果后,接下來畫出其因果圖,如圖2-4所示,其中設計2個中間狀態(tài)節(jié)點。(1)按下“橙汁”或“可樂”按鈕。(2)余額大于等于0。圖2-4自動售貨機因果圖

2.3因果圖法與決策表2.3.2決策表由于2與3,4與5不能同時發(fā)生,分別加上約束條件E。22與24、23與24為恒等關系,21與22,21與23為M約束關系,即若21為1,則22和23必為0,詳細情況就不一一列舉了,請讀者查看圖2-4。因果圖法是一種非常有效的黑盒測試方法,它能夠生成沒有重復性的且發(fā)現(xiàn)錯誤能力強的測試用例,而且對輸入、輸出同時進行了分析。接下來將因果圖轉換為決策表,如表2-13所示。表2-13自動售貨機決策表2.3因果圖法與決策表2.3.2決策表在表2-13中,結果中的24行表示自動更新余額,與22和23列存在約束關系。陰影部分表示因違反約束條件而不可能出現(xiàn)的情況(刪去)。第33列是條件6成立就表示結束,自動售貨機退錢,其他條件下售貨機不會退錢。最后可根據剩下的9列作為確定測試用例的依據。刪除不成立的列之后,得到表2-14。表2-14刪除不成立的列之后的決策表2.3因果圖法與決策表2.3.2決策表再通過觀察發(fā)現(xiàn),只要未投幣或余額少于3元,都是只輸出21項(即余額不足),這樣可以把第6、7、10、11列歸為1列,將26、27歸為1列,化簡之后剩下5列。把序號和中間結果刪除后,只剩下條件和結果,如表2-15所示。表2-15化簡后的決策表因果圖和決策表都可以反映復雜的輸入/輸出關系,兩者各有特點,因果圖以圖例的形式直觀地反映出輸入之間及輸入與輸出之間的邏輯關系。相比于因果圖,決策表能夠把復雜的問題按各種可能的情況一一列舉并形成表格,簡明且易于理解,也能避免遺漏,因此,對于多邏輯條件下執(zhí)行不同操作的情況,決策表使用得更多。2.3因果圖法與決策表2.3.3實例:三角形問題決策表在測試用例中,三角形問題是一個經典案例,這里繼續(xù)使用三角形講解決策表的構建與測試用例的設計。三角形的三條邊能否構成三角形?如果能,那么是構成一般三角形、等腰三角形還是等邊三角形?據此分析,三角形問題有4個原因———是否構成三角形,a=b?,b=c?,c=a?;有5個結果———非三角形、不規(guī)則三角形、等腰三角形、等邊三角形、不符合邏輯,據此寫出初步決策表,如表2-16所示。表2-16三角形問題初步決策表

2.3因果圖法與決策表2.3.3實例:三角形問題決策表接下來進行化簡,在表2-16中的規(guī)則9~16列中,只要c1

為N,c2、c3、c4

取任何值結果都是e1,因此,c2、c3、c4

是無關項,可以將規(guī)則9~16列合并成一條規(guī)則。規(guī)則2、3、5列的用例不符合邏輯,無法構建,因此將其刪除。這樣化簡后的結果剩下6種情況:1個等邊三角形,3個等腰三角形,1個不規(guī)則三角形和1個無法構成三角形。這樣就構成了6個測試用例,整理后的決策表如表2-17所示。表2-17整理后的決策表2.3因果圖法與決策表2.3.3實例:三角形問題決策表根據表2-17寫出6個測試用例,如表2-18所示。表2-18測試用例2.4正交實驗設計法2.4.1正交實驗設計法概述正交實驗設計(orthogonalexperimentdesign)法是一種研究多因素多水平的設計方法,它是根據正交性從全面實驗中挑選出部分有代表性的點進行實驗,這些有代表性的點具備了“均勻分散,齊整可比”的特點,正交實驗設計法是一種高效率、快速、經濟的實驗設計方法。日本著名的統(tǒng)計學家田口玄一將正交實驗選擇的水平組合列成表格,稱為正交表。當軟件測試用例數量太多時,一個非常自然的想法就是從中選擇一部分有代表性的影響因素的組合進行實驗。但是對于實驗設計知識較少的實際工作者來說,如何有效地選擇影響因素還是比較困難的。2.4正交實驗設計法2.4.1正交實驗設計法概述正交實驗設計法包含3個關鍵因素,具體如下。指標因子因子的狀態(tài)指標是判斷實驗結果優(yōu)劣的標準。因子也稱為因素,是指所有影響實驗指標的條件。因子的狀態(tài)也稱為因子的水平,它指的是因子變量的取值。2.4正交實驗設計法2.4.1正交實驗設計法概述利用正交實驗設計法設計測試用例時,可以按照以下步驟進行。（1)提取因子,構造因子狀態(tài)表。分析軟件的規(guī)格需求說明,得到影響軟件功能的因子,確定因子可以有哪些取值,即確定因子的狀態(tài)。例如,某高校學生成績查詢軟件,設置完系、課程后,要通過“性別”“班級”“成績”這3個查詢條件對某門課程的成績分布、男女比例或班級比例進行人員查詢。性別分為“男”“女”,班級分為“1班”“2班”,成績分為“及格”“不及格”。3個查詢條件稱為被測因素,每個因素有兩個取值,稱為水平值,所以全部測試用例的個數是2×2×2=8。據此構造該軟件運行功能的因子-狀態(tài)表,如表2-19所示。表2-19因子-狀態(tài)表2.4正交實驗設計法2.4.1正交實驗設計法概述(2)加權篩選,簡化因子-狀態(tài)表。在實際的軟件測試中,軟件的因子及因子的狀態(tài)會有很多,每個因子及其狀態(tài)對軟件的作用也大不相同,如果把這些因子及狀態(tài)都劃分到因子-狀態(tài)表中,那么最后生成的測試用例會相當大,從而會影響軟件測試的效率。因此,需要根據因子及狀態(tài)的重要程度進行加權篩選,選出重要的因子與狀態(tài),以簡化因子-狀態(tài)表。加權篩選就是根據因子或狀態(tài)的重要程度、出現(xiàn)頻率等因素計算因子和狀態(tài)的權值,權值越大,表明因子或狀態(tài)越重要,而權值越小,表明因子或狀態(tài)的重要性越小。加權篩選之后,可以去掉一部分權值較小的因子或狀態(tài),使得最后生成的測試用例集縮減到允許的范圍。2.4正交實驗設計法2.4.1正交實驗設計法概述(3)構建正交表,設計測試用例。正交表的表示形式為L行數(水平數因子數)例如,L4(23)是最簡單的正交表,它表示該實驗有3個因子,每個因子有兩個狀態(tài),也稱為水平,可以做4次實驗,如果用0和1表示每個因子的兩種狀態(tài),則該正交表就是一個4行3列的表,如表2-20所示。表2-20L4(23)正交表

2.4正交實驗設計法2.4.1正交實驗設計法概述(3)構建正交表,設計測試用例。上述成績查詢的例子中3個因子為性別、班級和成績,用戶名、密碼和驗證碼都有兩種狀態(tài),正常需要設計23=8個測試用例,而使用正交表只需要設計4個測試用例就可以達到同樣的測試效果,因此,正交實驗法是一種高效、快速、經濟的實驗設計方法。在表2-21中,3個因子的狀態(tài)都為2,這樣的正交實驗比較容易設計成正交表,但在實際的軟件測試中,大多數情況下軟件有多個因子,每個因子的狀態(tài)數目不一定相同,即各列的水平數不等,這樣的正交表稱為混合正交表,如L8(24

×41),這個正交表表示有4個因子有2種狀態(tài),有1個因子有4種狀態(tài)。混合正交表可以通過以下方式確定測試用例的數目。2.4正交實驗設計法2.4.1正交實驗設計法概述(3)構建正交表,設計測試用例。①通過以下網址確定。/techsup/technote/ts723_Designs.txt。https://www.york.ac.uk/depts/maths/tables/orthogonal.htm。②參考其他數理統(tǒng)計方面的書籍。舉例說明,打開/techsup/technote/ts723_Designs.txt,可以查詢到不同因子數、不同水平數的正交表的值。查詢24

×41

的正交表對應的n=8,結果如下。2.4正交實驗設計法2.4.1正交實驗設計法概述(3)構建正交表,設計測試用例。換成L8(24

×41)正交表,如表2-21所示。表2-21L8(24

×41)正交表

2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計假設某打印軟件的功能設置有以下4個。(1)打印范圍:分全部、當前幻燈片、給定范圍3種情況。(2)打印方式:有單面、雙面(翻轉長邊)、雙面(翻轉短邊)、手動雙面4種情況。(3)打印顏色:有顏色、灰度、黑白3種設置。(4)打印方向:有橫向、縱向兩種情況。2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計將其功能設置寫成因素狀態(tài)表,如表2-22所示。將文字描述轉為字母符號,得到符號因素狀態(tài)表,如表2-23所示。表2-22

因素狀態(tài)表表2-23符號因素狀態(tài)表2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計分析表2-23,發(fā)現(xiàn)打印軟件一共有4個被測參數,每個被測參數不完全一樣,A和C有3個,B有4個,D有2個。結合分析結果選擇正交表的依據如下。（1）正交表的因素≥4。（2）正交表至少有4個因素的水平數≥2。（3）行數取最小值。查表得到L16(45),如下所示。2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計用字母符號替換該表中的狀態(tài),得到新的正交表,如表2-24所示。表2-24正交表

2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計通過觀察發(fā)現(xiàn),4個因素只有一個的水平值是4,其他都小于等于3,所以設計用例行數為4×3=12,忽略第13~16行的測試用例。第5列不含測試因素,因此將其刪除,最后把表中剩余的數字按狀態(tài)均勻分布的原則填滿。根據上述分析,整理后得到新的正交表如表2-25所示。表2-25新的正交表

2.4正交實驗設計法2.4.2實例:打印功能正交實驗設計根據表2-25寫出12個測試用例,下面舉例說明,如表2-26所示。表2-26測試用例1小結本模塊主要講解了黑盒測試常用的技術方法,包括等價類劃分法、邊界值分析法、因果圖與決策表、正交實驗設計法。讀者要掌握每種測試方法的原理和測試用例的設計方法,這對后續(xù)學習實際的軟件項目測試很有幫助。模塊3白盒測試3.1用例設計3.2JUnit單元測試3.3使用PlantUML繪制流程圖3.1用例設計白盒測試法大致分為靜態(tài)分析方法和動態(tài)分析方法兩大類。靜態(tài)分析是一種不執(zhí)行程序而進行測試的技術,主要目的是檢查軟件的表示和描述是否一致。動態(tài)分析是當軟件系統(tǒng)在模擬或真實的環(huán)境中執(zhí)行前、執(zhí)行過程中和執(zhí)行后,對其進行行為分析,它顯示了一個系統(tǒng)在檢查狀態(tài)下是否正確。在動態(tài)分析技術中,最重要的技術是邏輯和路徑測試。3.1用例設計下面分別按邏輯覆蓋方法和路徑測試方法介紹語句覆蓋、判斷覆蓋、條件覆蓋、判斷條件覆蓋、條件組合覆蓋和路徑測試覆蓋方法。按覆蓋程度的大小進行排列的順序是:路徑測試覆蓋>條件組合覆蓋>判定條件覆蓋>條件覆蓋>判斷覆蓋>語句覆蓋。下文表達式和圖中所涉及的符號說明如下。（1)T表示True,F表示False。（2)A和B分別表示關系表達式。（3)A||B表示A和B表達式之間是或的關系。3.1用例設計1.語句覆蓋語句覆蓋是使程序中每一條語句最少執(zhí)行一次,但其覆蓋標準無法發(fā)現(xiàn)判定中邏輯運算的錯誤。測試用例條件:A||B=T。假設存在如下程序邏輯,寫出偽代碼。IF(A||B)THEN執(zhí)行P2路徑代碼;ELSE執(zhí)行P3路徑代碼;ENDIF將偽代碼轉換成流程圖,如圖3-1所示。圖3-1語句覆蓋流程圖3.1.1邏輯覆蓋法3.1用例設計1.語句覆蓋假設A=a>1&&b==0,B=a==2||x>1,則得出表3-1所示的語句覆蓋分析表。表3-1語句覆蓋分析表語句覆蓋不用考慮語句之間存在的邏輯關系,因此不能發(fā)現(xiàn)其中存在的邏輯缺陷,舉例來說,如果上述表格中的用例判定把a==2||x>1錯寫成a==2&&x>1,那么按表格的a、b、x的輸入值,判定結果沒有改變,無法發(fā)現(xiàn)判定式的錯誤。3.1.1邏輯覆蓋法3.1