測(cè)試團(tuán)隊(duì)中都有哪些角色？各負(fù)責(zé)什么任務(wù)？各有多少人？

測(cè)試負(fù)責(zé)人：制定測(cè)試計(jì)劃，監(jiān)督安排任務(wù)，進(jìn)行測(cè)試總結(jié)

測(cè)試工程師：進(jìn)行測(cè)試需求分析、設(shè)計(jì)用例、搭建環(huán)境、執(zhí)行用例、提交并跟蹤缺陷

技術(shù)支持：負(fù)責(zé)環(huán)境維護(hù)，1 配置管理員：維護(hù)版本架構(gòu)，維護(hù)版本庫(kù)，文檔配置

質(zhì)量保證人員：負(fù)責(zé)軟件質(zhì)量方面的工作

什么是軟件開發(fā)生命周期？

從軟件最初構(gòu)思到公開發(fā)行的過(guò)程。

瀑布模型的過(guò)程是計(jì)劃、需求、設(shè)計(jì)、編碼、測(cè)試、運(yùn)行、維護(hù)循環(huán)。瀑布模型有嚴(yán)格的開發(fā)步驟，每個(gè)階段是按順序進(jìn)行的，每個(gè)階段都必須編寫完整的文檔，每個(gè)階段完成后必須經(jīng)過(guò)審查才能進(jìn)入下一步。瀑布模型不能迭代、不能反復(fù)；測(cè)試在編碼之后，測(cè)試太晚；測(cè)試的只是程序。

軟件開發(fā)有什么模型？軟件測(cè)試主要有哪些模型？

軟件開發(fā)模型：大爆炸模型、邊寫邊改模型、瀑布模型、螺旋模型、敏捷開發(fā)模型 軟件測(cè)試模型：V 模型、W 模型、H 模型、X 模型、前置測(cè)試模型、敏捷測(cè)試模型

簡(jiǎn)述 V 模型。

V 模型的過(guò)程：用戶需求 → 需求分析 → 概要設(shè)計(jì) → 詳細(xì)設(shè)計(jì) → 編碼 → 單元測(cè)試 → 集成測(cè) 試 → 系統(tǒng)測(cè)試 → 驗(yàn)收測(cè)試。

優(yōu)點(diǎn)：

V 的左端表示傳統(tǒng)的瀑布開發(fā)模型，V 的右端明確地將測(cè)試分為不同的級(jí)別或階 段，測(cè)試過(guò)程更為具體；

測(cè)試各個(gè)階段和開發(fā)的各個(gè)階段相對(duì)應(yīng)；

V 模型的測(cè)試策略包括低層測(cè)試和高層測(cè)試，低層測(cè)試是為了源代碼的正確性， 高層測(cè)試是為了整個(gè)系統(tǒng)滿足用戶的需求。

缺點(diǎn)：

測(cè)試的對(duì)象就是程序本身。忽視了測(cè)試活動(dòng)對(duì)需求分析，系統(tǒng)設(shè)計(jì)等活動(dòng)的驗(yàn)證 和確認(rèn)的功能，直到后期的驗(yàn)收測(cè)試才被發(fā)現(xiàn)。

測(cè)試是開發(fā)之后的一個(gè)階段。實(shí)際應(yīng)用中容易導(dǎo)致需求階段的錯(cuò)誤一直到最后系統(tǒng)測(cè)試階段才被發(fā)現(xiàn)。

簡(jiǎn)述 W 模型。

W 模型的過(guò)程：左邊 V 是需求分析 → 概要設(shè)計(jì) → 詳細(xì)設(shè)計(jì) → 編碼實(shí)現(xiàn) → 模塊集成 → 系 統(tǒng)構(gòu)建 → 系統(tǒng)安裝；右邊 V 是需求測(cè)試 → 概要設(shè)計(jì)測(cè)試 → 詳細(xì)設(shè)計(jì)測(cè)試 → 單元測(cè)試 → 集成 測(cè)試 → 系統(tǒng)測(cè)試 → 驗(yàn)收測(cè)試。

優(yōu)點(diǎn)：

W 模型體現(xiàn)了盡早和不斷測(cè)試的原則，既強(qiáng)調(diào)測(cè)試方案設(shè)計(jì)，也強(qiáng)調(diào)測(cè)試執(zhí)行。

