軟件工程-質(zhì)量概念課件

第10章質(zhì)量概念主要內(nèi)容什么是軟件質(zhì)量產(chǎn)品度量框架10.1什么是質(zhì)量現(xiàn)如今軟件質(zhì)量仍然是一個(gè)問題，每年耗費(fèi)了大量的資金客戶責(zé)備開發(fā)人員，認(rèn)為粗心的實(shí)踐導(dǎo)致低質(zhì)量的軟件。開發(fā)人員責(zé)備額客戶，認(rèn)為不合理的交工日期以及連續(xù)不斷的變更使開發(fā)人員在還沒有完全驗(yàn)證時(shí)就交付了軟件。這都是問題所在。10.1什么是質(zhì)量質(zhì)量是什么不好清楚的定義質(zhì)量涵蓋很多觀點(diǎn)在最一般的意義上，軟件質(zhì)量可以這樣定義：在一定程度上應(yīng)用有效的軟件過程，創(chuàng)造有用的產(chǎn)品，為生產(chǎn)者和使用者提供明顯的價(jià)值。10.1什么是質(zhì)量軟件質(zhì)量是對明確陳述的功能和性能需求、明確記錄的開發(fā)標(biāo)準(zhǔn)以及對所有專業(yè)化軟件開發(fā)應(yīng)具備的隱含特征的符合度。Gavin的質(zhì)量維度Gavin建議采用多維的觀點(diǎn)考慮質(zhì)量：性能質(zhì)量—內(nèi)容、功能和特性是否交付特性質(zhì)量—用戶驚喜特性是否提供可靠性—所有的特性和能力是否提供符合性—標(biāo)準(zhǔn)、編碼慣例耐久性—是否能對軟件進(jìn)行維護(hù)和改正適用性—可否短時(shí)間內(nèi)完成維護(hù)和改正審美—難量化，但不可缺感知—偏見或好的聲譽(yù)10.1什么是質(zhì)量McCall的質(zhì)量因素影響軟件質(zhì)量的因素可以分為兩大類：可以直接測量的因素（如：測試期間發(fā)現(xiàn)的錯(cuò)誤）只能間接測量的因素（如：易用性和可維護(hù)性）所有情況下，度量都必須發(fā)生。McCall、Richards和Walters對軟件質(zhì)量的分類：正確性：程序滿足其需求規(guī)格說明和完成用戶目標(biāo)的程度?？煽啃裕浩谕绦蛞运蟮木韧瓿善漕A(yù)期功能的程度。效率：程序完成其功能所需計(jì)算資源和代碼的數(shù)量完整性：對為授權(quán)的人員訪問軟件或數(shù)據(jù)的可控程度。易用性：對程序?qū)W習(xí)、操作、準(zhǔn)備輸入和解釋輸出所需要的工作量。可維護(hù)性：定位和修復(fù)程序中的一個(gè)錯(cuò)誤所需要的工作量。靈活性：修改一個(gè)運(yùn)行的程序所需的工作量?？蓽y試性：測試程序以確保它能完成預(yù)期功能所需要的工作量?？梢浦残裕簩⒊绦驈囊粋€(gè)硬件和軟件系統(tǒng)環(huán)境移動(dòng)到另一個(gè)所需要的工作量。可復(fù)用性：程序（或程序的一部分）可以在另一個(gè)程序中使用的程度。可操作性：將一個(gè)系統(tǒng)連接到另一個(gè)系統(tǒng)所需要的工作量。10.1什么是質(zhì)量ISO質(zhì)量因素：ISO9126標(biāo)準(zhǔn)標(biāo)準(zhǔn)標(biāo)識(shí)了六個(gè)關(guān)鍵的質(zhì)量屬性：功能性，子屬性：適應(yīng)性、準(zhǔn)確性、互操作性、依從性和安全性可靠性，子屬性：成熟性、容錯(cuò)性和可恢復(fù)性易用性，子屬性：可理解性、易學(xué)習(xí)性和可操作性效率，子屬性：時(shí)間表現(xiàn)和資源表現(xiàn)可維護(hù)性，子屬性：可分析性、可修改性、穩(wěn)定性和可測試性可移植性，子屬性：適應(yīng)性、可安裝性和可替代性。10.1什么是質(zhì)量定向質(zhì)量因素軟件團(tuán)隊(duì)可以提出一套質(zhì)量特征和相關(guān)的問題以調(diào)查滿足每個(gè)質(zhì)量因素的程度。為了進(jìn)行評(píng)價(jià)，需要說明白具體的、可測量的屬性——細(xì)化。參看教材P218直覺界面布局易于理解嗎？界面操作容易找到和上手嗎？界面使用了可識(shí)別的隱喻嗎？輸入安排地節(jié)約敲擊鍵盤和點(diǎn)擊鼠標(biāo)嗎？界面符合３個(gè)重要原則嗎？美學(xué)的運(yùn)用有助于理解和使用嗎？效率：界面的布局和風(fēng)格可以使用戶有效地找到操作和信息嗎？一連串的操作（或數(shù)據(jù)輸入）可以用簡單動(dòng)作達(dá)到嗎？輸出的數(shù)據(jù)和顯示的內(nèi)容能被立即理解嗎？分層操作是否組織得能使用戶完成某項(xiàng)工作所需導(dǎo)航的深度更小？健壯性：如果輸入了規(guī)定邊界上的數(shù)據(jù)或恰好在規(guī)定邊界外的數(shù)據(jù)，軟件能識(shí)別出錯(cuò)誤嗎？更為重要的是，軟件還能繼續(xù)運(yùn)行而不出錯(cuò)或性能不下降嗎？界面能識(shí)別出常見的可識(shí)別的錯(cuò)誤或操作操作，并能清晰地指導(dǎo)用戶回到正確的軌道上來嗎？當(dāng)發(fā)現(xiàn)了錯(cuò)誤的情況（與軟件功能有關(guān)），界面是否提供有用的診斷或指導(dǎo)？豐富性界面是否能按照用戶的特定要求進(jìn)行客戶化？界面是否提供宏操作以使用戶將單個(gè)的行為或命令當(dāng)做一連串的常用操作？10.1什么是質(zhì)量過渡到量化觀點(diǎn)我們可以提出一組應(yīng)用于軟件質(zhì)量評(píng)估的軟件度量。在所有的情況下，這些度量表間接的測度（從不真正測量質(zhì)量，而是測量質(zhì)量的一些表現(xiàn)）10.2軟件質(zhì)量困境“足夠好”的軟件？成本高，可能錯(cuò)失市場機(jī)會(huì)“足夠好”可以起作用，但只是對于少數(shù)幾個(gè)公司，而且只是在有限的幾個(gè)應(yīng)用領(lǐng)域。10.2軟件質(zhì)量困境質(zhì)量成本表面上看，質(zhì)量是有成本的，但是缺乏質(zhì)量也要成本。既要了解實(shí)現(xiàn)質(zhì)量的成本，也要了解低質(zhì)量軟件的成本。

