測(cè)試流程與規(guī)范

測(cè)試流程與規(guī)范 V1.0測(cè)試流程與規(guī)范1 測(cè)試流程1.1 版本的控制版本的發(fā)布要有一定的規(guī)律，建議以時(shí)間為參考，定期發(fā)布版本： 版本的發(fā)布沿用目前傳至服務(wù)器63，告知相應(yīng)路徑和文件，并記錄所該問(wèn)題； 測(cè)試人員拿到當(dāng)日的版本后，部署到服務(wù)器上，注意要將之前的版本備份，確認(rèn)BVT測(cè)試通過(guò)后可將備份定期清除； 所測(cè)問(wèn)題jira中需注明測(cè)試日期和測(cè)試版本；1.2 測(cè)試環(huán)境的搭建和維護(hù) 測(cè)試環(huán)境盡量接近客戶的實(shí)際使用環(huán)境； 測(cè)試環(huán)境最好由測(cè)試人員維護(hù)，保留環(huán)境配置說(shuō)明文檔； 測(cè)試人員應(yīng)備份一個(gè)凈化版本，當(dāng)測(cè)試人員在測(cè)試過(guò)程中制造的測(cè)試數(shù)據(jù)已對(duì)測(cè)試工作造成重大阻礙的時(shí)候，恢復(fù)數(shù)據(jù)；1.3 BUG的管理1.3.1 BUG管理流程 一個(gè)完整的BUG需要注明:測(cè)試版本，測(cè)試時(shí)間，重現(xiàn)步驟，必要的截圖，問(wèn)題屬性，嚴(yán)重程度，緊急程度，問(wèn)題涉及的主要模塊等； BUG的當(dāng)前處理人處理當(dāng)前的問(wèn)題，處理完成后標(biāo)明處理版本，如有特殊處理在備注中標(biāo)明。 同一問(wèn)題不能在同處理人處耗時(shí)過(guò)久，否則很容易被遺漏。 定期生成bug報(bào)告發(fā)送相關(guān)人員。1.3.2 缺陷屬性缺陷涉及屬性如下：屬性名稱描述填寫(xiě)人嚴(yán)重等級(jí)體現(xiàn)缺陷的嚴(yán)重性和重要程度，開(kāi)發(fā)人員據(jù)此確定優(yōu)先修改的缺陷；（ABC）測(cè)試人員錄入BUG時(shí)填寫(xiě)解決方式缺陷的處理方式，開(kāi)發(fā)人員根據(jù)缺陷實(shí)際處理情況進(jìn)行選擇；開(kāi)發(fā)人員根據(jù)缺陷實(shí)際處理情況進(jìn)行選擇；缺陷狀態(tài)缺陷在整個(gè)跟蹤修復(fù)過(guò)程中所處的狀態(tài)；根據(jù)缺陷流轉(zhuǎn)自動(dòng)設(shè)置；1.3.3 優(yōu)先級(jí)缺陷類型說(shuō)明Blocker錯(cuò)誤性質(zhì)非常嚴(yán)重，影響系統(tǒng)無(wú)法運(yùn)行，或影響測(cè)試的工作進(jìn)行； Critical系統(tǒng)崩潰，丟失數(shù)據(jù)或內(nèi)存溢出等嚴(yán)重錯(cuò)誤；Major主要功能、重點(diǎn)功能錯(cuò)誤或無(wú)效；Minor非主要功能、重點(diǎn)功能錯(cuò)誤或無(wú)效，包括對(duì)現(xiàn)有系統(tǒng)的改進(jìn)；Trivial界面錯(cuò)誤，拼寫(xiě)錯(cuò)誤，文本未對(duì)齊等；1.3.4 解決方式 嚴(yán)重程度說(shuō)明FixedBUG已經(jīng)解決；Wont FixBUG不解決，或不會(huì)被解決；Duplicate重復(fù)BUG；IncompleteBUG描述不準(zhǔn)確、完全；Cannot ReproduceBUG不能重現(xiàn)，或者無(wú)足夠的信息重現(xiàn)問(wèn)題；1.3.5 缺陷狀態(tài)缺陷狀態(tài)說(shuō)明OpenBUG提交，待處理；In ProgressBUG處理中，未完成；ResolvedBUG已解決，待驗(yàn)證； ReopenBUG驗(yàn)證未通過(guò)，待開(kāi)發(fā)處理； ClosedBUG驗(yàn)證通過(guò)，系統(tǒng)中不存在BUG描述問(wèn)題； 1.3.6 管理BUG的經(jīng)驗(yàn)合理安排測(cè)試時(shí)間和Bug驗(yàn)證時(shí)間；及時(shí)驗(yàn)證Bug；對(duì)于已改的Bug，要求在下個(gè)更新版本驗(yàn)證完畢；只要發(fā)現(xiàn)該問(wèn)題仍然存在則應(yīng)立即將該問(wèn)題打回給開(kāi)發(fā)人員，并標(biāo)注：“該問(wèn)題在新版本中依然存在?！背霈F(xiàn)爭(zhēng)議時(shí)，盡量站在用戶的角度去思考、溝通問(wèn)題，如果發(fā)現(xiàn)自己不明確問(wèn)題時(shí)，及時(shí)尋求同事和上級(jí)的幫助，協(xié)調(diào)盡快促成問(wèn)題的定位和解決；及時(shí)與開(kāi)發(fā)人員溝通所發(fā)現(xiàn)的重大、緊急Bug，并合理確定Bug的優(yōu)先級(jí)。有效的報(bào)告Bug，盡可能詳細(xì)的描述Bug，并盡可能找出Bug出現(xiàn)的規(guī)律，以便開(kāi)發(fā)人員能及時(shí)對(duì)Bug定位。經(jīng)常跟蹤一些處理時(shí)間比較長(zhǎng)的Bug。復(fù)查Bug，對(duì)于程序員不處理的Bug，測(cè)試人員要認(rèn)真核查，如果核實(shí)確定要處理，與程序員溝通并及時(shí)修正Bug。2 測(cè)試規(guī)范2.1 需求確定階段在做市場(chǎng)調(diào)研后，確定了一定的用戶需求。PM確定立項(xiàng)。設(shè)計(jì)需求文檔的階段主要任務(wù)： 需求設(shè)計(jì)完成后，要通知相關(guān)人員參加需求的評(píng)審講解過(guò)程； Dev、Test 對(duì)業(yè)務(wù)以及邏輯可以提出質(zhì)疑，及時(shí)得到處理和反饋；2.2 設(shè)計(jì)階段 在需求確定以后，Dev需要依據(jù)需求文檔以及從PM在需求評(píng)審時(shí)獲得的對(duì)新功能的UI、使用邏輯等做出詳細(xì)的設(shè)計(jì)文檔。主要任務(wù)： 設(shè)計(jì)文檔設(shè)計(jì)完成后，也要通知本次參與該項(xiàng)目的相關(guān)人員組織評(píng)審大會(huì)； 設(shè)計(jì)評(píng)審中各個(gè)人要根據(jù)自己掌握的業(yè)務(wù)知識(shí)以及開(kāi)發(fā)經(jīng)驗(yàn)對(duì)設(shè)計(jì)進(jìn)行完善，盡量減少遺漏。 設(shè)計(jì)評(píng)審?fù)瓿珊?，Dev根據(jù)自己的設(shè)計(jì)以及會(huì)議中的補(bǔ)充和更改給出開(kāi)發(fā)時(shí)間；注意事項(xiàng)：需求、設(shè)計(jì)文檔都評(píng)審?fù)戤?，在Dev進(jìn)入新功能開(kāi)發(fā)階段，test依據(jù)現(xiàn)有資料，設(shè)計(jì)case，并進(jìn)行case評(píng)審。Case評(píng)審?fù)瓿珊蠼o出測(cè)試時(shí)間。測(cè)試人員在case評(píng)審 完成后，要摘出來(lái)主流程的case信息，命名為準(zhǔn)入case提供給Dev。為Dev開(kāi)發(fā)完成后完成自測(cè)提供依據(jù)。所有資料準(zhǔn)備齊全。測(cè)試根據(jù)對(duì)本次要測(cè)試的功能的了解，提前準(zhǔn)備測(cè)試需要數(shù)據(jù)以及環(huán)境等所需內(nèi)容。以便在功能進(jìn)入測(cè)試階段時(shí)不至于手忙腳亂。2.3 新功能的開(kāi)發(fā)階段。2.4 提測(cè)驗(yàn)證階段1. 代碼正確性的驗(yàn)證 驗(yàn)證release包中的信息是否完整，有沒(méi)有多余的代碼內(nèi)容；驗(yàn)證不通過(guò)找相關(guān)Dev負(fù)責(zé)人處理。 將正確的代碼發(fā)布到測(cè)試環(huán)境，正確的完成環(huán)境部署。2. 功能正確性的驗(yàn)證 驗(yàn)證本次需求中需要新增或變更你的功能是否全部完成； 驗(yàn)證準(zhǔn)入case是否全部通過(guò)，如未通過(guò)，該版本駁回，不進(jìn)入測(cè)試階段。本次CC為失敗。 驗(yàn)證通過(guò)，進(jìn)入下一階段：測(cè)試階段PS：準(zhǔn)入case驗(yàn)證是否通過(guò)，都需要給出回應(yīng)，讓相關(guān)人員知曉。2.5 測(cè)試階段 執(zhí)行所有case； Case中無(wú)法實(shí)現(xiàn)的測(cè)試場(chǎng)景也要測(cè)試到。盡量將測(cè)試點(diǎn)覆蓋全面。 將測(cè)試階段發(fā)現(xiàn)的bug提交到j(luò)ira上做記錄。最好在提bug時(shí)標(biāo)注清楚bug嚴(yán)重程度等相關(guān)信息。注意事項(xiàng)： 測(cè)試階段，需要Dev積極的配合，及時(shí)修復(fù)發(fā)現(xiàn)的bug； 該版本確認(rèn)測(cè)試完成可以發(fā)版時(shí)，jira上關(guān)于本次功能的所有bug原則上必須全部處于close狀態(tài)； 如有本次不修復(fù)且可以發(fā)版的bug一定要在發(fā)版前得到相關(guān)負(fù)責(zé)人的認(rèn)可。 在測(cè)試、開(kāi)發(fā)時(shí)間都比較緊張的情況下需要匯總bug信息按嚴(yán)重程序來(lái)決定先修復(fù)哪些bug。關(guān)于測(cè)試遺漏bug的說(shuō)明：1、 測(cè)試人員最終來(lái)說(shuō)不是業(yè)務(wù)人員，沒(méi)有真正的使用本產(chǎn)品的經(jīng)驗(yàn)，測(cè)試的依據(jù)只是相關(guān)文檔資料。以及經(jīng)驗(yàn)中了解的業(yè)務(wù)知識(shí)。所以遺漏bug在所難免；2、 線上是允許發(fā)現(xiàn)bug的。在運(yùn)行環(huán)境和場(chǎng)景不同的情況的有bug是正常情況。3、 如果發(fā)版后，有明顯的功能無(wú)法正常使用，此時(shí)測(cè)試人員就該自我檢討了！4、 產(chǎn)品以及Dev可以將測(cè)試認(rèn)為是對(duì)產(chǎn)品一無(wú)所知，一定要保證給出的測(cè)試依據(jù)的正確性。2.6 發(fā)版1. 場(chǎng)景一：產(chǎn)品發(fā)版準(zhǔn)備前置條件：產(chǎn)品根據(jù)設(shè)計(jì)已完成一定功能，或者規(guī)定時(shí)間內(nèi)發(fā)布的版本。所發(fā)版本經(jīng)測(cè)試無(wú)問(wèn)題，或現(xiàn)存問(wèn)題已由相關(guān)負(fù)責(zé)人確認(rèn)暫不處理。版本中應(yīng)包含：新版本部署文件，變更數(shù)據(jù)庫(kù)腳本，發(fā)版說(shuō)明。2. 場(chǎng)景二：客戶定制產(chǎn)品發(fā)版準(zhǔn)備根據(jù)與客戶商定的修改內(nèi)容，發(fā)版時(shí)間完成發(fā)版。版本中應(yīng)包含：新版本部署文件，變更數(shù)據(jù)庫(kù)腳本，發(fā)版說(shuō)明。3. 發(fā)版及線上驗(yàn)證 發(fā)版包準(zhǔn)備就緒，通知相關(guān)人員進(jìn)行發(fā)版； 客戶定制產(chǎn)品發(fā)版需行現(xiàn)場(chǎng)驗(yàn)證，并給出驗(yàn)證結(jié)果的答復(fù)。 正常發(fā)布通過(guò)后，版本歸檔。 如未能正常發(fā)版，則撤銷發(fā)版。注意事項(xiàng)：如果發(fā)版失敗后，需要版本回滾，要及時(shí)做驗(yàn)證。3 附錄3.1 測(cè)試時(shí)間的預(yù)估測(cè)試人員要根據(jù)自己設(shè)計(jì)的case以及一些無(wú)法用case體現(xiàn)出來(lái)的測(cè)試場(chǎng)景出發(fā)計(jì)算測(cè)試時(shí)間，對(duì)自己的工作時(shí)間的評(píng)估要負(fù)責(zé)、謹(jǐn)慎。選擇權(quán)利的同時(shí)也賦予了自己責(zé)任。3.2 測(cè)試點(diǎn)的遺漏 測(cè)試case沒(méi)有覆蓋到的主流程以及功能的遺漏點(diǎn)； 測(cè)試人員業(yè)務(wù)知識(shí)不夠豐富，導(dǎo)致的遺漏； Case覆蓋到了，在測(cè)試執(zhí)行時(shí)沒(méi)有嚴(yán)格按照case執(zhí)行測(cè)試的遺漏； 產(chǎn)品沒(méi)有經(jīng)過(guò)聯(lián)調(diào)，環(huán)境沒(méi)有跑通情況下發(fā)版，測(cè)試人員沒(méi)有評(píng)估到風(fēng)險(xiǎn)的；PS：基于如上幾點(diǎn)的測(cè)試點(diǎn)遺漏，測(cè)試人員需要負(fù)全責(zé)。 測(cè)試階段case執(zhí)行，且通過(guò)了，發(fā)版后又出現(xiàn)的bug； 發(fā)版后用戶在使用過(guò)程中發(fā)現(xiàn)的不符合業(yè)務(wù)邏輯，以及業(yè)務(wù)