軟件測試基本概念

軟件測試基本概念1第一頁，共四十六頁，編輯于2023年，星期一第1章回顧1.1軟件的含義1.2軟件開發(fā)過程模型1.3UML代表著軟件建模的發(fā)展趨勢1.4軟件測試的重要性2第二頁，共四十六頁，編輯于2023年，星期一第2章軟件測試的基本概念2.1軟件缺陷2.2驗(yàn)證和確認(rèn)2.3軟件測試的分類2.4測試模型2.5軟件測試的工作范疇3第三頁，共四十六頁，編輯于2023年，星期一缺陷是質(zhì)量的對立面要了解什么是缺陷(defect)，就必須清楚“質(zhì)量(Quality)”概念，因?yàn)槿毕菔窍鄬|(zhì)量而存在的，違背了質(zhì)量、違背了客戶的意愿，不能滿足客戶的要求，就會引起缺陷或產(chǎn)生缺陷。4第四頁，共四十六頁，編輯于2023年，星期一2.1軟件缺陷2.1.1軟件質(zhì)量的內(nèi)涵2.1.2軟件缺陷的定義2.1.3軟件缺陷的產(chǎn)生2.1.4軟件缺陷的構(gòu)成2.1.5修復(fù)軟件缺陷的代價(jià)5第五頁，共四十六頁，編輯于2023年，星期一軟件質(zhì)量

的內(nèi)涵1質(zhì)量(Quality)的概念在RUP(“Rational標(biāo)準(zhǔn)過程”理論)中，質(zhì)量被定義為：滿足或超出認(rèn)定的一組需求，并使用經(jīng)過認(rèn)可的評測方法和標(biāo)準(zhǔn)來評估，還使用認(rèn)定的流程來生產(chǎn)。RUP：RationalUnifiedProcess6第六頁，共四十六頁，編輯于2023年，星期一軟件質(zhì)量

的內(nèi)涵2軟件質(zhì)量的內(nèi)涵總結(jié)說來，高品質(zhì)軟件應(yīng)該是相對的無產(chǎn)品缺陷(bugfree)或只有極少量的缺陷，它能夠及時(shí)遞交給客戶，所花費(fèi)用都在預(yù)算內(nèi)，并且滿足客戶需求，是可維護(hù)的。但是，有關(guān)質(zhì)量好壞的最終評價(jià)依賴于用戶的反饋。7第七頁，共四十六頁，編輯于2023年，星期一高質(zhì)量軟件標(biāo)準(zhǔn)體系產(chǎn)品質(zhì)量是人們實(shí)踐產(chǎn)物的屬性和行為，是可以認(rèn)識，可以科學(xué)地描述的。并且可以通過一些方法和人類活動，來改進(jìn)質(zhì)量.質(zhì)量模型:McCall模型,Boehm模型,ISO9126模型過程質(zhì)量:

軟件能力成熟度模型

CMM(CapabilityMaturityModel).

國際標(biāo)準(zhǔn)過程模型

ISO9000

軟件過程改進(jìn)和能力決斷

SPICE(SoftwareProcessImprovementandCapabilitydEtermination)

在商業(yè)過程中有關(guān)的質(zhì)量內(nèi)容:

培訓(xùn)、成品制作、宣傳、發(fā)布日起、客戶、風(fēng)險(xiǎn)、成本等

8第八頁，共四十六頁，編輯于2023年，星期一產(chǎn)品質(zhì)量的標(biāo)準(zhǔn)-功能性

Functionality-可用性

Usability(簡單安裝;輕松使用;友好界面)-可靠性

Reliability(用戶使用的根本)-性能

Performance-容量

Capacity-可測量性

Scalability-可維護(hù)性

Servicemanageability-兼容性

Compatibility-可擴(kuò)展性

Extensibility9第九頁，共四十六頁，編輯于2023年，星期一軟件質(zhì)量特征

(ISO9126)

功能：與一組功能及其指定性質(zhì)有關(guān)的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。

可靠：在規(guī)定的一段時(shí)間和條件下，與軟件維持其性能水平的能力有關(guān)的一組屬性。