為了了解這些費(fèi)用，一個(gè)組織必須收集度量數(shù)據(jù)，為目前的質(zhì)量成本提供一個(gè)基準(zhǔn)10.2軟件質(zhì)量困境質(zhì)量成本可以分為：預(yù)防成本—管理、技術(shù)活動(dòng)、測試、培訓(xùn)評(píng)估成本—技術(shù)評(píng)審、收集、估算、測試和調(diào)試失效成本—內(nèi)部失效成本和外部失效成本10.2軟件質(zhì)量困境風(fēng)險(xiǎn)--質(zhì)量低劣導(dǎo)致風(fēng)險(xiǎn)，其中一些非常嚴(yán)重疏忽和責(zé)任—到了交付時(shí)，互相抱怨質(zhì)量和安全--沒有表現(xiàn)出高質(zhì)量的軟件比較容易被攻擊管理活動(dòng)的影響—決策對軟件質(zhì)量有重大影響估算決策—如果交付日期不合理，檢查立場很重要進(jìn)度安排決策—構(gòu)件之間有先后依賴關(guān)系，造成有些缺陷發(fā)現(xiàn)晚，影響質(zhì)量面向風(fēng)險(xiǎn)的決策—當(dāng)風(fēng)險(xiǎn)變成現(xiàn)實(shí)，質(zhì)量水平必然下降10.3實(shí)現(xiàn)軟件質(zhì)量1、軟件工程方法采用適當(dāng)?shù)姆治龊驮O(shè)計(jì)方法2、項(xiàng)目管理技術(shù)進(jìn)度管理、風(fēng)險(xiǎn)規(guī)劃、變更管理等3、質(zhì)量控制如檢查代碼、一系列的測試步驟、測量等4、質(zhì)量保證如審核和包噶，評(píng)估質(zhì)量控制過程的有效性和完整性10.4微軟軟件質(zhì)量測試常用度量產(chǎn)品設(shè)計(jì)規(guī)范(Spec或設(shè)計(jì)文檔)質(zhì)量狀態(tài)缺陷（bug）數(shù)據(jù)有關(guān)度量測試案例度量測試規(guī)范度量測試過的系統(tǒng)數(shù)量自動(dòng)化測試度量CodeCoverage（代碼覆蓋）單一功能測試驗(yàn)收質(zhì)量度量1.產(chǎn)品設(shè)計(jì)規(guī)范質(zhì)量狀態(tài)分類常用的五種狀態(tài)一頁(Onepage)–用于安排時(shí)間和分配人員草稿

