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

1.什么是缺陷報(bào)告，缺陷報(bào)告的作用，缺陷報(bào)告的要點(diǎn)

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

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

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

2.軟件測試缺陷報(bào)告的 5C 原則

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

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

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

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

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

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

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

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

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

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

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

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

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

b)然后，要獲取判斷的依據(jù)和標(biāo)準(zhǔn)：

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

認(rèn)的直接依據(jù);

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

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

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

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

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

做出決定。

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

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

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

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

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

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

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

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

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

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

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

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

傳智教育軟件測試培訓(xùn)