軟件測試技術(shù)（第三版） 課件全套 （范勇） 第1-7章 軟件測試基礎 - 系統(tǒng)測試

1.1軟件質(zhì)量第1章

軟件測試基礎無形性，通過運行體現(xiàn)其存在性可復制需求不確定性、多變性難以度量無老化問題維護復雜軟件特點軟件質(zhì)量定義ANSI/IEEE729-1983：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性：

(1)軟件產(chǎn)品質(zhì)量滿足用戶要求的程度；

(2)軟件各種屬性的組合程度；

(3)用戶對軟件產(chǎn)品的綜合反映程度；

(4)軟件在使用過程中滿足用戶要求的程度。軟件質(zhì)量ISO14598-1999定義：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力ISO9126-2001定義：軟件滿足用戶規(guī)定或潛在用戶需求的能力，要從軟件在內(nèi)部，外部和使用過程中的表現(xiàn)來衡量，包含內(nèi)部質(zhì)量、外部質(zhì)量、和使用質(zhì)量。SEI的WattsHumphrey：軟件質(zhì)量是“在實用性、需求、可靠性和可維護性一致上，達到優(yōu)秀的水準”QAI的BillPerry：用戶滿意度的高水準，忠實于用戶需求貝爾實驗室的JohnMusa：低缺陷率、軟件功能忠實于用戶需求、高可靠性的組合軟件質(zhì)量軟件質(zhì)量內(nèi)容軟件產(chǎn)品質(zhì)量：滿足使用要求的程度。產(chǎn)品的屬性和行為，是可以認識、科學地描述的。并且可以通過一些方法和人類活動，來改進質(zhì)量。功能性、可靠性、易使用性、效率等軟件過程質(zhì)量:能否滿足開發(fā)所帶來的成本、時間和風險等要求。軟件能力成熟度模型CMM、國際標準過程模型ISO9000、軟件過程改進和能力決斷SPICE可維護性、兼容性、效率、可移植性、可擴展性等軟件商業(yè)環(huán)境質(zhì)量培訓、成品制作、宣傳、發(fā)布日起、客戶、風險、成本、業(yè)務等可維護性、可移植性、可擴展性、安全性等軟件質(zhì)量廣義的軟件質(zhì)量觀軟件質(zhì)量模型ISO-IEC25010軟件質(zhì)量模型軟件質(zhì)量模型ISO-IEC25010內(nèi)部質(zhì)量和外部質(zhì)量軟件質(zhì)量模型軟件質(zhì)量模型ISO-IEC25010使用質(zhì)量軟件質(zhì)量模型軟件質(zhì)量屬性功能性：特定條件下，構(gòu)件提供的功能滿足規(guī)定或隱含需求功能的程度可靠性：在規(guī)定的條件下，在規(guī)定的時間內(nèi)完成規(guī)定功能/性能的能力易用性：指定使用條件下，被理解、學習、使用和吸引用戶的能力效率性：在規(guī)定的條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當性能的能力可維護性：在規(guī)定條件下，規(guī)定的時間內(nèi)，使用規(guī)定的工具或方法修復規(guī)定功能的能力可移植性：從一種環(huán)境遷移到另一種環(huán)境的能力安全性：在規(guī)定條件下，在規(guī)定權(quán)限下訪問數(shù)據(jù)、保護數(shù)據(jù)的能力兼容性：在共享軟硬件資源的環(huán)境下，與其它構(gòu)件交換信息或執(zhí)行其特定功能的能力程度軟件質(zhì)量模型任正非2019年1月《全面提升軟件工程能力與實踐，打造可信的高質(zhì)量產(chǎn)品》可信安全性（Security）。產(chǎn)品有良好的抗攻擊能力，保護業(yè)務和數(shù)據(jù)的機密性、完整性和可用性。韌性（Resilience）。系統(tǒng)受攻擊時保持有定義的運行狀態(tài)，包括降級，以及遭遇攻擊時快速恢復的能力。隱私性（Privacy）。遵從隱私保護既是法律法規(guī)的要求，也是價值觀的體現(xiàn)。用戶應該能夠適當?shù)乜刂扑麄兊臄?shù)據(jù)的使用方式。信息的使用政策應該是對用戶透明的。用戶應該根據(jù)自己的需要來控制何時接收以及是否接收信息。用戶的隱私數(shù)據(jù)要有完善的保護能力和機制?？煽啃院涂捎眯裕≧eliability&Availability）。產(chǎn)品能在生命周期內(nèi)長期保障業(yè)務無故障運行，具備快速恢復和自我管理的能力，提供可預期的、一致的服務。/cn/index.php?app=forum&mod=Detail&act=index&id=4134815軟件質(zhì)量重要性2021年11月30日，工業(yè)和信息化部印發(fā)了《“十四五”軟件和信息技術(shù)服務業(yè)發(fā)展規(guī)劃》，明確了軟件作為信息技術(shù)關(guān)鍵載體和產(chǎn)業(yè)融合關(guān)鍵紐帶，。。。并在七大方向上支持軟件高質(zhì)量發(fā)展，并促進軟件測試領(lǐng)域的大發(fā)展。軟件質(zhì)量重要性質(zhì)量保障未來軟件測試是軟件質(zhì)量保證的重要手段1.2軟件缺陷第1章

軟件測試基礎軟件正在定義世界，軟件需求量將越來越大Intel奔騰處理芯片缺陷（1994年）經(jīng)典案例Ariane5型運載火箭昂貴的簡單復制（1996年）1999年9月23日，美國航天局的火星氣候探測者號在即將進入火星軌道時在解體1999年12月3日，美國航天局的火星基地登陸飛船在試圖登陸火星表面時失蹤火星勘測者事故

（1999年）經(jīng)典案例愛國者導彈防御系統(tǒng)缺陷（1991年）經(jīng)典案例北京奧運訂票網(wǎng)站癱瘓（2007年）經(jīng)典案例經(jīng)典案例火車票訂票網(wǎng)站：12306GraceHopper格蕾斯.哈珀：計算機科學家、美國海軍將軍編譯器的發(fā)明者、COBOL語言的開發(fā)負責人創(chuàng)造了最大的bug——Y2K第一個Bug的故事IEEE(1983)729軟件缺陷一個標準的定義：從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。軟件缺陷的定義（1）軟件未達到產(chǎn)品說明書中已經(jīng)標明的功能；（2）軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤；（3）軟件未達到產(chǎn)品說明書中雖未指出但應當達到的目標；（4）軟件功能超出了產(chǎn)品說明書中指明的范圍；（5）軟件測試人員認為軟件難以理解、不易使用，或者最終用戶認為該軟件使用效果不良。軟件缺陷的定義軟件缺陷來源修復缺陷的開銷軟件行業(yè)中修復錯誤的開銷設計與編碼編譯或連接售前集成發(fā)布之后開發(fā)階段修復錯誤的開銷$139$455$977$7136$14102缺陷描述缺陷標識缺陷類型缺陷嚴重程度缺陷產(chǎn)生可能性缺陷優(yōu)先級缺陷狀態(tài)缺陷起源缺陷來源缺陷原因軟件缺陷的屬性缺陷優(yōu)先級級別描述

