計(jì)算機(jī)軟件及應(yīng)用Ch2-軟件測試概念-48課件

軟件測試與質(zhì)量保證Ch.2軟件測試的基本概念和方法第一章回顧軟件特點(diǎn)軟件開發(fā)的模型原型模型改進(jìn)的V模型增量模型和迭代模型XP模型

極限編程…測試的重要性2023/7/192第二章軟件測試的基本概念和方法2.1軟件質(zhì)量就是客戶的滿意度2.2軟件缺陷(Bug)是什么2.3軟件測試的基本方法2.4軟件測試的分類和階段2.5軟件測試的工作范疇2023/7/193軟件質(zhì)量的內(nèi)涵軟件質(zhì)量是客戶滿意度的體現(xiàn)客戶+

質(zhì)+量?2023/7/194質(zhì)量(Quality)質(zhì)量是系統(tǒng)、部件或過程滿足明確需求客戶或用戶需要或期望的程度不同IEEE<<StandardGlossaryofSoftwareEngineeringTerminology>>軟件質(zhì)量：軟件產(chǎn)品具有滿足

規(guī)定的或隱含要求能力要求有

關(guān)的特征與特征總和(ISO8492)

軟件質(zhì)量：軟件產(chǎn)品滿足

使用要求的程度

2023/7/195軟件質(zhì)量范圍-3AAccountability(可說明性)–用戶可以基于產(chǎn)品或服務(wù)的描述和定義進(jìn)行使用.

(例如:

市場需求說明書,功能設(shè)計(jì)說明書.)Availability(有效性)–產(chǎn)品或服務(wù)對于99.999%客戶總是有效的(例如:性能測試和恢復(fù)測試)Accessibility(易用性)–對于用戶,產(chǎn)品或服務(wù)非常容易使用并且一定是非常有用的功能.(例如:確認(rèn)測試和用戶可用性測試)

2023/7/196高質(zhì)量的軟件應(yīng)該是相對的無產(chǎn)品缺陷(BugFree)或只有極少量的缺陷,它能夠準(zhǔn)時(shí)遞交給用戶并且所用的費(fèi)用都是在預(yù)算內(nèi)的并且滿足客戶需求，是可維護(hù)的。但是,有關(guān)質(zhì)量的好壞最終評價(jià)依賴于用戶的反饋?！翱蛻簟睆V義定義

:內(nèi)在的定義:下一個(gè)環(huán)節(jié)/工序的接收者，更廣的服務(wù)的對象，周圍有任何聯(lián)系或影響的團(tuán)隊(duì)、人。

軟件的設(shè)計(jì)者，程序的檢測者，項(xiàng)目管理者，品質(zhì)管理人員

…-廣泛的定義:最終用戶，客戶管理，2023/7/197軟件質(zhì)量不同的視點(diǎn)

先驗(yàn)論觀點(diǎn)：質(zhì)量是產(chǎn)品一種可以認(rèn)識但不可定義的性質(zhì)。

用戶觀點(diǎn)：質(zhì)量是產(chǎn)品滿足使用目的之程度。

制造者的觀點(diǎn)：質(zhì)量是產(chǎn)品性能和規(guī)格要求的符合度。

產(chǎn)品觀點(diǎn)：質(zhì)量是聯(lián)結(jié)產(chǎn)品固有性能的紐帶。

基于價(jià)值觀點(diǎn)：質(zhì)量依賴于顧客愿意付給產(chǎn)品報(bào)酬的數(shù)量。2023/7/198高質(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)、成本、業(yè)務(wù)等

2023/7/199產(chǎn)品質(zhì)量的標(biāo)準(zhǔn)-功能性

Functionality-可用性

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

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

Performance-容量

Capacity-可測量性

Scalability-可維護(hù)性

Servicemanageability-兼容性

Compatibility-可擴(kuò)展性

Extensibility2023/7/1910軟件質(zhì)量特征(ISO9126)功能：與一組功能及其指定性質(zhì)有關(guān)的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。可靠：在規(guī)定的一段時(shí)間和條件下，與軟件維持其性能水平的能力有關(guān)的一組屬性。易用：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評價(jià)有關(guān)的一組屬性。效率：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性?？删S護(hù)：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性?？梢浦玻号c軟件從一個(gè)環(huán)境轉(zhuǎn)移到另一個(gè)環(huán)境的能力有關(guān)的一組屬性。

