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

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

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

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

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

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

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

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

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

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

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

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

13、on Efficiency)。程序運行效率。10可擴充性(expandability)。能夠對結構設計、數據設計和過程設計進行擴充的程度。1.1.2 軟件質量評價的準那么11通用性(generality)。程序部件潛在的應用范圍的廣泛性，即部件可重用。12硬件獨立性(hardware independence)。軟件同支持他運行的硬件系統不相關的程度。13檢測性(instrumentation)。監視程序的運行，一旦發生錯誤時，能明確地標識錯誤的程度。14模塊化(modularity)。程序部件的功能獨立性。15可操作性(operability)。操作一個軟件的難易程度。16平安性(secur

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

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

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

17、問題，糾錯的代價很高。軟件質量評價準那么 4、性能性能通常是指軟件的“時間-空間效率，而不僅是指軟件的運行速度。人們總希望軟件的運行速度高些，并且占用資源少些。 性能優化的關鍵工作是找出限制性能的“瓶頸 可以通過優化數據結構、算法和代碼來提高軟件的性能。 5、易用性易用性是指用戶使用軟件的容易程度?，F代人的生活節奏快，圖方便。所以把易用性作為重要的質量屬性對待無可非議。 導致軟件易用性差的根本原因 ：教育缺陷：沒有開設人機工程學、美學、心理學這些必修課，大局部開發人員不知道如何設計易用的軟件產品。開發人員犯了“錯位的毛?。核詾橹灰约河闷饋矸奖悖脩粢簿蜁M意。 軟件的易用性要讓用戶來評價。

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

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

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

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

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

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

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

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

26、SCM的度量和度量準那么圖表分析軟件剩余問題剩余變更和錯誤密度1.1.4 軟件質量度量的實施在確定要對一個軟件系統進行度量之后，一般，采取以下5個步驟，來實施對該軟件的度量： 1確定軟件質量需求； 在用戶需求中，除功能需求外，還有非功能需求，包括：質量需求、環境需求、設計約束、開發策略等。質量需求是用戶比較關心的內容。但是，我們已經知道，軟件的功能需求確實定，存在一定的難度。而非功能需求確實定，那么難度更大。這些困難包括：需求如何獲取，需求沖突如何協調、需求確實認和變更的授權等。過程： 需求獲?。菏紫?，你要理解用戶的需求，區分哪些是質量需求，把這些需求記錄下來，獲得用戶確實認。 需求分析：拿到

27、用戶確認的需求后，你可以開始把用戶的質量需求與我們設定的質量特性聯系起來，一直區分到子特性。這種聯系，就是把用戶語言描述的需求，轉變為計算機工程師語言的需求。建立了這種關聯后，可以根據分類，分級，確定直接度量。 1.1.4 軟件質量度量的實施2確定直接度量 直接度量就是實際的軟件質量測量活動，它的輸入是軟件或軟件過程，輸出是一個測量值。它通過執行一系列的任務，獲得一個質量值。 例如：對一個沒有經過培訓的用戶，讓他使用軟件系統的某一功能，在界面提示、聯機幫助、使用手冊的幫助下，他學會掌握該功能所花的時間。而用戶需求對此項指標的要求目標和現實系統所到達的實際值比方：10個人次測量后統計意義上的的比

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

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

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

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

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

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

34、工作內容比較接近，擔負人常常是一個人，環境區別并不大或者重新搭建環境在時間、本錢和人力上，都比較困難。這些都是一般工程組并沒有獨立的單元測試的原因。 將單元測試與模塊調試合并可能帶來的問題是：1單元測試沒有任何記錄和文檔。少有筆頭勤快的工程師，會把他每天測了什么、改了什么，記錄下來。軟件工程師要的就是沒有BUG的程序，任何中間結果都是垃圾。2由于調試的目標是獲得沒有故障的程序，因此，與功能無關的程序屬性往往被忽略，或者要到集成測試、確認測試時才被發現。例如：命名標準、程序形式標準等。 不管怎么說，現實情況，單元測試與模塊調試經常是混為一談的，要想改變，也不太容易。 由于單元測試在工程組中，常常

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

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

37、正確確實認測試是獨立的測試組中，具有相應知識的測試設計師，根據需求規格說明書，并依據該軟件在用戶方面將會是在什么環境下，用戶將如何使用該軟件，來設計測試方案和測試用例，安排測試人員進行測試。很顯然，現實離理想的距離還比較遙遠。 確認測試還包括軟件經修改后的再測試回歸測試。回歸測試是對已測試并發現故障的局部，修改后進行再測試?；貧w測試不應修改測試程序、測試內容或測試標準。它與正常測試不同的僅是：它可能并不需要再完整地走一遍所有確實認測試，而是小心地選擇局部確認測試程序，選擇的標準是不減低原標準的整體要求。 測試和測試 為了實際檢驗軟件的功能和性能，有時，常邀請特定的用戶幫助試用測試系統正式發布前

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

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

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

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

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

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

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

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

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

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

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

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

50、觀地評價被審查的軟件產品。軟件評審軟件評審的步驟準備簡要介紹情況閱讀被評審的文檔如檢查表開評審會返工復審軟件開發的各個階段，其檢查表的內容不一樣。6.3.1 軟件審查的準備評審人：審查一般由一個審查小組或審查委員會負責進行，審查小組內，應有以下角色構成： 1主持審查活動的主審員； 2被審查產品負責人，包括產品經理、技術經理、質量經理等； 3負責對被審查產品進行講解和解釋的主講人； 4來自各有關部門的審查員； 5記錄員； 6 工程經理 工程經理應該參與軟件的審查過程，關注審查結果，但不一定要參加審查會議。這要看審查的級別。如果是組織內的工程級審查，工程經理作為被審查產品的負責人，應參加審查會議，

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

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

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

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

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

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

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

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

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

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