缺陷管理

什麼是缺陷？

軟件缺陷的定義
IEEE 1983 of IEEE Standard 729中對軟件缺陷做了一個標準的定義：

• 從產品內部看，軟件缺陷是軟件產品開發或維護過程當中所存在的錯誤、毛病等各類問題。
• 從外部看，軟件缺陷是系統所須要實現的某種功能的失效或違背。

軟件缺陷是指存在於軟件（程序、數據、文檔）中的那些不符合用戶需求的問題。

• 軟件未達到需求規格說明書代表的功能。（計算器說明書通常聲稱該計算器將準確無誤地進行加、減、乘、除運算。若是測試人員或用戶選定了兩個數值後，隨意按下了「+」號鍵，結果沒有任何反應。）
• 軟件出現了需求規格說明書指明不會出現的錯誤。（假如計算器說明書指明計算器不會出現崩潰、死鎖或者中止反應，而在用戶隨意按、敲鍵盤後，計算器中止接受輸入或沒有了反應。）
• 軟件的功能超出了需求規格說明書指明的範圍。（若在進行測試時，發現除了規定的加、減、乘、除功能以外，還可以進行求平方根的運算，而這一功能並無在說明書的功能中規定。）
• 軟件未達到需求規格說明書雖未指明而應該達到的目標。（若在測試過程當中發現，每當計算器重啓後，計算值就出現誤差，但軟件需求規格說明書未能指出在此狀況下應如何進行處理。）
• 軟件測試人員認爲軟件難以理解、不易使用、運行速度慢、或者最終用戶認爲很差。（測試人員或最終用戶發現計算器某些地方很差用，好比，按鍵過小、顯示屏在亮光下沒法看清等。）

所以軟件缺陷就是軟件產品中所存在的問題，最終表現爲用戶所須要的功能沒有徹底實現，沒有知足用戶的需求。
因此，缺陷不只僅是程序出了bug。缺陷>=bug。

軟件缺陷的表現形式

• 功能、特性沒有實現或部分實現。
• 設計不合理，功能特性不明確，邏輯不清楚或存在矛盾。
• 產品實際結果和所指望的結果不一致。
• 沒有達到需求規格說明書所規定的性能指標等。
• 運行出錯，包括運行中斷、系統崩潰、界面混亂等。
• 數據不正確、精度不夠、不完整或格式不統一。
• 用戶不能接受的其餘問題，如存取時間過長、界面不美觀。
• 硬件或系統軟件上存在的其餘問題

軟件缺陷產生的緣由

軟件缺陷產生是不可避免的，形成軟件缺陷產生的緣由主要概括以下：

• 需求解釋或者記錄錯誤
• 用戶需求定義錯誤
• 設計說明存在錯誤
• 編碼說明、程序代碼有誤
• 硬件或者軟件系統上存在錯誤
• 其餘，如文檔錯誤、內容不正確或拼寫錯誤

需求說明書：需求說明書的錯誤或不清楚引發的錯誤，是缺陷第一大的來源；
設計文檔：設計文檔描述不許確、以及與需求說明書不一致，是缺陷的第二大來源；
編碼：純粹是由編碼的問題引發；
其餘：系統集成、測試等引發；

傳話遊戲

營長對值班軍官:明晚大約八點鐘左右,哈雷慧星將可能在這個地區看到,這種慧星每隔七十六年才能看見。命令全部士兵着野戰服在操場上集合,我將向他們解釋這一罕見的現象。若是下雨的話,就在禮堂裏集合,我爲他們放一部有關慧星的影片。 值班軍官對連長:根據營長的命令,明晚八點哈雷慧星將在操場上空出現若是下雨的話,就讓士兵穿着野戰服列隊前往禮堂,這一罕見的現象將在那裏出現。 連長對排長:根據營長的命令,明晚八點,非凡的哈雷慧星將身穿野戰服在禮堂中出現。若是操場上下雨的話,營長將下達另外一個命令,這種命令每隔七十六年纔會出現一次。 排長對班長:明晚八點,營長將帶着哈雷慧星在禮堂中出現,這是每隔七十六年纔會有的事。若是下雨的話,營長將命令慧星穿上野戰服到操場上去。 班長對士兵:在明晚八點下雨的時候,著名的七十六歲的哈雷將軍將在營長的陪同下身穿野戰服開着他那輛"慧星"牌汽車通過操場前往禮堂。