立即解決(Immediately)缺陷必須被立即解決。正常排隊(NormalQueue)缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。不緊急(NotUrgent)缺陷可以在方便時被糾正。缺陷嚴重級別缺陷嚴重等級描述嚴重缺陷（Critical）不能執(zhí)行正常工作功能或重要功能。或者危及人身安全。較嚴重缺陷（Major）嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正。一般缺陷（AverageServerity）嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法。次要缺陷（Minor）使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。改進型缺陷（Enhancement）其它錯誤缺陷起源起源描述需求（Requirement）在需求階段發(fā)現(xiàn)的缺陷架構(gòu)（Architecture）在架構(gòu)階段發(fā)現(xiàn)的缺陷設計（Design）在設計階段發(fā)現(xiàn)的缺陷代碼（Code）在編碼階段發(fā)現(xiàn)的缺陷測試（Test）在測試階段發(fā)現(xiàn)的缺陷缺陷的生命周期測試人員發(fā)現(xiàn)缺陷，提交新缺陷入庫，缺陷狀態(tài)為New；測試經(jīng)理審閱。確為缺陷，分配給相應的開發(fā)人員，并設置為Open狀態(tài)；若不是缺陷，則拒絕，設置為Declined狀態(tài)。開發(fā)人員對標記為Open狀態(tài)的缺陷進行確認，若不是缺陷，狀態(tài)修改為Declined；如果是缺陷則修復，并置狀態(tài)為Fixed。不能解決的缺陷，留下文字說明并保持Open狀態(tài)。缺陷修復后由測試人員驗證后，確認已修復，可關(guān)閉,狀態(tài)改為Closed。如果仍有問題，狀態(tài)改為Reopen。缺陷狀態(tài)新缺陷(New)：測試中新發(fā)現(xiàn)的缺陷；打開(Open)：被確認并分配給開發(fā)人員處理；修正(Fixed)：開發(fā)人員已經(jīng)完成，等待測試人員驗證；拒絕(Declined)：拒絕修改缺陷；延期(Deferred)：不在當前版本修復，在下一版本修復；關(guān)閉(Closed)：缺陷已被修復；重新打開(Reopen)：缺陷重新出現(xiàn)，需開發(fā)人員重新處理；思考問題、故障、bug、缺陷、錯誤。。。等術(shù)語的差異？缺陷檢測、缺陷修復、缺陷預防，對軟件質(zhì)量的影響分別是怎樣的？第1章

軟件測試基礎1.3軟件測試基本術(shù)語傳統(tǒng)：測試是一種旨在評估一個程序或系統(tǒng)的屬性或能力，確定它是否符合其所需結(jié)果的活動。1983年IEEE：測試是使用人工和自動手段來運行或檢測某個系統(tǒng)的過程，其目的在于檢驗系統(tǒng)是否滿足規(guī)定的需求或弄清預期結(jié)果與實際結(jié)果之間的差別。Myers：測試是為了發(fā)現(xiàn)錯誤而執(zhí)行一個程序或系統(tǒng)的過程。明確地提出軟件測試以檢驗是否滿足需求為目標。明確提出了“尋找錯誤”是測試目的。軟件測試定義從軟件質(zhì)量保證的角度看軟件測試是一種重要的軟件質(zhì)量保證活動測試過程中的活動包括“分析”軟件和“運行”軟件。軟件測試就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試定義測試的目的測試是為了證明程序有錯，而不是證明程序無錯誤；一個好的測試用例在于能夠發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。測試的“成功”與“失敗”就在于:

能否發(fā)現(xiàn)錯誤！軟件測試目的測試用例（testcase）測試用例是為某個特定測試目標而設計的，它是測試操作過程序列、條件、期望結(jié)果及相關(guān)數(shù)據(jù)的一個特定的集合軟件測試用例測試目標（testobjective）：為什么測試？測試對象（testtarget）：回答測什么？測試環(huán)境：測試用例運行時所處的環(huán)境，包括系統(tǒng)的軟硬件配置和設定等要求；軟件測試用例測試前提：測試在滿足什么條件下開始測試？輸入數(shù)據(jù)：運行測試時需要運行哪些測試數(shù)據(jù)？操作步驟：運行測試用例的操作步驟序列預期結(jié)果（testoracle）：按操作步驟序列運行測試用例時，被測件的預期運行結(jié)果。軟件測試用例按測試方法/技術(shù)（method/technology)軟件測試分類測試層次（級別）單元測試(UnitTesting)集成測試(IntegrationTesting)確認測試(ValidationTesting)系統(tǒng)測試(SystemTesting)驗收測試(VerificationTesting)軟件測試分類按測試實施組織劃分開發(fā)方測試用戶測試（β測試）第三方測試軟件測試分類按是否使用工具劃分手工測試自動化測試軟件測試分類按照企業(yè)中實際工作需要，測試主要包含下面的類型:功能測試接口測試健壯性測試強度測試壓力測試性能測試用戶界面測試安全測試可靠性測試安裝/反安裝測試文檔測試恢復測試兼容性測試回歸測試α測試β測試軟件測試分類軟件測試的一般流程思考：為什么需要測試用例？軟件測試和軟件質(zhì)量保證的區(qū)別與聯(lián)系？第1章

軟件測試基礎1.4軟件測試基本原則1.可追溯性所有的測試都應追溯到用戶的需求。系統(tǒng)中最嚴重的錯誤是那些導致程序無法滿足用戶需求的錯誤。

軟件測試的原則2.盡早開展預防性測試在軟件生命周期各階段都可能產(chǎn)生錯誤；缺陷具有放大的特點；缺陷的修改成本隨著階段的推移將急劇上升；軟件測試的原則問題發(fā)現(xiàn)越早，解決問題的代價就越小。3.不可能完全的測試輸入量太大執(zhí)行路徑太多M1D1D2D3D4M2M3M4M5M6M7D5<=20次循環(huán)次數(shù) 01 2………20獨立路徑數(shù) 51+52+53+……+521≈1014每個測試用例 5分鐘共需測試時間 10億年若X、Y為所有可能的整數(shù)，在字長32位機上測試：

X1、Y1Z1

． ． ．

Xn、YnZn

測試次數(shù)：n=232232=2641.841019程序PXYZ輸入輸出軟件測試的原則4.80-20原則測試發(fā)現(xiàn)的錯誤中80%很可能起源于20%的模塊中。應孤立這些疑點模塊重點測試。在所測程序段中，若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多。軟件測試的原則5.設立獨立的測試機構(gòu)或委托第三方測試避免測試自己的程序程序員輕易不會承認自己寫的程序有錯誤；程序員的測試思路有局限性，做測試時很容易受到編程思路的影響；程序員測試不具有典型性。軟件測試的原則6.回歸測試程序修改后必須進行回歸測試，避免引入新的錯誤。軟件測試的原則7.投入/產(chǎn)出原則不充分的測試是不負責任的；過分的測試是一種資源的浪費；在滿足軟件預期的質(zhì)量標準時，確定質(zhì)量的投入/產(chǎn)出比。軟件測試的原則8.缺陷集群性

測試工作的分配比例應該與預期的和后期觀察到的缺陷分布模塊相適應。少數(shù)模塊通常包含大部分在測試版本中發(fā)現(xiàn)的缺陷或失效。

軟件測試的原則9.殺蟲劑悖論

采用同樣的測試用例多次重復進行測試，最后將不再能夠發(fā)現(xiàn)新的缺陷。為了克服這種“殺蟲劑悖論”，測試用例需要進行定期評審和修改，同時需要不斷增加新的不同的測試用例來測試軟件或系統(tǒng)的不同部分，從而發(fā)現(xiàn)潛在的更多的缺陷。

軟件測試的原則10.測試活動依賴于測試背景

