現(xiàn)代軟件工程的質(zhì)量保證

1、?現(xiàn)代軟件工程?第七局部現(xiàn)代軟件工程的質(zhì)量保證 ?現(xiàn)代軟件工程?本局部主要參考書?軟件驗證與確認(rèn)的最正確管理方法?美Steven R. Rakitin著于秀山等譯電子工業(yè)出版社2002?測試流程管理?美Rex Black著北京大學(xué)出版社2001?軟件工程與軟件測試自動化教程?張克東、莊燕濱電子工業(yè)出版社?軟件工程標(biāo)準(zhǔn)?美Watts. S.Humphrey著，傅為、蘇俊、許青松譯清華大學(xué)出版社2004?軟件配置管理策略與Rational ClearCase?美Brian A. White著尤克濱等譯人民郵電出版社2003現(xiàn)代軟件工程的質(zhì)量保證過程-1軟件測試的組織與管理-2軟件系統(tǒng)的可靠性工程-

2、3配置管理方法與實踐-4第七局部 現(xiàn)代軟件工程的質(zhì)量保證第一章 現(xiàn)代軟件工程的質(zhì)量保證過程 軟件的質(zhì)量要素與度量-1.1軟件工程的質(zhì)量保證過程-1.2軟件工程的質(zhì)量保證活動-1.3軟件質(zhì)量保證體系建設(shè)-1.4 第七局部 現(xiàn)代軟件工程的質(zhì)量保證如何描述質(zhì)量用人的健康做類比如何判斷人是否健康？體檢因素：身高、體重、心跳、血壓、血液、體溫等如何描述軟件的質(zhì)量軟件系統(tǒng)功能齊全是不是就是質(zhì)量好？用戶界面友好是不是就是軟件的質(zhì)量好？沒有BUG是不是就是軟件的質(zhì)量好？用戶滿意？運行正確的軟件就是高質(zhì)量的軟件嗎？不貪污的官就是好官嗎？軟件測試是不是軟件質(zhì)量的全部？答復(fù)全部是：NO！那么，什么是軟件的質(zhì)量？什么

3、是軟件的質(zhì)量？現(xiàn)代軟件工程的質(zhì)量保證與軟件測試有什么不同？技術(shù)經(jīng)理、工程經(jīng)理與質(zhì)量經(jīng)理有什么不同？什么是現(xiàn)代軟件工程的質(zhì)量管理？開發(fā)團隊在質(zhì)量保證方面，要做什么工作？ 我們就來答復(fù)這些問題！什么是軟件工程的質(zhì)量管理？軟件質(zhì)量軟件質(zhì)量的定義：ANSI/IEEE Std 729-1983定義軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體。M.J. Fisher 定義軟件質(zhì)量為“所有描述計算機軟件優(yōu)秀程度的特性的組合。質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件的各項精確定義的功能、性能需求，符合文檔化的開發(fā)標(biāo)準(zhǔn)，需要相應(yīng)地給出或設(shè)計一些質(zhì)量特性及其組合。如

4、果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，那么這個軟件產(chǎn)品質(zhì)量就是高的。軟件需求是度量軟件質(zhì)量的根底。不符合需求的軟件就不具備質(zhì)量。標(biāo)準(zhǔn)定義了一組開發(fā)準(zhǔn)那么，用來指導(dǎo)軟件人員用工程化的方法來開發(fā)軟件。如果不遵守這些開發(fā)準(zhǔn)那么，軟件質(zhì)量就得不到保證。軟件質(zhì)量是各種特性的復(fù)雜組合。它隨著應(yīng)用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)量，問題最終要歸結(jié)到定義軟件的質(zhì)量特性。定義一個軟件的質(zhì)量，就等價于為該軟件定義一系列質(zhì)量特性。人們通常把影響軟件質(zhì)量的特性用軟件質(zhì)量模型來描述。軟件質(zhì)量軟件質(zhì)量軟件質(zhì)量的因素與度量有關(guān)直接度量的因素如單位時間內(nèi)千

5、行代碼中所產(chǎn)生的錯誤數(shù)。間接度量的因素如可用性或可維護性軟件質(zhì)量軟件質(zhì)量的度量模型1976年，Boehm第一次提出了軟件質(zhì)量度量的層次模型。1978年，Walters和McCall等人提出了從軟件質(zhì)量要素、準(zhǔn)那么到度量的三個層次式的模型。1985年，ISO建議軟件質(zhì)量模型由三層組成：高層：軟件質(zhì)量需求評價準(zhǔn)那么SQRC中層：軟件質(zhì)量設(shè)計評價準(zhǔn)那么SQDC低層：軟件質(zhì)量度量評價準(zhǔn)那么SQMC現(xiàn)代軟件工程的標(biāo)準(zhǔn)體系ISO/IEC12207應(yīng)用成果基礎(chǔ)產(chǎn)品實用產(chǎn)品需求軟件工程項目管理軟件配置管理風(fēng)險管理軟件質(zhì)量保證設(shè)計實現(xiàn)測試維護1.1 軟件質(zhì)量的要素與度量1.1.1 軟件的質(zhì)量要素1.1.2 軟件

6、質(zhì)量評價的準(zhǔn)那么1.1.3 軟件質(zhì)量的度量1.1.4 軟件質(zhì)量度量的實施1.1.1 軟件的質(zhì)量要素什么是軟件的質(zhì)量？ISO9000的質(zhì)量定義：質(zhì)量的定義：反映實體滿足明確和隱含需要能力的特性綜合定義的說明：明確需要：指合同中用戶明確提出的要求與需要隱含需要：指由生產(chǎn)企業(yè)通過市場調(diào)研進(jìn)行識別與探明的要求或需要質(zhì)量與等級的關(guān)系等級的含義是：對功能用途相同、但技術(shù)特性不同的存在事務(wù)的一種分類或排序例如：高質(zhì)量無錯誤、可讀性強的用戶手冊 低等級有限的功能 低質(zhì)量錯誤百出、編排混亂的用戶手冊 高等級大量功能確定質(zhì)量和等級標(biāo)準(zhǔn)水平，是工程經(jīng)理的責(zé)任 質(zhì)量的要素討論軟件的質(zhì)量定義，一般地從4個角度來看，即用

7、戶的角度、開發(fā)商的角度、產(chǎn)品的角度和價值的角度。1976年美國的和R.Brown 先后提出了三層次的評價度量模型：軟件質(zhì)量要素、準(zhǔn)那么、度量。隨后G.Mruine提出了自己的軟件質(zhì)量度量SQM技術(shù)，波音公司在軟件開發(fā)過程中采用了SQM技術(shù)，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在本錢控制和進(jìn)度安排方面取得了良好的效果。IEEE標(biāo)準(zhǔn)1061-1998以表格的形式，定義了有關(guān)確認(rèn)和收集與軟件質(zhì)量需求有關(guān)一個模型，或稱為一個框架。可度量的軟件的質(zhì)量要素IEEE定義的軟件質(zhì)量度量框架度量框架一種用來組織、選擇、溝通、評價軟件系統(tǒng)要求的質(zhì)量屬性的輔助決策法。它逐層分解為特性、子特性

8、和度量質(zhì)量特性一個與質(zhì)量有關(guān)的面向管理的軟件屬性質(zhì)量子特性質(zhì)量特性分解出來的技術(shù)組件直接度量一種不依賴與任何其他屬性測量的度量預(yù)計度量一種試用于開發(fā)階段的度量，它用來預(yù)計軟件質(zhì)量特性的值質(zhì)量度量一個函數(shù)、它的輸入是軟件數(shù)據(jù)，輸出是一個單一數(shù)值。它可解釋為給定的軟件屬性對其質(zhì)量的影響程度過程質(zhì)量一種用來測量在軟件系統(tǒng)開發(fā)、實現(xiàn)和維護過程中使用的方法、技術(shù)和工具特性的度量產(chǎn)品度量一種用來測量軟件開發(fā)過程中任何中間或最終產(chǎn)品特性的度量IEEE定義的軟件質(zhì)量度量框架第一層次：質(zhì)量需求在四層模型的第一層，軟件產(chǎn)品質(zhì)量層，是產(chǎn)品必須滿足的質(zhì)量需求。它是用用戶術(shù)語描述的，主要有四點：1產(chǎn)品將在用戶所在組織當(dāng)

