軟體缺陷標簽自動

❶ 軟體缺陷的簡介

軟體缺陷（Defect），常常又被叫做Bug。所謂軟體缺陷，即為計算機軟體或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟體產品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義：從產品內部看，缺陷是軟體產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。在軟體開發生命周期的後期，修復檢測到的軟體錯誤的成本較高。

❷ 軟體缺陷是什麼

一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟體是文檔，代碼等組成的，最初的錯誤是來自於這些軟體錯誤(software error)，如代碼中加法寫成減法。軟體錯誤導致軟體缺陷(software defect)，如設計缺陷，代碼缺陷等，可用靜態測試，如走查，靜態檢查，測試床（軍事軟體用的技術）等，軟體的缺陷導致一個或多個軟體故障 (software fault)，故障有內部故障，外部故障，也就是我們所說的bug，軟體故障導致了軟體在功能操作等方面的失效(software failure)。
我們平時測的bug實際上是軟體故障於失效的體現。一旦軟體錯誤得到修改，相應的故障與失效也就解除了。這樣分有助於我們定位問題，找到問題。
詳見《軟體可靠性工程》

❸ 軟體缺陷的狀態有哪些

bug提交到缺陷庫中會自動的被設置成New狀態 Assigned（已指派）： 當一個bug被認為New之後，將其分配開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為「Assigned」 Open（已打開）： 開發人員開始處理bug時，他將這個bug的狀態設置為「Open」，表示開發人員正在處理這個「bug」 Fixed（已修復）： 當開發人員進行處理（並認為已經解決）之後，他（她）就可以將這個bug的狀態設置為「Fixed」並將其提交給開發組的負責人，然後開發組的負責人將這個bug返還給測試組 Rejected(被拒絕)： 測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之後認為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設置為「Rejected」 Postponed（延期）： 有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試數據，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設置為「Postponed」 Closed（已關閉）： 測試人員經過再次測試後確認bug已經被解決，將bug的狀態設置為「Closed」 如經過再次測試發現bug仍然存在，測試人員將bug再次開發組，將bug的狀態設置為「Reopen」

❹ 一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容如何提交高質量的軟體缺陷（Bug）記錄

一個缺陷報告必須包含以下核心要素：
1）測試環境
2）軟體版本
3）缺陷標題（問題描述）
4）測試步驟
5）期望結果
6）實際結果
7）詳細日誌及界面截圖

一篇高質量的軟體缺陷記錄應該考慮一下方面：
1) 通用ui要統一、准確
缺陷報告的ui要與測試的軟體ui保持一致，便於查找定位。
2) 盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達准確，體現專業化。
3) 每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4) 不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
5) 明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬於其中某種形式。
6) 明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
7) 描述 (Description) ，簡潔、准確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要准確反映缺陷的本質內容，簡短明了。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（ui）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控制項的名稱。
8) 短行之間使用自動數字序號，使用相同的字體、字型大小、行間距
短行之間使用自動數字序號，使用相同的字體、字型大小、行間距，可以保證各條記錄格式一致，做到規范專業。
9) 每一個步驟盡量只記錄一個操作
保證簡潔、條理井然，容易重復操作步驟。
10) 確認步驟完整，准確，簡短
保證快速准確的重復缺陷，「完整」即沒有缺漏，「准確」即步驟正確，「簡短」即沒有多餘的步驟。
11) 根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
 附加必要的特殊文檔和個人建議和註解
如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
12) 檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13) 盡量使用短語和短句，避免復雜句型句式
軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和復雜的句型，增強可讀性。
以上概括了報告測試缺陷的規范要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
14) 缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發了解正確的結果應該是如何。

❺ 測試人員 如何定位軟體缺陷

這個說起來很復雜。需要很多知識和測試經驗。你要對你們的軟體、系統、伺服器（我們成為測試環境)很了解才可以相對准確的定位bug。然而有的bug你定位不了很正常。通過長期的測試工作你會慢慢熟練、准確的定位bug的。祝你好運~