針對不同的測試背景，進行不同的的測試活動。比如，對安全關(guān)鍵的軟件進行測試，與對一般的電子商務軟件的測試是不一樣的。軟件測試的原則關(guān)于測試原則應當把“盡早地和不斷地測試”作為軟件開發(fā)者的座右銘程序員應避免檢查自己的程序設計測試用例時，應包括合理的輸入和不合理的輸入，以及各種邊界條件，特殊情況下要制造極端狀態(tài)和意外狀態(tài)充分注意測試中的群集現(xiàn)象對測試錯誤結(jié)果一定要有一個確認過程制定嚴格的測試計劃，排除測試的隨意性注意回歸測試的關(guān)聯(lián)性，往往修改一個錯誤會引起更多錯誤妥善保存一切測試過程文檔，測試重現(xiàn)往往要靠測試文檔軟件測試的原則1.5軟件測試過程與管理第1章

軟件測試基礎測試層次的傳統(tǒng)觀點瀑布模型瀑布模型在20世紀80年代后期PaulRook提出了著名的軟件測試的V模型V模型V模型Evolutif公司提出了W模型的概念，W模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動。W模型X模型測試準備測試執(zhí)行測試流程其他流程測試就緒點H模型敏捷模型敏捷模型敏捷實踐的主要特征聚焦價值：始終做最有價值的事，用最少的投入獲取最大的回報；持續(xù)改進：消除浪費，持續(xù)提高效率和質(zhì)量；以人為本：溝通無障礙，充分激發(fā)和賦能團隊中的人；全面質(zhì)量：全過程、全員、全范圍，預防缺陷。敏捷模型TDD（Test-DrivenDevelopment）敏捷模型DevOps（Development（開發(fā)）和Operations（運維）的組合詞）敏捷模型第3章黑盒測試方法3.1黑盒測試方法概述概述黑盒測試被稱為功能測試或數(shù)據(jù)驅(qū)動測試。在測試時，把被測程序視為一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下進行。輸入輸出黒盒內(nèi)部實現(xiàn)不可見測試用例YX概述黑盒測試主要用于發(fā)現(xiàn)以下情況：①是否有不正確或遺漏了的功能②在接口上，能否正確地接受輸入數(shù)據(jù)，能否產(chǎn)生正確地輸出信息③訪問外部信息是否有錯④性能上是否滿足要求⑤界面是否錯誤，是否不美觀⑥初始化或終止錯誤概述黑盒測試主要優(yōu)勢：比較簡單，不需要了解程序內(nèi)部的代碼及實現(xiàn)；與軟件的內(nèi)部實現(xiàn)無關(guān)；從用戶角度出發(fā)，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟件開發(fā)文檔，所以也能知道軟件實現(xiàn)了文檔中的哪些功能；在做軟件自動化測試時較為方便。概述邊界值分析（Boundary-ValueAnalysis）組合測試（CombinatorialTesting)因果圖（

Cause-EffectGraphing）等價類劃分（EquivalencePartitioning)判定表(DecisionTables)狀態(tài)轉(zhuǎn)換測試（StateTransformTesting）場景測試（Scenario-BasedTesting）隨機測試（RandomTesting）概述3.2邊界值分析第3章黑盒測試方法無數(shù)的測試實踐表明，大量的故障往往發(fā)生在輸入定義域或輸出值域的邊界上，而不是在其內(nèi)部。因此，針對各種邊界情況設計測試用例，通常會取得很好的測試效果。如果輸入條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。邊界條件邊界在哪里？邊界點就是可能到達被測系統(tǒng)內(nèi)部處理機制發(fā)生變化的點需求中有利于識別邊界點的文字：位置、尺寸、數(shù)量、長度、速度、寬度、高度、距離、質(zhì)量、時間。。。邊界條件任何值得測試的范圍的臨界點，可分為:邊界值：在規(guī)格說明書中明確定義;次邊界：隱含在軟件中必須經(jīng)過分析才能獲得;

數(shù)值的邊界值邊界條件術(shù)語范圍或值bit（位）0或1byte（字節(jié)）0～255word（字）0～65,535（單字）或0～4,294,967,295（雙字）K（千）1,024M（兆）1,048,576G（千兆）1,073,741,824Tera1099511627776字符的邊界值邊界條件字符ASCII碼值字符ASCII碼值Null（空）0A65Space（空格）32a97/（斜杠）47Z900（零）48z122:（冒號）58‘（單引號）96@64{（大括號）123特殊邊界值DefaultBlank

ZeroEmptyNullNone邊界條件如果輸入條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試數(shù)據(jù)。如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試數(shù)據(jù)。分析規(guī)格說明，找出其他可能的邊界條件。邊界條件確定方法邊界值分析法利用輸入變量的最小值(min)、略大于最小值(min+)、輸入值域內(nèi)的任意值(nom)、略小于最大值(max-)和最大值(max)來設計測試用例。邊界值分析確定邊界情況，根據(jù)邊界值集合完成迪卡爾積（基于“單缺陷”假設）x2dacx1b●●●●●●●●●{<x1nom,x2min>,<x1nom,x2min+>,<x1nom,x2max->,<x1nom,x2max>,<x1min,x2nom>,<x1min+,x2nom>,<x1max-,x2nom>,<x1max,x2nom>,<x1nom,x2nom>}邊界值分析對于一個n變量的函數(shù)，邊界值分析會產(chǎn)生4n+1個測試用例。x1minx1maxx2minx2maxX1取值：x1min,x1min+,x1nom,x1max-,x1maxX2取值：x2min,x2min+,x2nom,x2max-,x2max除了變量的5個邊界分析取值還要考慮略超過最大值（max+）和略小于最小值（min-）時的情況dacx1b●●●●●●●●●●●●●6n+1個測試用例健壯性測試{<x1nom,x2min->,<x1nom,x2min>,<x1nom,x2min+>,<x1nom,x2max->,<x1nom,x2max>,<x1nom,x2max+>,<x1min-,x2nom>,<x1min,x2nom>,<x1min+,x2nom>,<x1max-,x2nom>,<x1max,x2nom>,<x1max+,x2nom>,<x1nom,x2nom>}X2最壞情況假設拒絕了“單缺陷”假設，它對每一個輸入變量首先進行包含最小值、略高于最小值、正常值、略低于最大值、最大值五個元素集合的測試，然后對這些集合進行笛卡爾積計算，以此來看系統(tǒng)的反應。dacx1b●●●●●●●●●●●●●●●●●●●●●●●●●n變量函數(shù)的最壞情況測試會產(chǎn)生5n個測試用例兩種變量最壞情況測試用例最壞情況測試X2健壯最壞情況測試是最壞情況測試的擴展，這種測試使用健壯性測試的七個元素集合的笛卡兒積,將會產(chǎn)生7n個測試用例。cdabX1X2健壯最壞情況測試邊界值覆蓋率=（執(zhí)行的邊界值的數(shù)量/總的邊界值的數(shù)量）*100%邊界值分析的局限性測試用例不充分不能發(fā)現(xiàn)測試變量之間的依賴關(guān)系不考慮含義和性質(zhì)，沒有利用理解和想象小結(jié)

有一個小程序，能夠求出三個在0到9999間整數(shù)中的最大者，請分別用邊界值分析和健壯性測試方法設計測試用例。練習3.3等價類劃分第3章黑盒測試方法劃分(PartitioningDomains)等價類（EquivalenceClass）指定義在集合A上的關(guān)系，滿足自反的、對稱的和傳遞的等性質(zhì)。設R是定義在集合A上的等價關(guān)系，與A中一個元素a有關(guān)系的所有元素的集合叫做a的等價類。等價類的劃分bi

bj=,

ij,bi,bjBqb1b2b3

b=DbBq每個等價類所揭示的程序錯誤都是等價的。有效等價類是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用它可以檢驗程序是否實現(xiàn)了預期的功能和性能（確認過程）。無效等價類是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。利用它可以檢驗程序?qū)τ跓o效數(shù)據(jù)的處理能力（驗證過程）。等價類的劃分如果輸入條件規(guī)定了取值范圍，或者值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類，例如：數(shù)據(jù)范圍是1~50有效等價類為“>=1&&<=50”兩個無效等價類為“<1”和“>50”如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每一個輸入值分別進行處理，這時要對每一個規(guī)定的輸入值確立一個有效等價類，而對于這組值之外的所有值確立一個無效等價類例：程序輸入x取值于一個固定的枚舉類型{1,3,7,15}，且程序中對這4個數(shù)值分別進行了處理，則有效等價類為x=1、x=3、x=7、x=15，無效等價類為x≠1,3,7,15的值的集合。劃分等價類的方法如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（即遵守規(guī)則的數(shù)據(jù)）和若干無效等價類（從不同角度違反規(guī)則的數(shù)據(jù)），例如：

