軟件缺陷測試面試問題總結(jié)

1.什么是缺陷報告，缺陷報告的作用，缺陷報告的要點

(1)缺陷報告是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟的集合。軟件缺陷報告 Software Bug Report(SBR)或軟件問題報告 software Problem Report(SPR)。

(2)缺陷報告是軟件測試人員的工作成果之一，體現(xiàn)軟件測試的價值缺陷報告可以把軟件存在的缺陷準確的描述出來，便于開發(fā)人員修正缺陷報告可以反映項目/產(chǎn)品當前的質(zhì)量狀態(tài)，便于項目整體進度和質(zhì)量控制軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力。

(3)標題(Title)簡潔、準確、完整、反映缺陷本質(zhì)、方便查詢前綴+標題正文，標題正文采用結(jié)果和動作，或者現(xiàn)象和位置的方式表達;步驟(Steps)可復現(xiàn)、完整、簡潔、準確按數(shù)字編號;實際結(jié)果(Actual results)準確、詳細描述軟件的現(xiàn)象和特征;期望結(jié)果(Expected results)準確、豐富、有理有據(jù);平臺(Platforms)準確;截圖(Sereenshots)準確反映缺陷特征;注釋(Notes)關于缺陷的輔助說明

2.軟件測試缺陷報告的 5C 原則

Correct(準確)：每個組成部分的描述準確，不會引起誤解;

Clear(清晰)：每個組成部分的描述清晰，易于理解;

Concise(簡潔)：只包含必不可少的信息，不包括任何多余的內(nèi)容;

Complete(完整)：包含復現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息;

Consistent(一致)：按照一致的格式書寫全部缺陷報告。

3.軟件缺陷的生命周期?

測試人員提交新的 Bug 入庫，錯誤狀態(tài)為 New。 高級測試人員驗證錯誤，如果確認是錯誤，分配給相應的開發(fā)人員，設置狀態(tài)為 Open。如果不是錯誤，則拒絕，設置為 Declined(拒絕)狀態(tài)。開發(fā)人員查詢狀態(tài)為 Open 的 Bug，如果不是錯誤，則置狀態(tài)為 Declined;如果是 Bug 則修復并置狀態(tài)為 Fixed。不能解決的 Bug，要留下文字說明及保持 Bug 為 Open 狀態(tài)。對于不能解決和延期解決的 Bug，不能由開發(fā)人員自己決定，一般要通過某種會議(評審會)通過才能認可。 測試人員查詢狀態(tài)為 Fixed 的 Bug，然后驗證 Bug 是否已解決，如解決置 Bug 的狀態(tài)為Closed，如沒有解決置狀態(tài)為 Reopen。

4.缺陷描述(報告單)中應該包括哪些內(nèi)容?

缺陷的標題，簡要描述。缺陷的類型。缺陷的詳細步驟描述。缺陷的實際結(jié)果。期望結(jié)果。有的缺陷需要上傳截圖，日志信息。缺陷的等級。缺陷指派給開發(fā)同事。(開發(fā)主管)

5.如何提高缺陷的記錄質(zhì)量?

通用 UI 要統(tǒng)一、準確;盡量使用業(yè)界慣用的表達術語和表達方法;使用業(yè)界慣用的表達術語和表達方法，保證表達準確，體現(xiàn)專業(yè)化;每條缺陷報告只包括一個缺陷;不可重現(xiàn)的缺陷也要報告;明確指明缺陷類型;明確指明缺陷嚴重等級和優(yōu)先等級;描述 (Description) ，簡潔、準確，完整，揭示缺陷實質(zhì)，記錄缺陷或缺陷出現(xiàn)的位置;短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距; 每一個步驟盡量只記錄一個操作;確認步驟完整，準確，簡短;根據(jù)缺陷，可選擇是否進行圖象捕捉; 檢查拼寫和語法缺陷;盡量使用短語和短句，避免復雜句型句式;缺陷描述內(nèi)容。

6.如果一個缺陷被提交后，開發(fā)人員認為不是問題，怎么處理

a)首先，將問題提交到缺陷管理庫里面進行備案。

b)然后，要獲取判斷的依據(jù)和標準：

v.根據(jù)需求說明書、產(chǎn)品說明、設計文檔等，確認實際結(jié)果是否與計劃有不一致的地方，提供缺陷是否確

認的直接依據(jù);

vi.如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷;

vii.根據(jù)用戶的一般使用習慣，來確認是否是缺陷;

viii.與設計人員、開發(fā)人員和客戶代表等相關人員探討，確認是否是缺陷;

c)合理的論述，向測試經(jīng)理說明自己的判斷的理由，注意客觀、嚴謹，不摻雜個人情緒。

d)等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級

做出決定。

7.缺陷的優(yōu)先級劃分和描述

一般來說按照下面的來分，具體的是由每個公司而定。

軟件缺陷有四種級別，分別為：致命的(Fatal)，嚴重的(Critical)，一般的(Major)，微小的(Minor)。

A 類—致命的軟件缺陷(Fatal):造成系統(tǒng)或應用程序崩潰、死機、系統(tǒng)掛起，或造成數(shù)據(jù)丟失，主要功能完全喪失，導致本模塊以及相關模塊異常等問題。如代碼錯誤，死循環(huán)，數(shù)據(jù)庫發(fā)生死鎖、與數(shù)據(jù)庫連接錯誤或數(shù)據(jù)通訊錯誤，未考慮異常操作，功能錯誤等

B 類—嚴重錯誤的軟件缺陷(critical)：系統(tǒng)的主要功能部分喪失、數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失。問題局限在本模塊，導致模塊功能失效或異常退出。如致命的錯誤聲明，程序接口錯誤，數(shù)據(jù)庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件

C 類—一般錯誤的軟件缺陷(major)：次要功能沒有完全實現(xiàn)但不影響使用。如提示信息不太準確，或用戶界面差，操作時間長，模塊功能部分失效等，打印內(nèi)容、格式錯誤，刪除操作未給出提示，數(shù)據(jù)庫表中有過多的空字段等

D 類—較小錯誤的軟件缺陷(Minor):使操作者不方便或遇到麻煩，但它不影響功能過的操作和執(zhí)行，如錯別字、界面不規(guī)范(字體大小不統(tǒng)一，文字排列不整齊，可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志)，輔助說明描述不清楚

E 類- 建議問題的軟件缺陷(Enhancemental)：由問題提出人對測試對象的改進意見或測試人員提出的建議、質(zhì)

軟件測試缺陷管理工具有哪些？測試管理工具介紹

日常工作中的缺陷跟蹤流程有哪些?

軟件缺陷處理流程包括哪些？

軟件缺陷產(chǎn)生的原因有哪些？【軟件測試】

傳智教育軟件測試培訓