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

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

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

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

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

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

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

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

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

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

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

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

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