軟件缺陷的根源

缺陷根源：指形成缺陷的根本因素，以尋求軟件開發流程的改進、管理水平的提升，軟件缺陷根源如上。

• 交流不充分：客戶與開發人員、開發人員與測試人員等，溝通太少。
• 軟件的複雜性：功能複雜、開發複雜、測試複雜。
• 開發人員的錯誤：對需求的理解、開發壓力、能力與經驗。
• 需求的變化：需求說明書、設計文檔、程序的變動。
• 進度壓力：項目週期比較緊，好比由原定3周改成1周。

軟件缺陷修復的費用

軟件在從需求、設計、編碼、測試一直到交付用戶公開使用後的過程當中，都有可能產生和發現缺陷。隨着整個開發過程的時間推移，更正缺陷或修復問題的費用呈幾何級數增加。
某些缺陷檢測方法的成本比其餘方法要高。最經濟的方法應該是找出缺陷的成本最低，而在其餘方面同別的方法並沒有二致。後一個條件很重要，由於查找缺陷的成本受到了不少因素的影響，例如特色的缺陷檢測技術所能找到的缺陷總量，缺陷被發現時所處的開發階段，以及經歷因素以外的其餘因素。
大部分研究都發現，檢查比測試的成本更小。NASA軟件工程實驗室的一項研究發現，閱讀代碼每小時可以檢測出的缺陷要比測試高出80%左右（Basili and Selby 1987），另外一個組織則發現使用測試來檢測缺陷的成本是檢查的6倍（Ackerman，Buchwald and Lewski 1989）。後來，IBM的一項研究又發現，檢查發現一個錯誤只須要3.5個工做時，而測試則須要花費15~25個工做時（Kaplan 1995）。

軟件缺陷的信息

爲了便於缺陷的定位、跟蹤和修改，要對所發現的缺陷，按照缺陷的嚴重程度、優先級、發現階段、修復階段、缺陷的性質、所屬功能模塊、系統環境等方面進行分類和統計。

缺陷狀態

編號	缺陷狀態	描述
1	提交（submited）	已提交的缺陷
2	打開（open）	確認「提交缺陷」，等待處理
3	拒絕（rejected）	拒絕「提交缺陷」，不須要修復或不是缺陷、重複缺陷、沒法重現
4	修復（resolved）	缺陷被修復
5	關閉（closed）	確認缺陷已修復，將其關閉
6	推遲（later）	能夠在之後解決，但要肯定修復日期或版本

軟件缺陷的信息

編號	屬性名稱	描述
1	缺陷ID	惟一的缺陷ID，能夠根據該ID追蹤缺陷
2	缺陷狀態	缺陷狀態指缺陷經過一個跟蹤修復過程的進展狀況
3	缺陷標題	描述缺陷的標題
4	缺陷的嚴重程度	對軟件產品的影響程度，分致命、較嚴重、嚴重、通常、低
5	缺陷的優先級	缺陷修復的前後順序，即哪些缺陷優先修正，哪些稍後修正
6	缺陷所屬模塊	缺陷所屬的項目和模塊，要能較精確的定位至模塊
7	缺陷記錄者	提交缺陷的人員姓名
8	缺陷提交時間	缺陷提交的時間
9	缺陷處理人	處理缺陷的處理人
10	處理結果描述	對處理結果的描述，描述處理狀況和代碼修改說明
11	缺陷處理時間	缺陷處理的時間
12	缺陷驗證人	對被處理缺陷驗證的驗證人（回測者）
13	驗證結果描述	對驗證結果的描述（經過、不經過）
14	缺陷詳細描述	缺陷的重現步驟
15	缺陷環境說明	對測試環境的描述
16	必要的附件	如涉及到附件的或錯誤現象的圖片等

爲了便於缺陷的定位、跟蹤和修改，要對所發現的缺陷，按照缺陷的嚴重程度、優先級、發現階段、修復階段、缺陷的性質、所屬功能模塊、系統環境等方面進行分類和統計。

