軟件工程原理與實(shí)踐（碩士）課件 7 軟件質(zhì)量管理與測(cè)試

高級(jí)軟件工程

SoftwareEngineering軟件質(zhì)量管理與測(cè)試軟件災(zāi)難蘇聯(lián)導(dǎo)彈預(yù)警系統(tǒng)軟件故障差點(diǎn)導(dǎo)致第三次世界大戰(zhàn)（1983年）造價(jià)80億美元的Ariane5型火箭因浮點(diǎn)數(shù)溢出，被迫引爆自毀。原因是5型的發(fā)射系統(tǒng)直接重用了4型的相應(yīng)代碼，而4型的飛行條件和5型的截然不同（1996年）由北京南站開往福州站的D301次列車與杭州站開往福州南站的D3115次列車發(fā)生追尾事故，造成40人死亡，直接經(jīng)濟(jì)損失2億元。原因是信號(hào)設(shè)備存在嚴(yán)重缺陷，遭雷擊發(fā)生故障后，導(dǎo)致本應(yīng)顯示為紅燈的信號(hào)機(jī)錯(cuò)誤顯示為綠燈（2011年）區(qū)塊鏈業(yè)界最大的眾籌項(xiàng)目TheDAO遭到攻擊，導(dǎo)致300多萬(wàn)以太幣資產(chǎn)被盜，原因是其智能合約中splitDAO函數(shù)有漏洞（2016年）印尼獅航一架波音737MAX8客機(jī)途中墜落，189人罹難，失事原因?yàn)檐浖O(shè)計(jì)缺陷，飛機(jī)的迎角傳感器“數(shù)據(jù)錯(cuò)誤”觸發(fā)“防失速”自動(dòng)操作，導(dǎo)致機(jī)頭不斷下壓，最終墜海（2018年）2問(wèn)題軟件系統(tǒng)功能齊全是不是就是質(zhì)量好？沒有BUG是不是就是軟件的質(zhì)量好？什么是用戶滿意的軟件項(xiàng)目？軟件測(cè)試是不是軟件質(zhì)量的全部？那么，什么是軟件的質(zhì)量？如何保證軟件的質(zhì)量？302-軟件質(zhì)量管理01-基本概念03-軟件評(píng)審404-軟件測(cè)試軟件質(zhì)量的定義ANSI/IEEEStd729-1983定義“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。M.J.Fisher定義“所有描述計(jì)算機(jī)軟件優(yōu)秀程度的特性的組合”。5何謂軟件質(zhì)量好明確聲明的功能和性能需求、明確文檔化過(guò)的開發(fā)標(biāo)準(zhǔn)、以及專業(yè)人員開發(fā)的軟件所應(yīng)具有的所有隱含特征都得到滿足。軟件需求是進(jìn)行質(zhì)量度量的基礎(chǔ)，與需求不符就是質(zhì)量不合格指定的標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則，如果不能遵照這些準(zhǔn)則，就極有可能導(dǎo)致質(zhì)量不好通常有一組隱含需求是不被提及的，如易維護(hù)性，如果軟件符合了明確的需求卻沒有滿足隱含需求，軟件質(zhì)量仍然值得懷疑6軟件的質(zhì)量屬性質(zhì)量的三種視角：內(nèi)部、外部、和使用質(zhì)量ISO/IEC25010:2011《軟件工程產(chǎn)品質(zhì)量》使用周境7ISO/IEC25010(SQuaRE)–Systemandsoftwarequalitymodels產(chǎn)品質(zhì)量模型（外部質(zhì)量和內(nèi)部質(zhì)量）8使用質(zhì)量模型9質(zhì)量與質(zhì)量特性軟件質(zhì)量是各種質(zhì)量特性的綜合體現(xiàn)但具體產(chǎn)品中各質(zhì)量特性的重要性與產(chǎn)品類型相關(guān)，例如關(guān)鍵任務(wù)系統(tǒng)(如銀行)強(qiáng)調(diào)可靠性和安全性大眾娛樂軟件強(qiáng)調(diào)用戶可用性廣泛分發(fā)的軟件服務(wù)(銀行支付服務(wù)等)強(qiáng)調(diào)互操作性實(shí)時(shí)系統(tǒng)特別強(qiáng)調(diào)時(shí)間效率嵌入式系統(tǒng)特別強(qiáng)調(diào)資源效率具有一定用戶面的特定領(lǐng)域產(chǎn)品強(qiáng)調(diào)可配置性和可維護(hù)性10質(zhì)量特性之間的關(guān)系無(wú)關(guān)互補(bǔ)或依賴易理解性與易操作性可靠性與容錯(cuò)性：特性與子特性沖突安全性與性能可移植性與效率11質(zhì)量成本12分類質(zhì)量成本典型成分一致性成本預(yù)防成本質(zhì)量管理體系建立和維持、軟件過(guò)程改進(jìn)、培訓(xùn)、工具、供應(yīng)商評(píng)價(jià)等評(píng)價(jià)成本測(cè)試、評(píng)審、審核等非一致性成本內(nèi)部故障成本重新設(shè)計(jì)、工期延期、BUG修復(fù)、返工、回歸測(cè)試、糾錯(cuò)、資源閑置等外部故障成本客戶投訴處理、故障處理、處罰及賠償、市場(chǎng)影響、銷售影響等02-軟件質(zhì)量管理01-基本概念03-軟件評(píng)審1304-軟件測(cè)試如何進(jìn)行質(zhì)量管理？ISO9000：質(zhì)量計(jì)劃、質(zhì)量控制、質(zhì)量保證、質(zhì)量改進(jìn)。ISO12207和SWEBOK

