實用軟件測試技術完整版ppt全套教學教程(最新)

1、實用軟件測試技術第1章 軟件測試概述內(nèi)容簡介 軟件測試基礎 軟件測試發(fā)展史和發(fā)展前景 軟件測試行業(yè)標準 軟件測試人員的基本素質(zhì)和需具備的思維方式本章導讀本章導讀什么是軟件測試？為什么要做軟件測試？本章試圖從軟件工程和軟件生命周期的角度去解釋軟件測試的基本概念，軟件測試的目的和意義以及對于軟件開發(fā)和質(zhì)量保證的重要性，為學習和掌握軟件測試技術做好準備。1.1軟件測試基礎1.1軟件測試基礎 在最早的工業(yè)制造和生產(chǎn)中，測試是被定義為“檢驗產(chǎn)品是否滿足預定需求”的生產(chǎn)過程，而軟件測試是伴隨著軟件產(chǎn)生而產(chǎn)生的，一為驗證軟件的功能，二為發(fā)現(xiàn)軟件存在的缺陷問題，以盡量減少軟件中的錯誤和不足。隨著軟件產(chǎn)業(yè)的日益

2、發(fā)展和軟件工程規(guī)范化的要求，測試是最有效的消除和預防軟件缺陷和軟件故障的手段。1.1軟件測試基礎軟件軟件工程軟件生命周期1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎1.軟件 軟件(Software)是一系列按照特定順序組織的計算機數(shù)據(jù)和指令的集合。一般分為系統(tǒng)軟件、應用軟件和介于這兩者之間的中間件。 (1)系統(tǒng)軟件 (2)應用軟件 (3)介于兩者之間的中間件 1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎1.軟件 軟件(Software)是一系列按照特定順序組織的計算機數(shù)據(jù)和指令的集合。一般分為系統(tǒng)軟件、應用軟件和介于這兩者之間的中間件。 (4)通常情

3、況下，軟件應包含如下內(nèi)容： 可以在計算機上運行的程序集合。 程序能夠妥善處理信息的數(shù)據(jù)結(jié)構(gòu)。 與這些程序相關的文檔集合。1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎2.軟件工程 從20世界50年代初至今，軟件的發(fā)展大致經(jīng)歷了四個階段，軟件工程這個概念是1968年在聯(lián)邦德國召開北大西洋公約組織的計算機科學家國際會議上討論“軟件危機”問題時正式被使用的，標志著軟件工程的誕生。伴隨著軟件產(chǎn)業(yè)的發(fā)展以及在學術界的推動下，目前，軟件工程已經(jīng)發(fā)展成為一門專業(yè)的學科了。 目前比較認可的一種定義認為：軟件工程是研究和應用如何以系統(tǒng)性的、規(guī)范化的、可定量的過程化方法去開發(fā)和維護軟件，以及如

4、何把經(jīng)過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結(jié)合起來，得到軟件生命周期的六個步驟：制訂計劃、需求分析、設計、編碼、測試和運行維護。 1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎3.軟件生命周期 軟件生命周期(Software Life Cycle,SLC)，也叫軟件生存期，是軟件從孕育、誕生、成長、成熟到衰亡的一個過程，。 軟件生命周期的六個步驟：制訂計劃、需求分析、設計、編碼、測試以及運行維護，這個過程是一個自頂向下逐步細化的過程；其中測試是保證軟件質(zhì)量的重要手段，測試的過程恰恰是一個相反的過程，是一個自底向上逐步集成的過程，低一級的測試為上一級測