其中每一個(gè)質(zhì)量特征都分別與若干子特征相對應(yīng)。2023/7/1911Boehm軟件質(zhì)量模型闡述性互用性數(shù)據(jù)公開性正確性可靠性效率完整性可用性可維護(hù)性可測試性靈活性可移植性重復(fù)性連貫性容錯(cuò)性執(zhí)行效率/儲存效率存取控制/存取檢查可訓(xùn)練溝通良好簡單性易操作的工具自我操作性擴(kuò)展性一般性模塊性軟件系統(tǒng)獨(dú)立性機(jī)器獨(dú)立性通訊公開性正確性可操作性2023/7/1912McCall模型設(shè)備獨(dú)立性易更改可靠性效率總體效用易用性可維護(hù)性可測試性人體工程學(xué)可移植性易懂性精確性完整性完全性可說明性

設(shè)備功效易操作性溝通良好自我操作性架構(gòu)性簡明性易懂性可維護(hù)性模塊獨(dú)立性連續(xù)性2023/7/1913軟件過程質(zhì)量軟件能力成熟度模型CMM(CapabilityMaturityModel).國際標(biāo)準(zhǔn)過程模型ISO9000軟件過程改進(jìn)和能力決斷SPICE(SoftwareProcessImprovementandCapabilitydEtermination)2023/7/1914質(zhì)量保證的策略主要分三個(gè)階段：

以檢測為重：產(chǎn)品制成之后進(jìn)行檢測，只能判斷產(chǎn)品質(zhì)量，不能提高產(chǎn)品質(zhì)量。

以過程管理為重：把質(zhì)量的保證工作重點(diǎn)放在過程管理上，對制造過程中的每一道工序都要進(jìn)行質(zhì)量控制。

以新產(chǎn)品開發(fā)為重：在新產(chǎn)品的開發(fā)設(shè)計(jì)階段，采取強(qiáng)有力的措施來消滅由于設(shè)計(jì)原因而產(chǎn)生的質(zhì)量隱患。2023/7/1915全面質(zhì)量管理(TQM)TQM=TotalQualityManagement全面質(zhì)量管理TQM是為了能夠在最經(jīng)濟(jì)的水平上，并考慮到充分滿足用戶要求的條件下進(jìn)行市場研究、設(shè)計(jì)、生產(chǎn)和服務(wù)，把企業(yè)內(nèi)各部門研制質(zhì)量、維持質(zhì)量和提高質(zhì)量的活動構(gòu)成為一體的一種有效體系

TQM內(nèi)容:

全員參與質(zhì)量管理

全過程質(zhì)量管理。

TQM的4個(gè)關(guān)鍵要素:關(guān)注客戶過程改進(jìn)質(zhì)量的人性化因素度量(即模型的測量和分析)2023/7/1916質(zhì)量管理發(fā)展五個(gè)階段1900手工操作者專職檢驗(yàn)員1920過程統(tǒng)計(jì)技術(shù)1931全面質(zhì)量管理1960以顧客為中心階段時(shí)間20002023/7/19172.2軟件缺陷(Bug)是什么任何程序、系統(tǒng)中的問題，和產(chǎn)品設(shè)計(jì)書的不一致性，不能滿足用戶的需求

2023/7/1918Anyproblem/disfigurement/limitationinproductdesign&development

Featureorfunctioncan’tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI,LowperformanceOthers問題出在哪里？項(xiàng)目沒有被很好地理解；計(jì)劃不周，最終導(dǎo)致進(jìn)度拖延。沒有充分的文檔資料。人與人的交流比寫程序困難得多。軟件可靠性缺少度量的標(biāo)準(zhǔn)，質(zhì)量無法保證。軟件難以維護(hù)、不易升級。2023/7/1919解決問題的想法Bettermanagement管理Differentteamorganizations組織Betterlanguages&tools語言和工具Uniformcodingconventions編程慣例必須意識到：“軟件”