：軟件質(zhì)量保證、驗(yàn)證和確認(rèn)、軟件評(píng)審、軟件審核、配置管理。SQuBOK：從組織級(jí)和項(xiàng)目級(jí)進(jìn)行質(zhì)量管理。14軟件質(zhì)量管理15項(xiàng)目級(jí)軟件質(zhì)量管理16軟件質(zhì)量計(jì)劃是軟件項(xiàng)目計(jì)劃的子計(jì)劃內(nèi)容：質(zhì)量目標(biāo)開展質(zhì)量活動(dòng)的質(zhì)量標(biāo)準(zhǔn)、方法、規(guī)程和工具驗(yàn)證、確認(rèn)、評(píng)審、測(cè)試、審核、問(wèn)題解決等質(zhì)量活動(dòng)和任務(wù)的安排開展質(zhì)量活動(dòng)的資源、日程和職責(zé)質(zhì)量記錄的標(biāo)識(shí)、收集、歸檔、維護(hù)和處理的規(guī)程17驗(yàn)證和確認(rèn)的定義V&V是一個(gè)用以分析、評(píng)價(jià)、測(cè)試系統(tǒng)和軟件文檔以及代碼系統(tǒng)的過(guò)程，從而盡可能地確保質(zhì)量、可靠性以及系統(tǒng)需求和目標(biāo)滿意度。

[IEEEStandardGlossary]驗(yàn)證(Verification)是“對(duì)系統(tǒng)或單元評(píng)價(jià)的過(guò)程，以確定一個(gè)給定的開發(fā)階段的產(chǎn)品是否滿足在此階段開始時(shí)所給定的條件”確認(rèn)(Validation)是“在軟件開發(fā)過(guò)程期間或結(jié)束時(shí)評(píng)價(jià)系統(tǒng)或單元的過(guò)程，以確定它是否滿足給定的需求”我們是否正確地完成了產(chǎn)品?我們是否完成了正確的產(chǎn)品？18質(zhì)量評(píng)價(jià)在軟件開發(fā)和運(yùn)維過(guò)程中，收集與其執(zhí)行過(guò)程、執(zhí)行結(jié)果和成果相關(guān)的數(shù)據(jù)，進(jìn)行質(zhì)量評(píng)價(jià)。評(píng)價(jià)結(jié)果作為判定能否批準(zhǔn)接收成果和進(jìn)度狀況的依據(jù)，并運(yùn)用于過(guò)程改進(jìn)。質(zhì)量評(píng)價(jià)的對(duì)象軟件產(chǎn)品（包括中間產(chǎn)品和最終產(chǎn)品）例如，項(xiàng)目在每個(gè)開發(fā)迭代結(jié)束時(shí)，都會(huì)以本次迭代的軟件版本為對(duì)象，以軟件需求規(guī)約為依據(jù)，遵循軟件產(chǎn)品質(zhì)量模型，進(jìn)行正式的產(chǎn)品質(zhì)量的評(píng)價(jià)，以確定項(xiàng)目是否進(jìn)入下一個(gè)迭代？需求是否必須改動(dòng)？軟件開發(fā)是否需要更多的資源？等。軟件過(guò)程例如，項(xiàng)目在每個(gè)開發(fā)迭代結(jié)束時(shí)，在產(chǎn)品質(zhì)量評(píng)價(jià)的同時(shí)，對(duì)項(xiàng)目過(guò)程的質(zhì)量進(jìn)行評(píng)價(jià)，以確定是否要對(duì)過(guò)程進(jìn)行修改。尤其當(dāng)產(chǎn)品質(zhì)量出現(xiàn)問(wèn)題時(shí)，需分析是否由于過(guò)程的問(wèn)題引起的。19軟件質(zhì)量管理技術(shù)20如何檢測(cè)軟件中的缺陷開發(fā)活動(dòng)軟件制品缺陷檢測(cè)活動(dòng)需求分析軟件設(shè)計(jì)軟件實(shí)現(xiàn)軟件運(yùn)行需求模型設(shè)計(jì)模型源代碼可執(zhí)行代碼軟件系統(tǒng)評(píng)審模擬形式化驗(yàn)證代碼靜態(tài)分析軟件測(cè)試運(yùn)行時(shí)監(jiān)控靜態(tài)方法動(dòng)態(tài)方法21可靠性預(yù)測(cè)符號(hào)執(zhí)行各種方法的缺陷檢測(cè)效果來(lái)源：“美國(guó)國(guó)防部：軟件技術(shù)進(jìn)展”，2010年221)軟件評(píng)審審查小組評(píng)審走查結(jié)對(duì)編程同級(jí)桌查輪查臨時(shí)評(píng)審正式化程度23系統(tǒng)分析和設(shè)計(jì)需求分析設(shè)計(jì)編碼系統(tǒng)方案評(píng)審需求規(guī)范評(píng)審設(shè)計(jì)文檔評(píng)審單元測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試2)軟件測(cè)試驗(yàn)收測(cè)試ɑ