5、試準備條件。1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎3.軟件生命周期 軟件工程中一般用軟件生命周期模型來表示和反映軟件生命周期內(nèi)的各個活動，根據(jù)不同的開發(fā)模式，模型的表示也不一樣，常見的模型有：邊做邊改模型(BuildandFix Model)瀑布模型(Waterfall Model)快速原型模型(Rapid Prototype Model)增量模型(Incremental Model)螺旋模型(Spiral Model)演化模型(Evolution Model)噴泉模型(Fountain Model)智能模型(四代技術(4GL)混合模型(Hybrid Model)快

6、速應用開發(fā)模型(RAD)1.1.1軟件、軟件工程、軟件生命周期的基本概念1.1軟件測試基礎1.軟件缺陷 (1)軟件缺陷的定義 在軟件工程或軟件測試中，對于軟件存在的問題，都可以稱為軟件缺陷或軟件故障。作為一名測試人員，可能發(fā)現(xiàn)的缺陷很多情況下都沒有上面所舉的案例那么顯明，但是其任務就是發(fā)現(xiàn)軟件中所隱藏的錯誤，包括常常用到的以下幾種術語： 異常(Anomaly)、事件(Incident)、偏差(Variance)、漏洞(Bug)，主要是指未按預先設計的運行，并不代表軟件失敗; 而故障(Fault)、失敗(Failure)、缺陷(Defect)則代表比較嚴重的情況，甚至危險的情況。1.1.2軟件缺

7、陷與軟件可靠性1.1軟件測試基礎1.軟件缺陷 對于軟件缺陷的，至少滿足下列五種情況之一，才稱為發(fā)生了一個軟件缺陷(Software Bug)： 軟件未實現(xiàn)產(chǎn)品規(guī)格說明書要求的功能。 軟件出現(xiàn)了產(chǎn)品規(guī)格說明書中明確不會出現(xiàn)的錯誤。 軟件實現(xiàn)了產(chǎn)品規(guī)格說明書中沒有提到的功能。 軟件未實現(xiàn)產(chǎn)品規(guī)格說明書中雖未明確提及但是應該實現(xiàn)的功能。 軟件難以理解、不易使用、運行緩慢或者讓最終用戶認為不好。1.1.2軟件缺陷與軟件可靠性1.1軟件測試基礎1.軟件缺陷(2)軟件缺陷產(chǎn)生的原因 軟件自身因素 軟件開發(fā)團隊因素 開發(fā)技術因素 項目管理因素1.1.2軟件缺陷與軟件可靠性1.1軟件測試基礎1.軟件缺陷(3)

8、軟件缺陷修復的費用 軟件缺陷所帶來的修復費用是隨著時間的推移而呈指數(shù)級別遞增的，如圖所示，即：隨著時間的推移，修復費用呈十倍、百倍、千倍甚至萬倍的增長。1.1.2軟件缺陷與軟件可靠性1.1軟件測試基礎2.軟件可靠性(1)軟件可靠性定義 軟件可靠性(Software Reliability)是軟件產(chǎn)品在規(guī)定的條件下和規(guī)定的時間區(qū)間完成規(guī)定功能的能力。規(guī)定的條件是指直接與軟件運行相關的使用該軟件的計算機系統(tǒng)的狀態(tài)和軟件的輸入條件，或統(tǒng)稱為軟件運行時的外部輸入條件；規(guī)定的時間區(qū)間是指軟件的實際運行時間區(qū)間；規(guī)定功能是指為提供給定的服務，軟件產(chǎn)品所必須具備的功能。軟件可靠性不但與軟件存在的缺陷和差錯有

9、關，而且與系統(tǒng)輸入和系統(tǒng)使用有關。軟件可靠性的概率度量稱軟件可靠度。1.1.2軟件缺陷與軟件可靠性1.1軟件測試基礎2.軟件可靠性(2)影響軟件可靠性的因素 軟件可靠性是關于軟件能夠滿足需求功能的性質(zhì)，軟件不能滿足需求是因為軟件中的差錯引起了軟件故障。 軟件差錯是軟件開發(fā)各階段潛入的人為錯誤，除了軟件可靠性外，影響可靠性的另一個重要因素是健壯性，對非法輸入的容錯能力。所以提高可靠性從原理上看就是要減少錯誤和提高健壯性。 1983年，美國IEEE計算機學會對“軟件可靠性”做出了明確的定義，該定義包含兩個方面的內(nèi)容：在規(guī)定的條件下和時間內(nèi)，軟件不引起系統(tǒng)失效的概率。在規(guī)定的時間周期內(nèi)，在所述條件下

10、程序執(zhí)行所要求的功能的能力。 其中，概率是系統(tǒng)輸入和系統(tǒng)使用的函數(shù)，也是軟件中存在的故障的函數(shù)，系統(tǒng)輸入將確定是否會遇到已存在的故障(如果故障存在的話)。1.1.2軟件缺陷與軟件可靠性1.1軟件測試基礎 概括地說，軟件質(zhì)量就是“軟件與明確的和隱含的定義的需求相一致的程度”。 具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準以及所有專業(yè)開發(fā)的軟件都應具有的和隱含特征相一致的程度。1.1.3軟件質(zhì)量與質(zhì)量保證1.1軟件測試基礎1.影響軟件質(zhì)量的主要因素 通常情況下，影響軟件質(zhì)量的因素是從管理角度對軟件質(zhì)量進行度量?？蓜澐譃槿M，分別反映用戶在使用軟件產(chǎn)品時的三種觀點。

11、 正確性、健壯性、效率、完整性、可用性、風險(產(chǎn)品運行)。 可理解性、可維修性、靈活性、可測試性(產(chǎn)品修改)。 可移植性、可再用性、互運行性(產(chǎn)品轉(zhuǎn)移)。1.1.3軟件質(zhì)量與質(zhì)量保證1.1軟件測試基礎2.軟件質(zhì)量標準 軟件需求是度量軟件質(zhì)量的基礎，與需求不一致就是質(zhì)量不高。 指定的標準定義了一組指導軟件開發(fā)的準則，如果沒有遵守這些準則，肯定會導致質(zhì)量不高。 通常，有一組沒有顯式描述的隱含需求(如期望軟件是容易維護的)。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。1.1.3軟件質(zhì)量與質(zhì)量保證1.1軟件測試基礎3.軟件質(zhì)量保證 軟件質(zhì)量保證(SQA)，是軟件質(zhì)

12、量管理這個龐大、復雜系統(tǒng)中的一個分支，與質(zhì)量計劃、質(zhì)量控制合稱為質(zhì)量管理的過程域。企業(yè)必須借助專業(yè)、高效的質(zhì)量管理方法和測試工具，從管理和技術兩方面雙管齊下，才能實現(xiàn)軟件質(zhì)量管理這個目標。質(zhì)量保證是貫穿整個項目生命周期的有計劃、有步驟地對整個項目質(zhì)量計劃執(zhí)行情況進行評估、檢查與改進的工作，目的是向管理者、客戶提供信任，以此確保項目質(zhì)量與技術一致。1.1.3軟件質(zhì)量與質(zhì)量保證 軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的，起初軟件開發(fā)時期20世紀50年代后期20世紀70年代末20世紀90年代 而在軟件測試工具平臺方面，目前商業(yè)化的軟件測試工具也很多。 由此可見，測試在軟件開發(fā)過程中，已經(jīng)不再是基于代碼而進

13、行的活動，軟件測試是一個基于整個軟件生命周期的質(zhì)量控制活動，并始終貫穿于軟件開發(fā)的各個階段。1.2軟件測試發(fā)展史和發(fā)展前景 1.3.1軟件測試的目的 軟件測試是指使用人工或者自動化工具來運行或測試某個系統(tǒng)的過程，其目的在于檢驗被試系統(tǒng)是否滿足產(chǎn)品需求規(guī)格說明中所規(guī)定的要求或者弄清預期結(jié)果與實際結(jié)果之間的差別，以便及時修正和改進。 軟件測試是一個系列過程活動，是幫助識別開發(fā)完成計算機軟件的正確度、完全度和質(zhì)量的軟件過程，是軟件質(zhì)量保證的重要手段。1.3軟件測試的目的、原則和相關標準 1.3.1軟件測試的目的 軟件測試的目的應包含如下內(nèi)容： 測試并不僅僅是找出錯誤，而是通過分析錯誤產(chǎn)生的原因和錯誤

14、發(fā)生的趨勢，從而幫助項目管理者發(fā)現(xiàn)軟件當前存在的缺陷，以便及時改進。 測試分析可以有效幫助測試人員設計有效的針對性測試方法，提高測試的有效性。 沒有發(fā)現(xiàn)錯誤的測試也是有價值的測試，完整的測試是評價軟件質(zhì)量的方法之一。 1.3軟件測試的目的、原則和相關標準 1.3.2軟件測試的原則 軟件測試的基本原則有助于測試人員進行高效的測試，盡早盡多地發(fā)現(xiàn)軟件存在的缺陷和錯誤，通過分析軟件存在的問題，從而能夠持續(xù)改進測試過程，保證軟件質(zhì)量。 (1)測試要盡早介入 (2)測試要能顯示缺陷的存在 (3)不存在窮盡測試 (4)測試的群集性1.3軟件測試的目的、原則和相關標準 1.3.2軟件測試的原則 軟件測試的基

15、本原則有助于測試人員進行高效的測試，盡早盡多地發(fā)現(xiàn)軟件存在的缺陷和錯誤，通過分析軟件存在的問題，從而能夠持續(xù)改進測試過程，保證軟件質(zhì)量。 (5)測試用例設計避免“殺蟲劑”效應 (6)測試要嚴格按測試計劃執(zhí)行 (7)測試必須貫穿于軟件整個生命周期 (8)測試需要獨立的測試團隊或使用第三方測試1.3軟件測試的目的、原則和相關標準1.3.3軟件測試的相關標準1.3軟件測試的目的、原則和相關標準編號標準代碼標準名稱01GB/T 17544-1998信息技術軟件包質(zhì)量要求和測試02GB/T 16260-2006軟件工程產(chǎn)品質(zhì)量03GB/T 18905-2002軟件工程產(chǎn)品評價04GB/T 15532-2

16、008計算機軟件測試規(guī)范05GB/T 17544-1998信息技術軟件包質(zhì)量要求和測試06GB/T 8567-2006計算機軟件文檔編制規(guī)范07GB/T 9386-2008計算機軟件測試文檔編制規(guī)范08GB/T 25000.1-2010軟件工程軟件產(chǎn)品質(zhì)量要求與評價（SQuaRE）SQuaRE指南09CSTCJSBZ02應用軟件產(chǎn)品測試規(guī)范10CSTCJSBZ03軟件產(chǎn)品測試評分標準1.4.1測試人員的基本素質(zhì) 1.良好的溝通能力 2.掌握全面的技術 3.要具備充分的自信心、足夠的耐心和責任感 4.具有懷疑精神 5.超強的洞察力和記憶力1.4軟件測試人員1.4軟件測試人員1.4軟件測試人員1.

17、4.2軟件測試人員需具備的思維方式 1.逆向思維方式 2.組合思維方式 3.全局思維方式 4.兩極思維方式 5.簡單思維方式 6.比較思維方式1.4.3軟件測試工程師職位簡介初級測試工程師測試工程師/程序分析師高級測試工程師/程序分析師測試組負責人測試/編程負責人測試/質(zhì)量保證/開發(fā)(項目)經(jīng)理計劃經(jīng)理1.4軟件測試人員1.4軟件測試人員軟件測試概述1.簡述軟件測試的目的。2.軟件缺陷的定義和劃分。3.簡述軟件測試的原則和意義。4.簡述軟件測試工程師應具備的基本素質(zhì)和思維方式。知識總結(jié)與課后思考THANKS!本章結(jié)束！實用軟件測試技術第2章 軟件測試技術內(nèi)容簡介軟件測試原理及分類白盒測試相關技

18、術黑盒測試相關技術其他測試技術本章導讀本章導讀軟件測試涉及技術、管理等多個層面的內(nèi)容，為了更好地實施軟件測試，必須了解測試的基本原理、分類和相關測試技術。本章從技術層面系統(tǒng)介紹軟件測試過程中用到的測試方法和技術。2.1軟件測試技術概述 軟件測試是指使用人工方式或者自動化工具運行測試被測對象(軟件系統(tǒng))的過程，目的在于驗證被測對象是否滿足需求說明書中規(guī)定的內(nèi)容和功能，盡早發(fā)現(xiàn)軟件存在的缺陷。 軟件測試是軟件質(zhì)量保證的重要手段，其目標就是以最少的時間和人力盡早找出軟件潛在的各種錯誤和缺陷，證明軟件的功能和性能與需求說明相符。此外，實施測試收集到的測試結(jié)果數(shù)據(jù)也可為可靠性分析提供依據(jù)。2.1軟件測試

19、技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 2.按執(zhí)行狀態(tài)分 3.按執(zhí)行主體分 4.按測試技術分 5.按執(zhí)行是否需要人工干預分 6.其他測試類型2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 軟件測試貫穿于軟件開發(fā)的整個生命周期，按照軟件開發(fā)的階段，軟件測試分為單元測試、集成測試、確認測試、系統(tǒng)測試、驗收測試等。 (1)單元測試 (2)集成測試 (3)確認測試 (4)系統(tǒng)測試 (5)驗收測試 2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 (1)單元測試 單元測試(Unit Testing)又稱為模塊測試(Module Testing)，

20、是軟件測試對象中的最小可測單元，目的是檢查每個單元是否正確實現(xiàn)了詳細設計文檔中定義的功能、性能、接口等要求，以便發(fā)現(xiàn)各個模塊內(nèi)部可能出現(xiàn)的各種錯誤和缺陷，保證了最小單元的代碼準確，會令設計更好，大大減少花在調(diào)試上的時間。 單元測試通常是在軟件開發(fā)人員編碼后進行的，一般是開發(fā)人員互換模塊進行交叉測試，但是實際上在不正規(guī)的軟件開發(fā)團隊中，單元測試都由開發(fā)人員自己來完成。大部分軟件測試方法都適用于單元測試。 2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 (2)集成測試 集成測試(Integration Testing)又稱為組裝測試?；趩卧獪y試后的單元模塊，依據(jù)概要設計文檔

21、，對通過單元測試的模塊組裝為系統(tǒng)或子系統(tǒng)進行測試，其目的是檢驗不同模塊單元之間的接口是否符合概要設計的要求，能否正常運行。與單元測試相比，集成測試則關注的是單元模塊的外部接口。2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 (3)確認測試 確認測試(Conformation Testing)是通過檢驗和提供客觀證據(jù)，證實軟件是否滿足特定預期用途的需求。確認測試檢測以證實軟件是否滿足軟件需求說明書中規(guī)定的要求。 (4)系統(tǒng)測試 系統(tǒng)測試(System Testing)是為了驗證和確認系統(tǒng)是否達到了預期的功能和目標，主要由測試工程師進行測試，分為功能測試和性能測試。2.1軟件

22、測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 (5)驗收測試 驗收測試(Acceptance Testing)又稱為接受測試，是在系統(tǒng)測試后期，以用戶為主，測試人員和質(zhì)量保證人員共同輔助進行測試，驗證測試是軟件正式交付上線前的最后一個測試環(huán)節(jié)。 驗收測試依據(jù)軟件需求規(guī)格說明文檔和軟件驗收標準。驗收測試又分為測試和測試。2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 2.按執(zhí)行狀態(tài)分 按照被測軟件是否需要執(zhí)行，可將軟件測試分為靜態(tài)測試和動態(tài)測試。 (1)靜態(tài)測試 又稱為靜態(tài)分析(Static Analysis)，指不運行被測程序，而是分析和檢查程序的形式與結(jié)構(gòu)

23、，查找缺陷，進行需求確認。主要包括對源代碼、程序界面、各類文檔等進行測試，相當于是對被測程序進行特性分析。 (2)動態(tài)測試 又稱為動態(tài)分析(Dynamic Analysis)，是需要實際運行被測軟件程序的，通過運行時表現(xiàn)出的狀態(tài)、行為發(fā)現(xiàn)程序的錯誤與缺陷。運行時依據(jù)測試用例，對實際測試結(jié)果與預期結(jié)果進行對比分析，發(fā)現(xiàn)程序與客戶需求不一致的問題。2.1軟件測試技術概述2.1.1軟件測試分類 1.按照軟件開發(fā)階段分 2.按執(zhí)行狀態(tài) 動態(tài)測試貫穿在測試的各個階段中，是一種非常有效的測試方法， 比較 內(nèi)容測試方法是否運行軟件是否需要測試用例是否可以直接定位缺陷測試實現(xiàn)難易度精準性獨立性靜態(tài)測試否否是容

24、易否否動態(tài)測試是是否困難是是表2-1 靜態(tài)測試與動態(tài)測試比較2.1軟件測試技術概述2.1.1軟件測試分類 3.按執(zhí)行主體分 按照測試組織方劃分，軟件測試分為開發(fā)方測試、用戶測試和第三方測試。 開發(fā)方測試又稱為驗收測試或測試，在軟件開發(fā)環(huán)境下，測試軟件是否實現(xiàn)了需求規(guī)格說明中的功能，是否達到了要求的性能。用戶測試又稱為測試，在用戶的實際環(huán)境下，讓用戶使用、評價和檢查軟件，發(fā)現(xiàn)軟件存在的問題和缺陷，并做出相應的評價。第三方測試指由第三方測試機構(gòu)執(zhí)行測試，也稱為獨立測試。在測試組織、技術、管理上與開發(fā)方和用戶方都是獨立的，通常都是在模擬用戶實際使用環(huán)境下對軟件進行確認測試。2.1軟件測試技術概述2.

25、1.1軟件測試分類4.按測試技術分 按照對被測對象的了解程度和是否查看代碼，測試又分為：黑盒測試白盒測試灰盒測試2.1軟件測試技術概述2.1.1軟件測試分類4.按測試技術分 (1)黑盒測試 黑盒測試是將被測對象看作一個黑盒子，不考慮程序內(nèi)部的結(jié)構(gòu)和邏輯結(jié)構(gòu)，提供輸入，檢查輸出，主要檢查軟件的每個功能是否正常使用，屬于功能性測試。優(yōu)點：能從產(chǎn)品功能角度進行測試，確保從用戶角度出發(fā)，測試用例不因程序內(nèi)部邏輯變化而變化，測試人員容易上手。缺點：無法測試程序內(nèi)部，若規(guī)格說明有誤，錯誤無法發(fā)現(xiàn)，產(chǎn)品得不到充分性測試。應用范圍：等價類劃分法、邊界值分析法以及決策表測試。2.1軟件測試技術概述2.1.1軟件

26、測試分類4.按測試技術分 (2)白盒測試 與黑盒測試相反，白盒測試則要了解程序內(nèi)部和邏輯結(jié)構(gòu)，檢測內(nèi)部是否按照規(guī)格說明書的規(guī)定正常進行?；诖a測試的白盒測試，需要了解程序內(nèi)部的架構(gòu)、具體需求以及程序的編寫技巧，屬于驗證性結(jié)構(gòu)測試。優(yōu)點：可以針對程序內(nèi)部進行覆蓋測試，程序內(nèi)部可以得到充分性測試，有很多工具可以支持完成。缺點：不易生成測試數(shù)據(jù)，無法測試程序外部特性，工作量大，一般用于單元測試。應用范圍：語句覆蓋、條件覆蓋、判定覆蓋、路徑覆蓋等。2.1軟件測試技術概述2.1.1軟件測試分類4.按測試技術分 (3)灰盒測試 灰盒測試是介于白盒測試和黑盒測試之間的測試，相對于白盒測試，不需要關注詳細、

27、完整的內(nèi)部結(jié)構(gòu)，只需要測試各個組件間的邏輯關系是否正確?；液袦y試的重點在于測試程序的處理能力和健壯性，與白盒測試和黑盒測試相比，投入的時間和維護工作量較小。2.1軟件測試技術概述2.1.1軟件測試分類 5.按執(zhí)行是否需要人工干預分劃分 按照執(zhí)行測試時是否需要人工參與，可以將測試分為手工測試和自動化測試。 (1)手工測試 手工測試是指測試完全由人工完成，包括測試計劃制訂、測試用例編寫、執(zhí)行、測試結(jié)果分析等，傳統(tǒng)的測試工作都由人工來完成。 (2)自動化測試 與手工測試相比，自動化測試則是指測試所涉及的任何活動都由測試工具完成，包括測試腳本編寫、開發(fā)、執(zhí)行和管理，不需要人工干預，目前主要用于功能測試

28、、性能測試和回歸測試活動中。 2.1軟件測試技術概述2.1.1軟件測試分類 6.其他測試類型 除上面介紹的測試分類外，還有一些重要的測試，比如冒煙測試、回歸測試和隨機測試等。 (1)冒煙測試 冒煙測試(Smoking Testing)源自硬件行業(yè)，因為當電路板做好以后，加電測試，如果板子沒有冒煙再進行其他測試，否則就必須重新來過。如果類似的冒煙測試沒有通過，那么仍舊會返回給開發(fā)人員進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。多用于回歸測試中，優(yōu)點是節(jié)省測試時間，防止創(chuàng)建失敗，缺點則是覆蓋率偏低。2.1軟件測試技術概述2.1.1軟件測試分類 6.其他測試類型 (1)冒煙測試 (2)回

29、歸測試 回歸測試(Regression Testing)是指對軟件的新的版本測試時，重復執(zhí)行上一個版本測試時的用例。 (3)隨機測試 軟件測試中除了根據(jù)測試用例和測試說明書進行測試外，還需要進行隨機測試(Adhoctesting)，主要是根據(jù)測試者的經(jīng)驗對軟件進行功能和性能抽查。重點對一些特殊情況點、特殊環(huán)境并發(fā)性進行檢查。2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。 1.V模型 2.W模型 3.X模型 4.H模型 5.前置模型2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。

30、 1.V模型V模型示意圖2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。 2.W模型W模型示意圖2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。 3.X模型X模型示意圖2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。 4.H模型 H模型示意圖2.1軟件測試技術概述2.1.2軟件測試模型 軟件測試和軟件開發(fā)一樣，都遵循軟件工程原理，遵循管理學原理。 5.前置模型 前置測試模型是由Robin F Goldsmith等人提出的，

31、是一個將測試和開發(fā)緊密結(jié)合的模型，該模型提供了輕松的方式，可以使項目加快速度。有以下特點： (1)開發(fā)和測試相結(jié)合 (2)對每一個交付內(nèi)容進行測試 (3)在設計階段進行計劃和測試設計 (4)測試和開發(fā)結(jié)合在一起 (5)讓驗收測試和技術測試保持相互獨立 (6)反復交替的開發(fā)和測試 (7)發(fā)現(xiàn)內(nèi)在的價值 2.2 測試環(huán)境2.2.1測試環(huán)境定義 簡單地說，測試環(huán)境就是軟件運行的平臺，即進行軟件測試所必需的平臺和前提條件，可用如下公式來表示：測試環(huán)境=硬件+軟件+網(wǎng)絡+歷史數(shù)據(jù)2.2 測試環(huán)境2.2.2測試環(huán)境的重要性 測試環(huán)境的重要性主要體現(xiàn)在以下幾個方面： 1.加快測試速度 穩(wěn)定、可控的測試環(huán)境，

32、可以使測試人員花費較少的時間就能完成測試用例的執(zhí)行，也無須花費額外的時間在維護測試用例和測試過程上。 2.準確重現(xiàn)缺陷 穩(wěn)定、可控的測試環(huán)境可以讓被提交的缺陷在任何時刻都能準確地重現(xiàn)。 3.提高測試效率和保證軟件質(zhì)量 經(jīng)過良好規(guī)劃和管理的測試環(huán)境，可以盡可能地減少環(huán)境變動對測試工作的不利影響，并積極推動測試工作效率和質(zhì)量的提高。2.2 測試環(huán)境2.2.3良好測試環(huán)境的要素 具備良好的測試環(huán)境三要素： 1.良好的測試模型 2.多樣化的系統(tǒng)配置 3.熟練使用各種工具的測試人員2.2 測試環(huán)境2.2.3良好測試環(huán)境的要素 具備良好的測試環(huán)境三要素： 1.良好的測試模型 2.多樣化的系統(tǒng)配置 3.熟練

33、使用各種工具的測試人員2.2 測試環(huán)境2.2.5測試環(huán)境的維護和管理 測試環(huán)境搭建好后，為減少被測應用的每次版本發(fā)布對測試環(huán)境產(chǎn)生的影響。為此，需考慮如下問題： 1.設置專門的測試環(huán)境管理員角色 2.明確測試環(huán)境管理所需的各種文檔 3.測試環(huán)境訪問權(quán)限的管理 4.測試環(huán)境的變更管理 5.測試環(huán)境的備份和恢復2.3 白盒測試 白盒測試(WhiteBox Testing)，又稱為結(jié)構(gòu)測試、邏輯測試或基于程序的測試，是軟件測試技術中最為有效和實用的測試方法之一。 白盒測試的目的：通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu)，對軟件中的邏輯路徑進行覆蓋測試;在程序不同地方設立檢查點，檢查程序的狀態(tài)，以確定實際運行狀態(tài)與