可用：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評價(jià)有關(guān)的一組屬性。

效率：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。

可維護(hù)：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。

可移植：與軟件從一個環(huán)境轉(zhuǎn)移到另一個環(huán)境的能力有關(guān)的一組屬性。

其中每一個質(zhì)量特征都分別與若干子特征相對應(yīng)。10第十頁，共四十六頁，編輯于2023年，星期一ISO9126軟件質(zhì)量三層模型-SQRC

軟件質(zhì)量需求評價(jià)準(zhǔn)則（高層）-SQDC軟件質(zhì)量設(shè)計(jì)評價(jià)準(zhǔn)則（中層）-SQMC軟件質(zhì)量度量評價(jià)準(zhǔn)則（低層）11第十一頁，共四十六頁，編輯于2023年，星期一McCall軟件質(zhì)量模型互用性正確性可靠性效率完整性可用性可維護(hù)性可測試性靈活性可移植性重復(fù)性闡述性數(shù)據(jù)公開性連貫性容錯性執(zhí)行效率/儲存效率存取控制/存取檢查可訓(xùn)練溝通良好簡單性易操作的工具自我操作性擴(kuò)展性一般性模塊性軟件系統(tǒng)獨(dú)立性機(jī)器獨(dú)立性通訊公開性正確性可操作性產(chǎn)品操作產(chǎn)品修改產(chǎn)品轉(zhuǎn)換12第十二頁，共四十六頁，編輯于2023年，星期一什么是Bug?2.1.2軟件缺陷的定義Anyproblem/disfigurement/limitationinproductdesign&development

Featureorfunctioncan’tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI,LowperformanceOthers任何程序、系統(tǒng)中的問題，和產(chǎn)品設(shè)計(jì)書的不一致性，不能滿足用戶的需求

13第十三頁，共四十六頁，編輯于2023年，星期一軟件缺陷IEEE(1983)729軟件缺陷一個標(biāo)準(zhǔn)的定義：

從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

14第十四頁，共四十六頁，編輯于2023年，星期一軟件開發(fā)描述圖15第十五頁，共四十六頁，編輯于2023年，星期一軟件缺陷軟件錯誤產(chǎn)生的可能原因是：需求規(guī)格說明書包含錯誤的需求、或漏掉一些需求，或沒有準(zhǔn)確表達(dá)客戶所需要的內(nèi)容需求規(guī)格說明書中有些功能不可能或無法實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)(systemdesign)中的不合理性程序設(shè)計(jì)中的錯誤程序代碼中的問題，包括錯誤的算法、復(fù)雜的邏輯等16第十六頁，共四十六頁，編輯于2023年，星期一軟件缺陷軟件缺陷的主要類型/現(xiàn)象：功能、特性沒有實(shí)現(xiàn)或部分實(shí)現(xiàn)設(shè)計(jì)不合理，存在缺陷實(shí)際結(jié)果和預(yù)期結(jié)果不一致運(yùn)行出錯，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂數(shù)據(jù)結(jié)果不正確、精度不夠用戶不能接受的其他問題，如存取時(shí)間過長、界面不美觀17第十七頁，共四十六頁，編輯于2023年，星期一軟件缺陷的種類:按照嚴(yán)重性級別的定義不盡相同，但一般可以概括為4種類型：致命的(fatal)：致命的錯誤，造成系統(tǒng)或應(yīng)用程序崩潰(crash)、死機(jī)、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。嚴(yán)重的(critical)：嚴(yán)重錯誤，指功能或特性沒有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失，提示信息不太準(zhǔn)確，或致命的錯誤聲明一般的(major)：不太嚴(yán)重的錯誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實(shí)現(xiàn)功能，沒有達(dá)到預(yù)期效果。如次要功能喪失，提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長微小的(minor)：一些小問題，對功能幾乎沒有影響，產(chǎn)品或?qū)傩匀钥墒褂茫缬袀€別錯別字、文字排列不整齊等。此外，有時(shí)還需要“建議(Suggestion)”級別來處理測試人員所提出的建議或質(zhì)疑。軟件缺陷18第十八頁，共四十六頁，編輯于2023年，星期一軟件缺陷的狀態(tài)軟件缺陷除了嚴(yán)重性以外，還存在反映軟件缺陷處于一種什么樣的狀態(tài)，便于跟蹤和管理某個產(chǎn)品的缺陷，可以定義不同的bug狀態(tài)：激活狀態(tài)(Active或Open)：問題沒有解決，測試人員新報(bào)的bug，或驗(yàn)證后bug依然存在已修正狀態(tài)(Fixed或Resolved)：開發(fā)人員針對所存在的缺陷，修改程序，認(rèn)為已解決問題，或通過單元測試關(guān)閉或非激活狀態(tài)(Close或Inactive)：測試人員驗(yàn)證fixedbug后，確認(rèn)bug不存在之后的狀態(tài)。此外，還有下面一些中間狀態(tài)：保留(Hold)：bug目前無法解決或是由第三方軟件產(chǎn)品引起的延期(Differed):bug暫時(shí)不需要解決或在下一版本中解決更徹底一些軟件缺陷19第十九頁，共四十六頁，編輯于2023年，星期一造成軟件缺陷產(chǎn)生的主要原因有：1.技術(shù)問題主要包括：算法錯誤、語法錯誤、計(jì)算和精度問題、系統(tǒng)結(jié)構(gòu)不合理、算法不科學(xué)，造成系統(tǒng)性能低下、接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問題2.團(tuán)隊(duì)工作對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難；開發(fā)人員相互理解不一致；設(shè)計(jì)或編程上的一些假定或依賴性，沒有得到充分的溝通3.軟件本身文檔錯誤、用戶使用場合(userscenario)，時(shí)間上不協(xié)調(diào)、或不一致性所帶來的問題。系統(tǒng)的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題軟件缺陷的產(chǎn)生20第二十頁，共四十六頁，編輯于2023年，星期一軟件缺陷構(gòu)成