測(cè)試

?

測(cè)試試運(yùn)行內(nèi)部外部項(xiàng)目產(chǎn)品243)代碼靜態(tài)分析不運(yùn)行代碼，通過(guò)詞法分析、語(yǔ)法分析、控制流分析等技術(shù)，對(duì)代碼進(jìn)行檢查，分析代碼的結(jié)構(gòu)，查找代碼的問(wèn)題（例如內(nèi)存泄漏、安全漏洞、重復(fù)代碼、未使用變量等），度量代碼的質(zhì)量（例如耦合度、內(nèi)聚度、復(fù)雜度、重用度等）分析對(duì)象：源代碼、bytecode或二進(jìn)制代碼可以由人工進(jìn)行，也可以借助代碼分析工具進(jìn)行商用代碼分析工具：Understand(多語(yǔ)言)、Sourceinsight(多語(yǔ)言)等開源代碼分析工具：PMD和Checkstyle(Java)、flake8和pylint(Python)、SonarQube(多語(yǔ)言)等25常用的代碼靜態(tài)分析技術(shù)詞法分析：從左至右一個(gè)字符一個(gè)字符的讀入源程序，對(duì)構(gòu)成源程序的字符流進(jìn)行掃描，通過(guò)使用正則表達(dá)式匹配方法將源代碼轉(zhuǎn)換為等價(jià)的符號(hào)（Token）流，生成相關(guān)符號(hào)列表，Lex為常用分析工具。語(yǔ)法分析：判斷源程序結(jié)構(gòu)上是否正確，通過(guò)使用上下文無(wú)關(guān)語(yǔ)法將相關(guān)符號(hào)整理為語(yǔ)法樹，Yacc為常用工具。抽象語(yǔ)法樹分析：將程序組織成樹形結(jié)構(gòu)，樹中相關(guān)節(jié)點(diǎn)代表了程序中的相關(guān)代碼，目前已有javacc等抽象語(yǔ)法樹生成工具。語(yǔ)義分析：對(duì)結(jié)構(gòu)上正確的源程序進(jìn)行上下文有關(guān)性質(zhì)的審查。控制流分析：生成有向控制流圖，用節(jié)點(diǎn)表示基本代碼塊，節(jié)點(diǎn)間的有向邊代表控制流路徑，反向邊表示可能存在的循環(huán)；還可生成函數(shù)調(diào)用關(guān)系圖，表示函數(shù)間的嵌套關(guān)系。數(shù)據(jù)流分析：對(duì)控制流圖進(jìn)行遍歷，記錄變量的初始化點(diǎn)和引用點(diǎn)，保存相關(guān)數(shù)據(jù)信息。污點(diǎn)分析：基于數(shù)據(jù)流圖判斷源代碼中哪些變量可能受到攻擊，是驗(yàn)證程序輸入、識(shí)別代碼表達(dá)缺陷的關(guān)鍵。