左側(cè) V 是開發(fā)，右側(cè) V 是與開發(fā)并行的測(cè)試，相對(duì)于 V 模型，W 模型增加了軟件 各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)，W 明確表示出了測(cè)試與開發(fā)的并行關(guān)系。測(cè) 試與開發(fā)是同步進(jìn)行的，有利于盡早地全面地發(fā)現(xiàn)問(wèn)題。測(cè)試伴隨整個(gè)軟件開發(fā)周期，且測(cè)試的對(duì)象不僅僅是程序，需求、設(shè)計(jì)等同樣要 測(cè)試。

缺點(diǎn)：

在 W 模型中，需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行的，測(cè)試和開發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個(gè)階段工作。這樣就無(wú)法支持迭代 開發(fā)模型，不利于當(dāng)前軟件開發(fā)復(fù)雜多變的情況。

簡(jiǎn)述 H 模型。

H 模型將測(cè)試活動(dòng)完全獨(dú)立出來(lái)，形成一個(gè)完全獨(dú)立的流程，將測(cè)試準(zhǔn)備活動(dòng)和測(cè)試執(zhí)行活動(dòng)清晰地體現(xiàn)出來(lái)。

H 模型的測(cè)試流程是只要測(cè)試準(zhǔn)備工作完成，達(dá)到測(cè)試就緒點(diǎn)，測(cè)試就可以執(zhí)行了。

優(yōu)點(diǎn)：

軟件測(cè)試不僅僅指測(cè)試的執(zhí)行，還包括很多其他的活動(dòng)。- 軟件測(cè)試是一個(gè)獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其他流程并發(fā)地進(jìn)行。當(dāng)某個(gè)測(cè)試時(shí)間點(diǎn)就緒時(shí)，軟件測(cè)試即從測(cè)試準(zhǔn)備階段進(jìn)入測(cè)試執(zhí)行階段。

H 模型反映出軟件測(cè)試要盡早準(zhǔn)備，盡早執(zhí)行。

軟件測(cè)試可以進(jìn)行迭代、反復(fù)進(jìn)行。

敏捷開發(fā)

敏捷開發(fā)的核心思想是：以人為本，適應(yīng)變化。具體講：

認(rèn)為個(gè)體和交互重于過(guò)程和工具，強(qiáng)調(diào)通過(guò)過(guò)程和工具理解個(gè)人和交流的作用；

認(rèn)為可用軟件重于完備文檔，強(qiáng)調(diào)通過(guò)全面的文檔理解運(yùn)行的軟件；

認(rèn)為客戶協(xié)作重于合同談判，強(qiáng)調(diào)通過(guò)合同和談判得到客戶的協(xié)作；

認(rèn)為響應(yīng)變化重于遵循計(jì)劃，強(qiáng)調(diào)在計(jì)劃的執(zhí)行中做出對(duì)變更的響應(yīng)。

特點(diǎn)：

敏捷開發(fā)提倡迭代式和增量式的開發(fā)模式，并強(qiáng)調(diào)測(cè)試在其中的重要作用。

敏捷開發(fā)是以用戶為中心、以客戶需求為導(dǎo)向的開發(fā)過(guò)程，在此過(guò)程中隨時(shí)做好 “迎接變化”的準(zhǔn)備，客戶是敏捷的關(guān)鍵環(huán)節(jié)。

敏捷開發(fā)沒有單一固定的開發(fā)方法或過(guò)程，敏捷開發(fā)有三個(gè)共同點(diǎn)：依賴客戶的 參與、測(cè)試驅(qū)動(dòng)以及緊湊的迭代開發(fā)周期。

敏捷測(cè)試

敏捷測(cè)試是協(xié)同測(cè)試的一種形式，程序員結(jié)對(duì)編程，程序員分飾測(cè)試員角色，敏 捷測(cè)試是連續(xù)測(cè)試。

敏捷測(cè)試側(cè)重單元測(cè)試和驗(yàn)收測(cè)試。單元測(cè)試的過(guò)程是先設(shè)計(jì)單元測(cè)試用例，然 后進(jìn)行編碼，之后執(zhí)行測(cè)試。

敏捷測(cè)試強(qiáng)調(diào)客戶參與，單元測(cè)試通過(guò)之后代碼集成到代碼庫(kù)中，再由客戶進(jìn)行 驗(yàn)收測(cè)試，驗(yàn)收測(cè)試的結(jié)論反饋給開發(fā)人員，缺陷得以迅速修復(fù)。