34、預期狀態(tài)是否一致。 白盒測試的測試方法總體上分為：靜態(tài)方法動態(tài)方法2.3 白盒測試 采用白盒測試方法必須遵循以下幾條原則，才能達到測試目的。 保證一個模塊中的所有獨立路徑至少被測一次。 所有邏輯值均需測試真(True)和假(False)兩個分支。 檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，保證其結(jié)構(gòu)的有效性。 在上下邊界及可操作范圍內(nèi)運行所有循環(huán)。 在白盒測試中，一般會用覆蓋率來度量測試的完整性。測試覆蓋率是程序被一組測試用例執(zhí)行的百分比。覆蓋率=(至少被執(zhí)行一次的被測項)/被測項總數(shù)2.3 白盒測試 2.3.1邏輯覆蓋測試 邏輯覆蓋測試法是白盒測試中以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎的設計測試用例的技術方法，目的是測

35、試程序中的判定和條件。測試程序邏輯結(jié)果通常需要通過使用控制流覆蓋準則來度量測試的進行程度。 根據(jù)覆蓋目標的不同和覆蓋源程序語句的詳盡程度，邏輯覆蓋又可以分為： 語句覆蓋 判定覆蓋 條件覆蓋 條件/判定覆蓋 條件組合覆蓋 修正條件/判定覆蓋2.3 白盒測試 2.3.1邏輯覆蓋測試 1.語句覆蓋(Statement Coverage，SC) 語句覆蓋就是設計若干測試用例運行被測程序，使得程序中每一可執(zhí)行語句至少被執(zhí)行一次。其中“若干”的意思，就是說使用的測試用例越少越好。語句覆蓋在測試中主要發(fā)現(xiàn)缺陷或錯誤語句。 語句覆蓋率的公式：語句覆蓋率(SCP)=被評價到的語句數(shù)量/可執(zhí)行的語句總數(shù)100%缺