264)符號(hào)執(zhí)行

符號(hào)執(zhí)行（symbolicexecution）是指在不執(zhí)行代碼的前提下，用符號(hào)值表示代碼中變量值，然后模擬程序執(zhí)行來(lái)進(jìn)行相關(guān)分析的技術(shù)，分析代碼的語(yǔ)義信息。符號(hào)執(zhí)行分為：過(guò)程內(nèi)分析是指只對(duì)單個(gè)過(guò)程的代碼進(jìn)行分析；過(guò)程間分析（又稱全局分析）指對(duì)整個(gè)軟件代碼進(jìn)行上下文敏感的分析。27intm=M,n=N,q=Q;intx1=0,x2=0,x3=0;if(m!=0){x1=-2;}if(n<12){

if(!m&&q){x2=1;}

x3=2;}assert(x1+x2+x3!=3)分析什么樣的輸入向量<M,N,Q>的情況下，得到的三個(gè)輸出變量的和等于35)形式化驗(yàn)證形式化驗(yàn)證用以驗(yàn)證軟件是否滿足其規(guī)約的要求，常用于驗(yàn)證關(guān)鍵軟件的安全性主要技術(shù)：定理證明(Theoremproving)模型檢驗(yàn)（modelchecking）286)模擬

模型的動(dòng)態(tài)模擬用于需求分析與設(shè)計(jì)模型的質(zhì)量控制例如：狀態(tài)圖與工作流的模擬運(yùn)行等目的：更深入地看到需求和設(shè)計(jì)的完整性、正確性和合理性等，從而確保需求反映了用戶的真實(shí)要求，設(shè)計(jì)能滿足預(yù)期的需求。代碼在宿主機(jī)/開發(fā)環(huán)境上的模擬運(yùn)行模擬目標(biāo)機(jī)/運(yùn)行環(huán)境297)運(yùn)行時(shí)監(jiān)控系統(tǒng)監(jiān)控是對(duì)運(yùn)行時(shí)軟件系統(tǒng)的性能和可靠性等進(jìn)行實(shí)時(shí)監(jiān)視的技術(shù)，記錄和分析運(yùn)行日志、軌跡和拋出異常，檢查系統(tǒng)的在線服務(wù)質(zhì)量，并及時(shí)發(fā)現(xiàn)問(wèn)題。三種監(jiān)控手段：日志（Logging）、指標(biāo)（Metrics）、追蹤（Tracing）工具舉例：Actuator、Prometheus、Grafana、LogStash、APM等308)可靠性預(yù)測(cè)采用可靠性增長(zhǎng)模型定量地評(píng)價(jià)軟件可靠性?？煽啃栽鲩L(zhǎng)模型能根據(jù)測(cè)試階段和運(yùn)行階段的數(shù)據(jù)推斷出軟件可靠性。因?yàn)殡S著測(cè)試及運(yùn)行，缺陷被不斷發(fā)現(xiàn)與排除，可靠性會(huì)隨之增長(zhǎng)，故稱為可靠性增長(zhǎng)模型。軟件可靠性增長(zhǎng)模型一般可分為：故障發(fā)生時(shí)間模型，如NHPP模型、馬爾可夫過(guò)程模型等故障發(fā)現(xiàn)數(shù)量模型，如貝葉斯模型、危險(xiǎn)率模型等31七種基本質(zhì)量工具（7QC）32質(zhì)量控制圖33魚骨圖34Pareto圖Pareto法則：80%的缺陷經(jīng)常由于20%的原因引起的3502-軟件質(zhì)量管理01-基本概念03-軟件評(píng)審3604-軟件測(cè)試評(píng)審目的提高質(zhì)量減少軟件開發(fā)/維護(hù)的時(shí)間和費(fèi)用提高生產(chǎn)率提高估算準(zhǔn)確性培訓(xùn)EngineeringDocumentsRulesForwritingEng.Docs.軟件評(píng)審Defects發(fā)現(xiàn)缺陷、預(yù)防缺陷37投資回報(bào)率從4:1到30:1Review:評(píng)審方法審查小組評(píng)審走查結(jié)對(duì)編程同級(jí)桌查輪查臨時(shí)評(píng)審正式化程度從高到低38審查Inspection最系統(tǒng)化、最嚴(yán)密的評(píng)審技術(shù)被認(rèn)為是軟件工業(yè)中最實(shí)用的、最有效的評(píng)審方法嚴(yán)格定義的審查過(guò)程，明確的分工審查組長(zhǎng)、讀者、審查者作者、記錄員39審查過(guò)程初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審40受審查的工件初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備評(píng)審會(huì)議重寫重審項(xiàng)目計(jì)劃需求規(guī)格說(shuō)明書概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)系統(tǒng)測(cè)試計(jì)劃、用例和報(bào)告代碼