軟件質(zhì)量要求有哪些？

功能要求和非功能要求。

軟件非功能要求有哪些？

性能要求（負(fù)載測(cè)試、壓力測(cè)試、容量測(cè)試、可靠性測(cè)試）、界面測(cè)試、兼容性測(cè)試、易用性測(cè)試、文檔測(cè)試、可用性測(cè)試、安裝測(cè)試、安全測(cè)試、災(zāi)難恢復(fù)測(cè)試等。

簡(jiǎn)述測(cè)試的基本過(guò)程

測(cè)試人員進(jìn)行測(cè)試需求分析。

測(cè)試負(fù)責(zé)人編寫測(cè)試計(jì)劃。

測(cè)試人員根據(jù)測(cè)試需求分析設(shè)計(jì)和編寫測(cè)試用例。

測(cè)試人員搭建測(cè)試環(huán)境、創(chuàng)建測(cè)試數(shù)據(jù)、執(zhí)行測(cè)試用例、提交缺陷報(bào)告并進(jìn)行跟 蹤、記錄測(cè)試事件。

進(jìn)行測(cè)試評(píng)估和總結(jié)。每一分步工作完成后都進(jìn)行評(píng)審。

拿到一個(gè)軟件后，應(yīng)該怎樣開始工作？

編寫需求分析并評(píng)審

編寫測(cè)試計(jì)劃并評(píng)審

設(shè)計(jì)測(cè)試用例并評(píng)審

搭建測(cè)試環(huán)境、執(zhí)行測(cè)試用例、提交缺陷報(bào)告

進(jìn)行評(píng)估和總結(jié)

怎么做測(cè)試？

編寫需求分析并評(píng)審

編寫測(cè)試計(jì)劃并評(píng)審

設(shè)計(jì)測(cè)試用例并評(píng)審

搭建測(cè)試環(huán)境、執(zhí) 行測(cè)試用例、提交缺陷報(bào)告

進(jìn)行評(píng)估和總結(jié)

簡(jiǎn)介測(cè)試流程

編寫需求分析并評(píng)審

編寫測(cè)試計(jì)劃并評(píng)審

設(shè)計(jì)測(cè)試用例并評(píng)審

搭建測(cè)試環(huán)境、執(zhí) 行測(cè)試用例、提交缺陷報(bào)告

進(jìn)行評(píng)估和總結(jié)。

怎么進(jìn)行測(cè)試需求分析？

收集各類文檔，仔細(xì)閱讀文檔，提出問(wèn)題，分析問(wèn)題或溝通解決，整理需求信息。

編寫測(cè)試需求分析說(shuō)明書：功能分解，編寫檢查點(diǎn)和測(cè)試點(diǎn)。

需求評(píng)審。

拿到項(xiàng)目后，需要分析或咨詢軟件哪些方面的問(wèn)題？

軟件主要的功能、流程、開發(fā)環(huán)境（開發(fā)語(yǔ)言<含數(shù)據(jù)類型>、數(shù)據(jù)庫(kù)、中間件）、運(yùn)行 環(huán)境（硬件、軟件、網(wǎng)絡(luò)、軟件架構(gòu)）、用戶群、測(cè)試范圍、測(cè)試優(yōu)先級(jí)。

什么時(shí)候提交發(fā)現(xiàn)的缺陷？

測(cè)試執(zhí)行發(fā)現(xiàn)缺陷時(shí)立即提交缺陷。

什么是入口準(zhǔn)則、出口準(zhǔn)則？

入口準(zhǔn)則是進(jìn)行一項(xiàng)測(cè)試工作前需要準(zhǔn)備好的前提條件。出口準(zhǔn)則是一項(xiàng)測(cè)試工作可以結(jié)束的前提條件。

需求評(píng)審都有哪些人參與？

項(xiàng)目經(jīng)理、開發(fā)經(jīng)理、測(cè)試經(jīng)理、測(cè)試人員、開發(fā)人員、市場(chǎng)經(jīng)理、客戶等。

怎么做需求評(píng)審或者說(shuō)需求評(píng)審需要評(píng)審哪些方面？

編寫或設(shè)計(jì)需求評(píng)審檢查單，比如可以檢查有無(wú)錯(cuò)別字、病句，標(biāo)點(diǎn)符號(hào)使用是否正確， 格式是否一致，是否還有多余需求，是否有錯(cuò)誤需求，是否有遺漏需求等。