36、點：對程序執(zhí)行邏輯的覆蓋很低。2.3 白盒測試 2.3.1邏輯覆蓋測試 2.判定覆蓋(Decision Coverage，DC) 判定覆蓋也稱為分支覆蓋，設計若干測試用例，運行被測程序，使得每個判定分支的取真(True)和取假(False)至少被執(zhí)行一次。 判定路徑覆蓋率的公式：判定路徑覆蓋率(DCP)=被判定到的路徑數(shù)/判定路徑總數(shù)100%優(yōu)點：判定覆蓋比語句覆蓋至少多出一倍的測試路徑，自然比語句覆蓋的測試能力強大一些。缺點：判定覆蓋雖然把程序所有分支都覆蓋了，但主要對整個表達式進行取值，忽略了表達式內(nèi)部取值。2.3 白盒測試 2.3.1邏輯覆蓋測試 3.條件覆蓋(Condition Cov

37、erage，CC) 條件覆蓋要求能夠保證程序中每個復合判定表達式的每個簡單判定條件的取真(True)和取假(False)至少被執(zhí)行一次。與判定覆蓋相比較，條件覆蓋增加了對符合判定情況的測試，增加了測試路徑。要達到條件覆蓋就得有足夠多的測試用例，滿足了條件覆蓋不一定能保證滿足判定覆蓋和語句覆蓋。2.3 白盒測試 2.3.1邏輯覆蓋測試 4.條件/判定覆蓋(Condition/Decision Coverage，C/DC) 條件/判定覆蓋是指設計足夠的測試用例，使得判定中的每個條件的所有可能(真/假)至少出現(xiàn)一次，并且每個判定本身的判定結(jié)果也至少出現(xiàn)一次。 條件/判定覆蓋公式： 條件/判定覆蓋率(

38、C/DCP)=被判定到的條件取值和判定分支的數(shù)量/(條件取值總數(shù)+判定分支總數(shù))100%缺點：沒有考慮到單個判定對整體結(jié)果的影響，無法發(fā)現(xiàn)邏輯錯誤。2.3 白盒測試 2.3.1邏輯覆蓋測試 5.條件組合覆蓋(Condition Combination Coverage，CCC) 條件組合覆蓋也稱為多條件覆蓋，是指設計足夠多的測試用例，使得每個判定中條件的各自可能組合至少出現(xiàn)一次。滿足條件組合覆蓋一定滿足判定覆蓋、條件覆蓋和條件/判定覆蓋。 條件組合覆蓋公式：條件組合覆蓋率(CCCP)=被判定到的條件取值組合的數(shù)量/條件取值組合的總數(shù)100%缺點：當判定語句較多時，條件組合值比較多。2.3 白盒