21第二十一頁，共四十六頁，編輯于2023年，星期一軟件缺陷在不同階段的分布在真正的程序測試之前，通過審查、評審會可以發(fā)現(xiàn)更多的缺陷。規(guī)格說明書的缺陷會在需求分析審查、設(shè)計(jì)、編碼、測試等過程中會逐步發(fā)現(xiàn)，而不能在需求分析一個階段發(fā)現(xiàn)22第二十二頁，共四十六頁，編輯于2023年，星期一缺陷成本軟件缺陷的發(fā)現(xiàn)隨著時(shí)間的推移帶來的成本越來越大。23第二十三頁，共四十六頁，編輯于2023年，星期一2.2驗(yàn)證和確認(rèn)2.2.1驗(yàn)證和確認(rèn)2.2.2評審2.2.3質(zhì)量保證和測試的關(guān)系24第二十四頁，共四十六頁，編輯于2023年，星期一驗(yàn)證和確認(rèn)（V&V）

Verification：Arewebuildingtheproductright？是否正確地構(gòu)造了軟件？即是否正確地做事，驗(yàn)證開發(fā)過程是否遵守已定義好的內(nèi)容。驗(yàn)證產(chǎn)品滿足規(guī)格設(shè)計(jì)說明書的一致性Validation：Arewebuildingtherightproduct?

是否構(gòu)造了正是用戶所需要的軟件？即是否正在做正確的事。驗(yàn)證產(chǎn)品所實(shí)現(xiàn)的功能是否滿足用戶的需求25第二十五頁，共四十六頁，編輯于2023年，星期一評審?fù)ㄟ^軟件評審，可以更早地發(fā)現(xiàn)需求工程、軟件設(shè)計(jì)等各個方面的問題，大大減少大量的后期返工，將質(zhì)量成本從昂貴的后期返工轉(zhuǎn)化為前期的缺陷發(fā)現(xiàn)。評審是對軟件元素或者項(xiàng)目狀態(tài)的一種評估手段，以確定其是否與計(jì)劃的結(jié)果保持一致，并使其得到改進(jìn)。檢驗(yàn)工作產(chǎn)品是否正確地滿足了以往工作產(chǎn)品中建立的規(guī)范。軟件評審是軟件測試的組成部分。26第二十六頁，共四十六頁，編輯于2023年，星期一評審分類管理評審技術(shù)評審文檔評審流程評審27第二十七頁，共四十六頁，編輯于2023年，星期一什么是SQA?軟件質(zhì)量保證是通過對軟件產(chǎn)品和活動有計(jì)劃的進(jìn)行評審和審計(jì)來驗(yàn)證軟件是否合乎標(biāo)準(zhǔn)的系統(tǒng)工程活動.