等41審查的規(guī)劃初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審審查組長(zhǎng)判斷是否已滿足審查的進(jìn)入標(biāo)準(zhǔn)作者和審查組長(zhǎng)協(xié)同對(duì)審查進(jìn)行規(guī)劃，確定審查員和時(shí)間進(jìn)度審查會(huì)議效率：每小時(shí)4~6頁(yè)

審查人員不超過(guò)7人或者更少審查人員可以是開發(fā)人員、測(cè)試人員、項(xiàng)目經(jīng)理、用戶等42RelativeTeamEfficiency:MajorDefects/timeused(uniquetotal)2367CheckersonteamRelative

Effectiveness:MajorDefectsfoundperpage(totalbyteam).Source:S?renSkogstadNielsen,Denmark’sTechnologicalInstitute(DTI),Lyngby,Denmark(Switch+4543504350).MajorDefectsfoundperPage45MajordefectsfoundperHourNote:thischartisanapproximationandisnotexactEffectivenesspeaksataround5or6checkersEfficiencypeaksataround3to4checkers評(píng)審小組人數(shù)對(duì)效率的影響143審查的準(zhǔn)備初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審將需求說(shuō)明書等到交給每位審查員每個(gè)審查員以審查清單為指導(dǎo)，檢查文檔可能出現(xiàn)的錯(cuò)誤，并提出問(wèn)題75%的錯(cuò)誤是在準(zhǔn)備階段發(fā)現(xiàn)的44審查會(huì)議初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審參加人員：審查組長(zhǎng)、作者、記錄員、審查人員（選其中一個(gè)為讀者）每次會(huì)議不超過(guò)2小時(shí)審查目標(biāo)：盡可能多地發(fā)現(xiàn)問(wèn)題，而不是解決問(wèn)題遞交：會(huì)議記錄（問(wèn)題和缺陷）、審查結(jié)論45重寫初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審由作者根據(jù)審查發(fā)現(xiàn)的問(wèn)題，重寫文檔46重審初始工件基線工件規(guī)劃總體會(huì)議準(zhǔn)備審查會(huì)議重寫重審由審查組長(zhǎng)或指派人單獨(dú)重審由作者重寫的文檔，確保所有問(wèn)題得到解決，所有錯(cuò)誤得到修改。由審查組長(zhǎng)判斷：是否已滿足審查的退出標(biāo)準(zhǔn)47小組評(píng)審TeamReview評(píng)審過(guò)程計(jì)劃、準(zhǔn)備、開會(huì)、返工作者或評(píng)審組長(zhǎng)主持會(huì)議讀者這個(gè)角色被省略了，改由評(píng)審組長(zhǎng)詢問(wèn)其他評(píng)審者這一部分是否有問(wèn)題使用記錄員使用缺陷檢查表48走查Walkthrough評(píng)審過(guò)程計(jì)劃、開會(huì)、返工作者主持會(huì)議，起主導(dǎo)作用，陳述產(chǎn)品常用走查方法使用一些樣品數(shù)據(jù)一步步執(zhí)行一個(gè)模塊，和同事一道檢查以確保正確的邏輯和行為。使用交互式調(diào)試器按腳本執(zhí)行，腳本描述了一項(xiàng)具體的任務(wù)或場(chǎng)景，用以說(shuō)明系統(tǒng)如何在用戶會(huì)話中發(fā)揮功能49結(jié)對(duì)編程PairProgramming極值編程XP中的一個(gè)實(shí)踐兩個(gè)開發(fā)者在一個(gè)工作站上同時(shí)編寫同一個(gè)程序，進(jìn)行實(shí)時(shí)的、持續(xù)的、非正式的評(píng)審。司機(jī)和搭檔的角色還要不時(shí)地交換。由于搭檔的實(shí)時(shí)評(píng)審，結(jié)對(duì)者可以迅速糾正錯(cuò)誤?？焖俚牡苁乖O(shè)計(jì)和程序更加強(qiáng)壯。結(jié)對(duì)編程技術(shù)除了能應(yīng)用于編碼，還能應(yīng)用需求、設(shè)計(jì)、測(cè)試等文檔。50同級(jí)桌查PeerDeskcheck在兩次編譯之間仔細(xì)地檢查源代碼以保證程序正確執(zhí)行，這就是桌查。桌查是PSP的組成部分,是一種自評(píng)審，不屬于同級(jí)評(píng)審。在同級(jí)桌查中，除作者外的一位評(píng)審者對(duì)工作產(chǎn)品進(jìn)行檢查。評(píng)審者可以和作者坐在一起討論，也可以獨(dú)立檢查。評(píng)審?fù)瓿珊?，評(píng)審者把錯(cuò)誤表交給作者，或者兩人一起坐下來(lái)共同準(zhǔn)備錯(cuò)誤表，或者簡(jiǎn)單地將做過(guò)標(biāo)記的工作產(chǎn)品交給作者。要尋找一位足夠?qū)I(yè)且值得信賴的人擔(dān)任評(píng)審者。51輪查Passaround輪查是由多人組成的并行同級(jí)桌查輪查有助于緩和同級(jí)桌查的兩個(gè)主要風(fēng)險(xiǎn)評(píng)審者不能及時(shí)提供反饋評(píng)審效果太糟52選擇合適的評(píng)審方法評(píng)審目標(biāo)審查小組評(píng)審走查結(jié)對(duì)編程同級(jí)桌查輪查查找產(chǎn)品缺陷√√√√√√檢查規(guī)范的一致性√√