39、測試 2.3.1邏輯覆蓋測試 6.修正條件/判定覆蓋(Modified Condition/Decision Coverage，MD/CC) 修正條件/判定覆蓋要求判定(由條件和零個或多個布爾操作符組成的布爾表達式)中的每一個條件(不含布爾操作符的布爾表達式)的所有可能結(jié)果至少出現(xiàn)一次。每個判斷的所有結(jié)果至少出現(xiàn)一次，每個程序模塊的入口點和出口點都至少被調(diào)用一次，且每個條件都能單獨影響判定的結(jié)果。2.3 白盒測試 2.3.2基本路徑測試 基本路徑測試法就是在程序控制流圖的基礎上，通過分析控制構(gòu)造的環(huán)路復雜度，導出基本可以執(zhí)行路徑集合，從而設計測試用例的方法。設計的測試用例要保證在測試程序中的每

40、個可執(zhí)行語句至少被執(zhí)行一次。 基本路徑測試方法包括以下四個步驟：根據(jù)程序設計畫出程序的控制流圖(控制流圖是描述程序控制流的一種圖示方法)。計算程序的環(huán)路復雜度。通過環(huán)路復雜度可以導出程序基本路徑集合中的獨立路徑條數(shù)，由此可以確定每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上限。導出基本路徑集，確定程序的獨立路徑。設計測試用例，確?；韭窂郊忻恳粭l路徑的執(zhí)行。2.3 白盒測試 2.3.2基本路徑測試 控制流圖是描述程序控制流的一種圖示方法。只用兩種符號即可描述。圓圈用來描述節(jié)點，代表一條或者多條無分支的語句；箭頭代表控制流，稱為邊或連接。2.3 白盒測試 2.3.2基本路徑測試 在將程序流