9、前使用的平臺和操作系統(tǒng)上運行。2產(chǎn)品將是可靠的并能防止數(shù)據(jù)喪失的機制。3產(chǎn)品將提供完成某些任務(wù)所必需的功能。4產(chǎn)品將易于使用。第二層次：質(zhì)量特性在模型的第二層，表示與整個質(zhì)量需求有關(guān)的特殊質(zhì)量特性，它代表了用戶的質(zhì)量需求。它采用從用戶角度考慮的立場，把軟件質(zhì)量分解成四類質(zhì)量特性，這四個質(zhì)量特性是軟件的根本特征。IEEE的四個質(zhì)量特性是：可移植性、可靠性、功能性、可使用性。IEEE定義的軟件質(zhì)量度量框架四層模型質(zhì)量需求質(zhì)量特性質(zhì)量子特性直接度量度量描述（例子）產(chǎn)品將在多平臺和當(dāng)前用戶正在使用的操作系統(tǒng)上運行可移植性硬件獨立性硬件依賴性計算硬件的依賴性軟件獨立性軟件依賴性計算軟件的依賴性易安裝性安

10、裝時間測量安裝時間可重用性能夠用于其他軟件中計算能夠或已經(jīng)應(yīng)用于其他軟件系統(tǒng)的模塊數(shù)量產(chǎn)品將是可靠的并能提供防止數(shù)據(jù)丟失的機制可靠性無缺陷性測試覆蓋測量測試覆蓋度審查覆蓋計算已做過的代碼審查模塊容錯性數(shù)據(jù)完整性統(tǒng)計用戶數(shù)據(jù)被破壞情況數(shù)據(jù)恢復(fù)測量恢復(fù)被破壞的數(shù)據(jù)的能力可用性軟件可用的百分比軟件可用時間除以總的軟件使用時間產(chǎn)品將提供完成某些任務(wù)所必需的功能功能性完備性測試覆蓋計算調(diào)用或分支測量覆蓋正確性缺陷密度計算每一版本發(fā)布前的缺陷安全性數(shù)據(jù)安全性統(tǒng)計用戶數(shù)據(jù)被破壞的情況用戶安全性沒有被阻止的非法用戶入侵?jǐn)?shù)兼容性環(huán)境變化軟件安裝后必須修改的環(huán)境變量數(shù)量互操作性混合應(yīng)用環(huán)境下軟件的可操作性混合應(yīng)用

11、環(huán)境下可正確運行的數(shù)量產(chǎn)品將易于使用可使用性易理解性學(xué)習(xí)所用時間新用戶學(xué)習(xí)軟件特性所花費的時間易學(xué)性學(xué)習(xí)所用時間新用戶學(xué)會操作軟件提供的基本功能所花費的時間易操作性人的因素新用戶基于人類工程學(xué)對軟件消極方面的評價數(shù)量溝通性人的因素新用戶基于人類工程學(xué)對軟件消極方面的評價數(shù)量質(zhì)量需求質(zhì)量特性質(zhì)量子特性直接度量度量描述（例子）1978年，Walters和McCall等人提出了從軟件質(zhì)量要素、準(zhǔn)那么到度量的三個層次式的模型。McCall選擇的軟件質(zhì)量要素評價準(zhǔn)那么共21種，它們是：1可審查性(auditability)。檢查軟件需求、規(guī)格說明、標(biāo)準(zhǔn)、過程、指令、代碼與合同是否一致的難易程度。2準(zhǔn)確性

12、(accuracy)。計算和控制的精度，是對無誤差程序的一種定量估計。最好表示成相對誤差的函數(shù)。值越大表示精度越高。3通信通用性(communication commonality)。使用標(biāo)準(zhǔn)接口、協(xié)議、標(biāo)準(zhǔn)的程序。4完全性 (completeness)。所需功能完全實現(xiàn)的程度。 5簡明性(conciseness)。程序源代碼的緊湊與簡潔性。6一致性(consistency)。設(shè)計文檔與系統(tǒng)實現(xiàn)的一致性。7數(shù)據(jù)通用性(datacommonality)。在程序中使用標(biāo)準(zhǔn)的數(shù)據(jù)結(jié)構(gòu)和類型。8容錯性(error-tolerance)。系統(tǒng)在各種異常條件下提供繼續(xù)操作的能力。9執(zhí)行效率(executi

13、on Efficiency)。程序運行效率。10可擴充性(expandability)。能夠?qū)Y(jié)構(gòu)設(shè)計、數(shù)據(jù)設(shè)計和過程設(shè)計進(jìn)行擴充的程度。1.1.2 軟件質(zhì)量評價的準(zhǔn)那么11通用性(generality)。程序部件潛在的應(yīng)用范圍的廣泛性，即部件可重用。12硬件獨立性(hardware independence)。軟件同支持他運行的硬件系統(tǒng)不相關(guān)的程度。13檢測性(instrumentation)。監(jiān)視程序的運行，一旦發(fā)生錯誤時，能明確地標(biāo)識錯誤的程度。14模塊化(modularity)。程序部件的功能獨立性。15可操作性(operability)。操作一個軟件的難易程度。16平安性(secur

14、ity)。控制或保護程序和數(shù)據(jù)不受破壞的機制，以防止程序和數(shù)據(jù)受到意外的或蓄意的存取、使用、修改、毀壞或泄密。17自文檔化(sdlf-documentation)。源代碼提供有意義文檔的程度。18簡單性(simplicity)。理解程序的難易程度。19軟件系統(tǒng)獨立性(software system independence)。程序與非標(biāo)準(zhǔn)的程序設(shè)計語言特征、操作系統(tǒng)特征以及其他環(huán)境約束無關(guān)的程度。20可追蹤性(reacebility)。從設(shè)計表示或?qū)嶋H程序構(gòu)件，追蹤到需求的能力。21易培訓(xùn)性(training)。軟件支持新用戶使用該系統(tǒng)的能力。McCall的軟件質(zhì)量評價準(zhǔn)那么軟件質(zhì)量評價準(zhǔn)那么

15、 1、正確性正確性是指軟件按照需求正確執(zhí)行任務(wù)的能力。 “正確性的語義涵蓋了“精確性。正確性無疑是第一重要的軟件質(zhì)量屬性。技術(shù)評審和測試的第一關(guān)都是檢查工作成果的正確性。 機器不會主動欺騙人，軟件運行出錯通常都是人造成的，所以不要找借口埋怨機器有毛病。2、健壯性 健壯性是指在異常情況下，軟件能夠正常運行的能力。 正確性描述軟件在需求范圍之內(nèi)的行為，而健壯性描述軟件在需求范圍之外的行為。開發(fā)者往往把異常情況當(dāng)成正常情況而不作處理，結(jié)果降低了健壯性。 用戶才不管正確性與健壯性的區(qū)別，反正軟件出了過失都是開發(fā)方的錯。所以提高軟件的健壯性也是開發(fā)者的義務(wù)。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。

16、 3、可靠性 可靠性是指在一定的環(huán)境下，在給定的時間內(nèi)，系統(tǒng)不發(fā)生故障的概率?？煽啃员緛硎怯布I(lǐng)域的術(shù)語。比方某個電子設(shè)備在剛開始工作時挺好的，但由于器件在工作中其物理性質(zhì)會發(fā)生變化如發(fā)熱，慢慢地系統(tǒng)的功能或性能就會失常。所以一個從設(shè)計到生產(chǎn)完全正確的硬件系統(tǒng)，在工作中未必就是可靠的。 軟件在運行時不會發(fā)生物理性質(zhì)的變化，人們常以為如果軟件的某個功能是正確的，那么它一輩子都是正確的。可是我們無法對軟件進(jìn)行徹底地測試，無法鏟除軟件中潛在的錯誤。平時軟件運行得好好的，說不準(zhǔn)哪一天就不正常了，如有千年等一回的“千年蟲問題，司空見慣的“內(nèi)存泄露問題、“誤差累積問題等等。 時隱時現(xiàn)的錯誤一般都屬于可靠性