√√檢查是否符合標(biāo)準(zhǔn)√

√√檢查完整性/正確性√

√

評(píng)估可理解性/可維護(hù)性√√

√

√證實(shí)關(guān)鍵構(gòu)件的質(zhì)量√

過(guò)程改進(jìn)√√

測(cè)量文檔質(zhì)量√

培訓(xùn)其他組員熟悉產(chǎn)品

√√√

√對(duì)方法達(dá)成共識(shí)

√√√

確保修改和糾錯(cuò)正確

√√

√

尋找可替換的方法

√√

模擬執(zhí)行程序

√

評(píng)審開銷最小化

√

5302-軟件質(zhì)量管理01-基本概念03-軟件評(píng)審5404-軟件測(cè)試軟件測(cè)試技術(shù)白盒測(cè)試黑盒測(cè)試基于直覺和經(jīng)驗(yàn)即興測(cè)試*探索式測(cè)試*基于代碼控制流測(cè)試*基本路徑測(cè)試*數(shù)據(jù)流測(cè)試基于規(guī)約等價(jià)類劃分*邊界值分析*隨機(jī)測(cè)試*基于錯(cuò)誤錯(cuò)誤猜測(cè)*變異測(cè)試基于模型因果圖/判定表基于有限狀態(tài)機(jī)的測(cè)試基于形式化規(guī)約的測(cè)試專用測(cè)試技術(shù)（即基于應(yīng)用類型）面向?qū)ο蟮臏y(cè)試基于構(gòu)件的測(cè)試并發(fā)程序的測(cè)試基于Web的測(cè)試圖形用戶界面的測(cè)試協(xié)議一致性的測(cè)試實(shí)時(shí)系統(tǒng)的測(cè)試55軟件測(cè)試的層次56單元測(cè)試（unittesting）又稱為模塊測(cè)試，是針對(duì)軟件結(jié)構(gòu)中獨(dú)立的基本單元（如函數(shù)、子過(guò)程、類）進(jìn)行的測(cè)試。單元測(cè)試可看作是編碼工作的一部分，應(yīng)該由程序員完成，也就是說(shuō)，經(jīng)過(guò)了單元測(cè)試的代碼才是已完成的代碼，提交產(chǎn)品代碼時(shí)也要同時(shí)提交測(cè)試代碼。測(cè)試驅(qū)動(dòng)開發(fā)（testdrivendevelopment）:在詳細(xì)設(shè)計(jì)的時(shí)候就編寫測(cè)試用例，然后再編寫程序代碼來(lái)滿足這些測(cè)試用例。自動(dòng)化的單元測(cè)試:目前最流行的單元測(cè)試工具是xUnit系列框架，如JUnit(Java)，CppUnit(C++)，Cunit(C)，Dunit(Delphi)，Nunit(.net)，PhpUnit(PHP)，PyUnit/unittest/pytest(Python)，Jest(Javascript)等等。57單元測(cè)試技術(shù)–白盒測(cè)試白盒測(cè)試：基于代碼的測(cè)試控制流測(cè)試數(shù)據(jù)流測(cè)試基本路徑測(cè)試581）語(yǔ)句覆蓋2）判定覆蓋（分支）3）條件覆蓋4）判定/條件覆蓋5）條件組合覆蓋6）路徑覆蓋集成測(cè)試（integrationtesting）又稱組裝測(cè)試，根據(jù)設(shè)計(jì)將軟件模塊組裝起來(lái)，進(jìn)行有序的、遞增的測(cè)試，并通過(guò)測(cè)試評(píng)價(jià)它們之間的交互。集成測(cè)試重點(diǎn)關(guān)注：在把各個(gè)軟件單元連接起來(lái)的時(shí)候，穿越單元接口的數(shù)據(jù)是否會(huì)丟失；一個(gè)軟件單元的功能是否會(huì)對(duì)另一個(gè)軟件單元的功能產(chǎn)生不利的影響；各個(gè)子功能組合起來(lái)，能否達(dá)到預(yù)期要求的父功能；全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題；單個(gè)軟件單元的誤差累積起來(lái)，是否會(huì)放大，從而達(dá)到不能接受的程度。集成測(cè)試工具：postman、APIfox、SoapUI等API測(cè)試工具；Spring后端應(yīng)用的集成測(cè)試工具SpringBootTest；ReactNative集成測(cè)試工具Cavy等59集成測(cè)試技術(shù)–灰盒測(cè)試灰盒測(cè)試(白盒+黑盒):基于設(shè)計(jì)的測(cè)試舉例：服務(wù)端的接口測(cè)試，采用Apifox測(cè)試工具白盒：API