測試密碼域，要求密碼必須是數(shù)字或字母

有效等價類為“密碼是數(shù)字和字母的組合”（還可以細分）

無效等價類為“密碼包括中文”、“密碼包括其它符號”等如果輸入條件是一個布爾量，則可以確立一個有效等價類和一個無效等價類如果確知已劃分的等價類中的各元素在程序中的處理方式不同（例如字母還要區(qū)分大小寫等），則應進一步劃分成更小的等價類

劃分等價類的方法如圖，假設：

a≦x1≦d，區(qū)間為[a,b),[b,c),[c,d]e≦x2≦g，區(qū)間為[e,f),[f,g]●x2gfedcba●●●●●x1●●●●●●●●●●●●●●等價類測試類型有效等價類無效等價類X1a<=x1<=dx1<a和d<x1X2e<=x2<=gx2<e和g<x2弱一般弱健壯強一般強健壯x2gfex1dcba●●●弱一般等價類測試用例●x2gfedcba●●●●●弱健壯等價類測試用例x1●x2gfedcba●●●●●強一般等價類測試用例●●x2gfedcba●●●●●強健壯等價類測試用例x1●●●●●●●●●●●●●●等價類測試類型步驟a)分析輸入輸出b)劃分出有效等價類和無效等價類，建立等價類表，每一個等價類分別規(guī)定一個唯一的編號c)設計一個新的測試用例，使它能夠盡量覆蓋尚未覆蓋的有效等價類。重復這個步驟，直到所有的有效等價類均被測試用例所覆蓋。d)設計一個新的測試用例，使它僅覆蓋一個尚未覆蓋的無效等價類。重復這一步驟，直到所有的無效等價類均被測試用例所覆蓋。等價類設計測試用例1. 等價類測試的弱形式不如對應的強形式的測試全面。2. 如果實現(xiàn)語言是強類型，則沒有必要使用健壯形式的測試。3. 如果錯誤條件非常重要，則進行健壯形式的測試是合適的。4.如果輸入數(shù)據(jù)以離散值區(qū)間和集合定義，則等價類測試是合適的。當然也適用于如果變量值越界系統(tǒng)就會出現(xiàn)故障的系統(tǒng)。等價類測試指導方針和觀察5. 通過結(jié)合邊界值測試，等價類測試可得到加強。6. 強等價類測試假設變量是獨立的，相應的測試用例相乘會引起冗余問題。如果存在依賴關(guān)系，則常常會生成錯誤測試用例。7. 在發(fā)現(xiàn)合適的等價關(guān)系之前，可能需要進行多次嘗試。等價類測試指導方針和觀察以下界面可以設計哪些等價類？練習3.4基于決策表的測試第3章黑盒測試方法簡單組合問題根據(jù)組合知道結(jié)果的問題，就采用判定表方法/決策表方法(Decisiontable)?！伴喿x指南”決策表12345678問題覺得疲倦？YYYYNNNN感興趣嗎？YYNNYYNN糊涂嗎？YNYNYNYN建議重讀√繼續(xù)√跳下一章√√休息√√√√決策表的組成決策表通常由以下4部分組成：條件樁—列出問題的所有條件條件項—針對條件樁給出的條件列出所有可能的取值動作樁—列出問題規(guī)定的可能采取的操作動作項—指出在條件項的各組取值情況下應采取的動作