17、問題，糾錯的代價很高。軟件質(zhì)量評價準(zhǔn)那么 4、性能性能通常是指軟件的“時間-空間效率，而不僅是指軟件的運行速度。人們總希望軟件的運行速度高些，并且占用資源少些。 性能優(yōu)化的關(guān)鍵工作是找出限制性能的“瓶頸 可以通過優(yōu)化數(shù)據(jù)結(jié)構(gòu)、算法和代碼來提高軟件的性能。 5、易用性易用性是指用戶使用軟件的容易程度。現(xiàn)代人的生活節(jié)奏快，圖方便。所以把易用性作為重要的質(zhì)量屬性對待無可非議。 導(dǎo)致軟件易用性差的根本原因 ：教育缺陷：沒有開設(shè)人機工程學(xué)、美學(xué)、心理學(xué)這些必修課，大局部開發(fā)人員不知道如何設(shè)計易用的軟件產(chǎn)品。開發(fā)人員犯了“錯位的毛?。核詾橹灰约河闷饋矸奖?，用戶也就會滿意。 軟件的易用性要讓用戶來評價。

18、當(dāng)用戶真的感到軟件很好用時，一股溫暖的感覺油然而生，于是就用“界面友好 等詞來評價軟件產(chǎn)品。 軟件質(zhì)量評價準(zhǔn)那么 6、清晰性 清晰意味者所有的工作成果易讀、易理解，可以提高團隊開發(fā)效率，降低維護代價。 開發(fā)人員只有在自己思路清晰的時候才可能寫出讓別人易讀、易理解的程序和文檔。 可理解的東西通常是簡潔的。一個原始問題可能很復(fù)雜，但高水平的人就能夠把軟件系統(tǒng)設(shè)計得很簡潔。如果軟件系統(tǒng)臃腫不堪，它遲早會出問題。所以簡潔是人們對工作“精益求精的結(jié)果，而不是潦草應(yīng)付的結(jié)果。 千萬不要把在學(xué)校里“造文章的手法用于開發(fā)產(chǎn)品！ 7、平安性 平安性是指防止系統(tǒng)被非法入侵的能力，既屬于技術(shù)問題又屬于管理問題。 “

19、道高一尺，魔高一丈 ，絕對平安的信息系統(tǒng)幾乎不存在。開發(fā)商和客戶愿意為提高平安性而投入的資金是有限的，他們要考慮值不值得。 軟件質(zhì)量評價準(zhǔn)那么 8、可擴展性 可擴展性反映軟件適應(yīng)“變化的能力。 在軟件開發(fā)過程中，“變化是司空見慣的事情，如需求、設(shè)計的變化，算法的改進(jìn)，程序的變化等等。由于軟件是“軟的，是否它天生就容易修改以適應(yīng)“變化？關(guān)鍵要看軟件的規(guī)模和復(fù)雜性。 現(xiàn)代軟件產(chǎn)品通常采用“增量開發(fā)模式，不斷推出新版本，獲取增值利潤。可擴展性越來越重要。可擴展性是系統(tǒng)設(shè)計階段重點考慮的質(zhì)量屬性。 9、兼容性兼容性是指兩個或兩個以上的軟件相互交換信息的能力。兼容性的商業(yè)規(guī)那么：弱者設(shè)法與強者兼容，否那

20、么無容身之地；強者應(yīng)當(dāng)防止被兼容，否那么市場將被瓜分。10、可移植性可移植性是指軟件運行于不同軟硬件環(huán)境的能力編程語言越低級，其程序越難移植，反之那么容易。軟件設(shè)計時應(yīng)該將“設(shè)備相關(guān)程序與“設(shè)備無關(guān)程序分開，將“功能模塊與“用戶界面分開。軟件質(zhì)量評價準(zhǔn)那么 1985年，國際標(biāo)準(zhǔn)化組織ISO建議，軟件質(zhì)量度量模型由三層組成。高層稱軟件質(zhì)量需求評價準(zhǔn)那么SQRC，中層稱軟件質(zhì)量設(shè)計評價準(zhǔn)那么SQDC，低層稱軟件質(zhì)量度量評價準(zhǔn)那么SQMC。分別對應(yīng)McCall等人的要素、評價準(zhǔn)那么和度量。ISO認(rèn)為應(yīng)對高層和中層建立國際標(biāo)準(zhǔn)，以便在國際范圍內(nèi)推廣應(yīng)用軟件質(zhì)量管理，而低層可由各使用單位自行制定。ISO

21、高層由8個要素組成、中層由23個評價準(zhǔn)那么組成。高層的8個要素為左表的行，中層的23個準(zhǔn)那么為下表的列。它們之間的關(guān)系如左表所示。ISO/IEC9126-1?產(chǎn)品質(zhì)量-質(zhì)量模型?的軟件質(zhì)量模型軟件質(zhì)量的另一種理解內(nèi)部質(zhì)量的定義是：反映軟件產(chǎn)品在規(guī)定條件下使用時，滿足需求的能力的特性，是軟件開發(fā)過程中各階段需求開發(fā)、軟件設(shè)計、代碼編寫等產(chǎn)生的中間軟件產(chǎn)品的質(zhì)量。了解軟件產(chǎn)品的內(nèi)部質(zhì)量，可以預(yù)計最終產(chǎn)品的質(zhì)量。外部質(zhì)量的定義是：反映軟件產(chǎn)品在規(guī)定條件下使用時，滿足需求的程度。外部特性反映在預(yù)定的系統(tǒng)環(huán)境中運行時可到達(dá)的質(zhì)量水平。軟件質(zhì)量的另一種理解使用質(zhì)量的定義是：反映軟件產(chǎn)品在規(guī)定的使用環(huán)境下，

22、使特定用戶在到達(dá)規(guī)定目標(biāo)方面的能力。反映的是從用戶角度看到的軟件產(chǎn)品在特定系統(tǒng)環(huán)境下滿足其需求的滿足程度。對內(nèi)部和外部質(zhì)量特性的度量描述包括：功能性、可靠性、易用性、效率、可維護性、可移植性等；對使用質(zhì)量特性的度量描述包括：有效性、生產(chǎn)率、平安性、滿意程度等軟件質(zhì)量的另一種理解1.1.3 軟件質(zhì)量的度量軟件度量：分析模型的度量對分析模型的度量以測試系統(tǒng)的大小設(shè)計模型的度量度量體系結(jié)構(gòu)、數(shù)據(jù)和系統(tǒng)的復(fù)雜度源代碼的度量度量程序的長度、層次、開發(fā)量、時間等對測試的度量度量測試的寬度、深度、錯誤的級別對維護的度量度量軟件的穩(wěn)定性 軟件質(zhì)量度量每個軟件屬性都有一套度量方法，選擇度量方法時，必須考慮以下因

23、素。1. 與軟件屬性的相關(guān)性相關(guān)性分為4個等級：A度量方法與相應(yīng)的軟件屬性始終存在正相關(guān)AA幾乎總是存在正相關(guān)U經(jīng)常存在正相關(guān)S偶爾存在正相關(guān)軟件質(zhì)量度量2. 度量值的可理解性定量的度量方法所得到的值分為5種情況：AL通過一個自動算法很容易理解UR不需要受過專門訓(xùn)練的人員TR需要受過專門訓(xùn)練的人員ER需要專家EX需要執(zhí)行程序3. 開發(fā)自開工具的容易性開發(fā)度量工具的難易程度分為3種情況E容易M存在困難D很困難軟件質(zhì)量度量4. 自開工具的完備性 所開發(fā)的自開工具是否完全等價于度量方法，有2種情況C完全等價P局部等價5. 潛在效益潛在效益分為5個級別：5、4、3、2、1軟件質(zhì)量度量軟件質(zhì)量度量兩個軟

