通用軟體測試技術之缺陷
1. 缺陷的定義
- 軟體未實現產品說明書中要求的功能;
- 軟體未實現產品說明書中未明確提及但應該實現的目標;
- 軟體實現了產品說明書中未提到的功能;
- 軟體出現了產品說明書中指明不應該出現的功能。
- 軟體難以理解、不易使用、執行緩慢或者—從測試員的角度看—終端使用者會認為不好
2. 缺陷的屬性
缺陷屬性 | 描述 |
---|---|
缺陷型別(type) | 缺陷型別是根據缺陷的自然屬性劃分的缺陷種類 |
缺陷嚴重程度(Severity) | 缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度 |
缺陷優先順序(Priority) | 缺陷的優先順序指缺陷必須被修復的緊急程度 |
缺陷狀態(Status) | 缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況 |
缺陷起源(Origin) | 缺陷起源指缺陷引起的故障或事件第一次被檢測到的階段 |
缺陷來源(Source) | 缺陷來源指缺陷的起因 |
缺陷根源(Root Cause) | 缺陷根源指發生錯誤的根本因素 |
3. 缺陷型別
缺陷型別是根據缺陷的自然屬性劃分的缺陷種類
缺陷型別 | 描述 |
---|---|
功能 | 影響了各種系統功能、邏輯的缺項 |
使用者介面 | 影響了使用者介面、人機互動特性,包括螢幕格式、使用者輸入靈活性、結果輸出格式等方面的缺陷 |
文件 | 影響釋出和維護,包括註釋、使用者手冊、設計文件 |
軟體包 | 由於軟體配置庫、變更管理或版本控制引起的錯誤 |
效能 | 不滿足系統可測量的屬性值,如執行時間、事務處理速率等 |
系統/模組介面 | 與其他元件、模組或裝置驅動程式、呼叫函式、控制塊或引數列表等不匹配、衝突 |
功能(Function)、介面(UI)、文件(Documentation)、軟體包(Package)、效能(Performance)、介面(Interface)
注意:需求分析、設計階段,文件型別的缺陷多;
整合測試階段,一般介面型別的缺陷多一點;
系統測試階段,功能、介面型別的缺陷多一些;
驗收測試階段,更多的關注效能缺陷;
實施過程,可能會遇到一些軟體包的缺陷。
4. 缺陷嚴重程度
缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。
缺陷嚴重等級 | 描述 |
---|---|
致命(Fatal) | 系統任何一個主要功能完全喪失,使用者資料收到破壞,系統奔潰、懸掛、宕機,或者危機人身安全 |
嚴重(Critical) | 系統的主要功能部分喪失,資料不能儲存,系統的次要功能完全喪失,系統所提供的功能或服務受到明顯的影響 |
一般(Major) | 系統的次要功能沒有完全實現,但不影響使用者的正常使用。例如:提示資訊不太準確或使用者介面差、操作時間長等一些問題 |
較小(Minor) | 是操作者不方便或遇到麻煩,但它不影響功能的操作和執行,如個別不影響產品理解的錯別字、文字排列不整齊等一些小問題 |
5. 缺陷優先順序
缺陷的修復優先順序:缺陷的優先順序指缺陷必須被修復的緊急程度。
缺陷優先順序 | 描述 |
---|---|
立即解決(P1級) | 缺陷導致系統幾乎不能使用或測試不能繼續,需立即修復 |
高優先順序(P2級) | 缺陷嚴重,影響測試,需要優先考慮 |
正常排隊(P3級) | 缺陷需要正常排隊等待修復 |
低優先順序(P4級) | 缺陷可以在開發人員有時間的時候被糾正 |
缺陷的嚴重程度和優先順序有什麼聯絡?
- 沒有任何的直接聯絡
嚴重性(Severity)顧名思義就是軟體缺陷對軟體質量的破壞程度,即此軟體缺陷的存在將對軟體的功能和效能產生怎樣的影響。
在軟體測試中,軟體缺陷的嚴重性的判斷應該從軟體終端使用者的觀點做出判斷,即判斷缺陷的嚴重性要為使用者考慮,考慮缺陷對使用者使用造成的惡劣後果的嚴重性。
優先順序是表示處理和修正軟體缺陷的先後順序的指標,即哪些缺陷需要優先修正,哪些缺陷可以稍後修正。
確定軟體缺陷優先順序,更多的是站在軟體開發工程師的角度考慮問題,因為缺陷的修正順序是個複雜的過程,有些不是純粹技術問題,而且開發人員更熟悉軟體程式碼,能夠比測試工程師更清楚修正缺陷的難度和風險。
- 缺陷的嚴重性和優先順序是含義不同但相互聯絡密切的兩個概念。它們都從不同的側面描述了軟體缺陷對軟體質量和終端使用者的影響程度和處理方式。
一般地,嚴重性程度高的軟體缺陷具有較高的優先順序。嚴重性高說明缺陷對軟體造成的質量危害性大,需要優先處理,而嚴重性低的缺陷可能只是軟體不太盡善盡美,可以稍後處理。
但是,嚴重性和優先順序並不總是一一對應。有時候嚴重性高的軟體缺陷,優先順序不一定高,甚至不需要處理,而一些嚴重性低的缺陷卻需要及時處理,具有較高的優先順序。
6. 缺陷狀態
缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。
缺陷狀態 | 描述 |
---|---|
啟用或開啟 | 問題還沒有解決,存在原始碼中,確認“提交的缺陷”,等待處理,如新報的缺陷 |
已修正或修復 | 已被開發人員檢查、修復過的缺陷,通過單元測試,認為已解決但還沒有被測試人員驗證 |
關閉或非啟用 | 測試人員驗證後,確認缺陷不存在之後的狀態 |
重新開啟 | 測試人員驗證後,還依然存在的缺陷,等待開發人員進一步修復 |
推遲 | 這個軟體缺陷可以在下一個版本中解決 |
保留 | 由於技術原因或第三者軟體的缺陷,開發人員不能修復的缺陷 |
不能重現 | 開發不能再現這個軟體缺陷,需要測試人員檢查缺陷復現的步驟。例如:閃退,奔潰 |
需要更多資訊 | 開發能再現這個軟體缺陷,但開發人員需要一些資訊,例如切線的日誌檔案、圖片等 |
重複 | 這個缺陷已經被其他測試人員發現 |
不是缺陷 | 這個問題不是軟體缺陷 |
需要修改軟體規格說明書 | 由於軟體規格說明書對軟體設計的要求,必須要修改軟體規格說明書 |
7. 缺陷起源
缺陷起源指缺陷引起的故障或事件被第一次被檢測到的階段
缺陷來源 | 描述 |
---|---|
需求說明書 | 需求說明書的錯誤或不清楚引起的問題 |
設計文件 | 設計文件描述不準確,和需求說明書不一致的問題 |
系統整合介面 | 系統各模組引數不匹配、開發組之間缺乏協調引起的缺陷 |
資料流(庫) | 是編碼中的問題所引起的缺陷 |
8. 缺陷根源
缺陷根源指發生錯誤的根本因素
缺陷根源 | 描述 |
---|---|
測試策略 | 錯誤的測試範圍,誤解了測試目標,超越測試能力等 |
過程,工具和方法 | 無效的需求收集過程,過時的風險管理過程,不適用的專案管理方法,沒有估算規程,無效的變更控制過程等 |
團隊/人 | 專案團隊職責交叉,缺乏培訓。沒有經驗的專案團隊,缺乏士氣和動機不純等 |
缺乏組織和通訊 | 缺乏使用者參與,職責不明確,管理失敗等 |
硬體 | 硬體配置不對、缺乏,或作業系統錯誤導致無法釋放資源,工具軟體的錯誤,編譯器的錯誤,千年蟲的問題等 |
工作環境 | 組織機構調整,預算改變,工作環境惡劣,如噪音過大 |
9. 缺陷的生命週期
——每個公司、每一個工具對bug生命週期的定義都是不一致的,下面僅是一個常見的例子:
測試人員應該跟蹤一個Bug的整個生命週期,從Open到Closed的所有狀態。
10. 缺陷的生命週期
- 發現缺陷:由測試人員。開發也能知道自己哪裡寫錯了,但是不會廣而告之。
- 提交缺陷:由測試人員。開發更不可能提交bug。
- 確認缺陷:一般由測試主管、或者質量保證(QA)、由產品經理進行確認。
- 分配缺陷:經確認後,有效的缺陷會指派給相關人員進行處理。一般由誰確認的缺陷,就由誰分配。分配的物件可能是開發、也可能是UI、也可能是產品經理。
- 修復缺陷:主要由開發修復,也有可能是產品經理修復問題,也有可能是UI修復問題。
- 驗證缺陷:測試去驗證缺陷有沒有修復成功。
- 關閉缺陷:只能是測試人員進行。否則出了問題,測試人員一律不背鍋。
狀態 | 描述 |
---|---|
New | 新建 |
Open | 開啟 |
Assign | 指派 |
Test | 測試 |
Verified | 確認 |
Deferred | 延期 |
Reopened | 重新開啟 |
Duplicate | 重複 |
Rejected | 拒絕 |
Closed | 關閉 |
面試提問:針對你工作中發現的一個bug,說說這個bug的處理過程。(缺陷的生命週期中,每一個環節由誰做什麼)
10. 缺陷的識別
- 通過測試用例中的預期結果進行識別
- 通過需求規格說明書進行識別
- 通過使用者手冊及其他文件進行識別
- 通過同行業相類似成熟的商業軟體來識別
- 通過和開發人員的溝通進行識別
- 通過和有經驗的測試人員溝通進行識別
- 參照同行業隱式需求進行識別
缺陷的識別
依據
需求文件、設計文件、產品原型、測試用例,都是客觀的依據。
同行業的類似成熟軟體,和開發人員溝通,跟有經驗的測試人員溝通,同行業隱形需求,都是帶有主觀色彩的依據。
測試人員在識別缺陷的時候,要很靈活的對待。
11. 報告模板
1.編寫目的和預期讀者
- 缺陷報告編寫目的
- 易於搜尋軟體測試報告的缺陷
- 報告的軟體缺陷進行了必要的隔離,報告的缺陷資訊更具體、準確
- 軟體開發人員希望獲得缺陷的本質特徵和復現步驟
- 市場和技術支援等部門希望獲得缺陷型別分佈以及對市場和使用者的影響程度
- 預期讀者
- 開發人員、質量管理人員、市場人員、運維人員·······
2. 報告編寫準則
- Correct(準確):每個組成部分的描述準確,不會引起誤解
- Clear(清晰):每個組成部分的描述清晰,易於理解
- Concise(簡潔):只包含必不可少的資訊,不包括任何多餘的內容
- Complete(完整):包含復現該缺陷的完整步驟和其他本質資訊
- Consistent(一致):按照一致的格式書寫全部缺陷報告
3. 缺陷描述準則
- 單一準確
- 可以再現
- 完整統一
- 短小簡練
- 特定條件
- 補充完善
- 不做評價
4. 缺陷管理方式和模版
缺陷編號 | 所屬模組 | 優先順序 | 嚴重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 備註 |
---|---|---|---|---|---|---|---|
Bug_OA_CJGL_ZZJG_0001 | 一級模組/二級模組 | P1/P2/P3/P4 | S1/S2/S3/S4 | 一句話描述(時間、地點、人物、事件) | 復現步驟、實際結果、預期結果 | XXX | 特殊條件、產生該缺陷的測試用例編號 |
注意:
缺陷報告模板
- 缺陷編號:Bug_專案名稱 _功能名稱 _0001。
- 所屬模組:一級模組/二級模組/三級模組。例如:上課所用的直播軟體,如果想要檢視簽到歷史記錄,需要進入直播介面——互動應用——簽到——簽到歷史記錄。
- 優先順序:缺陷的修復緊急程度。P1>P2>P3>P4。
- 嚴重程度:S1>S2>S3>S4。
- 缺陷概述:用一句話描述缺陷的基本情況。
- 缺陷的描述:缺陷的復現步驟、預期結果和實際結果列出來。
- 提交人:是誰就寫誰的名
- 備註:一般寫產生該缺陷的特殊情況。將bug的截圖作為備註資訊。
缺陷報告的編寫目的
1. 展現缺陷的詳細資訊
2. 展現缺陷的影響程度和方式
由於缺陷報告的讀者很多:開發、質量管理、市場人員、運維人員,所以缺陷報告要寫的很直白、清晰、明瞭。
報告編寫的準則:準確、清晰、一致、簡潔、完整。
缺陷描述的規則:
可以再現。針對絕大多數的缺陷都是如此。但是有一些小部分的缺陷是難以做到(類似閃退、崩潰這種不可再現缺陷,無需做的。針對一些可以重複出現的閃退缺陷,也要進行步驟的詳細描述)
不做評價。不對缺陷的出現的嚴重程度和缺陷表現出來的效果進行主觀臆斷。
缺陷報告本身要保證沒有任何表述性的錯誤。
測試需求和測試用例、缺陷報告的關係?
測試的基本流程:獲取測試需求——編寫測試計劃——制定測試方案——設計和開發測試用例——執行測試——提交缺陷——測試分析和評審——測試總結——準備下一版本的測試。
獲取測試需求是測試工作的重點,也是第一步。通過需求的分析,瞭解和掌握測試的方向和內容。例如:
1. 分析出系統的模組和組織結構
2. 分析出軟體的基本功能和執行流程。(業務分析)包括可能會有哪些人或者哪些角色要用。
3. 識別出軟體的重要功能和次要功能。獲取測試需求的過程中,測試人員就要有相應的分析成果。一般用Xmind這樣的思維導圖工具進行分析,或者使用需求跟蹤矩陣來完成測試需求的獲取和分析。
設定測試中需求的正、反向,和優先順序。
當有了測試需求之後,就開始針對每一個需求點進行測試用例的設計。也就是,每一個需求點,都要被測試。
因此測試的過程中,衡量需求的覆蓋程度,就非常的重要。使用: 需求的覆蓋程度=被測試用例覆蓋的需求數/需求點總數 進行計算和說明。
如果需求覆蓋度<100%,那一定說明了測試的覆蓋度不夠。
測試中,最能體現測試人員工作量的指標就是缺陷的數量和用例的數量。
1. 設計的測試用例總量 TC。
2. 自信的測試用例數量 EC。
3. 為執行的測試用例數量 WC。
4. 執行通過的測試用例總量 SC。
5. 執行失敗的測試用例總量 FC。
6. 提交的缺陷的總量 BC(Bug Counts)。
以上幾個資料,他們要符合如下的數量關係。
1. TC大於等於EC。
2. TC=EC+WC。
3. EC=SC+FC。
4. BC大於等於FC。提交的bug數量,多於執行未通過的用例數。一條用例的預期結果數量是固定(甚至是唯一的)。說明了,測試過程中發現的缺陷,除一部分是用例執行失敗帶來的,還有一部分應該是測試人員自身經驗和直覺(其他知識)帶來的。
5. 通過 SC/EC 可以表現出系統的質量是否合格。
6. 通過 EC/TC 可以表現出系統的需求是否得到滿足。