條件樁動作樁條件項動作項規(guī)則將任何一個條件組合的特定取值及相應要執(zhí)行的動作稱為一條規(guī)則。在決策表中貫穿條件項和動作項的一列就是一條規(guī)則。決策表的組成判定表圖示條目部分中的一列就是一條規(guī)則。規(guī)則指示在規(guī)則的條件部分中指示的條件環(huán)境下要采取什么行動。“—”叫“不關(guān)心”：條件無關(guān)或條件不適用。條目部分條件部分樁行動部分決策表的組成若表中有兩條以上規(guī)則具有相同的動作，并且在條件項之間存在極為相似的關(guān)系，便可以合并。合并后的條件項用符號“-”表示，說明執(zhí)行的動作與該條件的取值無關(guān)，稱為無關(guān)條件。決策表的合并于約簡構(gòu)造決策表的5個步驟：（1）確定規(guī)則的個數(shù)。有n個條件的決策表有2n個規(guī)則（每個條件取真、假值）。（2）列出所有的條件樁和動作樁。（3）填入條件項。（4）填入動作項，得到初始決策表。（5）簡化決策表，合并相似規(guī)則。決策表的構(gòu)造決策表測試法適用于具有以下特征的應用程序：if-then-else邏輯突出；輸入變量之間存在邏輯關(guān)系；涉及輸入變量子集的計算；輸入與輸出之間存在因果關(guān)系。適用于使用決策表設計測試用例的條件：規(guī)格說明以決策表形式給出，或較容易轉(zhuǎn)換為決策表。條件的排列順序不會也不應影響執(zhí)行的操作。規(guī)則的排列順序不會也不應影響執(zhí)行的操作。當某一規(guī)則的條件已經(jīng)滿足，并確定要執(zhí)行的操作后，不必檢驗別的規(guī)則。如果某一規(guī)則的條件要執(zhí)行多個操作，這些操作的執(zhí)行順序無關(guān)緊要。小結(jié)3.5其他黑盒測試方法第3章黑盒測試方法場景的定義場景從用戶的角度描述系統(tǒng)的運行行為。場景：是由一系列相關(guān)的活動組成的，而且場景中的活動還可以由一系列的場景構(gòu)成?，F(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流。場景測試場景的構(gòu)成基本流備用流場景測試場景1：基本流場景2：基本流備選流1場景3：基本流備選流1備選流2場景4：基本流備選流3場景5：基本流備選流3備選流1場景6：基本流備選流3備選流1備選流2場景7：基本流備選流4場景8：基本流備選流3備選流4場景測試場景測試步驟(1)根據(jù)程序說明，找出程序的基本流及備選流；(2)根據(jù)基本流和各項備選流生成不同的場景；(3)對每一個場景生成相應的測試用例(4)對每一個測試用例確定測試數(shù)據(jù)值。場景測試思考練習：ATM自動取款機分析ATM自動取款機的場景流程，并設計測試用例、選擇測試數(shù)據(jù)。場景測試多個參數(shù)多個取值怎么辦？正交試驗法正交試驗法正交試驗設計法(Orthogonalexperimentaldesign)正交試驗法正交試驗法

應用正交表設計測試用例的步驟識別測試對象的參數(shù)確定每個參數(shù)的取值個數(shù)選擇正交表參數(shù)取值映射到正交表構(gòu)建測試用例正交試驗法正交試驗法129664正交試驗法功能性測試的優(yōu)點功能性測試與軟件如何實現(xiàn)無關(guān)，如果實現(xiàn)發(fā)生變化，功能性測試用例仍然可用（可重用性，面向回歸測試）測試用例開發(fā)可以與軟件開發(fā)同時進行，可節(jié)省軟件開發(fā)時間，通過軟件的用例（usecase）就可以設計出大部分功能性測試用例功能性測試的缺點測試用例數(shù)量較大測試用例可能產(chǎn)生很多冗余功能性測試的覆蓋范圍不可能達到100%功能測試總結(jié)4.1白盒測試方法概述第4章白盒測試方法白盒測試(white-box,oropen-box,clear-boxtesting):Usethestructureoftheprogramtotest.——Structuraltesting此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試方法測試用例被測程序源程序分析覆蓋情況分析執(zhí)行路徑白盒測試方法圖的定義一組結(jié)點N，N非空一組初始結(jié)點N0

，N0

非空一組終止結(jié)點Nf，Nf非空一組邊E，每條邊從一個結(jié)點到了一個結(jié)點，(ni,nj),i

是前驅(qū),j

為后繼1N0={1}Nf={1}E={}程序結(jié)構(gòu)分析publicvoidfunction(inta,intb,intc){if((a>1)&&(b==0){c=c/a;}if((a==5)||(c>1){c=c+1;}c=a+b+c;}源代碼程序控制流程圖程序結(jié)構(gòu)分析控制流圖是退化的程序流程圖，圖中每個處理都退化成一個結(jié)點，流線變成連接不同結(jié)點的有向弧?？刂屏鲌D中的基本元素：節(jié)點邊在控制流圖中用圓“○”表示節(jié)點，一個圓代表一條或多條語句?？刂屏鲌D中的箭頭線稱為邊，代表控制流。程序結(jié)構(gòu)分析基本控制流圖順序結(jié)構(gòu)IF選擇結(jié)構(gòu)While循環(huán)結(jié)構(gòu)Until循環(huán)結(jié)構(gòu)Case多分支結(jié)構(gòu)程序結(jié)構(gòu)分析程序結(jié)構(gòu)分析(a)程序流程圖i=0i<100i++n=n+il=l+ii%2==0開始結(jié)束FalseFalseTrueTrue6354217e1e2e3e4e5e6e8e7R1R2R3(b)控制流圖復合邏輯下的控制流圖改復合條件的判定為一系列單個條件的嵌套的判定程序結(jié)構(gòu)分析aorbx++x--(a)(b)(c)ax++x++x--b定義：有m個節(jié)點的控制流圖矩陣，是一個m×m矩陣：A=(a(i，j))，其中a(i，j)是1，當且僅當從節(jié)點i到節(jié)點j有一條弧，否則該元素為0。程序結(jié)構(gòu)分析邏輯覆蓋方法基路徑測試循環(huán)測試數(shù)據(jù)流測試（定義-使用覆蓋）域測試。。。白盒測試方法4.2邏輯覆蓋測試第4章白盒測試方法邏輯覆蓋測試(Logicalcoverage)邏輯覆蓋主要考察使用測試數(shù)據(jù)運行被測程序時對程序邏輯的覆蓋程度。通常希望選擇最少的測試用例來滿足所需的覆蓋標準。主要的覆蓋標準語句覆蓋判定覆蓋條件覆蓋判定－條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋測試例子程序if((A>1)&&(B==0))X=X/A;if((A==2)||(X>1))X=X+1;(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc邏輯覆蓋測試⑴語句覆蓋(Statementcoverage):選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個可執(zhí)行語句都至少執(zhí)行一次。語句覆蓋Case1：A=2,B=0,X=3(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdcCase2：A=2,B=1,X=3(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc此語句未覆蓋語句覆蓋Case1：A=2,B=0,X=3(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc錯寫成OR錯寫成AND語句覆蓋是最弱的覆蓋語句覆蓋⑵判定覆蓋(Branchcoverage)：（也稱分支覆蓋）是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結(jié)果都至少執(zhí)行一次（即判定的每個分支至少經(jīng)過一次）。判定覆蓋Case1：A=2,B=0,X=3(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdcCase3：A=1,B=0,X=1(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc判定覆蓋

只作到判定覆蓋將無法確定判定內(nèi)部條件的錯誤。(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc錯寫成X<1

因此判定覆蓋仍是弱的覆蓋標準。判定覆蓋⑶條件覆蓋(Conditioncoverage)：選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中的每個條件的所有可能結(jié)果都至少出現(xiàn)一次。條件覆蓋上例中設條件滿足條件覆蓋的一組測試用例ABX路徑覆蓋分支覆蓋條件Case6211abebeT1F2T3F4Case7103abebeF1T2F3T4條件覆蓋(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc⑷判定/條件覆蓋：選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結(jié)果都至少執(zhí)行一次，并且，每個判定中的每個條件的所有可能結(jié)果都至少出現(xiàn)一次。判定-條件覆蓋滿足判定-條件覆蓋的一組測試用例ABX路徑覆蓋分支覆蓋條件Case1203aceceT1T2T3T4Case8111abdbdF1F2F3F4(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdcCase1：A=2,B=0,X=3判定-條件覆蓋Case8：A=1,B=1,X=1(A>1)AND

(B==0)(A==2)OR(X>1)aX=X/AX=X+1eFFTTbdc(5)條件組合覆蓋：指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中條件結(jié)果的所有可能組合都至少出現(xiàn)一次。條件組合測試上例中需考慮4個條件的8種組合①A>1,B=0T1T2判定一為真②A>1,B≠0T1F2③A≤1,B=0F1T2判定一為假④A≤1,B≠0F1F2

⑤A=2，X>1T3T4⑥A=2，X≤1T3F4

判定二為真⑦A≠2，X＞1F3T4⑧A≠2，X≤1F3

F4判定二為假ABX路徑覆蓋組號覆蓋條件Case1203ace①⑤T1T2T3T4Case8211abe②⑥T1F2T3F4Case9103abe③⑦F1T2F3T4Case10111abd④⑧F1F2F3F4滿足條件組合覆蓋的一組測試用例條件組合測試

⑹路徑覆蓋(Pathcoverage):選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每條可能執(zhí)行到的路徑都至少經(jīng)過一次（如果程序中包含環(huán)路，則要求每條環(huán)路至少經(jīng)過一次）。路徑覆蓋用例ABX執(zhí)行路徑Case1203aceCase7101abdCase8211abeCase11301acd語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋小結(jié)4.3基本路徑測試第4章白盒測試方法基本路徑測試基本路徑測試是TomMcCabe提出的一種白盒測試技術(shù)，這種方法首先根據(jù)程序或設計圖畫出控制流圖，并計算其區(qū)域數(shù)，然后確定一組獨立的程序執(zhí)行路徑（稱為基本路徑），最后為每一條基本路徑設計一個測試用例。概述程序的環(huán)路復雜性即McCabe復雜性度量，簡單的定義為控制流圖的區(qū)域數(shù)。程序環(huán)路復雜性又叫圈復雜度。圈復雜度：是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用于計算程序的基本的獨立路徑數(shù)目。程序環(huán)路復雜性圈復雜度程序圖的圈復雜度計算方法（三種）：V（G）=e–n+2p；e：邊數(shù)，n：節(jié)點數(shù)，p：連接區(qū)域數(shù)當p=1時，V（G）=e–n+2；V（G）=P+1；P是圖G中判定節(jié)點的數(shù)量程序圖中區(qū)域的數(shù)量對應于環(huán)路的復雜性程序環(huán)路復雜性程序環(huán)路復雜性方法一：E=8，N=7，V(G)=E－N+2=8－7+2=3，程序的環(huán)路復雜性為3方法二：V(G)＝P＋1=2+1=3方法三：圖中有3個區(qū)域：R1，R2，R3，其環(huán)路復雜性為3獨立路徑：包括一組以前沒有處理的語句或條件的一條路徑。選擇獨立路徑時必須包含一條在定義之前不曾用到的邊。（每一條新的路徑至少包含一條新的邊）控制流圖中所有獨立路徑的集合就構(gòu)成了基本路徑集。獨立路徑獨立路徑一組獨立路徑path1：1-2-7；path2：1-2-3-4-6-2-7；path3：1-2-3-5-6-2-7；通過分析程序控制流圖的環(huán)路的復雜性，導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次?；韭窂綔y試步驟：1.導出程序的控制流圖；2.計算控制流圖的環(huán)路復雜度V(G)；3.確定只包含獨立路徑的基本路徑集；4.設計測試用例；基路徑測試方法示例publicvoidf(intRecordNum,intType){intx=0;inty=8;while(RecordNum>0){ if(Type==0) x=y+2;else{ if(Type==1) x=y+5;elsex=y+10;}RecordNum--}}基路徑測試方法第一步：畫出控制流圖第二步：計算圈復雜度V(G)=E–N+2=11–9+2=4V(G)=P+1

=3+1=4R1、R2、R3、R4基路徑測試方法R2R1R3R451764389112105176438911210第三步：找出獨立路徑路徑1：1-2-3-4-5-9-10-3-11路徑2：1-2-3-4-6-7-9-10-3-11；路徑3：1-2-3-4-6-8-9-10-3-11；路徑4：1-2-3-11。5176438911210基路徑測試方法第四步：導出測試用例publicvoidf(intiRecordNum,intiType){intx=0;inty=8;while(iRecordNum>0){ if(iType==0) x=y+2;else{ if(iType==1) x=y+5;elsex=y+10;}iRecordNum--}}5176438911210基路徑測試方法用例編號路徑輸入數(shù)據(jù)預期輸出2路徑2：1-2-3-4-6-7-9-10-3-11iRecordNum=1,iType=1x=5用例編號路徑輸入數(shù)據(jù)預期輸出1路徑1：1-2-3-4-5-9-10-3-11iRecordNum=1,iType=0x=2用例編號路徑輸入數(shù)據(jù)預期輸出3路徑3：1-2-3-4-6-8-9-10-3-11；iRecordNum=1,iType＝3x=10用例編號路徑輸入數(shù)據(jù)預期輸出4路徑4：1-2-3-11iRecordNum=0x=04.4其他白盒測試方法第4章白盒測試方法循環(huán)分為4種不同類型：簡單循環(huán)、串接循環(huán)、嵌套循環(huán)和非結(jié)構(gòu)循環(huán)。循環(huán)測試(1)簡單循環(huán)按照下列規(guī)則設計測試用例：①零次循環(huán)：從循環(huán)入口到出口②一次循環(huán)：檢查循環(huán)初始值③二次循環(huán)：檢查多次循環(huán)④m次循環(huán)：檢查多次循環(huán)⑤最大次數(shù)循環(huán)⑥比最大次數(shù)多一次的循環(huán)⑦比最大次數(shù)少一次的循環(huán)循環(huán)測試(2)嵌套循環(huán)按照下列規(guī)則設計測試用例：①先測試最內(nèi)層循環(huán)：所有外層的循環(huán)變量置為最小值，該層按簡單循環(huán)測試；②由里向外，測試上一層循環(huán)：測試時此層以外的所有外層循環(huán)的循環(huán)變量取最小值，此層以內(nèi)的所有嵌套內(nèi)層循環(huán)的循環(huán)變量取“典型”值，該層按簡單循環(huán)測試；③反復進行，直到所有各層循環(huán)測試完畢；④對全部各層循環(huán)同時取最小循環(huán)次數(shù)，或者同時取最大循環(huán)次數(shù)循環(huán)測試(3)串接循環(huán)

如果各個循環(huán)互相獨立，則可以分別用簡單循環(huán)的方法進行測試；但如果第一個循環(huán)的循環(huán)計數(shù)是第二個循環(huán)的初值，則兩個循環(huán)不獨立，此時，可用測試嵌套循環(huán)的辦法來處理。(4)非結(jié)構(gòu)循環(huán)

這一類循環(huán)應該先將其結(jié)構(gòu)化，然后再測試。循環(huán)測試數(shù)據(jù)流測試按照程序中的變量定義和使用的位置來選擇程序的測試路徑；數(shù)據(jù)流測試關(guān)注變量接收值的點和使用這些值的點；一種簡單的數(shù)據(jù)流測試策略是要求覆蓋每個定義－使用路徑一次；數(shù)據(jù)流測試用做路徑測試的“真實性檢查”。數(shù)據(jù)流測試數(shù)據(jù)流分析常常集中于定義/引用異常的缺陷：變量被定義，但從來沒有使用；所使用的變量沒有被定義；變量在使用之前被定義兩次；

數(shù)據(jù)流測試白盒測試的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。白盒測試存在以下缺點：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發(fā)人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統(tǒng)龐大時，測試開銷會非常大。小結(jié)第5章

單元測試單元測試的定義單元測試目標單元測試的意義單元測試的內(nèi)容5.1單元測試概述

5.1.1單元測試定義1.概念單元（Unit）指一個可獨立運行的代碼段，獨立運行是指的是這個工作不受前一次或接下來的程序運行的結(jié)果影響。單元測試（unittesting）對軟件設計的最小單元進行功能、性能、接口和設計約束等正確性進行檢驗，主要測試其在語法、格式和邏輯上的錯誤，并驗證程序是否符合規(guī)范所要求功能的最具有實踐意義的方法。5.1.1單元測試定義單元測試是對軟件基本組成單元進行的測試。單元測試從程序的內(nèi)部結(jié)構(gòu)出發(fā)來進行測試的，多采用白盒測試（結(jié)構(gòu)性測試）技術(shù)。單元測試是軟件開發(fā)過程中進行的最低級別的測試活動。測試進行得越早越好。測試工作主要是由程序開發(fā)人員進行自測和互測，同時還需要單獨的測試角色，來進行測試和評審。5.1.1單元測試定義1.測試對象：“單元”結(jié)構(gòu)化編程語言單元測試對象是函數(shù)或者子過程。面向?qū)ο笳Z言單元測試對象是類或者類的方法。如一個菜單、屏幕顯示界面或?qū)υ捒虻?.1.1單元測試定義2.單元測試方法靜態(tài)測試動態(tài)測試5.1.2單元測試目標3.目標(1)單元測試能更準更全面地找到錯誤，顯著提高軟件質(zhì)量檢查代碼實現(xiàn)是否符合設計測試依據(jù)是詳細設計描述(2)單元測試能夠大量削減開發(fā)時間和成本盡早發(fā)現(xiàn)錯誤5.1.3單元測試的意義1.單元測試對軟件的設計實現(xiàn)的意義加強代碼的可測試性，促進代碼的重構(gòu)；更加清晰的揭示出開發(fā)中的設計流程；對架構(gòu)的反思：更清楚怎樣使用該被測試單元。軟件的代碼更容易維護。保證軟件項目組人員的良好溝通；

有效的單元測試是推行全局質(zhì)量文化的一部分，而這種質(zhì)量文化將會為軟件開發(fā)者帶來無限的商機。5.1.3單元測試的意義2.單元測試對軟件開發(fā)者的意義更清晰的認識設計規(guī)格書中所要求的功能；鍛煉程序開發(fā)人員邏輯思維能力，代碼靜態(tài)分析技能；促進代碼編寫標準的一致性；

接觸部分以外的其他領(lǐng)域；

提供一個學習的機會。單元測試的內(nèi)容很多，我們需要通過各種測試方法來找到錯誤，通過不斷的總結(jié)，形成了許多檢查列表（CheckList）。通過它幫助開發(fā)人員形成良好的編程風格，提高源程序的可讀性和可維護性，降低出錯的機會。同時也可以使得測試更加全面，避免遺漏。

5.1.4單元測試的內(nèi)容單元測試主要對模塊的五個基本特性進行評價錯誤處理模塊接口局部數(shù)據(jù)結(jié)構(gòu)

重要的執(zhí)行路徑邊界條件模塊1）模塊接口測試對通過被測模塊的數(shù)據(jù)流進行測試，檢查進出模塊的數(shù)據(jù)是否正確。Checklist：模塊的實際輸入與定義的輸入是否一致個數(shù)、類型、順序模塊中對于非內(nèi)部/局部變量是否合理使用使用其他模塊時，是否檢查可用性和處理結(jié)果使用外部資源時，是否檢查可用性并及時釋放資源內(nèi)存、文件、硬盤、端口等其他1）模塊接口測試（續(xù)）在做內(nèi)外存交換時要考慮：文件屬性是否正確；OPEN與CLOSE語句是否正確；緩沖區(qū)容量與記錄長度是否匹配；在進行讀寫操作之前是否打開了文件；在結(jié)束文件處理時是否關(guān)閉了文件；正文書寫/輸入錯誤；I/O錯誤是否檢查并做了處理。2）模塊局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)能否保持完整性Checklist：變量從來沒有被使用可能別的地方使用了錯誤的變量名變量沒有初始化錯誤的類型轉(zhuǎn)換數(shù)組越界非法指針變量或函數(shù)名稱拼寫錯誤使用了外部變量或函數(shù)其他3）模塊邊界條件測試檢查臨界數(shù)據(jù)是否正確處理Checklist：普通合法數(shù)據(jù)是否正確處理普通非法數(shù)據(jù)是否正確處理邊界內(nèi)最接近邊界的(合法)數(shù)據(jù)是否正確處理邊界外最接近邊界的(非法)數(shù)據(jù)是否正確處理其他4）模塊獨立執(zhí)行路徑測試對模塊中重要的執(zhí)行路徑進行測試。檢查由于計算錯誤、判定錯誤、控制流錯誤導致的程序錯誤。Checklist：死代碼錯誤的計算優(yōu)先級精度錯誤比較運算錯誤賦值錯誤表達式的不正確符號：>、>=；=、==、!=循環(huán)變量的使用錯誤錯誤賦值其他5）模塊內(nèi)部錯誤處理測試檢查內(nèi)部錯誤處理設施是否有效Checklist：是否檢查錯誤出現(xiàn)資源使用前后其他模塊使用前后出現(xiàn)錯誤，是否進行錯誤處理拋出錯誤通知用戶進行記錄錯誤處理是否有效在系統(tǒng)干預前處理報告和記錄的錯誤真實詳細其他靜態(tài)測試動態(tài)測試5.2單元測試的策略和方法

不實際運行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質(zhì)量的軟件測試技術(shù)。也稱為靜態(tài)代碼分析技術(shù)。它有助于提高產(chǎn)品質(zhì)量、安全性，甚至縮短上市時間。代碼走讀(Codewalkthrough)代碼審查(CodeInspection)代碼評審（codeReview）5.2.1靜態(tài)測試定義：開發(fā)組內(nèi)部進行的，采用講解、討論和模擬運行的方式進行的查找錯誤的活動。經(jīng)驗：限時避免跑題參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項目組的新人由本模塊的開發(fā)者進行講解、回答問題并記錄檢查要點邏輯錯誤代碼標準/規(guī)范/風格代碼走讀自動化+人工定義：開發(fā)組內(nèi)部進行的，采用講解、提問并使用Checklist方式進行的查找錯誤的活動。一般有正式的計劃、流程和結(jié)果報告。經(jīng)驗：以會議的形式，制定會議目標、流程和規(guī)則，結(jié)束后要編寫報告參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項目組的新人由另外一名開發(fā)者進行講解、其他開發(fā)者主要按照Checklist進行提問并填表、本模塊開發(fā)者回答問題并記錄檢查要點設計需求代碼標準/規(guī)范/風格代碼審查定義：

開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進行的，采用講解、提問并使用Checklist方式進行的查找錯誤的活動。一般有正式的計劃、流程和結(jié)果報告。經(jīng)驗：以會議的形式，制定會議目標、流程和規(guī)則，結(jié)束后要編寫報告。相關(guān)資料要在會議前下發(fā)并閱讀。參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員測試組和相關(guān)人員由另外一名開發(fā)者進行講解、其他開發(fā)者主要按照Checklist進行提問并填表、本模塊開發(fā)者回答問題并記錄檢查要點設計需求代碼標準/規(guī)范/風格文檔的完整性和一致性代碼評審檢查是否符合編程規(guī)范快速理解源代碼，找出流程設計中的問題對原有代碼的重構(gòu)2.靜態(tài)代碼測試的主要任務動態(tài)測試（dynamictesting），指的是實際運行被測程序，輸入相應的測試數(shù)據(jù)，檢查實際輸出結(jié)果和預期結(jié)果是否相符的過程。

所以判斷一個測試屬于動態(tài)測試還是靜態(tài)的，唯一的標準就是看是否運行程序。5.2動態(tài)測試單元測試環(huán)境基本單元本身不是一個獨立的程序，自己不能運行，要靠其它部分來調(diào)用和驅(qū)動。驅(qū)動模塊(driver)樁模塊(stub)──存根模塊單元測試環(huán)境驅(qū)動模塊(Driver)被測基本單元的主程序，它接收測試數(shù)據(jù)，并把數(shù)據(jù)傳送給被測單元，最后輸出實測結(jié)果。樁模塊(Stub)用來代替被測基本單元調(diào)用的其他基本單元。在面向過程和面向?qū)ο蟮某绦蛟O計中，驅(qū)動程序和樁在實現(xiàn)的過程中存在一定的差異。具體的差異如下：面向過程和面向?qū)ο鬁y試插樁差異

面向?qū)ο蟮某绦蛟O計面向過程的程序設計驅(qū)動模塊帶有main函數(shù)的類，且創(chuàng)建被測試類的對象，并調(diào)用被測試類的方法。main函數(shù)，且調(diào)用被測試函數(shù)。樁模塊樁為對象。模擬被調(diào)用方法的對象（mock

object），如圖所示樁為方法。模擬被調(diào)用方法。如圖所示。

怎么構(gòu)造驅(qū)動模塊通過單元測試框架構(gòu)建怎樣構(gòu)造樁模塊通過Mock工具構(gòu)造樁模塊單元環(huán)境構(gòu)造JUnitXUnitGTestJest

繼承是面向?qū)ο笤O計中另一個重要特性，繼承性表達了類與類之間的關(guān)系，一個類可以定義為另一個類的擴充或者受限。

繼承對測試的影響當一個類被子類繼承后，繼承的方法需要在子類中重新測試？繼承層次結(jié)構(gòu)中類測試的測試用例可以采用如下增補原則：(1)

如果子類新增了一個或者多個新的操作，就需要增加相應的測試用例。(2)

如果子類定義的同名方法覆蓋了父類的方法，需要增加相應的測試用例。是否需要產(chǎn)生新的子類測試用例？Class_A+operation1(

)+operation2(

)Class_B+operation3(

)Class_C+operation2(

)+operation3(

)類之間的繼承關(guān)系類繼承類類方法是否改變是否增加測試用例Class_Aoperation1()operation2()Class_BClass_Aoperation1()FALSEFALSEoperation2()FALSEFALSEoperation3()TRUETRUEClass_CClass_Boperation1()FALSEFALSEoperation2()TRUETRUEoperation3()TRUETRUE接口不存在任何構(gòu)造方法，因此無法被實現(xiàn);由于接口一定會在某個類中實現(xiàn)，因此就使用一個實現(xiàn)接口的類來做測試。遵循以下原則：如果接口沒有被任何類實現(xiàn)就無需進行測試。如果已被別的類實現(xiàn)，那么就針對實現(xiàn)該接口的類進行逐一測試。

接口類測試抽象類不能創(chuàng)建對象（不能被實例化）。測試時，首先需要繼承被測試抽象類，實現(xiàn)里面的抽象方法（函數(shù)）。抽象類測試重載和覆蓋測試覆蓋是在子類中重新定義了從父類中繼承的同名方法；重載是類對自身已有的同名方法的重新定義。在測試過程中，可以參考如下兩個原則：①要對類實例方法的所有重載形式分別進行測試；②要對覆蓋了父類的同名方法進行測試；靜態(tài)代碼分析工具，有針對不同開發(fā)語言的，也有集合多語言檢測的檢測平臺。選擇靜態(tài)代碼分析測試工具的基本要求：與IDE工具的結(jié)合使用規(guī)則的自定義可生成報告與持續(xù)集成平臺和質(zhì)量保障平臺的結(jié)合使用5.3測試工具

1.靜態(tài)代碼分析工具常用靜態(tài)代碼分析工具工具名支持語言網(wǎng)址checkStylestopBugsPMDalibabaP3Cjavahttps://checkstyle.sourceforge.io/https://spotbugs.github.io/index.htmlhttps://pmd.github.io//5445/p3cCppCheckCppLintC/C++http://cppli//ESLintjavascript/HTMLHintHTML/StyleLintCSS/SCSS/stylelint/stylelintStyleCopC#/PyCheckerPylintpython//通過靜態(tài)測試后，規(guī)范的代碼可以通過文檔生成工具，為我們生成美觀，方便查閱的文檔。工具語言說明及官方網(wǎng)站javaDocjava文檔生成工具，jdk內(nèi)置該工具SandcastleC#微軟官方的文檔生成工具/EWSoftware/SHFB/releasessphinxpython文檔生成工具

pydocpythonpython內(nèi)置文檔生成工具DoxygenC、C++、Java、Objective-C和IDL語言，部分支持PHP、C#文檔生成工具，可以結(jié)合graphviz工具繪制代碼相關(guān)設計圖形，如類圖，調(diào)用關(guān)系圖等。https://www.doxygen.nl/jsdocJavaScriptAPI文檔生成器/jsdoc/jsdoc文檔生成工具選擇動態(tài)測試工具的具有的特性：1.測試覆蓋率工具與單元測試框架相兼容。2.Mock工具和測試覆蓋率工具、單元測試框架相兼容。3.單元測試框架輸出測試報告。4.覆蓋率工具輸出覆蓋率測試報告。5.單元測試框架提供持續(xù)集成工具調(diào)用接口。6.覆蓋率測試工具架提供持續(xù)集成工具調(diào)用接口。5.3測試工具

2.動態(tài)測試工具動態(tài)單元測試工具工具名支持語言簡介JUnitTestNGJava單元測試工具ParasoftJTestMockitoPowerMockjMock、EasyMockJavaMock工具JaCoco覆蓋率工具GTestboost.Testcatch2docTestctestCppUnit

VisualUnitC++、C單元測試工具gmockC++

Mock框架gcovlcov覆蓋工具XUnit.NetNUnitC#單元測試工具vsinstrOpenCover覆蓋率工具NMockMock測試工具unittestpytestPython單元測試工具coverage.py覆蓋率工具mockMock測試工具JestMocha+chaikarmaJasmineAVATapejavascriptJavascript測試框架istanbulJsCover覆蓋率工具通過覆蓋率統(tǒng)計工具怎樣評估測試質(zhì)量單元測試總結(jié)單元測試,是對軟件設計的最小單元進行功能、性能、接口和設計約束等正確性檢驗工作，主要測試其在語法、格式和邏輯上的錯誤。單元測試是驗證程序是否符合規(guī)范所要求功能的最具有實踐意義的方法。單元測試包括靜態(tài)測試和動態(tài)測試。。

單元測試成為了質(zhì)量軟件的控制方法的重要方法之一，無論對控制軟件質(zhì)量還是軟件開發(fā)者都有著極其重要的現(xiàn)實意義。

第6章

集成測試6.1集成測試概述集成測試(Integrationtest)也叫組裝測試或聯(lián)合測試是在單元測試的基礎上，將所有模塊按照設計要求集成為系統(tǒng)或子系統(tǒng)，在單元組裝過程中，進行測試，發(fā)現(xiàn)并清除在單元連接過程中出現(xiàn)的問題，確保集成到一起的各單元能共同完成預期的功能，并達到要求的性能。集成測試與單元測試的區(qū)別測試對象有所區(qū)別;集成測試關(guān)注的是模塊間的接口，接口之間的數(shù)據(jù)傳遞關(guān)系，單元組合后是否實現(xiàn)預計的功能。集成測試組裝的對象比單元測試的對象級別要高。集成測試與系統(tǒng)測試的區(qū)別測試對象系統(tǒng)測試對象是整個系統(tǒng)以及與系統(tǒng)交互的硬件和軟件平臺。對系統(tǒng)做功能性的和非功能性驗證。集成測試的對象是模塊間的接口，其目的是要找出在模塊接口上面的問題。測試依據(jù)系統(tǒng)測試的依據(jù)來自用戶的需求規(guī)格說明書和行業(yè)的已成文的或事實上的標準。集成測試的依據(jù)來自系統(tǒng)的高層設計（架構(gòu)設計或概要設計）。集成測試目的集成測試的目標就是檢測系統(tǒng)是否達到需求；對業(yè)務流程及數(shù)據(jù)流的處理是否符合標準；檢測系統(tǒng)對業(yè)務流處理是否存在邏輯不嚴謹或者錯誤；檢測需求是否存在不合理的標準及要求。具體檢測包括功能正確性驗證、接口測試、全局數(shù)據(jù)結(jié)構(gòu)的測試以及計算精度檢測等在集成測試時可能出現(xiàn)的錯誤?；诠δ芊纸獾募煞菨u增式集成漸增式集成：自頂向下、自底向上、三明治集成基于調(diào)用圖的集成基于UML的集成6.2集成測試的方法非漸增式集成-大棒集成定義又叫大棒集成(Big-bangIntegration)。所有通過了單元測試的模塊按設計要求，一次全部組裝起來，然后進行整體測試。目的盡可能縮短測試時間，使用最少的測試用例驗證系統(tǒng)。優(yōu)點需要的測試用例少；測試方法簡單易行；缺點難以保證對各個模塊之間的接口進行充分測試；對全局數(shù)