24、件程序質(zhì)量度量方法Halstead的軟件科學(xué)根本思路是根據(jù)程序中可執(zhí)行代碼行的操作符和操作數(shù)的數(shù)量來計算程序的復(fù)雜性。操作符和操作數(shù)的量越大，程序結(jié)構(gòu)就越復(fù)雜。McCabe復(fù)雜性度量法程序的復(fù)雜性很大程度上取決于程序控制流的復(fù)雜性單一的順序程序結(jié)構(gòu)最簡單，循環(huán)和選擇所構(gòu)成的環(huán)路越多，程序就越復(fù)雜。軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量是利用定量或定性的方法，估算軟件質(zhì)量的評價值，以得到軟件質(zhì)量的比較精確的估算值。第一種叫做尺度度量，這是一種定量度量。它適用于一些能夠直接度量的特性，例如，出錯率定義為：錯誤數(shù)KLOC單位時間。第二種叫做二元度量，這是一種定性度量。它

25、適用于一些只能間接度量的特性，例如，可使用性、靈活性等等。驗收度量是在軟件開發(fā)各階段的檢查點，對軟件的要求質(zhì)量進(jìn)行確認(rèn)性檢查的具體評價值，它是對開發(fā)過程中的預(yù)測進(jìn)行評價。尺度度量檢查表二元度量檢查表基于軟件配置管理的度量和度量準(zhǔn)那么SCM 提供軟件產(chǎn)品的狀態(tài)統(tǒng)計。統(tǒng)計提供尋找軟件開發(fā)的瓶頸和解決方法，并據(jù)此衡量軟件產(chǎn)品的成熟度。度量準(zhǔn)那么：平均嚴(yán)重程度嚴(yán)重程度級的分布平均關(guān)閉時間嚴(yán)重程度的圖示各配置項或子系統(tǒng)的圖示 SCM的度量和度量準(zhǔn)那么軟件產(chǎn)品成熟度數(shù)據(jù)要求： 軟件變更問題數(shù)量 描述 計算機軟件配置項標(biāo)識CSCI 嚴(yán)重程度級 翻開變更的日期或發(fā)現(xiàn)問題 關(guān)閉變更問題和實施日期 軟件變更統(tǒng)計

26、SCM的度量和度量準(zhǔn)那么圖表分析軟件剩余問題剩余變更和錯誤密度1.1.4 軟件質(zhì)量度量的實施在確定要對一個軟件系統(tǒng)進(jìn)行度量之后，一般，采取以下5個步驟，來實施對該軟件的度量： 1確定軟件質(zhì)量需求； 在用戶需求中，除功能需求外，還有非功能需求，包括：質(zhì)量需求、環(huán)境需求、設(shè)計約束、開發(fā)策略等。質(zhì)量需求是用戶比較關(guān)心的內(nèi)容。但是，我們已經(jīng)知道，軟件的功能需求確實定，存在一定的難度。而非功能需求確實定，那么難度更大。這些困難包括：需求如何獲取，需求沖突如何協(xié)調(diào)、需求確實認(rèn)和變更的授權(quán)等。過程： 需求獲?。菏紫龋阋斫庥脩舻男枨?，區(qū)分哪些是質(zhì)量需求，把這些需求記錄下來，獲得用戶確實認(rèn)。 需求分析：拿到

27、用戶確認(rèn)的需求后，你可以開始把用戶的質(zhì)量需求與我們設(shè)定的質(zhì)量特性聯(lián)系起來，一直區(qū)分到子特性。這種聯(lián)系，就是把用戶語言描述的需求，轉(zhuǎn)變?yōu)橛嬎銠C工程師語言的需求。建立了這種關(guān)聯(lián)后，可以根據(jù)分類，分級，確定直接度量。 1.1.4 軟件質(zhì)量度量的實施2確定直接度量 直接度量就是實際的軟件質(zhì)量測量活動，它的輸入是軟件或軟件過程，輸出是一個測量值。它通過執(zhí)行一系列的任務(wù)，獲得一個質(zhì)量值。 例如：對一個沒有經(jīng)過培訓(xùn)的用戶，讓他使用軟件系統(tǒng)的某一功能，在界面提示、聯(lián)機幫助、使用手冊的幫助下，他學(xué)會掌握該功能所花的時間。而用戶需求對此項指標(biāo)的要求目標(biāo)和現(xiàn)實系統(tǒng)所到達(dá)的實際值比方：10個人次測量后統(tǒng)計意義上的的比

28、較，就是將提交質(zhì)量評審的質(zhì)量值。 在進(jìn)行直接度量前，你應(yīng)該有以下準(zhǔn)備： 1工具：有助于計算度量值的硬件/軟件工具，如：缺陷跟蹤工具； 2應(yīng)用：描述度量結(jié)果的希望值、度量值的意義、作用和對度量結(jié)果數(shù)據(jù)的使用方法； 3數(shù)據(jù)：獲得度量結(jié)果所需的數(shù)據(jù)、程序、過程等度量對象； 4計算：度量程序、步驟和方法。 5費用：測試是要花錢人力、物力、時間等的。1.1.4 軟件質(zhì)量度量的實施 3分析度量結(jié)果 對度量過程進(jìn)行跟蹤和分析，需要時，可能會對度量程序、度量工具、度量方法，甚至原始數(shù)據(jù)，做出補充和調(diào)整。 4確認(rèn)質(zhì)量度量 在度量過程中，進(jìn)行度量結(jié)果確實認(rèn)非常重要。首先，要確認(rèn)度量過程是否與事實相符，脫離現(xiàn)實真實

29、的度量，與目標(biāo)再相符的結(jié)果也是沒有意義的。其次，是確認(rèn)方法的有效性，例如：在度量中，我們用到很多統(tǒng)計學(xué)方法，在這些方法中，我們有一些概率分布假設(shè)例如：某些錯誤的發(fā)生，我們假設(shè)符合隨機概率分布，當(dāng)這些假設(shè)并不成立時，度量的結(jié)果是不真實的。一個系統(tǒng)集成工程的質(zhì)量特性與度量可交付成果的質(zhì)量采購的主機/存儲/網(wǎng)絡(luò)硬件/軟件運輸/安裝/檢驗/調(diào)試/測試培訓(xùn)/效勞/技術(shù)支持/維護/響應(yīng)資料文檔手冊提供工程實施過程的質(zhì)量工程的方案性組織準(zhǔn)備的充分與周到性溝通與協(xié)調(diào)性操作與行為的標(biāo)準(zhǔn)性案例分析1、你已經(jīng)確認(rèn)的，你的工程的質(zhì)量需求質(zhì)量特性是什么？2、這些質(zhì)量需求的面向度量的子特性是什么？3、如何進(jìn)行這些子特性的

30、度量方法設(shè)計？4、度量結(jié)果度量值的評價標(biāo)準(zhǔn)是什么？問題1：1.2.1 確認(rèn)過程1.2.2 驗證過程1.2 軟件工程的質(zhì)量保證過程軟件質(zhì)量保證什么是質(zhì)量保證它是為保證產(chǎn)品和效勞充分滿足消費者要求的質(zhì)量而進(jìn)行的有方案、有組織的活動。質(zhì)量保證是面向消費者的活動，是為了使產(chǎn)品實現(xiàn)用戶要求的功能，站在用戶立場上來掌握產(chǎn)品質(zhì)量的。什么是軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品。軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動。即為了確定、到達(dá)和維護需要的軟件質(zhì)量而進(jìn)行的所有有方案、有系統(tǒng)的管理活動?，F(xiàn)代軟件工程的質(zhì)量保證過程，主要包括軟件確認(rèn)與

