## 質量管理 ### 管什么？ 經過多年的發展，質量管理已經有了一套基本的理論和方法。質量管理包括質量保證和質量 控制兩大類。質量保證是指在項目過程中實施的有計劃、有系統的活動，確保滿足相關的標 準，典型的例子是評審和審計。質量控制是指采取適當的方法監控項目結果，確保結果符合 質量標準，典型的例子就是測試以及之后的缺陷跟蹤。 在IT行業軟件開發領域中，常見的公認的質量活動包括：配置管理、評審、測試以及缺陷跟 蹤。 * 評審：檢查項目中間產品，早期發現缺陷以減少后期項目返工和修改的工作量。 * 測試：直接檢測軟件產品中的缺陷，確保符合質量要求。一般通過單元測試、集成測試、 系統測試和性能測試實現。 * 缺陷跟蹤：記錄和追蹤缺陷從發現到解決的整個過程，確保所有的結論都有結論。 * 審計：對項目工作過程進行檢查，確保所有活動按照規程進行。 * 變更控制：版本本更控制，也是重要的一環。 * 配置管理：記錄中間和最終產品（配置項）的變更歷史。 質量經理在項目中的職責如下： * 貫徹公司的質量管理規范，負責質量管理過程中的檢查和指導。 * 負責制定項目開發/測試環境的標準和規范。 * 負責項目的配置管理，通過權限控制和備份機制確保交付物的完備和安全。 * 負責組織同行評審，確保中間交付物的質量。 * 制定測試策略和測試計劃，組織測試，確保最終交付成果的質量。 ### 項目配置管理 項目配置管理是一項看不見的財富，可以在無形中減少因為版本意外等開發中出現的問題導 致的返工、重做等資源浪費。 **Q: 什么是項目配置管理？** 配置管理是在某一特定時點，確定軟件配置的一個過程，通過對已標識的軟件配置的一個過 程，通過對已表示的軟件的配置的變更進行系統控制，從而在整個軟件生命周期中保持軟件 的整體性和可追溯性。 **Q: 配置管理的具體要做什么？** 通常來說，軟件配置管理主要通過計劃、標識和控制變更和發布配置狀態報告來協調軟件開 發，目的是使錯誤率達到最小并最有效地提高生產效率。 ### 質量評審 評審的目的是盡早發現問題，一團和氣的評審會完全達不到發現問題的目的。 **Q: 評審中的角色有哪些？** 首先要把評審中設計到的各個人員確認下來。評審過程中涉及的角色主要有四種：責任人、 主審人、評審專家和記錄員。 主審人要先選定評審組的成員，然后再做評審的前期準備。在 評審過程中保證規范和高效， 評審結束后要將結果及時發布被評審相關人員。最后，還要對 評審中發現的問題追蹤，直 到問題關閉。 責任人就是要被評審的對象。他們在評審之前準備好資料，在評審過程中解答提出的問題。 對于發現的問題要積極修正后提交給主審人。 記錄員就是在評審過程中，把專家提出的問題都記錄下來，還要記錄責任人的回答信息，最 終要行程會議紀要，并且記錄評審結果。 評審專家要徹底了解被評審的資料，其任務是尋找這些資料中的缺陷，側重于發現問題而不 是解決問題。要保持客觀。 **Q: 評審的過程是什么？** 評審的過程分為計劃、預備會議、準備、評審會議和追蹤幾個階段。 * 計劃階段與項目計劃同步，也就是說項目中有哪些要評審在項目計劃中就已經提前定義好 了。 * 預備會議，針對要評審的資料對評審組進行培訓，并討論評審資料。 * 準備工作，是評審專家要徹底熟悉評審資料，以保證評審的質量和高效。 * 評審會議，是主審人和評審專家對項目資料中的錯誤和缺陷進行確認。 * 跟蹤，主審人要確保責任人采取必要的措施修正發現的錯誤。 一個評審反饋表如下：  ### 讓測試深入人心 保證質量最有效的措施就是測試。 **Q: 為什么要有多種測試呢？** 不同的測試是針對不同的開發活動來設置的。下面是軟件測試的一個『V模型』：  * 單元測試，主要是開發人員對編寫的代碼進行自測或相互進行交叉測試，用以檢查代碼是 否符合編碼規范，是否存在邏輯錯誤。 * 集成測試，將經過單元測試的模塊組裝成完整的程序。工作任務包括制定集成測試策略， 確定集成測試步驟，設計集成測試用例，然后逐一添加模塊進行測試。 * 系統測試，是為了驗證需求分析確定的功能是否被正確的實現，同時還要對安裝、部署、 適應性、安全性、界面等非功能性需求進行測試。 * 性能測試，用來測試系統是否滿足規定的性能需求。性能測試通常選擇一些典型的功能， 檢驗這些功能在大量用戶同時使用時是否穩定。 * 用戶驗收測試，目的是驗證需求與系統的匹配性，以及界面的友好性，響應時間等等。 ### 缺陷跟蹤 **Q: 為什么要進行缺陷跟蹤？** 缺陷跟蹤可以記錄測試結果，確定代碼質量，是確保問題得到解決的一個關鍵流程。其目的 是規范評審、測試、試運行等過程中發現缺陷的更改活動；跟蹤缺陷處理的各個環節、避免 缺陷修改失控和遺漏；如實的反映缺陷處理過程。 **Q: 怎么進行缺陷跟蹤？** 缺陷跟蹤的起點是各種發現缺陷的活動，發現缺陷之后就進入了缺陷的跟蹤流程，包括提交、 判斷、分發、修改、復核和關閉幾個關鍵步驟。 缺陷跟蹤除了記錄和跟蹤缺陷的修復過程，很重要的還有對缺陷進行分類、統計和分析。 缺陷的類型一般分為一下幾種： | 缺陷類型 | 描述 | 可能的缺陷來源 | | --- | --- | --- | | 用戶界面 | 用戶界面顯示或者操作存在問題 | 詳細設計 | | 架構 | 系統存在架構方面問題 | 架構設計、概要設計 | | 接口 | 系統內、外部接口錯誤，不能正常連接和工作 | 架構設計、概要設計 | | 業務功能 | 業務功能不完善、未實現或者出現錯誤 | 需求分析、需求規格 | | 系統功能 | 與業務無關，但是系統必須實現的功能不完整、未實現或者出現錯誤 | 架構設計、概要設計 | | 性能 | 系統的響應時間、吞吐量、并發量等不滿足需求 | 架構設計、概要設計、編碼 | | 可重用性 | 不滿足被其他系統或者模塊復用的要求 | 概要設計、編碼 | | 可移植性 | 不滿足可跨平臺移植或者部署的要求 | 概要設計、詳細設計 | 缺陷的嚴重性說明了缺陷給最終交付的系統或者產品可能造成的影響程度。其中A級影響程 度最大，E級最小。 | 嚴重性等級 | 描述 | | --- | --- | | A級（系統級） | 系統整體崩潰，或者不能穩定地連續工作 | | B級（應用級） | 部分應用或者子系統不能運行，或者不能穩定地連續工作 | | C級（業務級） | 導致業務流程終止，或者因結果錯誤、數據不一致失敗；因安全、容錯性和性能問題等非功能性問題影響使用 | | D級（操作級） | 不易于學習使用，界面操作困難；難以理解而不容易使用 | | E級（文檔級） | 安裝手冊、操作手冊、在線幫助等文檔不能提供幫助或 |