(Draft)–用于提出疑問和初步設(shè)想以供討論審閱

(Review)–有所有的設(shè)計(jì)技術(shù)細(xì)節(jié)，可以供審閱提交審核會(huì)(Inspection)–所有的設(shè)計(jì)技術(shù)細(xì)節(jié)到位、沒有明顯遺留疑問、漏洞等開始編碼(Coding)–開發(fā)人員可以開始編寫代碼來實(shí)現(xiàn)該設(shè)計(jì)功能規(guī)范產(chǎn)品設(shè)計(jì)規(guī)范質(zhì)量到位狀況五種狀態(tài)中各占的%是多少?按事先計(jì)劃日程完成的比例是多少？多少%開發(fā)人員至少有一個(gè)指派給他的功能可以進(jìn)行編碼？2.缺陷統(tǒng)計(jì)數(shù)據(jù)的度量所有缺陷數(shù)量的時(shí)間走勢或趨勢統(tǒng)計(jì)(BugTrendsByTime)未被處理的缺陷按照嚴(yán)重程度的統(tǒng)計(jì)(ActiveBugsBySeverity)

未被處理的缺陷按照優(yōu)先程度的統(tǒng)計(jì)(ActiveBugsByPriority)未被處理的缺陷數(shù)量的時(shí)間走勢或趨勢統(tǒng)計(jì)

（ActiveBugsOverTime）所有的缺陷按照嚴(yán)重程度的統(tǒng)計(jì)(AllBugsBySeverity)新被發(fā)現(xiàn)的缺陷按嚴(yán)重程度的統(tǒng)計(jì)(OpenedBugsBySeverity)

已處理的缺陷按照嚴(yán)重程度的統(tǒng)計(jì)(ResolvedBugsBySeverity)

被修復(fù)的缺陷按照嚴(yán)重程度的統(tǒng)計(jì)

(FixedBySeverity)時(shí)間缺陷數(shù)量所有的缺陷按照嚴(yán)重程度的統(tǒng)計(jì)(AllBugsBySeverity)2.缺陷統(tǒng)計(jì)數(shù)據(jù)的度量(續(xù))已發(fā)現(xiàn)缺陷的數(shù)量和已修復(fù)的缺陷的數(shù)量的比率

(Fixed/Found)。也被稱為修改率或糾錯(cuò)率(FixRate)

未處理的缺陷數(shù)量和已處理的的缺陷數(shù)量的比率