31、驗證二個過程軟件確實認(rèn)Validation與驗證Verification簡稱為VV 或V2，也是軟件產(chǎn)品質(zhì)量度量的具體方法。軟件確認(rèn)的概念確認(rèn)是這樣一個過程，它評價“在軟件開發(fā)過程期間針對單元或結(jié)束針對系統(tǒng)時，單元或系統(tǒng)是否滿足用戶特定的需求。換句話說，是開發(fā)結(jié)束期間確認(rèn)，我們的產(chǎn)品符合用戶要求嗎？因此，確認(rèn)的產(chǎn)品質(zhì)量。確認(rèn)活動圍繞三個根本過程來開展，測試、度量和軟件可靠性增長軟件驗證的概念而驗證是這樣一個過程，它評價“在一個給定的開發(fā)階段中，單元或系統(tǒng)是否滿足在此階段開始時確定的條件。因此，它的意思是，我們正在制作的產(chǎn)品符合用戶要求嗎？因此，驗證的是產(chǎn)品開發(fā)過程質(zhì)量工作質(zhì)量。驗證活動也是圍繞

32、三個根本過程來進(jìn)行，審查、度量和配置管理。軟件工程的質(zhì)量保證過程軟件質(zhì)量保證傳統(tǒng)的軟件質(zhì)量保證的活動技術(shù)方法的應(yīng)用正式技術(shù)評審的實施軟件測試標(biāo)準(zhǔn)的執(zhí)行修改的控制度量記錄和記錄保存現(xiàn)代方法基于架構(gòu)的迭代和增量開發(fā)配置管理軟件確認(rèn)過程1：測試根據(jù)不同的軟件生命周期定義，測試的階段、方法和類型構(gòu)成一個層次結(jié)構(gòu)，如以下圖： V模型中的過程從左到右，描述了根本的開發(fā)過程和測試行為。V模型的價值在于它非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。 測試與開發(fā)階段的對應(yīng)V模式單元測試 單元測試的內(nèi)容主要是： 算法邏輯、數(shù)據(jù)定義的理解和使用、接口、各種C

33、ASE路徑、邊界條件、錯誤處理等。 單元測試的目的通常是: 在開發(fā)環(huán)境中，程序設(shè)計工程師為了檢查單元程序模塊內(nèi)部的邏輯、算法和數(shù)據(jù)處理結(jié)果的正確性等。單元測試通常由負(fù)責(zé)編碼的工程師自己在代碼完成后測試，也有在工程組內(nèi)，由工程師相互交叉測試。 調(diào)試與測試的最大的不同點是二者的目的和視角的區(qū)別： 調(diào)試包括查找BUG、定位BUG、修改并最終確認(rèn)BUG已經(jīng)被修復(fù)的軟件故障排除過程。 測試是在一個相對獨立的環(huán)境下測試應(yīng)盡可能地模擬運行環(huán)境，調(diào)試是在開發(fā)環(huán)境，運行系統(tǒng)單元，觀察和記錄運行結(jié)果，對結(jié)果進(jìn)行獨立評價的過程。 單元測試模塊測試 實際上，在單元測試級，一般工程組很難做到把調(diào)試與測試分開。因為二者的

34、工作內(nèi)容比較接近，擔(dān)負(fù)人常常是一個人，環(huán)境區(qū)別并不大或者重新搭建環(huán)境在時間、本錢和人力上，都比較困難。這些都是一般工程組并沒有獨立的單元測試的原因。 將單元測試與模塊調(diào)試合并可能帶來的問題是：1單元測試沒有任何記錄和文檔。少有筆頭勤快的工程師，會把他每天測了什么、改了什么，記錄下來。軟件工程師要的就是沒有BUG的程序，任何中間結(jié)果都是垃圾。2由于調(diào)試的目標(biāo)是獲得沒有故障的程序，因此，與功能無關(guān)的程序?qū)傩酝缓雎?，或者要到集成測試、確認(rèn)測試時才被發(fā)現(xiàn)。例如：命名標(biāo)準(zhǔn)、程序形式標(biāo)準(zhǔn)等。 不管怎么說，現(xiàn)實情況，單元測試與模塊調(diào)試經(jīng)常是混為一談的，要想改變，也不太容易。 由于單元測試在工程組中，常常

35、由編碼工程師完成，工程經(jīng)理的管理一般并不深入到單元測試層。 集成測試子系統(tǒng)測試集成測試又稱組裝測試，它是在單元測試完成后，組裝為一個子系統(tǒng)后，對以下只有組裝后才能發(fā)生和測試到的問題，進(jìn)行檢查：1組裝后一個模塊對一個模塊的影響；2合并功能是否是預(yù)期的；3獨立的誤差在合并后的變化，是擴大還是減小，是否在可接受的范圍內(nèi)；4實際的接口測試；包括：模塊之間對實際銜接的標(biāo)準(zhǔn)、時序?qū)崟r性、應(yīng)答響應(yīng)、容錯與錯誤處理等；5模塊間的資源競爭等。 集成測試也很重視集成的階段性。最壞的情況是系統(tǒng)只有一次集成，就是系統(tǒng)全部模塊完成后進(jìn)行集成。實際上，這就像一部汽車，直到要出廠時，才來一次總測試。而當(dāng)你每天生產(chǎn)一部完全不

36、同規(guī)格、型號的汽車時，這個時候的測試，可能是非常要命的。 比較好的方法是通常采用的增量組裝法，包括自頂向下或自低向上的增量組裝。分階段的增量組裝測試，可以解決一次集成，問題的隔離和區(qū)分不易的困難。 確認(rèn)測試系統(tǒng)測試 確認(rèn)測試的目的是按照與用戶確認(rèn)的軟件需求規(guī)格說明書的要求，檢查系統(tǒng)的需求實現(xiàn)。確認(rèn)需求的測試依據(jù)是需求階段產(chǎn)生的測試腳本測試用例。 國內(nèi)工程組的現(xiàn)實情況有以下幾種：1沒有確認(rèn)測試；2沒有獨立確實認(rèn)測試，測試與設(shè)計、編碼不別離；3有獨立確實認(rèn)測試，但測試用例是設(shè)計和編碼人員寫的，因此，獨立測試人員相當(dāng)于按設(shè)計和編碼人員的設(shè)計思路再測一遍。 上述這些情況，就喪失了確認(rèn)測試的大局部意義。

37、正確確實認(rèn)測試是獨立的測試組中，具有相應(yīng)知識的測試設(shè)計師，根據(jù)需求規(guī)格說明書，并依據(jù)該軟件在用戶方面將會是在什么環(huán)境下，用戶將如何使用該軟件，來設(shè)計測試方案和測試用例，安排測試人員進(jìn)行測試。很顯然，現(xiàn)實離理想的距離還比較遙遠(yuǎn)。 確認(rèn)測試還包括軟件經(jīng)修改后的再測試回歸測試。回歸測試是對已測試并發(fā)現(xiàn)故障的局部，修改后進(jìn)行再測試。回歸測試不應(yīng)修改測試程序、測試內(nèi)容或測試標(biāo)準(zhǔn)。它與正常測試不同的僅是：它可能并不需要再完整地走一遍所有確實認(rèn)測試，而是小心地選擇局部確認(rèn)測試程序，選擇的標(biāo)準(zhǔn)是不減低原標(biāo)準(zhǔn)的整體要求。 測試和測試 為了實際檢驗軟件的功能和性能，有時，常邀請?zhí)囟ǖ挠脩魩椭囉脺y試系統(tǒng)正式發(fā)布前

38、的版本，請用戶對系統(tǒng)進(jìn)行評價。這就是通常所說的測試和測試。測試是由一個用戶在開發(fā)者的場所，在開發(fā)者指導(dǎo)下進(jìn)行的測試。開發(fā)者記錄下問題和錯誤，是在開發(fā)者“控制下的測試。測試是用戶的環(huán)境中，開發(fā)者可能并不在現(xiàn)場，由用戶“活用系統(tǒng)情況下的測試。用戶記錄下問題，報告給開發(fā)者。在商用套裝軟件中，這種情況比較多見，在行業(yè)應(yīng)用系統(tǒng)中，由于現(xiàn)實環(huán)境并不允許不成功的軟件直接投入使用，用戶也沒有參與測試義務(wù)、時間和資源的投入和配合的積極性，因此，這種測試很少發(fā)生。 驗收測試在行業(yè)應(yīng)用軟件環(huán)境中，驗收測試是工程過程非常重要的一環(huán)，也是工程經(jīng)理非常關(guān)注的一項工作。驗收測試與確認(rèn)測試非常相似，所不同的是，確認(rèn)測試是工程