signature;黑盒：根據(jù)API的輸入和輸出，采用黑盒測(cè)試技術(shù)進(jìn)行測(cè)試60系統(tǒng)測(cè)試（systemtesting）對(duì)整個(gè)軟件系統(tǒng)進(jìn)行一系列測(cè)試，以驗(yàn)證系統(tǒng)是否滿足需求規(guī)約功能測(cè)試性能測(cè)試可靠性測(cè)試易用性測(cè)試安全性測(cè)試兼容性測(cè)試……61系統(tǒng)測(cè)試技術(shù)–黑盒測(cè)試黑盒測(cè)試：基于需求規(guī)約的測(cè)試等價(jià)類劃分邊界值分析判定表法錯(cuò)誤推測(cè)法62等價(jià)類劃分邊界值分析

1234條件兒童1100白天時(shí)段0110動(dòng)作票價(jià)8折

票價(jià)9折

票價(jià)不打折

測(cè)試用例

TC1TC2TC3TC4判定表法功能測(cè)試功能測(cè)試（functionalitytesting），又稱為正確性測(cè)試或一致性測(cè)試，其目的是用以確認(rèn)軟件在指定條件下使用時(shí)，軟件產(chǎn)品提供滿足明確和隱含要求的功能的能力。測(cè)試方法采用場(chǎng)景法測(cè)試所有用例的所有事件流采用等價(jià)類劃分、邊界值分析、判定表法、錯(cuò)誤推測(cè)法等進(jìn)行輸入輸出的測(cè)試人工測(cè)試或自動(dòng)化測(cè)試自動(dòng)化的功能測(cè)試工具，又稱為回歸測(cè)試工具，或UI測(cè)試工具，例如Web應(yīng)用的開源Selenium工具App應(yīng)用的開源Appium工具63性能測(cè)試性能測(cè)試（performancetesting）用來(lái)測(cè)試軟件在規(guī)定條件下，相對(duì)于所用資源的數(shù)量，可提供適當(dāng)性能的能力。壓力測(cè)試（stresstesting），又稱強(qiáng)度測(cè)試，是一種超常情況下的性能測(cè)試。它需要在超常數(shù)量、頻率或資源的方式下執(zhí)行系統(tǒng)，以獲得系統(tǒng)對(duì)非正常情況下（如大數(shù)據(jù)量的輸入、處理和輸出，大并發(fā)數(shù)等）的承受程度。自動(dòng)化的性能/壓力測(cè)試工具：HP的Loadrunner開源的Jmeter……64可靠性測(cè)試軟件可靠性測(cè)試（reliabilitytesting）用以測(cè)試在故障發(fā)生時(shí)，軟件產(chǎn)品維持規(guī)定的績(jī)效級(jí)別的能力。