(active/resolved)已處理的被修復(fù)的缺陷數(shù)量和已處理的缺陷數(shù)量的比率（ResolvedasFixed/resolved）重新被激活的已修復(fù)的缺陷數(shù)量(Bugre-activationrate)通過測試找到的缺陷的統(tǒng)計(jì)(Bugsopenedbytestingactivity)2.缺陷統(tǒng)計(jì)數(shù)據(jù)的度量(續(xù))不同語言版本缺陷數(shù)量的統(tǒng)計(jì)(BugsopenedbyLanguageversion)被報(bào)告存在缺陷的各功能統(tǒng)計(jì)(Whereyourbugswerefound)處理缺陷的平均時(shí)間的統(tǒng)計(jì)(AverageTimetoResolve)關(guān)閉缺陷的平均時(shí)間的統(tǒng)計(jì)(AverageTimetoClose)被處理缺陷的不同結(jié)論統(tǒng)計(jì)(ResolvedBugsByResolution)里程碑編程階段缺陷變化趨勢3.測試案例度量運(yùn)行測試案例數(shù)量和通過測試的案例數(shù)量之比不同產(chǎn)品開發(fā)階段該比率變化測試案例包括的范圍運(yùn)行測試案例的頻率有測試案例的功能數(shù)量4.測試規(guī)范度量測試規(guī)范數(shù)量和所有功能數(shù)量之比滿足撰寫要求的測試規(guī)范數(shù)量和所有測試規(guī)范數(shù)量之比必要的內(nèi)容遺漏的比率測試規(guī)范:微軟把針對怎樣測試某功能的，有細(xì)分功能后的具體測試條例等細(xì)節(jié)的測試文檔叫做測試規(guī)范（TestDesignSpecification或簡稱TDS）。5.測試過的系統(tǒng)數(shù)量所支持的不同語言系統(tǒng)的總數(shù)與測試過的語言系統(tǒng)數(shù)量所支持系統(tǒng)的總數(shù)與測試過的系統(tǒng)數(shù)量Windows2000(SPx)WindowsXP(SPx)Windows2003Server(SPx)TabletPC新的系統(tǒng)平臺(tái)6.自動(dòng)化測試度量測試的可自動(dòng)化程度能自動(dòng)化的和實(shí)現(xiàn)自動(dòng)化的比率運(yùn)行通過的自動(dòng)化腳本比率不同產(chǎn)品開發(fā)階段該比率變化7.CodeCoverage（代碼覆蓋）代碼覆蓋度量定義和目的代碼覆蓋種類代碼覆蓋的有效使用開發(fā)人員：單元測試(unittesting)測試人員：系統(tǒng)測試(systemtesting)和自動(dòng)化測試代碼覆蓋是什么？動(dòng)態(tài)白盒測試評(píng)價(jià)技術(shù)已經(jīng)執(zhí)行（測試）了什么（whathasbeenexecuted）沒有執(zhí)行的（測試）有什么whathasnotbeenexecutedandstillremainstobetested.需要有源代碼內(nèi)部輔助工具使用代碼覆蓋度量的目地經(jīng)驗(yàn)總結(jié)：大約的20%代碼囊括缺陷總數(shù)的80%目的不是要達(dá)到某個(gè)神奇的數(shù)字，而是要發(fā)現(xiàn)測試中的漏洞達(dá)到比較廣泛的覆蓋率相對容易，但要達(dá)到100%覆蓋常需要多得多的成本平均目標(biāo)65%理想目標(biāo)75%代碼覆蓋度量種類代碼函數(shù)覆蓋數(shù)量代碼運(yùn)行使用到的功能覆蓋數(shù)量代碼數(shù)據(jù)種類覆蓋數(shù)量代碼函數(shù)條件覆蓋數(shù)量代碼通路(path)覆蓋數(shù)量代碼覆蓋結(jié)果分析使用代碼覆蓋度量改進(jìn)測試代碼覆蓋度量只能揭示測試的漏洞，并不能直接改進(jìn)測試為什么有些代碼沒有執(zhí)行到？腳本運(yùn)行時(shí)執(zhí)行到了代碼不意味著測試的深度和全面性先查功能代碼覆蓋率，再計(jì)劃寫自動(dòng)化腳本的優(yōu)先順序撰寫測試用例已覆蓋所有要測試的功能行為，然后編寫自動(dòng)化腳本加以驗(yàn)證添加新自動(dòng)化腳本覆蓋找到的漏洞使用代碼覆蓋度量結(jié)果分析沒有覆蓋代碼的可能原因和改進(jìn)措施：遺漏的功能行為：追加測試程序中有‘死角’代碼，沒有功能行為可以執(zhí)行該代碼：刪除？很難模擬的出錯(cuò)條件：可否有其他方法？過時(shí)的功能規(guī)范？--更新功能規(guī)范8.單一功能測試驗(yàn)收質(zhì)量度量