缺陷分類（bug類型）

系統缺陷

• 因爲程序所引發的司機，異常退出。
• 程序死循環。
• 程序錯誤，不能執行正常工做或重要功能，是系統崩潰或資源不足。

數據缺陷

• 數據計算錯誤。
• 數據約束錯誤。
• 數據輸入、輸出錯誤。

嚴重地影響系統要求或基本功能的實現，且沒有辦法更正（從新安裝或者重啓不屬於更正的方法）。

數據庫缺陷

• 數據庫發生死鎖。
• 數據庫的表、缺省值爲加約束條件。
• 數據庫鏈接錯誤。
• 數據庫中的表由過多的空字段。

接口缺陷

• 數據通訊錯誤。
• 程序接口錯誤。

功能缺陷

• 功能沒法實現。
• 功能實現錯誤。

嚴重地影響系統要求或基本功能的實現，且沒有有合理的辦法更正（從新安裝或者重啓不屬於更正的方法）。
安全性缺陷

• 用戶權限沒法實現。
• 超時限制錯誤。
• 訪問控制錯誤。
• 加密錯誤。

兼容性缺陷

• 與需求規定配置兼容性不符合。

性能缺陷

• 未達到預期的性能目標。
• 性能測試中出錯，致使沒法繼續進行測試。

界面缺陷

• 操做界面錯誤。
• 打印內容、格式錯誤。
• 刪除操做未給出提示。
• 長時間操做未給出提示。
• 界面不規範。

用戶操做不方便或者遇到麻煩，但不影響執行工做功能的實現。

軟件缺陷嚴重性與優先級

軟件缺陷分類：嚴重性

嚴重等級	描述
5-Critical	系統癱瘓、異常退出、死循環、嚴重的計算錯誤等
4-VeryHigh	頻繁的死機，系統大部分功能不可用
3-High	a.功能點沒有實現，或不符合用戶需求b.數據丟失
2-Medium	a.影響一個相對獨立的功能　　b.僅僅在特定條件上發生c.與產品需求定義不一致　　　d.斷斷續續的出現問題
1-Low	表面性錯誤（如錯別字）

軟件缺陷分類：優先級

優先級別	描述
5-Urgent	最高優先級。在這個錯誤影響下，系統幾乎不可用。
4-VeryHigh	高優先級。錯誤對這套系統的能力產生嚴重的影響。
3-High	中優先級。若是這個錯誤存在與系統中，會制約開發和測試的活動的進行，若是先前沒有修復它，那麼須要在發佈前修復它。
2-Medium	低優先級。不會延遲發佈，可是會在之後修正這個錯誤。
1-Low	最低優先級。時間和資源容許時修正。

缺陷修改說明

再來聊聊缺陷修改中碰到的一些狀況。
開發人員拒絕修改的缺陷

• 程序員沒法重現或者現象難以捕捉
• 沒有明確的報告以說明重現缺陷的步驟
• 程序員沒法讀懂的缺陷報告
• 用戶不多使用或者不符合用戶使用習慣的操做出錯
• 由不受信任的測試人員提出

不是全部缺陷都會修改

• 市場的壓力使得產品最終發行有時間限制
• 測試人員錯誤理解或者不正確操做引出的缺陷(FAQ)
• 錯誤的修改影響的模塊較多，帶來的風險較大(遺留)
• 修改性價比過低
• 缺陷報告中提出的問題很難重現

bug

說完了缺陷，讓咱們深刻缺陷中，來聊聊bug。

什麼是bug

• bug泛指軟件程序的漏洞和缺陷。
• 測試工程師或用戶發現與提出的，軟件能夠改進的細節部分、或者與需求文檔存在功能誤差的實現。
• 測試工程師主要職責就是發現bug，提交bug信息給研發人員，研發人員修復bug。

案例
例如登陸時，要求輸入帳號密碼。
輸入正確的帳號密碼:
結果提示：用戶名/密碼不存在
再三確認帳號密碼是否錯誤，能夠從新再註冊一個帳號進行登陸
如新帳號也是帳號不存在，此登陸已是bug了！

bug的類型
想要肯定bug的類型，須要對產品有較深的理解。
禪道系統中對bug定義劃分以下：