39、組或組織內(nèi)部的測試，驗收測試是用戶主導(dǎo)、現(xiàn)場參與、現(xiàn)場環(huán)境下的測試。驗收測試通常由工程組先提出測試大綱，定義測試目的、范圍、方法、測試用例、預(yù)期結(jié)果、驗收標(biāo)準(zhǔn)等。經(jīng)用戶同意批準(zhǔn)，可能包括用戶的修改、增加后，確定測試時間，開始進(jìn)入驗收測試。用戶在完成按測試用例的測試后，在測試記錄上逐條確認(rèn)、簽字，最后，在測試報告上簽字，完成驗收測試。一般地、驗收測試報告是工程初驗、終驗的依據(jù)和主要驗收形式。 單元測試與驗收測試 單元測試和驗收測試沒有什么區(qū)別？單元測試可以類比為一個建筑的質(zhì)檢人員對建筑進(jìn)行的檢測， 他關(guān)注的重點是建筑的內(nèi)部結(jié)構(gòu)、地基、框架以及墻壁是否垂直等。他的檢測是要保證建筑的各個局部是正常的

40、、平安的，換句話說，就是要保證施工滿足建筑上面的質(zhì)量標(biāo)準(zhǔn)。驗收測試可以類比為建筑的使用者來對建筑進(jìn)行的檢測。他關(guān)心建筑的外觀是否美觀、各個房間的大小是否適宜，窗戶的位置是否適宜，是否能夠滿足家庭的需要等。這里，建筑的使用者執(zhí)行的就是驗收測試，他是從用戶的角度出發(fā)的。正是這種角度的不同決定了單元測試和驗收測試之間的區(qū)別。它們是對系統(tǒng)的不同的方面進(jìn)行的測試，二者是互相補充的。不管我們在系統(tǒng)的構(gòu)建中使用了多么聰明的方法，不管我們的系統(tǒng)是多么的靈活，但是首先我們的產(chǎn)品必須是可用的，否那么我們所做的就是浪費時間，從這一點上來說驗收測試要比單元測試顯得更加重要。 測試方法測試所處的階段不同，方法也不同：白

41、盒測試在單元測試階段，由于測試者對被測對象的內(nèi)部結(jié)構(gòu)、邏輯思路、接口關(guān)系等比較熟悉，一般采取白盒測試的方法，它是根據(jù)模塊的內(nèi)部邏輯，進(jìn)行測試設(shè)計的方法。有些集成測試也采用白盒方法，關(guān)鍵看集成階段的劃分。黑盒測試在集成測試以至此后的各階段，測試設(shè)計和測試人員，對被測對象的內(nèi)部結(jié)構(gòu)不了解也不需要了解，他的目的是按需求功能進(jìn)行確認(rèn)。因此，黑盒測試是嚴(yán)格按軟件需求進(jìn)行測試設(shè)計的方法。代碼走查 測試類型在不同階段，測試的類型也不相同，常有的測試類型是：1功能測試：軟件實現(xiàn)的功能是否符合需求規(guī)格說明書中定義的功能；2性能測試：軟件在規(guī)定配置下的性能是否符合需求規(guī)定；3算法測試：確認(rèn)實現(xiàn)的算法的正確性；4正

42、向測試：按照用戶正常的理解、操作方式、思維和使用習(xí)慣使用軟件，得到的結(jié)果是否與需求一致。5逆向測試：如果不按用戶正常的理解、操作發(fā)生、思維和使用習(xí)慣使用軟件，軟件是否能正確地進(jìn)行處理。如：無效操作、錯誤的數(shù)據(jù)輸入處理、非法進(jìn)入等。6邊界測試：按軟件的限制、假設(shè)條件的邊界輸入，進(jìn)行測試。7配置測試：對軟件環(huán)境進(jìn)行配置變化，軟件需求實現(xiàn)，特別是性能實現(xiàn)是否能符合需求規(guī)定要求。8負(fù)載測試：在業(yè)務(wù)處理量、數(shù)據(jù)負(fù)載量、通訊負(fù)載量到達(dá)何種情況，系統(tǒng)的性能變化和承載能力情況。測試方案測試估計在擬定測試方案時，首先需要對以下情況，做出估計：1 完成測試設(shè)計所需要的工作量：2 完成測試設(shè)計所需要的工作時間：3

43、完成測試所需要的時間：根據(jù)以上三個局部的結(jié)果，我們已經(jīng)知道了測試的范圍、內(nèi)容、任務(wù)分配、時間等，這樣，工程經(jīng)理可以能比較充分地規(guī)劃資源，制訂出一份比較全面和切實的測試工作方案。測試分配測試方案確定了測試的范圍、內(nèi)容和估計時間，根據(jù)WBS方法，測試方案還應(yīng)說明具體測試任務(wù)的分解和測試工作的分配。測試組的成員根據(jù)分工，各自完成一局部測試任務(wù)。測試組與工程開發(fā)組還需要保持一定的同步，使測試與開發(fā)、修改在協(xié)調(diào)的步驟下進(jìn)行，以節(jié)約珍貴的工程總時間。測試確認(rèn)測試用例名稱工號權(quán)限被測子系統(tǒng)名卡/號資源管理測試用例來源 公司測試組 內(nèi)部測試抽查參考文檔序號測試用例描述XWYY001測試目的能否正確識別合法的操

44、作員進(jìn)入應(yīng)用系統(tǒng)測試步驟1.啟動“卡/號資源管理”應(yīng)用程序。2. 輸入系統(tǒng)中不存在的工號1000，再輸入密碼12345，檢查能否進(jìn)入系統(tǒng)。3.輸入系統(tǒng)中存在的工號nj001和正確的密碼，檢查能否進(jìn)入系統(tǒng)。4. 輸入系統(tǒng)中存在的工號yd002和正確的密碼，檢查能否進(jìn)入系統(tǒng)。輸入數(shù)據(jù)描述1、工號1000根本不是系統(tǒng)合法的工號。2、工號nj001是前臺營業(yè)受理的工號，不能進(jìn)行卡號資源管理系統(tǒng)。3、工號yd002是卡號資源管理系統(tǒng)的工號。期望的結(jié)果1. 工號1000無論如何進(jìn)入不了系統(tǒng)，系統(tǒng)提示無此員工2. 工號nj001也不能進(jìn)入系統(tǒng)，系統(tǒng)提示該操作員無權(quán)執(zhí)行卡號資源管理系統(tǒng)3工號yd002可以進(jìn)入

45、系統(tǒng)，并能打開所有的功能菜單測試結(jié)果描述相符測試人員測試日期2003-03-08復(fù)測人員復(fù)測日期備注測試用例： 測試用例由誰設(shè)計？ 設(shè)計測試用例的依據(jù)是什么？ 測試設(shè)計的重點是什么？測試報告： 收集齊上述的所有測試用例，構(gòu)成了測試報告的根本要件。 測試報告是對所有測試用例測試過程的總結(jié)。 在測試報告中，應(yīng)反映： 1測試中出現(xiàn)問題的統(tǒng)計匯總和分析； 2未解決問題的匯總和解決方案建議； 3回歸測試的統(tǒng)計和分析度量 ； 4對測試方案的總結(jié)或修改。測試過程組織一個獨立的測試小組為例，測試過程一般如下：1測試準(zhǔn)備：制定人員、環(huán)境、工具、培訓(xùn)和外部支持方案。2測試方案：確定測試策略、建立測試方案。3測試用