測(cè)試資源需求有哪些方面？

人力資源、硬件資源、軟件資源。

什么是測(cè)試策略？什么是測(cè)試范圍？

測(cè)試策略主要指如何進(jìn)行某種測(cè)試（如功能測(cè)試、性能測(cè)試、兼容性測(cè)試、可用性測(cè)試、易用性測(cè)試等），用于說(shuō)明測(cè)試方法以及如何使用測(cè)試方法。

測(cè)試范圍有時(shí)候等價(jià)于測(cè)試策略，有時(shí)候可以表示要進(jìn)行測(cè)試的某個(gè)軟件部位。

什么是冒煙測(cè)試？版本驗(yàn)證測(cè)試？怎么測(cè)？

冒煙測(cè)試用例是一組，想先運(yùn)行以確定這個(gè)給出的小版本是否可以測(cè)試的測(cè)試用例。

冒煙測(cè)試主要測(cè)試軟件的基本功能，以判斷整個(gè)軟件值不值得進(jìn)行大規(guī)模測(cè)試。通常由一個(gè)人進(jìn)行1-2 小時(shí)的測(cè)試，一般不測(cè)試次要功能和各種錯(cuò)誤。

測(cè)試計(jì)劃的內(nèi)容和目的是什么？

包含了產(chǎn)品概述、測(cè)試區(qū)域/測(cè)試策略/測(cè)試范圍/測(cè)試目標(biāo)（測(cè)試項(xiàng)、被測(cè)特征）、測(cè)試 配置/測(cè)試資源、測(cè)試周期、進(jìn)度安排（測(cè)試任務(wù)、人員安排）、測(cè)試方法/途徑、測(cè)試交流、 風(fēng)險(xiǎn)分析等內(nèi)容。

目的是指導(dǎo)測(cè)試過(guò)程，規(guī)定測(cè)試活動(dòng)的范圍、方法、資源和進(jìn)度；明確正 在測(cè)試的項(xiàng)目、要測(cè)試的特性、要執(zhí)行的測(cè)試任務(wù)、每個(gè)任務(wù)的責(zé)任人以及與計(jì)劃相關(guān)的風(fēng) 險(xiǎn)。

怎么判斷是不是軟件缺陷？

軟件未達(dá)到產(chǎn)品說(shuō)明書標(biāo)明的功能；

軟件出現(xiàn)了產(chǎn)品說(shuō)明書指明不會(huì)出現(xiàn)的錯(cuò)誤；

軟件功能超出產(chǎn)品說(shuō)明書指明范圍；

軟件未達(dá)到產(chǎn)品說(shuō)明書雖未指出但應(yīng)達(dá)到的目標(biāo)；

軟件測(cè)試員具體問(wèn)題具體分析，認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢， 或者最終用戶認(rèn)為不好。

缺陷的產(chǎn)生主要有哪些原因？最主要的原因是什么？

需求頻繁變更、溝通不良、不了解客戶的需求、實(shí)現(xiàn)新功能或很酷的功能、追求新技術(shù)、項(xiàng)目期限的壓力、需求分析或設(shè)計(jì)投入的時(shí)間和精力不夠、產(chǎn)品的復(fù)雜度、開發(fā)人員疲勞、 壓力過(guò)大或受到干擾、缺乏足夠的知識(shí)、技能和經(jīng)驗(yàn)、缺乏動(dòng)力等。最主要的原因：需求方面的原因

當(dāng)你發(fā)現(xiàn)一個(gè)缺陷時(shí)，應(yīng)該怎么確認(rèn)的確是一個(gè)缺陷？

根據(jù)缺陷的判斷原則來(lái)甄別發(fā)現(xiàn)的問(wèn)題是不是一個(gè)缺陷，發(fā)現(xiàn)缺陷后，應(yīng)該做好分離和再現(xiàn)（3 次），記錄錯(cuò)誤現(xiàn)象或是日志，然后才能提交。

在正式提交一個(gè)缺陷前，你應(yīng)該做些什么？

分離缺陷、再現(xiàn)缺陷（3 次），然后才能提交。

怎么處理無(wú)法再現(xiàn)的缺陷？

首先，應(yīng)當(dāng)對(duì)這樣的缺陷進(jìn)行詳細(xì)的記錄，并盡快提交給開發(fā)人員。