廣義的可靠性包括可靠性和可用性可靠性使用MTBF（MeanTimeBetweenFailure）度量。平均故障間隔時(shí)間，或稱為平均無(wú)故障工作時(shí)間，指相鄰兩次故障之間的平均工作時(shí)長(zhǎng)。易恢復(fù)性使用MTTR（MeanTimeToRecover）度量，即平均故障修復(fù)時(shí)間?？捎眯杂?jì)算：MTBF/(MTBF+MTTR)可靠性測(cè)試方法：系統(tǒng)運(yùn)行一段時(shí)間，觀察正常工作的時(shí)間，以及故障發(fā)生的頻率和修復(fù)時(shí)間以主動(dòng)制造故障的方法來(lái)驗(yàn)證容災(zāi)和恢復(fù)能力65易用性測(cè)試易用性測(cè)試（usabilitytesting）用以評(píng)價(jià)用戶學(xué)習(xí)和使用軟件（包括用戶文檔）的難易程度、支持用戶任務(wù)的有效程度、從用戶的錯(cuò)誤中恢復(fù)的能力。易用性測(cè)試可以采用模擬用戶的方式進(jìn)行，也可以通過(guò)觀察用戶的操作行為來(lái)執(zhí)行。66易用性原則說(shuō)明狀態(tài)可見針對(duì)用戶的操作，系統(tǒng)能及時(shí)反饋操作是否生效環(huán)境貼切用戶常用操作和大部分系統(tǒng)設(shè)計(jì)保持一致，不應(yīng)出現(xiàn)“反人類”的設(shè)計(jì)用戶可控為了避免用戶的誤操作，系統(tǒng)應(yīng)支持撤銷的功能，并以方便的形式允許用戶使用，從而使得用戶能夠方便地回退到之前的狀態(tài)一致性系統(tǒng)中同一用語(yǔ)、功能、操作保持一致，同樣的語(yǔ)言、同樣的情景、操作應(yīng)該出現(xiàn)同樣的結(jié)果防錯(cuò)系統(tǒng)應(yīng)防止用戶的誤操作易取系統(tǒng)應(yīng)減少用戶記憶負(fù)擔(dān)，把需要記憶的內(nèi)容放在可見界面上靈活高效系統(tǒng)應(yīng)提供特定能力以使得用戶在使用某些功能時(shí)更加靈活、操作更加高效優(yōu)美簡(jiǎn)約系統(tǒng)界面上多余的信息會(huì)分散用戶對(duì)有用或者相關(guān)信息的注意力，因此界面應(yīng)貼合實(shí)際場(chǎng)景，突出重點(diǎn)，弱化和剔除無(wú)關(guān)信息容錯(cuò)系統(tǒng)應(yīng)幫助用戶從錯(cuò)誤中恢復(fù)并將損失降到最低。如果無(wú)法自動(dòng)挽回，則應(yīng)提供詳盡的說(shuō)明文字和指示方向，而不應(yīng)該使用代碼人性化幫助系統(tǒng)應(yīng)提供幫助性提示，包括一次性提示、常駐提示、幫助文檔等安全性測(cè)試（SecurityTesting）

常見的面向Web應(yīng)用的信息安全測(cè)試的測(cè)試內(nèi)容67類型測(cè)試內(nèi)容服務(wù)器信息測(cè)試運(yùn)行賬號(hào)測(cè)試；web服務(wù)器端口版本測(cè)試；HTTP方法測(cè)試文件目錄測(cè)試目錄遍歷測(cè)試；文件歸檔測(cè)試；目錄列表測(cè)試認(rèn)證測(cè)試驗(yàn)證碼測(cè)試；認(rèn)證錯(cuò)誤測(cè)試；找回、修改密碼測(cè)試會(huì)話管理測(cè)試會(huì)話超時(shí)測(cè)試；會(huì)話固定測(cè)試；會(huì)話標(biāo)識(shí)隨機(jī)性測(cè)試授權(quán)管理測(cè)試橫向越權(quán)測(cè)試；縱向越權(quán)測(cè)試；跨站偽造請(qǐng)求測(cè)試文件上傳下載測(cè)試文件上傳測(cè)試；文件下載測(cè)試信息泄露測(cè)試數(shù)據(jù)庫(kù)賬號(hào)密碼測(cè)試；客戶端源代碼測(cè)試；異常處理測(cè)試輸入數(shù)據(jù)測(cè)試SQL注入測(cè)試；XML注入測(cè)試；LDAP注入測(cè)試跨站腳本攻擊測(cè)試反射型測(cè)試；存儲(chǔ)型跨站測(cè)試；DOM型跨站測(cè)