41、程圖簡化為控制流圖時，應重點注意以下問題： 在選擇或多分支結(jié)構(gòu)中，分支的匯聚處應有一個匯聚點。 邊和節(jié)點圍成的圈稱為區(qū)域，當對區(qū)域計數(shù)時，圖形外的區(qū)域也應記為一個區(qū)域。 如果判斷中的條件表達式是由一個或多個邏輯運算符(OR、AND、NAND、NOR)連接的復合條件表達式時，則需要改為一系列只有單條件的嵌套的判斷。2.3 白盒測試2.3.3白盒測試策略 在軟件開發(fā)過程的不同階段，研發(fā)組可能都需要進行白盒測試。使用白盒測試技術進行測試的策略如下：在測試中，應盡量先用測試工具進行靜態(tài)結(jié)構(gòu)分析。在測試中，可以采用先靜態(tài)后動態(tài)的組合方式，先進行靜態(tài)結(jié)構(gòu)分析、代碼檢查和靜態(tài)質(zhì)量度量，再進行覆蓋率測試。利用

42、靜態(tài)分析的結(jié)果作為引導，通過代碼檢查和動態(tài)測試的方式對靜態(tài)分析結(jié)果進一步確認，使測試工作更為有效。覆蓋率測試是白盒測試的重點，一般可以使用獨立路徑測試法達到語句覆蓋標準；對于軟件重點模塊，應使用多種覆蓋率標準衡量代碼的覆蓋率。在不同的測試階段，測試的側(cè)重點會有所不同。在單元測試階段，以代碼檢查、邏輯覆蓋為主；在集成測試階段，需要增加靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量；在系統(tǒng)測試階段，應根據(jù)黑盒測試的結(jié)果，采取相應的白盒測試。2.3 白盒測試2.3.3白盒測試策略 在軟件開發(fā)過程的不同階段，研發(fā)組可能都需要進行白盒測試。使用白盒測試技術進行測試的策略如下：在測試中，應盡量先用測試工具進行靜態(tài)結(jié)構(gòu)分析。在

43、測試中，可以采用先靜態(tài)后動態(tài)的組合方式，先進行靜態(tài)結(jié)構(gòu)分析、代碼檢查和靜態(tài)質(zhì)量度量，再進行覆蓋率測試。利用靜態(tài)分析的結(jié)果作為引導，通過代碼檢查和動態(tài)測試的方式對靜態(tài)分析結(jié)果進一步確認，使測試工作更為有效。覆蓋率測試是白盒測試的重點，一般可以使用獨立路徑測試法達到語句覆蓋標準；對于軟件重點模塊，應使用多種覆蓋率標準衡量代碼的覆蓋率。在不同的測試階段，測試的側(cè)重點會有所不同。在單元測試階段，以代碼檢查、邏輯覆蓋為主；在集成測試階段，需要增加靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量；在系統(tǒng)測試階段，應根據(jù)黑盒測試的結(jié)果，采取相應的白盒測試。2.3 白盒測試2.3.3白盒測試策略 下面是策略的一種：(1)自我檢查簡

44、述：程序員實現(xiàn)制定功能后，在進行單元測試之前，對源代碼進行初步檢查。重點：語句的使用等是否符合編碼規(guī)范，并根據(jù)編碼規(guī)范調(diào)整自己的代碼以符合編碼規(guī)范的要求。參與人員：開發(fā)人員。2.3 白盒測試2.3.3白盒測試策略 下面是策略的一種： (2)單元測試簡述：又稱模塊測試。在傳統(tǒng)結(jié)構(gòu)化編程中，以一個函數(shù)、過程為一個單元；在面向?qū)ο蟮木幊讨?，一般把類作為單元進行測試。重點：采用白盒測試和黑盒測試相結(jié)合的方法。參與人員：專門的白盒測試人員。方法：大家共同閱讀代碼或由程序編寫者講解代碼，同其他同行邊聽邊分析問題。參與人員：全體開發(fā)小組。2.3 白盒測試2.3.3白盒測試策略 下面是策略的一種： (3)代碼

45、評審簡述：在編碼初期或編寫過程中采用一種有同行參與的評審活動。重點：通過組織或同其他程序員共同查看程序，可以找出問題，使大家的代碼風格一致或遵守編碼規(guī)范。方法：大家共同閱讀代碼或由程序編寫者講解代碼，同其他同行邊聽邊分析問題。參與人員：全體開發(fā)小組。2.3 白盒測試2.3.3白盒測試策略 下面是策略的一種： (4)同行評審簡述：引用CMM(能力成熟度模型)中的術語，如用在評審源代碼上，就是代碼評審；在同行評審中，由軟件工作產(chǎn)品創(chuàng)建者的同行們檢查該工作的產(chǎn)品，識別產(chǎn)品的缺陷，改進產(chǎn)品的不足。目的：檢驗工作產(chǎn)品是否滿足了以往的工作產(chǎn)品中建立的規(guī)范，如需求或設計文檔；識別工作產(chǎn)品相對于標準的偏差，包