• 代碼錯誤(研發代碼有誤，功能未實現)
• 設計缺陷
• 界面優化
• 性能問題
• 配置相關
• 安裝部署
• 安全相關
• 標準規範
• 測試腳本
• 其餘(功能類、界面類、性能類、易用性類、兼容性類、其餘)

bug等級劃分

根據bug等級劃分爲三級或四級。
等級越高，可能被修復的等級也越高，公司也會根據測試提交的bug數量以及bug等級做爲績效考覈標準。
判斷bug的等級，以下分類：

• 致命錯誤
  • 常規操做缺引發系統崩潰、死機、死循環
  • 形成數據庫泄露的安全問題，如惡意攻擊形成的帳戶私密信息泄露
  • 涉及金錢隱患，金錢計算bug(如金額不足，還能夠購買產品，對公司金額形成重大損失
• 嚴重錯誤
  • 重要功能未實現，如點擊註冊無反應，沒法登陸
  • 很是規操做（誤操做）致使程序崩潰、死機、死循環
  • UI界面的嚴重問題
  • 密碼明文顯示，數據庫泄露
• 普通錯誤
  • 不影響產品運行，不會影響故障，但對產品外觀界面影響較大，如刪除了好友，好友卻未消失
  • 功能沒法正常顯示功能
  • 操做界面錯亂
  • 查詢數據錯誤
  • 頁面未作輸入格式限制
  • 刪除錯誤未給與提示

缺陷報告

接下來，聊聊缺陷報告，那什麼是缺陷報告？什麼是報告缺陷呢？

報告缺陷的重要性

軟件缺陷的描述是軟件缺陷報告的基礎部分，須要使用簡單、準確、專業的術語來描述缺陷。不然，它就會含糊不清，可能會誤導開發人員，影響開發人員的效率，也會影響測試人員自身的聲譽，準確報告缺陷是很是重要的。

• 清晰準確的軟件缺陷描述能夠減小開發人員退回來的缺陷數量，能夠節省開發人員和測試人員的時間。
• 提升軟件缺陷修復的速度，使項目組可以有效地工做。
• 提升測試人員的可信任程度，能夠獲得開發人員對有效缺陷的及時響應。
• 增強開發人員、測試人員和管理人員的協同工做，讓他們更好的工做。

報告缺陷注意事項

儘可能確保缺陷能夠重現。

• 若是提交的缺陷沒法重現，會影響開發人員的工做效率。

簡潔、準確、完整。

• 測試人員在提交缺陷報告時，要站在開發人員的角度上思考問題，要確保開發人員能迅速定位問題，而不會產生理解上的歧義。

一個缺陷一個報告，有的測試人員喜歡在一個缺陷報告裏提交多個缺陷，這種習慣不提倡，緣由有如下兩點：

• 不便於分配，好比缺陷報告有2個缺陷，分別屬於不一樣的開發人員，到底該分配給誰呢？
• 不便於驗證，好比一個缺陷報告裏面有2個缺陷，缺陷1已經解決，缺陷2尚未解決，那麼這個缺陷報告該不應關閉呢？

缺陷報告書寫規範
標題：應保持簡短、準確，提供缺陷的本質信息。

• 儘可能按缺陷發生的緣由與結果的方式書寫。
• 避免使用模糊不清的詞語，例如：「功能中斷，功能不正確，行爲不起做用」等。應該使用具體文字說明缺陷的症狀。
• 爲了便於他人理解，避免使用俚語或過度具體的測試細節。
  復現步驟：應包含如何使別人可以很容易的復現該缺陷的完整步驟。爲了達到這個要求，復現步驟的信息必須是完整的、準確的、簡明的、可復現的。常見問題：
• 包含了過多的多餘步驟，且句子結構混亂，可讀性差，難以理解。
• 包含的信息過少，丟失了操做的必要步驟。

復現步驟的正確書寫方式：

• 提供測試的環境信息。
• 簡單地一步步引導復現該缺陷，一個步驟包含的操做不要多。
• 每一個步驟前使用數字對步驟編號。
• 儘可能使用短語或短句，避免複雜句型句式。
• 復現的步驟要完整、準確、簡短。
• 將常見步驟合併爲較少步驟。
• 按實際須要決定是否包含步驟執行後的結果。

實際結果：是執行復現步驟後軟件的現象和產生的行爲。

• 實際結果的描述應向標題信息那樣，要列出具體的缺陷症狀，而不是簡單地指出「不正確」或「不起做用」。

指望結果：描述應與實際結果的描述方式相同。一般須要列出指望的結果是什麼。
附件：對缺陷描述的補充說明，能夠是如下一些類型：

• 缺陷症狀的截圖。
• 測試使用的數據文件，166 199 188

其它：

• 選擇合適的缺陷嚴重性屬性。
• 按相應的規定，填寫相應的字段信息。

避免常見的錯誤：

• 避免使用我、你等人稱代詞，能夠直接使用動詞或必要時使用「用戶」代替
• 避免使用情緒化的語言和強調符號；
• 避免使用諸如「彷佛」、「看上去可能」等含義模糊的詞彙，而須要報告肯定的缺陷結果；
• 避免使用自認爲比較幽默的語句，只需客觀地描述缺陷的信息；
• 避免提交不肯定的測試問題，本身至少須要重現一次再提交。

反面的示例：

• 上海人：哪能查詢到的結果和查詢條件不搭噶的。
• 北京人：哥們好不容易輸入一堆我的詳細信息後，點擊保存後全瞎了。

缺陷處理流程

缺陷跟蹤

新提交的缺陷爲新建狀態，確認有效後爲打開狀態，經開發人員修改後，缺陷變爲已修復（待驗證）狀態。此時就須要測試人員對缺陷進行迴歸測試，驗證問題是否修復。

• 若是問題仍然存在，則測試人員將該缺陷的狀態修改成從新打開。
• 若是問題已經修復，則測試人員將該缺陷的狀態置爲關閉狀態（驗證經過），同時添加回測說明如「該缺陷已解決」。

還有一種狀況：開發人員認爲缺陷在當前版本能夠暫不修改，而考慮在後續版本中再作修正，缺陷的對應狀態爲延期。對於這種狀況，項目負責人應召集開發人員、測試人員和其餘項目相關人員進行討論，若是討論結果爲贊成則延期，若是不一樣意，則從新打開缺陷。

缺陷統計

• 對軟件問題的功能域分佈進行分析，找出系統的薄弱環節。
  • 要詳細採集每一個功能模塊或系統構件的缺陷數據，並按功能、錯誤類型、嚴重程度等分類。
  • 二八定理：80%的軟件問題老是發生在大約20%的功能模塊中。
• 對缺陷的注入階段的分佈進行分析，並與歷史數據相比較。應按不一樣的開發階段詳細採集缺陷的數據。
• 應對軟件缺陷類型進行分析，以便針對各自的特色，先修復嚴重缺陷。
• 應動態採集每一個測試周期中發現的缺陷數，並有效地控制缺陷的修復率。
• 應密切觀察缺陷的狀態，並及時跟蹤其狀態的變化，以檢查測試和開發人員的工做狀況。

bug統計
缺陷按活動分佈：

缺陷密度

基本的缺陷測量是以每千行代碼的缺陷數(個/KLOC)來測量的。稱爲缺陷密度，其測量單位是defects／KLOC。可按照如下步驟來計算一個程序的缺陷密度：

• 累計開發過程當中每一個階段發現的缺陷總數。
• 統計程序中新開發的和修改的代碼行數。
• 計算每千行的缺陷數=1000*缺陷總數/代碼行數。

例如：一個132.2萬行的源程序總共有210個缺陷，那該程序的缺陷密度是：

缺陷密度 = 1000 * 210 / 1322000 = 0.15個/KLOC

PS：KLOC，千行代碼
缺陷數據分析

• 缺陷數據分析關注的問題
• 缺陷數據分析的重要性
• 缺陷數據分析的數據指標

缺陷數據分析關注的問題

• 正在測試的軟件哪一個模塊的問題最多
• 測試人員中誰報告的軟件缺陷最多
• 各種缺陷所佔的數量百分比分別是多少
• 開發人員能及時修復軟件缺陷嗎
• 開發人員一次正確修復缺陷的百分比是多少
• 正在開發的軟件可否在計劃的時間內正常發佈

缺陷數據分析的重要性

• 統計未修復的缺陷數目（特別是嚴重性高的缺陷），預計軟件是否能夠如期發佈。
• 分析缺陷的類型分佈，發現存在較多缺陷的程序模塊，找出緣由，進行軟件開發過程改進。
• 根據測試人員報告缺陷的數量和準確性，評估測試有效性和測試技能。
• 根據報告的缺陷修復是否及時，改進軟件開發與測試的關係，使測試與開發更有機的配合。

缺陷數據分析的數據指標

• 天天/週報告的新缺陷數目。
• 天天/周修復的缺陷數。
• 累計報告的缺陷數目。
• 累計修復的缺陷數。
• 不一樣嚴重性類型的缺陷數。
• 程序模塊與發現的缺陷的對應關係。

經常使用缺陷識別方法

• 經過技術文檔識別缺陷
• 設計和分析文檔
• 用戶使用手冊，幫助手冊
• 經過行業標準規範識別缺陷
• 與專業人員來溝通識別缺陷

注意：不得站在本身主觀意識去判斷缺陷

來列舉一些例子：

• 頁面大小
  • 在B/S結構的軟件系統中，當一個頁面元素太多，未做精簡時，在打開該頁面時可能須要較長的加載時間，這對於軟件性能是一個不小的影響，既增長了服務器的壓力，又容易引發用戶的反感。例如：
    • 圖片未經壓縮、格式不正確。好比採用BMP。
    • 代碼冗餘，存在太多無用代碼。
    • 頁面元素太多，太過複雜。
• 界面文字
  • 頁面信息描述不清楚，有語病，錯別字。簡單語言複雜化，描述不正確，不符合當前頁面。錯誤的幫助信息，亂碼等。
• 容錯處理（功能缺陷）
  • 容錯處理在軟件系統中佔據十分重要的地位。所謂容錯，就是容忍錯誤的能力。當用戶在使用軟件過程當中發生錯誤後，軟件應該能給出引導信息，指應用戶進行正確的操做。例如：
    • 用戶輸入錯誤，系統無提示，無響應，用戶不能清晰知道系統不處理的緣由。
    • 給出信息提示，用戶接受後沒法繼續操做，不給用戶「改過自新」的機會。
    • 用戶輸入不合法的信息後，系統給出提示，用戶肯定後，系統仍能處理錯誤的信息。
    • 取消功能不能取消，好比刪除，系統給出提示，是否肯定刪除，用戶否定後仍執行了刪除。
• 性能缺陷
  • 這裏所說的性能問題不需專業的工具就能發現的問題，這類問題在日常作黑盒測試的時候就能發現。例如：
    • 打開文檔，10秒應該能夠完成的，卻花了3分鐘。
    • 啓動軟件，CPU長時間100%，內存消耗過多。
    • 5個用戶能夠正常使用，20個用戶使用時系統崩潰。打開一個登陸頁面花了1分鐘。
    • 完成一個查詢功能，花了2分鐘。

接下來，就考驗我的情商環節了，由於一不當心，可能面臨捱打的風險！接下來的一些列舉項，一般都由專業的人員完成，好比UI的設計師，DBA，人家是專業，你在人家的領域當心指手畫腳啊，好比你跟UI說這個頁面設計的真醜，那UI的小暴脾氣上來，不用小拳錘胸口咋地！

你要是跟DBA說什麼SQL有問題：

• 數據轉換
  • 軟件中的功能主體通常由等組成。例如：增長、修改、刪除、查詢。
    • 沒法增長記錄，好比點擊新增，頁面自動關閉。
    • 增長記錄後無顯示，但提示增長成功。
    • 增長記錄後顯示不正確，顯示爲亂碼，信息顯示不全。
    • 增長記錄後多出記錄。
    • 沒法修改記錄。修改後不能自動更新，需手工更新。
    • 沒法刪除記錄，沒法所有刪除。
    • 刪除不成功，但相應的記錄已被刪除。
    • 沒法查詢、查詢結果錯誤。
• UI用戶界面
  • 色彩：色彩的搭配無序、混亂是軟件圖形界面設計的大忌，圖形界面應儘可能設計得溫和些。這類缺陷主觀類強，我的美感佔據主動，所提交的缺陷通常嚴重程度不可定得過高。例如：
    • 總體頁面色彩單調，無變化，僅使用一種色彩，且篇幅較大，可提交建議性的缺陷，即便是簡單的界面，寧肯採用無色，也不可以使用鮮豔的單色，如紅色，黃色、綠色等。
    • 背景色與界面字體色彩相近，不能清晰區分，色彩搭配混亂、複雜，且不符合軟件標準。
• 功能結構佈局
  • 功能結構佈局主要從界面的功能區域劃分來考慮。相同的、相似的功能應該放在鄰近的區域。例如：
    • 記錄添加功能界面，添加按鈕未放在醒目的位置。
    • 導航功能位於界面的右則。
    • 總體功能區域分佈混亂。
• 圖片
  • 圖片選用不合理，與當前軟件類型不符，沒法正確體現當前界面功能性含義。圖片不規範、不清晰。例如：
    • 圖片色彩過於豔麗或黯淡，模糊不清。
    • 圖片變形。
    • 圖片不符合當前界面的主題，圖片與描述性文字不符。
• 字體
  • 字體在軟件界面中尤爲重要，字體的使用要符合軟件開發規範。例如：
    • 字體過大，與其餘頁面信息脫節，沒法造成主體。
    • 字體太小，沒法看清楚。
    • 字體不符合當前界面風格。
• 窗體大小
  • 窗體的設計要有層次感，父窗口、子窗口應該有所區別。窗口不該該有太多空白處，功能區域充實。例如：
    • 窗口太大，功能按鈕分散，間隔太大。
    • 窗口過小，功能按鈕過於集中，間隔過小，或控件顯示不全。
    • 彈出窗口未能定於屏幕居中位置。

不一樣軟件組織的缺陷管理過程

• 個體行爲
  • 處於CMM第一級（或稱爲初始級）的軟件組織，對軟件缺陷的管理無章可循。工程師們只是在發現缺陷後，修改相應的軟件。一般，沒有人會去記錄本身發現的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。並且，只有在下一輪測試中才有可能知道那些所謂已被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。
  • 因此這樣的軟件組織的項目交貨期（Release Date）表現出強烈的不可預測性。而且， 爲了得到一個高質量的軟件產品（若是可以的話），一般要在測試上花費大量的人力。
• 項目行爲
  • 在CMM第二級（或稱爲可重複級）的軟件組織中，軟件項目會從自身的須要出發，制定本項目的缺陷管理過程。一個完備軟件缺陷管理過程一般會包括以下幾個方面：
    • 提交缺陷。
    • 分析和定位缺陷。
    • 提請修改相應的軟件。
    • 修改相應的軟件。
    • 驗證修改。
  • 項目組會完整地記錄開發過程當中的缺陷，監控缺陷的修改過程，並驗證修改缺陷的結果。
• 組織行爲
  • CMM第三級（或稱爲已定義級）的軟件組織會聚集組織內部之前項目的經驗教訓，制定組織級的缺陷管理過程。而且，要求項目根據組織級的缺陷管理過程定製本項目的缺陷管理過程。
  • 從而，整個軟件組織中的項目都遵循相似的過程來管理缺陷。好的缺陷管理實踐成爲全部項目的實踐，而教訓也爲全部項目所瞭解。更重要的是，隨着組織的不斷髮展完善，組織的過程會獲得持續性的改進，全部項目的過程也都會相應的改進。
• 持續優化
  • 與CMM第四級相比，CMM第五級（或稱爲持續優化級）更強調對組織的過程進行持續性改進，從而使過程能力獲得不斷的提高。
  • 就缺陷管理而言，軟件組織應當在量化理解其過程能力的基礎上，持續地改進組織級的開發過程、缺陷發現過程，引入新方法、新工具，增強經驗交流，從而實現缺陷預防（Defect Prevention）。
  • 缺陷預防的着眼點在於缺陷的共性緣由（Common Cause）。經過找尋、分析和處理缺陷的共性緣由，實現缺陷預防。