46、例：建立測試順序樹、確定測試的優(yōu)先級、詳細(xì)列出測試程序和測試數(shù)據(jù)，設(shè)計測試用例。4測試環(huán)境：了解需求、搭建環(huán)境、安裝備份和恢復(fù)程序，記錄初始環(huán)境、測試環(huán)境、恢復(fù)環(huán)境等。5測試執(zhí)行：從測試方案復(fù)審測試方案進(jìn)度表、恢復(fù)測試執(zhí)行環(huán)境。6結(jié)果分析：執(zhí)行結(jié)果分析、度量。7測試報告：錯誤趨勢圖、測試變動指示、產(chǎn)品檢查點建議。軟件審查的概念回憶：我們在上節(jié)介紹軟件確實認(rèn)和驗證過程時，已經(jīng)介紹了軟件驗證的三個過程是：審查、測量和配置管理。同時，我們也談到，驗證與確認(rèn)的區(qū)別是，確認(rèn)是在整個軟件系統(tǒng)完成交付前或某模塊完成交付前的檢查，它的檢查點是交付前。而驗證貫穿于整個開發(fā)過程，是對過程確實認(rèn)。因此，驗證的范圍包

47、括了整個開發(fā)過程，它是軟件質(zhì)量保證并持續(xù)改進(jìn)的強大工具。 什么是審查，審查是一個正式的、嚴(yán)格的、具有深度的技術(shù)評審過程。因此，評審的目的是： 1在軟件開發(fā)過程中，盡早可能地發(fā)現(xiàn)問題，特別是過程性的問題； 2確保對需求保持一致的意見； 3驗證任何修改和變更滿足預(yù)先定義的準(zhǔn)那么； 4為組織提供產(chǎn)品在質(zhì)量和過程方面是否有效的實際數(shù)據(jù)； 5使團隊成員之間在技術(shù)上建立相互的了解； 6增加軟件確認(rèn)測試的有效性； 7提高優(yōu)秀軟件工程師的水準(zhǔn)。軟件評審軟件評審在軟件開發(fā)的各個階段，都要采用評審的方法，以便及早發(fā)現(xiàn)軟件的缺陷。軟件評審的必要性1. 從技術(shù)角度進(jìn)行的審查是保證軟件質(zhì)量的重要措施由于人的認(rèn)識不可能百

48、分之百地符合客觀實際，因此生命周期每個階段的工作中都可能發(fā)生錯誤。由于前一階段的成果是后一階段工作的根底，前一階段的錯誤自然會導(dǎo)致后一階段的工作結(jié)果中有相應(yīng)的錯誤，而且錯誤會積累起來，如以下圖所示。原始要求正確的規(guī)格說明錯誤的規(guī)格說明需求分析設(shè)計正確的設(shè)計錯誤的設(shè)計對錯誤說明的設(shè)計編碼正確編碼錯誤編碼對錯誤設(shè)計的編碼對錯誤說明的編碼測試正確功能可改正的錯誤不可改正的錯誤潛伏的錯誤不完善的軟件產(chǎn)品軟件評審2. 技術(shù)審查也是降低本錢的一個重要舉措由于再后期改正一個錯誤比在早期改正同一個錯誤需要付出的代價高二至三個數(shù)量級，所以越在早期發(fā)現(xiàn)的錯誤越容易改正，代價越低。3. 在技術(shù)審查合格之后，再進(jìn)行管

49、理復(fù)審，可以使管理人員專心從管理角度對開發(fā)工作進(jìn)行審查，而不必顧及技術(shù)問題軟件評審軟件評審的方法成立評審小組，組員包括：組長、作者、評審員1. 組長組長是小組的核心，最后由技術(shù)水平較高且沒有直接參與這項工程的人擔(dān)任。組長的任務(wù)是組織和領(lǐng)導(dǎo)技術(shù)審查的全過程，如安排會議日程，分發(fā)必要的文檔資料，主持審查會議，確保審查全面、公正。2. 作者作者是被審查文檔或程序的編寫者。如果開發(fā)小組由一個小組集體完成，通常由技術(shù)小組負(fù)責(zé)人代表小組參加審查小組。作者的責(zé)任是答復(fù)技術(shù)上的問題3. 評審員評審員也應(yīng)由技術(shù)專家擔(dān)任。通常一個是前一階段的技術(shù)骨干，另一個是后一階段的骨干。評審員的任務(wù)是分別從各自的角度，公正客

50、觀地評價被審查的軟件產(chǎn)品。軟件評審軟件評審的步驟準(zhǔn)備簡要介紹情況閱讀被評審的文檔如檢查表開評審會返工復(fù)審軟件開發(fā)的各個階段，其檢查表的內(nèi)容不一樣。6.3.1 軟件審查的準(zhǔn)備評審人：審查一般由一個審查小組或?qū)彶槲瘑T會負(fù)責(zé)進(jìn)行，審查小組內(nèi)，應(yīng)有以下角色構(gòu)成： 1主持審查活動的主審員； 2被審查產(chǎn)品負(fù)責(zé)人，包括產(chǎn)品經(jīng)理、技術(shù)經(jīng)理、質(zhì)量經(jīng)理等； 3負(fù)責(zé)對被審查產(chǎn)品進(jìn)行講解和解釋的主講人； 4來自各有關(guān)部門的審查員； 5記錄員； 6 工程經(jīng)理 工程經(jīng)理應(yīng)該參與軟件的審查過程，關(guān)注審查結(jié)果，但不一定要參加審查會議。這要看審查的級別。如果是組織內(nèi)的工程級審查，工程經(jīng)理作為被審查產(chǎn)品的負(fù)責(zé)人，應(yīng)參加審查會議，

51、否那么，應(yīng)該由具體的產(chǎn)品、技術(shù)或質(zhì)量經(jīng)理去參加這樣的會議。 被審產(chǎn)品的負(fù)責(zé)人參加這樣的會議，不是為了解釋審查中發(fā)現(xiàn)的缺陷，及其責(zé)任，進(jìn)行辯白，而只是如實地向?qū)彶樾〗M介紹產(chǎn)品為什么要這樣做，和做了什么。審查的目的不是為了追究什么人的責(zé)任，而是為了改進(jìn)過程。如果把評審，引入到人與人之間的斗爭中去，那么完全喪失了評審，作為過程改進(jìn)手段的意義。評審內(nèi)容及要求，見下表：審查類型被審查項需提交的資料提交審查條件需求軟件需求規(guī)格說明書軟件需求規(guī)格說明書及在此之前有關(guān)的需求分析文檔、需求基線及批準(zhǔn)文檔確認(rèn)的需求、已經(jīng)被分析和形式化描述，需求基線已經(jīng)被確定 設(shè)計軟件設(shè)計說明軟件設(shè)計文檔設(shè)計完成編碼源代碼模塊源程

52、序代碼、設(shè)計文檔、組織的編碼標(biāo)準(zhǔn)與規(guī)范被審查模塊已經(jīng)編譯正確并完成獨立測試確認(rèn)測試測試記錄測試結(jié)果報告、質(zhì)量和驗收標(biāo)準(zhǔn) 系統(tǒng)確認(rèn)及回歸測試已經(jīng)完成 審查內(nèi)容 作為被審查對象的工程組，按照審查組的要求，提交被審查材料，接受審查。 作為審查員，應(yīng)該做什么準(zhǔn)備？ 首先，明確作為審查員的定角色位、職責(zé)。 審查員是那些具有相關(guān)知識和對被審查產(chǎn)品具有一定熟悉程度的，但不一定就是直接從事相同崗位有時，還特別需要交叉換位的人員。在參加審查前，他必須花一定的時間和精力，來了解產(chǎn)品，并能通過閱讀提交的資料，了解產(chǎn)品與文檔、標(biāo)準(zhǔn)和標(biāo)準(zhǔn)之間的差異。 因此，他在審查中的責(zé)任是：1必須完全熟悉要審查的產(chǎn)品和產(chǎn)品所依據(jù)的文

53、檔和標(biāo)準(zhǔn)；2對照產(chǎn)品和文檔，鑒別其中的差異；3客觀地評價差異，識別是屬于實現(xiàn)程度差異、缺陷，還是錯誤；4判斷差異是實現(xiàn)的個表達(dá)象，還是過程問題；5以對產(chǎn)品而不是對人的態(tài)度，對差異進(jìn)行評估和分析；6向主審員報告審查結(jié)果和分析意見。審查員的職責(zé)軟件審查的過程 在審查開始之前，審查組與被審查工程的有關(guān)人員，產(chǎn)品經(jīng)理、技術(shù)經(jīng)理、質(zhì)量經(jīng)理和工程經(jīng)理們開一個“審查開工會，主審員向被審查對象的有關(guān)人員介紹本次審查的目的、對象、范圍和內(nèi)容，有必要的話，花一點時間介紹一下審查方法，使得審查員和被審查工程的有關(guān)人員，在審查過程中易于溝通和理解。當(dāng)被審查有關(guān)人員知道不是同意審查的主要內(nèi)容后，主審員把審查工作，按分工