確保SQA活動要自始至有計(jì)劃的進(jìn)行審查軟件產(chǎn)品和活動是否遵守適用的標(biāo)準(zhǔn)、規(guī)程和要求并得到客觀驗(yàn)證。SQA的活動和結(jié)果要保證全員參與，溝通順暢。逐級解決不符合問題28第二十八頁，共四十六頁，編輯于2023年，星期一SQA與軟件測試有什么關(guān)系和區(qū)別？

29第二十九頁，共四十六頁，編輯于2023年，星期一SQA與軟件測試的關(guān)系SQA是管理工作、審查對象是流程、強(qiáng)調(diào)以預(yù)防為主測試是技術(shù)工作、測試對象是產(chǎn)品、主要是以事后檢查SQA指導(dǎo)測試、監(jiān)控測試測試為SQA提供依據(jù)30第三十頁，共四十六頁，編輯于2023年，星期一2.3軟件測試的分類方法目標(biāo)/特性單元測試系統(tǒng)測試驗(yàn)收測試性能測試強(qiáng)壯性測試功能測試白盒測試黑盒測試測試階段或?qū)哟芜m用性測試可靠性測試集成測試安全性測試31第三十一頁，共四十六頁，編輯于2023年，星期一不同的分類按測試的對象或范圍分類，如單元測試、文檔測試、系統(tǒng)測試等）按測試目的分類，如功能測試、回歸測試、性能測試、可靠性測試、安全性測試和兼容性測試等根據(jù)測試過程中被測軟件是否被執(zhí)行，分為靜態(tài)測試和動態(tài)測試根據(jù)是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法來完成測試，可分為白盒測試和黑盒測試32第三十二頁，共四十六頁，編輯于2023年，星期一2.4.1軟件測試模型：V模型33第三十三頁，共四十六頁，編輯于2023年，星期一2.4.2軟件測試模型：X模型34第三十四頁，共四十六頁，編輯于2023年，星期一2.5軟件測試的工作范疇軟件測試工作的組織與管理：制定測試策略、測試計(jì)劃，確認(rèn)所采用的測試方法與規(guī)范，控制測試進(jìn)度，管理測試資源。測試工作的實(shí)施：編制符合標(biāo)準(zhǔn)的測試文檔，搭建測試環(huán)境，開發(fā)測試腳本、與開發(fā)組織協(xié)作實(shí)現(xiàn)各階段的測試活動。35第三十五頁，共四十六頁，編輯于2023年，星期一測試工作流程36第三十六頁，共四十六頁，編輯于2023年，星期一2.5.1測試計(jì)劃制定在測試計(jì)劃中，主要包括以下內(nèi)容：1.制定測試策略制定測試策略主要分析測試的目標(biāo)和指標(biāo)，確定測試的對象和依據(jù)，明確測試的重點(diǎn)和采用的方法2.確定測試范圍測試主要依據(jù)“產(chǎn)品設(shè)計(jì)規(guī)格說明書”，根據(jù)產(chǎn)品的新特性或功能修改需求所做的代碼變化，以及這種變化可能引起的問題或給其他模塊造成的影響。3.所需資源和日程安排資源包括計(jì)算機(jī)硬件、軟件和人力資源。在進(jìn)行資源安排時(shí)，更重要的是設(shè)置不同的角色，清楚地定義每個人的工作內(nèi)容和責(zé)任。對于日程安排，主要是設(shè)置整個測試周期的項(xiàng)目進(jìn)程。為了合理、準(zhǔn)確地安排日程，對測試工作量要進(jìn)行正確的估計(jì)。37第三十七頁，共四十六頁，編輯于2023年，星期一2.5.2設(shè)計(jì)測試用例在單元測試階段，主要用白盒測試方法設(shè)計(jì)測試用例；在功能測試階段，主要用黑盒測試方法來設(shè)計(jì)測試用例。測試用例定義了為執(zhí)行測試所需要的條件或環(huán)境、輸入或操作步驟，以及所期望的結(jié)果。測試環(huán)境是測試的基礎(chǔ)。要盡量模擬軟件系統(tǒng)實(shí)際應(yīng)用的環(huán)境。輸入值。除了正常的輸入值，關(guān)鍵是需要尋找哪些是屬于邊界條件的輸入值和正常輸入值。期望結(jié)果或標(biāo)準(zhǔn)。是根據(jù)系統(tǒng)設(shè)計(jì)規(guī)格說明書來確定的輸出結(jié)果、標(biāo)準(zhǔn)。有時(shí)是由經(jīng)驗(yàn)作出正確判斷、理解所確定。38第三十八頁，共四十六頁，編輯于2023年，星期一2.5.3執(zhí)行測試執(zhí)行測試主要有下列一些活動：建立必要的測試環(huán)境按照所寫的測試用例，編寫測試腳本根據(jù)測試對象和目的，構(gòu)造測試用例的集合運(yùn)行測試腳本或手工按測試用例進(jìn)行記錄測試結(jié)果結(jié)果比較分析，找出軟件缺陷將軟件缺陷記錄到缺陷數(shù)據(jù)庫中，清楚地描述該缺陷跟蹤和管理軟件缺陷驗(yàn)證被處理的軟件缺陷，并進(jìn)行回歸測試對測試過程進(jìn)行管理，保證測試工作執(zhí)行的正確性，實(shí)現(xiàn)資源調(diào)撥和相關(guān)合作方的協(xié)調(diào)。對測試中的問題進(jìn)行全程跟蹤39第三十九頁，共四十六頁，編輯于2023年，星期一2.5.4測試結(jié)果分析和質(zhì)量報(bào)告一個好的測試報(bào)告建立在測試結(jié)果的基礎(chǔ)之上，不僅要提供必要測試結(jié)果的實(shí)際數(shù)據(jù)，同時(shí)要對結(jié)果進(jìn)行分析，發(fā)現(xiàn)產(chǎn)品中問題的本質(zhì)，對產(chǎn)品質(zhì)量進(jìn)行準(zhǔn)確的評估。分析的對象和內(nèi)容是：測試的覆蓋率bug分析產(chǎn)品總體質(zhì)量分析40第四十頁，共四十六頁，編輯于2023年，星期一習(xí)題1．單元測試是以

a說明書為指導(dǎo)，測試源程序代碼；集成測試以

b說明書為指導(dǎo)，測試軟件結(jié)構(gòu)；確認(rèn)測試以

c說明書為指導(dǎo)。a.詳細(xì)設(shè)計(jì)b.概要設(shè)計(jì)c.需求分析2．軟件是包括

a、

b、

c、

d的完整集合。a.程序b.文檔c.數(shù)據(jù)d.服務(wù)填空題：3．動態(tài)測試分為

a即功能測試，和

b即結(jié)構(gòu)測試。

a.黑盒測試b.白盒測試41第四十一頁，共四十六頁，編輯于2023年，星期一習(xí)題1．測試是為了驗(yàn)證軟件正確地實(shí)現(xiàn)了用戶需求。2．確認(rèn)測試主要測試軟件功能是否滿足用戶的合理需求，以“需求規(guī)格說明書”為測試依據(jù)。判斷題：3．如果發(fā)布的軟件有質(zhì)量問題，那是軟件測試人員的錯。4.設(shè)計(jì)－實(shí)現(xiàn)－測試，軟件測試是開發(fā)后期的一個階段。對錯錯錯42第四十二頁，共四十六頁，編輯于2