其次，對(duì)于尋找難以再現(xiàn)的缺陷要合理地安排時(shí)間，對(duì)一時(shí)難以再現(xiàn)的缺陷可以暫時(shí)擱置，以保證項(xiàng)目的正常進(jìn)度。

最后，在測(cè)試過(guò)程中對(duì)未再現(xiàn)缺陷予以關(guān)注。

什么是重復(fù)缺陷？怎么避免重復(fù)缺陷？

提交了一個(gè)缺陷庫(kù)中存在或者開發(fā)人員已經(jīng)知道的缺陷。

如果缺陷是跟同事提交的重復(fù)，任務(wù)分工解決，也可以在提交之前查詢下庫(kù)缺陷是否存在。

如果缺陷是與自己提交的缺陷重復(fù)，則需要提高發(fā)現(xiàn)缺陷的能力，通過(guò)提高開發(fā)能力來(lái)理解兩個(gè)缺陷本質(zhì)上是一個(gè)缺陷。

什么是無(wú)效缺陷？怎么避免無(wú)效缺陷？

提交的缺陷不是真正的缺陷。

充分了解需求、提高自己識(shí)別缺陷的能力、提高缺陷的寫作能力

缺陷報(bào)告的寫作準(zhǔn)則是什么？

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

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

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

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

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

缺陷報(bào)告的內(nèi)容有哪些？

缺陷標(biāo)題（或者說(shuō)缺陷摘要、缺陷概述、缺陷基本信息）

預(yù)處理、復(fù)現(xiàn)步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、嚴(yán)重程度、優(yōu)先級(jí)

測(cè)試環(huán)境、測(cè)試版本、測(cè)試執(zhí)行人、注釋

缺陷報(bào)告的寫作需要注意什么問(wèn)題？

使用準(zhǔn)確的描述，針對(duì)問(wèn)題進(jìn)行總結(jié)，不上升到個(gè)人。

簡(jiǎn)述缺陷報(bào)告的處理流程

軟件測(cè)試人員提交缺陷報(bào)告；

測(cè)試負(fù)責(zé)人審核后將缺陷報(bào)告分配給相關(guān)的開發(fā)人員修改；

缺陷被修改后由測(cè)試人員根據(jù)缺陷報(bào)告中的修改記錄進(jìn)行返測(cè)

返測(cè)通過(guò)的缺陷報(bào)告由負(fù)責(zé)人關(guān)閉；

返測(cè)未通過(guò)的缺陷報(bào)告直接返回開發(fā)人員重新修改，然后再由測(cè)試人員返測(cè)，直到測(cè)試和開發(fā)達(dá)成一致處理意見。

簡(jiǎn)述重復(fù)缺陷的處理流程

提交缺陷、分配缺陷、是重復(fù)缺陷、置為無(wú)效缺陷。

缺陷按照嚴(yán)重程度可以分為哪些類型？

致命、嚴(yán)重、一般、較小錯(cuò)誤、意見建議等

缺陷按照優(yōu)先級(jí)可以分為哪些類型？

缺陷必須立即解決；

缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單；

缺陷可以在方便時(shí)被糾正；

下一個(gè)版本修復(fù)；不修復(fù)。

最后： 可以在公眾號(hào)：傷心的辣條 ！ 自行領(lǐng)取一份216頁(yè)軟件測(cè)試工程師面試寶典文檔資料【免費(fèi)的】。以及相對(duì)應(yīng)的視頻學(xué)習(xí)教程免費(fèi)分享！，其中包括了有基礎(chǔ)知識(shí)、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫(kù)、抓包工具專題、接口測(cè)試工具、測(cè)試進(jìn)階-Python編程、Web自動(dòng)化測(cè)試、APP自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試、測(cè)試高級(jí)持續(xù)集成、測(cè)試架構(gòu)開發(fā)測(cè)試框架、性能測(cè)試、安全測(cè)試等。

我推薦一個(gè)【Python自動(dòng)化測(cè)試交流群：746506216】，大家可以一起探討交流軟件測(cè)試，共同學(xué)習(xí)軟件測(cè)試技術(shù)、面試等軟件測(cè)試方方面面，助你快速進(jìn)階Python自動(dòng)化測(cè)試/測(cè)試開發(fā)，走向高薪之路。

喜歡軟件測(cè)試的小伙伴們，如果我的博客對(duì)你有幫助、如果你喜歡我的博客內(nèi)容，請(qǐng) “點(diǎn)贊” “評(píng)論” “收藏” 一? 鍵三連哦！