54、，分配給各審查員，并請工程組指定有關(guān)的配合人員。會議約定好完成分組審查的時間，即召開審查匯報會的時間。 獲得審查資料的審查員，可以開始從看資料如手，進(jìn)入審查階段。如果需要實際測試和運行檢查，工程組要配合安排機器時間、軟件演示等與操作有關(guān)的環(huán)境。 審查員經(jīng)過一段時間的工作，已經(jīng)對所分工的局部，通過閱讀資料、實際查看等，獲得了必要的信息，有關(guān)的疑問，通過向工程組實際詢問，解釋了不清楚的地方。審查員對差異，已經(jīng)做好了記錄。主審員按時間和進(jìn)度，可以招集審查匯報會。在審查匯報會上，審查員匯報分組審查中發(fā)現(xiàn)的潛在的還沒有定論的錯誤、缺陷和差異。審查小組對每一個問題進(jìn)行討論，并爭取獲得一致的意見。必要時，可

55、以請工程組再做解釋。記錄員此時應(yīng)詳細(xì)記錄討論的過程和各自的意見，并確保這些記錄的完整性、正確性和真實性。 如果一次會議不能解決爭論的問題，或者需要再擴大參加人員的范圍，或者需要再做測試，那就那樣去做?；蛘邔彶榻M發(fā)現(xiàn)問題已經(jīng)非常嚴(yán)重，已經(jīng)超出了軟件評審的范圍，那么，應(yīng)立即停止評審，向有關(guān)上級報告問題，以便上級做出重大改進(jìn)的措施。 審查結(jié)果的發(fā)布是一個非技術(shù)的敏感問題。什么性質(zhì)的結(jié)果可以發(fā)布，在多大范圍內(nèi)發(fā)布。審查結(jié)果如果比較滿意，它的發(fā)布將對工程組是一個正向的鼓勵，是相關(guān)人員能力的象征。負(fù)面的審查結(jié)果可能引來更大的爭議和動亂。因此，審查小組和工程經(jīng)理，要充分溝通，從積極的方面，使用審查結(jié)果。 任

56、何審查結(jié)果都不是針對個人的，但是任何工作都是由具體個人來負(fù)責(zé)和承擔(dān)相應(yīng)責(zé)任的。因此，審查結(jié)果的難處，就在這句話的二面性。軟件審查的過程需求審查需求文檔與需求屬性第二章已經(jīng)介紹 需求審查表問題清單 1 需求是否認(rèn)義了要向用戶展示的全部信息？2 需求是否論述了系統(tǒng)對用戶錯誤操作的反映？3 每一需求項的描述是否清楚、簡潔和沒有二意性？4 每一項需求是否都是可測試的？5 需求是否有隱含或暗示的功能理解？6 需求項之間是否有自相矛盾的地方？7 需求是否有應(yīng)該論述但沒有提及的地方？8 需求對實時性、精確度、負(fù)載能力等有沒有定義？9 需求是否包括了性能需求、質(zhì)量需求等非功能需求？10 如果需求涉及復(fù)雜的關(guān)聯(lián)

57、關(guān)系、復(fù)雜的算法、復(fù)雜的決策 機制，用戶能完全理解嗎？11 需求對軟件升級、版本變更是否有明確的承諾？12 需求文檔是否含有不必要的設(shè)計細(xì)節(jié)？13 是否可以根據(jù)需求，開發(fā)出適當(dāng)?shù)暮屯暾臏y試用例集？14 需求的假設(shè)和限制條件是否明確？需求審查需求審查過程 我們在上一節(jié)，已經(jīng)一般地討論過審查的過程。需求審查也遵循這樣的過程：組織審查組；收集工程組提交的被審查資料；確定審查日期；審查員在獲得審查任務(wù)分配和開始工作，包括：對資料的閱讀和評審、做實地的檢查、調(diào)查和詢問、記錄并報告；參加評審會議并報告自己的發(fā)現(xiàn)和分析。 審查小組首先檢查審查活動是否充分和沒有偏差、疏漏。審查員對問題的認(rèn)識有沒有片面和主觀

58、。主審員根據(jù)自己的經(jīng)驗，可能會對年輕的審查員要求做出補充調(diào)查。通過討論，審查小組爭取對問題取得一致的意見，并形成審查報告。 追蹤與改正 審查的目的是監(jiān)督工程組對軟件的品質(zhì)，保持良好的狀態(tài)和不斷地改進(jìn)。因此，審查小組有責(zé)任跟蹤工程組對審查結(jié)果的利用情況。 關(guān)注工程組的改進(jìn)，是工程經(jīng)理比關(guān)注審查結(jié)果更重要的事情。設(shè)計審查概要設(shè)計審查表問題清單 詳細(xì)設(shè)計審查表問題清單 設(shè)計審查的目標(biāo)： 概要設(shè)計重點審查以下幾個方面概要設(shè)計針對需求 1概要設(shè)計對需求的完整實現(xiàn)； 2概要設(shè)計與需求的一致性； 3概要設(shè)計向需求的反向可追蹤； 4概要設(shè)計中，對系統(tǒng)結(jié)構(gòu)設(shè)計的邏輯性、合理性和可擴展性； 由于概要設(shè)計是直接銜接

59、需求的，因此，概要設(shè)計審查更多地是把設(shè)計與需求相銜接。 在詳細(xì)設(shè)計中，應(yīng)重點審查以下方面詳細(xì)設(shè)計針對實現(xiàn) 1設(shè)計應(yīng)符合組織即定的標(biāo)準(zhǔn)； 2設(shè)計結(jié)果對下一階段的編碼是可用的。 由于詳細(xì)設(shè)計直接提供編碼實現(xiàn)，因此，在組織內(nèi)，應(yīng)對詳細(xì)設(shè)計的“粒度做出規(guī)定。這樣，即明確詳細(xì)設(shè)計與代碼實現(xiàn)的界面，同時，也是編碼標(biāo)準(zhǔn)化的工作根底。在這方面，應(yīng)結(jié)合實際，進(jìn)行研究。代碼審查 代碼的審查與具體實現(xiàn)工具有關(guān)，而且與具體實現(xiàn)工具的版本有關(guān)，因此，我們在這里就不具體討論代碼審查的內(nèi)容。有不少文章具體討論代碼的標(biāo)準(zhǔn)化和設(shè)計技巧，可以作為審查的范本如果必要的話。 代碼審查的一個方法是走查。就是由審查人員“讀工程師寫的代碼

60、，然后對照“標(biāo)準(zhǔn)進(jìn)行檢查，是對軟件文檔的一種書面檢查。它通過人工模擬執(zhí)行源程序的過程，檢查軟件設(shè)計的正確性。人工模擬也像計算機執(zhí)行那樣，可以仔細(xì)推敲、校驗和核實每一步的執(zhí)行結(jié)果，進(jìn)而確定其執(zhí)行邏輯、控制模型、算法和使用參數(shù)與數(shù)據(jù)的正確性。 走查是一件非常艱苦的工作，同時是需要非常大的毅力和記憶力的工作。因為一個系統(tǒng)程序量之大，組織的規(guī)那么和要求之多。審查員要做的是N的N次方的核對?，F(xiàn)在也有一些計算機程序，按一定的規(guī)那么，幫助審查員“讀程序，并挑出有的可以做簡單的修改毛病，VB就有這樣的程序。如果沒有計算機程序的幫助，審查員會“瘋掉的。測試審查測試審查是對測試結(jié)果進(jìn)行審查，它審查的內(nèi)容包括： 1