≠編程，它有自己的生命周期(lifecycle)。大型軟件系統(tǒng)的開發(fā)與其它工程項(xiàng)目如建造橋梁、制造飛機(jī)、輪船等的開發(fā)是同理的。2023/7/1920實(shí)踐證明：對軟件進(jìn)行充分的測試 才能夠有效的保證軟件質(zhì)量軟件測試對軟件產(chǎn)品進(jìn)行充分測試，找出其中的缺陷(Bug),并進(jìn)行修復(fù)(Fix)。2023/7/1921缺點(diǎn)（defect）偏差（variance）謬誤（fault）失?。╢ailure）問題（problem）矛盾（inconsistency）錯(cuò)誤（error）毛?。╥ncident）異常（anomy）缺陷-Bug2023/7/1922軟件缺陷IEEE(1983)729軟件缺陷一個(gè)標(biāo)準(zhǔn)的定義：

從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯(cuò)誤、毛病等各種問題；

從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

軟件缺陷的主要類型/現(xiàn)象：

功能、特性沒有實(shí)現(xiàn)或部分實(shí)現(xiàn)

設(shè)計(jì)不合理，存在缺陷

實(shí)際結(jié)果和預(yù)期結(jié)果不一致

運(yùn)行出錯(cuò)，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂

數(shù)據(jù)結(jié)果不正確、精度不夠

用戶不能接受的其他問題，如存取時(shí)間過長、界面不美觀2023/7/1923軟件缺陷的產(chǎn)生

技術(shù)問題算法錯(cuò)誤，語法錯(cuò)誤，計(jì)算和精度問題，接口參數(shù)傳遞不匹配團(tuán)隊(duì)工作誤解、溝通不充分軟件本身文檔錯(cuò)誤、用戶使用場合(userscenario)，時(shí)間上不協(xié)調(diào)、或不一致性所帶來的問題系統(tǒng)的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題2023/7/1924軟件缺陷構(gòu)成2023/7/1925軟件缺陷在不同階段的分布在真正的程序測試之前，通過審查、評審會可以發(fā)現(xiàn)更多的缺陷。規(guī)格說明書的缺陷會在需求分析審查、設(shè)計(jì)、編碼、測試等過程中會逐步發(fā)現(xiàn)，而不能在需求分析一個(gè)階段發(fā)現(xiàn)2023/7/1926缺陷成本2023/7/19272.3軟件測試的基本方法根據(jù)G.J.Myers觀點(diǎn)--軟件測試的目:

軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程

一個(gè)好的測試能夠在第一時(shí)間發(fā)現(xiàn)程序中存在的錯(cuò)誤

一個(gè)好的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯(cuò)誤的測試。軟件測試是質(zhì)量控制的重要手段，保證客戶拿到或用戶使用高質(zhì)量的軟件產(chǎn)品2023/7/1928軟件測試誤區(qū)

誤區(qū)一：如果發(fā)布出去的軟件有質(zhì)量問題，都是軟件測試人員的錯(cuò)誤區(qū)二：軟件測試技術(shù)要求不高，至少比編程容易多了誤區(qū)三：有時(shí)間就多測試一些，來不及就少測試一些誤區(qū)四：軟件測試是測試人員的事，與開發(fā)人員無關(guān)誤區(qū)五：根據(jù)軟件開發(fā)瀑布模型，軟件測試是開發(fā)后期的一個(gè)階段2023/7/1929軟件測試的原則所有測試的標(biāo)準(zhǔn)都是建立在用戶需求之上。軟件測試必須基于“質(zhì)量第一”的思想去開展各項(xiàng)工作，當(dāng)時(shí)間和質(zhì)量沖突時(shí)，時(shí)間要服從質(zhì)量。事先定義好產(chǎn)品的質(zhì)量標(biāo)準(zhǔn)，只有有了質(zhì)量標(biāo)準(zhǔn)，才能根據(jù)測試的結(jié)果，對產(chǎn)品的質(zhì)量進(jìn)行分析和評估。軟件項(xiàng)目一啟動，軟件測試也就是開始，而不是等程序?qū)懲?，才開始進(jìn)行測試。窮舉測試是不可能的。甚至一個(gè)大小適度的程序，其路徑排列的數(shù)量也非常大，因此，在測試中不可能運(yùn)行路徑的每一種組合。2023/7/1930軟件測試的原則（2）第三方進(jìn)行測試會更客觀，更有效。軟件測試計(jì)劃是做好軟件測試工作的前提。測試用例是設(shè)計(jì)出來的，不是寫出來的，所以要根據(jù)測試的目的，采用相應(yīng)的方法去設(shè)計(jì)測試用例，從而提高測試的效率，更多地發(fā)現(xiàn)錯(cuò)誤，提高程序的可靠性。對發(fā)現(xiàn)錯(cuò)誤較多的程序段，應(yīng)進(jìn)行更深入的測試。一般來說，一段程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)越多，其中存在的錯(cuò)誤概率也就越大。重視文檔，妥善保存一切測試過程文檔（測試計(jì)劃、測試用例、測試報(bào)告等）2023/7/1931軟件測試的原則（3）