46、括可能影響軟件可維護性的問題；向創(chuàng)建者提出改進建議；促進參與者之間的技術交流和學習。參與人員：程序員、設計師、單元測試工程師、維護者、需求分析師、編碼標準專家(此為CMM標準中提出的參與角色，可根據(jù)實際情況調(diào)整，至少需要開發(fā)人員、測試人員、設計師參與)。2.3 白盒測試2.3.3白盒測試策略 下面是策略的一種： (5)代碼走查簡述：由測試小組組織或者專門的代碼走查小組進行代碼走查，這時需要開發(fā)人員提交有關的資料文檔和源代碼給走查人員，并進行必要的講解。代碼走查往往根據(jù)代碼檢查單來進行，代碼檢查單常常是根據(jù)編碼規(guī)范總結(jié)出來的一些條目。目的：檢查代碼是否是按照編碼規(guī)范來編寫的。當然，代碼走查的最終

47、目的還是為了發(fā)現(xiàn)代碼中潛在的錯誤和缺陷。重點：把材料(需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準、代碼缺陷檢查表等)發(fā)給走查小組每個成員，讓他們認真研究程序。參與人員：測試人員(一般不讓代碼的創(chuàng)建者參與)。代碼檢查速度建議：C代碼 150行/小時，C+/Java 200300行/小時。2.4黑盒測試2.4黑盒測試 黑盒測試(BlackBox Testing)，也稱為功能測試、行為測試或數(shù)據(jù)驅(qū)動測試，是軟件測試中最為重要的基本測試方法之一。在軟件測試的過程中占有非常重要的地位。黑盒測試的基本方法有等價類劃分法、邊界值分析法、決策表法和因果圖法等。 黑盒測試屬于功能測試，是從用戶角

48、度出發(fā)，依據(jù)規(guī)格說明書，重點測試軟件的功能需求，對程序功能和接口進行測試，發(fā)現(xiàn)以下錯誤：功能不正確或有遺漏。界面不符合規(guī)格說明書要求。數(shù)據(jù)結(jié)構(gòu)錯誤或訪問數(shù)據(jù)庫錯誤。性能是否滿足需求。初始化和終止錯誤。2.3黑盒測試2.4黑盒測試 黑盒測試以規(guī)格說明書為依據(jù)，關注的是程序的功能是否都已經(jīng)實現(xiàn)，每個功能是否都能正常使用，滿足用戶的需求。 黑盒測試的步驟如下： 1.測試計劃 根據(jù)需求說明書中描述的功能和性能指標的規(guī)格說明書定義測試計劃，后續(xù)的測試工作都依據(jù)該計劃執(zhí)行，計劃包括測試內(nèi)容、選擇的方法、人員安排、測試時間以及相關資源配置等。 2.測試設計 依據(jù)測試計劃，分解、細化測試執(zhí)行過程，結(jié)合測試方法

49、為每個測試任務編寫測試用例。2.4黑盒測試2.4黑盒測試 黑盒測試以規(guī)格說明書為依據(jù)，關注的是程序的功能是否都已經(jīng)實現(xiàn)，每個功能是否都能正常使用，滿足用戶的需求。 黑盒測試的步驟如下： 3.測試開發(fā) 建立可重復使用的測試用例或者開發(fā)用于自動化測試的測試腳本。 4.測試執(zhí)行 依照設計的測試用例執(zhí)行測試，并對發(fā)現(xiàn)的缺陷進行跟蹤和管理。 5.測試評估 結(jié)合量化的測試覆蓋率及測試缺陷跟蹤，對測試團隊的工作及軟件質(zhì)量做出綜合評價，并完成測試報告。2.4黑盒測試2.4 黑盒測試 黑盒測試的優(yōu)點與缺點 (1)優(yōu)點 針對性強，定位問題準確。 可以明確被測對象(軟件系統(tǒng)或產(chǎn)品)是否達到用戶要求的功能。 可以將測

50、試中性能測試的部分交由自動化工具完成。 (2)缺點 對測試人員要求較高，需要測試人員經(jīng)驗豐富、技術嫻熟。 大部分需要手工測試。 涉及大量文檔資料，需要測試人員去編制和管理。2.4黑盒測試2.4 黑盒測試 2.4.1等價類劃分法 等價類劃分法是黑盒測試中最典型的測試方法。等價類是指把程序的輸入集合劃分為若干個互不相交的子集。所謂等價類，是指輸入域的某個子集合，體現(xiàn)了完備性和冗余性的特點。從每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件，就可以用少量有代表性的測試數(shù)據(jù)取得較好的測試效果。2.4 黑盒測試2.4 黑盒測試 2.4.1等價類劃分法 1.等價類的兩種情況 等價類劃分有兩種情況，有效等價類和無

51、效等價類。 (1)有效等價類 有效等價類是指對軟件規(guī)格說明而言，是由合法且有意義的輸入數(shù)據(jù)組成的集合。利用有效等價類，可以檢驗程序是否實現(xiàn)了規(guī)格說明預先定義的功能和性能。 (2)無效等價類 無效等價類是指對軟件規(guī)格說明而言，是由不合理或無意義的輸入數(shù)據(jù)組成的集合。利用無效等價類，可以檢驗程序的實現(xiàn)是否有不符合規(guī)格說明預先定義的功能的地方。2.4 黑盒測試2.4 黑盒測試 2.4.1等價類劃分法 2.等價類劃分原則 (1)在輸入條件規(guī)定的取值范圍或值的個數(shù)確定的情況下，可以確定一個有效等價類和兩個無效等價類。 (2)在規(guī)定了輸入數(shù)據(jù)的一組值中(假定有n個值)，并且在程序要對每個輸入值分別處理的情

52、況下，可以確定n個有效等價類和一個無效等價類。 (3)在規(guī)定輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可以確定一個有效等價類和若干個無效等價類。 (4)在輸入條件規(guī)定了輸入值的集合或規(guī)定了“必須如何”的條件下，可以確定一個有效等價類和一個無效等價類。 (5)在確定已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應將該等價類進一步劃分為更小的等價類。2.4 黑盒測試2.4 黑盒測試 2.4.1等價類劃分法 3.等價類測試用例設計 (1)采用等價類劃分法設計測試用例的步驟： 按照輸入條件有效等價類無效等價類 建立等價類表，列出所有劃分出的等價類。 為每一個等價類規(guī)定唯一的編號。 設計一個新的測試用例

53、，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止。 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。2.4 黑盒測試2.4 黑盒測試 2.4.1等價類劃分法 3.等價類測試用例設計 (1)采用等價類劃分法設計測試用例的步驟： (2)實例分析 用等價類劃分法為下面程序進行測試用例設計。（略。）2.4 黑盒測試2.4.2邊界值分析法 1.邊界值分析法概述 邊界值分析法(Boundary Value Analysis，BVA)，是一種對等價類劃分法的補充技術，它的測試用例來源于等價類的邊界。根據(jù)實際經(jīng)驗

54、，大量的錯誤往往發(fā)生在輸入或輸出范圍的邊界上，而不是輸入、輸出的內(nèi)部。因此，針對邊界進行測試，有可能會發(fā)現(xiàn)更多的錯誤和缺陷。 在使用邊界值分析法設計測試用例時，首先要確定邊界，一般情況下，輸入和輸出的等價類邊界都是應該著重測試的邊界。選取剛好等于、大于或小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中典型值或任意值作為測試數(shù)據(jù)。2.4 黑盒測試2.4.2邊界值分析法 2.設計原則 在使用邊界值分析法設計測試用例時，應該遵循以下原則： 如果輸入條件規(guī)定了值的范圍,則應取剛達到這個范圍的邊界值，以及剛剛超越這個范圍邊界值作為測試輸入數(shù)據(jù)。 如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù)、最小個數(shù)、比最小個數(shù)

55、少1、比最大個數(shù)多1的數(shù)作為測試數(shù)據(jù)。 將規(guī)則和應用于輸出條件，即設計測試用例使輸出值達到邊界值及其左右的值。 如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例。 如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu),則應當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例。 分析規(guī)格說明，找出其他可能的邊界條件。2.4 黑盒測試2.4.3決策表法 1.決策表概述 決策表又稱判斷表，是一種呈表格狀的圖形工具，適用于描述處理判斷條件較多，各條件又相互組合、有多種決策方案的情況。精確而簡潔描述復雜邏輯的方式，將多個條件與這些條件滿足后要執(zhí)行的動作相對應。但不同于傳統(tǒng)程序語

56、言中的控制語句，決策表能將多個獨立的條件和多個動作之間的聯(lián)系清晰地表示出來。 決策表是軟件黑盒測試方法中邏輯性最強、最嚴格的測試方法，是分析多種邏輯條件下執(zhí)行不同操作的技術。在程序開發(fā)初期，決策表作為程序編寫的輔助工具來使用。使用決策表可以把復雜的邏輯關系和多種條件組合情況全部列舉并表達明確。因此,使用決策表法設計測試用例可以設計出完整的測試用例集合。2.4 黑盒測試2.4.3決策表法 1.決策表概述 決策表適合以下特征的應用程序： ifthenelse分支邏輯突出。 輸入變量之間存在邏輯關系。 涉及輸入變量子集的計算。 輸入與輸出之間存在因果關系。 很高的圈復雜度。2.4 黑盒測試2.4.3

57、決策表法2.決策表構(gòu)成決策表由四個部分組成，如圖所示。(1)條件樁 列出了問題的所有條件。(2)動作樁 列出了問題規(guī)定可能采取的操作。(3)條件項 列出針對它所列條件的取值，在所有可能情況下的真假值。(4)動作項 列出在條件項的各種取值情況下應該采取的動作。 規(guī)則:任何一個條件組合的特定取值及其相應要執(zhí)行的操作稱為規(guī)則。在決策表中，條件項和動作項的交叉列就是規(guī)則。顯然，決策表中列出多少組條件取值，就有多少規(guī)則。決策表中具有n個條件的有限條目決策表有2n個規(guī)則。2.4 黑盒測試2.4.3決策表法 3.決策表設計測試用例 使用決策表法設計測試用例的步驟：確定規(guī)則個數(shù)。列出所有的條件樁和動作樁。填入

58、條件項。填入動作樁和動作項，得到初始判定表?；啠喜⑾嗨埔?guī)則。依據(jù)判定表，選擇測試數(shù)據(jù)，設計測試用例。2.4 黑盒測試2.4.4因果圖法 因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。 因果圖法是從需求中找出因(輸入條件)和果(輸出或程序狀態(tài)的改變)，通過分析輸入條件之間的關系(組合關系、約束關系等)及輸入和輸出之間的關系繪制出因果圖，再轉(zhuǎn)化成判定表，從而設計出測試用例的方法，該方法主要適用于各種輸入條件之間存在某種相互制約關系或輸出結(jié)果依賴于各種輸入條件的組合時的情況。2.4 黑盒測試2.4.4因果圖法 1.4種符號在因果圖

59、中，使用4種符號表示4種因果關系，如圖所示。用直線連接左右節(jié)點。c1：原因(輸入狀態(tài))。e1：結(jié)果(輸出狀態(tài))。恒等：原因、結(jié)果同時出現(xiàn)。非：原因出現(xiàn)，結(jié)果不出現(xiàn)；原因不出現(xiàn)，結(jié)果出現(xiàn)?；颍涸虺霈F(xiàn)1個，結(jié)果就出現(xiàn)；原因都不出現(xiàn)，結(jié)果就不出現(xiàn)。且：原因都出現(xiàn)，結(jié)果才出現(xiàn)。2.4 黑盒測試2.4.4因果圖法2.4種約束 在實際問題中，為了表示原因與原因之間、結(jié)果與結(jié)果之間可能存在的約束條件，因果圖中還附加一些表示約束條件的符號，如圖所示。2.4 黑盒測試2.4.4因果圖法2.4種約束 約束符號亦包含多種類型，根據(jù)“從輸入考慮”和“從輸出考慮”兩方面進行歸類如下：(1)從輸入考慮E(互斥/異或)：

60、表示a、b兩原因不會同時成立，最多一個能成立。I(包含)：a、b、c三個原因中至少有一個必須成立。O(唯一)：a、b當中必須有一個，且僅有一個成立。R(要求)：當a出現(xiàn)時，b必須也出現(xiàn)；不可能a出現(xiàn)，b不出現(xiàn)。(2)從輸出考慮M(強制或屏蔽)：a是1時，b必須是0；a是0時，b的值不定。2.4 黑盒測試2.4.4因果圖法 3.因果圖設計測試用例 使用因果圖設計測試用例的步驟 分析軟件規(guī)格說明描述中哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結(jié)果(即輸出條件)，并給每個原因和結(jié)果賦予一個標識符。 分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應的關系，根據(jù)這些關系，畫出