應(yīng)當(dāng)把“盡早和不斷地測試”作為測試人員的座右銘

回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個(gè)錯(cuò)誤而引起更多錯(cuò)誤出現(xiàn)的現(xiàn)象并不少見

測試應(yīng)從“小規(guī)?！遍_始，逐步轉(zhuǎn)向“大規(guī)模”。

不可將測試用例置之度外，排除隨意性。

必須徹底檢查每一個(gè)測試結(jié)果。

一定要注意測試中的錯(cuò)誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系

對測試錯(cuò)誤結(jié)果一定要有一個(gè)確認(rèn)的過程。2023/7/1932測試方法

黑盒子和白盒子

靜態(tài)的和動態(tài)的

文檔、代碼審查

數(shù)據(jù)輸入邊界條件法

等價(jià)劃分、數(shù)據(jù)流程圖

狀態(tài)變換圖

邏輯路徑法2023/7/1933黑盒子和白盒子功能測試數(shù)據(jù)驅(qū)動測試結(jié)構(gòu)測試邏輯驅(qū)動測試

客戶需求事件驅(qū)動輸入輸出2023/7/1934靜態(tài)的和動態(tài)的主持人作者記錄員列席人員內(nèi)審員技術(shù)專業(yè)人員用戶代表不正式正式互審

走讀審查會議運(yùn)行程序2023/7/1935自動測試和手工測試手工模擬用戶操作2023/7/1936驗(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)的功能是否滿足用戶的需求2023/7/19372.4軟件測試的分類和階段開發(fā)生命周期...

維護(hù)需求定義應(yīng)用定義應(yīng)用開發(fā)

修訂

建立

建立測試生命周期...執(zhí)行.執(zhí)行執(zhí)行.測試計(jì)劃缺陷跟蹤測試開發(fā)測試設(shè)計(jì)評估2023/7/1938軟件測試分類方法目標(biāo)/特性單元測試系統(tǒng)測試驗(yàn)收測試性能測試強(qiáng)壯性測試功能測試白盒測試黑盒測試測試階段或?qū)哟芜m用性測試可靠性測試集成測試安全性測試2023/7/1939軟件測試階段階段輸入

輸出

需求分析需求定義,市場分析文檔,相關(guān)技術(shù)文檔市場需求分析會議記要,功能設(shè)計(jì),技術(shù)設(shè)計(jì)設(shè)計(jì)審查市場需求文檔,技術(shù)設(shè)計(jì)文檔測試計(jì)劃,測試用例功能驗(yàn)證代碼完成文件包,功能詳細(xì)設(shè)計(jì)說明書最終技術(shù)文檔完整測試用例,完備的測試計(jì)劃,缺陷報(bào)告,功能驗(yàn)證測試報(bào)告系統(tǒng)測試代碼修改后的文件包完整測試用例,完備的測試計(jì)劃缺陷報(bào)告缺陷狀態(tài)報(bào)告項(xiàng)目階段報(bào)告確認(rèn)測試代碼凍結(jié)文件包確認(rèn)測試用例缺陷狀態(tài)報(bào)告缺陷報(bào)告審查版本審查版本發(fā)布代碼發(fā)布文件包測試計(jì)劃檢查清單當(dāng)前版本已知問題的清單版