項(xiàng)目中測試執(zhí)行基本規(guī)范

類型,具體要求,備注

測試執(zhí)行,"1、完整性：以模塊為單位建立測試集(如雙機(jī)模塊-姓名-用例數(shù)量)，并確認(rèn)模塊用例已全部導(dǎo)入(如分階段執(zhí)行也需保證)

2、執(zhí)行策略：按測試策略要求執(zhí)行，建議執(zhí)行順序bvt、leve1、leve2、leve3或按照質(zhì)量屬性來；建議用例區(qū)域執(zhí)行順序：基本功能、高風(fēng)險(xiǎn)區(qū)域、復(fù)雜邏輯優(yōu)先測試，測試完成率增加比較慢，但對被測對象質(zhì)量的信心卻增加很快

3、執(zhí)行狀態(tài)：按用例執(zhí)行標(biāo)記規(guī)范標(biāo)記執(zhí)行狀態(tài)，測試執(zhí)行結(jié)束時(shí)，只能存在N/A、pass、NotModify；NotComplete、N/A狀態(tài)需找PM或責(zé)任人確認(rèn)

4、用例優(yōu)化：執(zhí)行過程如用例存在問題，可直接提交評審記錄，并讓責(zé)任人處理或自己處理","用例執(zhí)行標(biāo)記規(guī)范：

NotComplete：用例無效、用例錯(cuò)誤、無測試環(huán)境等過程狀態(tài)，需處理；

Passed：執(zhí)行通過

NoRun：默認(rèn)狀態(tài)，未執(zhí)行

N/A：無須執(zhí)行，需填寫備注，需處理(某個(gè)發(fā)布測試項(xiàng)無須執(zhí)行)

Failed：執(zhí)行失敗，需填寫B(tài)UGID

Blocked：被其他問題阻塞

NotModify：由Failed狀態(tài)而來，用例發(fā)現(xiàn)的bug不修改，bug為halt、Won'tFix

注意：需求變更刪除、重復(fù)覆蓋應(yīng)該移走無效用例，測試集可刪除無效用例，系統(tǒng)保留的是有效用例"

探索測試,"1、執(zhí)行策略：需明確過程探索測試要求，有效保證用例執(zhí)行，不能在執(zhí)行過程中探索；執(zhí)行過程中記錄探索，經(jīng)過分析后在驗(yàn)證，因?yàn)橛锌赡芴剿鳒y試點(diǎn)已被用例覆蓋，或過度測試

2、探索方法：提前明確探索測試方法和形式(基于思維導(dǎo)圖、基于質(zhì)量分析等)

3、過程記錄：所有探索測試記錄都要在TP上記錄",

bug提交,"1、提交規(guī)范：正確填寫各字段的信息，“概要”部分要達(dá)到使人一看就基本明白是怎樣一個(gè)bug，“描述”部分按規(guī)范填寫，

2、提交要求：提交時(shí)需查看是否存在相同bug；禁止提交詢問式bug，此類問題提交前先私下與相關(guān)人員確認(rèn)；同一個(gè)頁面的體驗(yàn)性問題、相同原因的同類體驗(yàn)性問題，可提交在一個(gè)bug里，其它情況都得獨(dú)立提交

3、疑難問題：A、對于疑難問題，盡量找開發(fā)人員現(xiàn)場確認(rèn)，并讓開發(fā)盡量保留現(xiàn)場；B、對于應(yīng)用層堆棧宕機(jī)bug，需提交數(shù)據(jù)流、堆棧信息、宕機(jī)信息、core文件、map文件、blackbox、日志等相關(guān)信息，也可以采用自動(dòng)收集腳本進(jìn)行收集；文件較小時(shí)直接放入TD，文件較大時(shí)放入服務(wù)器，TD中備注鏈接地址；C、對于非必現(xiàn)BUG，需明確操作過程，導(dǎo)出配置文件

4、字段填寫：TD字段填寫要保證正確性，以便于后續(xù)質(zhì)量分析，否則會(huì)導(dǎo)致分析有偏差，如當(dāng)時(shí)不能確定，在回歸bug時(shí)修改TD字段(所屬模塊、bug案例分析、bug執(zhí)行分析、嚴(yán)重性、發(fā)現(xiàn)版本及階段、bug類型)

","bug描述規(guī)范：

【測試環(huán)境】

說明測試的軟硬件和網(wǎng)絡(luò)環(huán)境(哪個(gè)升級包、硬件平臺(tái)，測試軟件的客戶端和服務(wù)端、訪問了某個(gè)網(wǎng)頁等與BUG直接相關(guān)的信息)

【測試步驟】

按照1、2…的方式列出重現(xiàn)該bug的步驟。好的情形是，描述清晰，別人按照此步驟也能把該bug重現(xiàn)出來。

非必現(xiàn)的bug要列出足夠多的步驟信息。

不容易說清楚的，在附件中可加入截圖信息。

【期望結(jié)果】

應(yīng)該的預(yù)期結(jié)果，即正確的結(jié)果

【實(shí)際結(jié)果】

實(shí)際操作結(jié)果，即bug的現(xiàn)象

【備注】

其它需要說明的附加信息（如Log），或bug初步定位情況等，以方便開發(fā)人員及時(shí)修改bug"

bug跟蹤,"1、嚴(yán)重問題：阻塞問題在缺陷標(biāo)題中標(biāo)注【阻塞】、嚴(yán)重問題在缺陷標(biāo)題中標(biāo)注【宕機(jī)】【嚴(yán)重】，并實(shí)時(shí)關(guān)注修復(fù)進(jìn)展，

2、嚴(yán)重問題跟蹤：優(yōu)先關(guān)注【阻塞】【宕機(jī)】【嚴(yán)重】問題，如影響測試進(jìn)度，需找項(xiàng)目經(jīng)理協(xié)助，每天要有處理進(jìn)展

3、例行跟蹤：測試人員應(yīng)每天例行查看bug解決進(jìn)展和TD備注，以便及時(shí)配合開發(fā)修復(fù)缺陷，同時(shí)查看其它人員發(fā)現(xiàn)的問題，以便及時(shí)分析與驗(yàn)證",

bug重現(xiàn),"1、重現(xiàn)前提：bug提交時(shí)已詳細(xì)記錄過程操作、日志、截圖、監(jiān)控等等

2、重現(xiàn)過程：A、首先明確重現(xiàn)思路、重現(xiàn)說明、如果重現(xiàn)是否可以定位出來、調(diào)試日志，并與開發(fā)人員討論；B、重現(xiàn)過程重按照規(guī)范填寫備注","bug重現(xiàn)規(guī)范：

【開發(fā)是否提供調(diào)試模塊】

【測試重現(xiàn)跟蹤】

問題出現(xiàn)次數(shù)：

原因可能分析：

計(jì)劃重現(xiàn)方法：

實(shí)際重現(xiàn)結(jié)果：

嘗試重現(xiàn)次數(shù)："

bug回歸,"1、回歸規(guī)范：A、bug回歸備注部分按bug回歸規(guī)范執(zhí)行;B、bug回歸不要進(jìn)行階段性回歸，要在過程中及時(shí)回歸或制定周計(jì)劃(包括前期bug，同時(shí)督促開發(fā)及時(shí)修復(fù)bug)；C、bug回歸時(shí)必須用新包進(jìn)行回歸，不能替換文件進(jìn)行回歸測試

2、回歸過程：A、Closed和Closed_Dupbug回歸備注必須覆蓋開發(fā)的測試建議，提交bug的測試步驟，TD備注中需回歸的點(diǎn)，討論出的發(fā)散測試點(diǎn)，并備注說明升級包名稱、驗(yàn)證的具體的測試點(diǎn)和驗(yàn)證結(jié)果，此類原因?qū)е碌穆y都視為執(zhí)行漏測；B、對于開發(fā)備注的測試建議不具體可當(dāng)時(shí)溝通；C、bug回歸時(shí)需清楚開發(fā)改動(dòng)和原理；C、回滾的bug需要驗(yàn)證回滾前的功能，確認(rèn)開發(fā)是否真的已經(jīng)回滾","bug回歸規(guī)范：

【是否關(guān)聯(lián)和優(yōu)化案例】

【回歸升級包名稱或時(shí)間(開發(fā)只回歸代碼級測試的自提bug)】

【回歸和關(guān)聯(lián)測試點(diǎn)測試結(jié)果】"

BUG關(guān)聯(lián),"1、關(guān)聯(lián)規(guī)范：

A、一級測試用例無覆蓋的bug需補(bǔ)充用例(后續(xù)會(huì)使用模塊用例)，其他可不做用例關(guān)聯(lián)；

B、bug回歸時(shí)需說明【是否關(guān)聯(lián)和優(yōu)化案例】；

C、對于非必現(xiàn)的問題可不做關(guān)聯(lián)；

D、未覆蓋的bug需正確填寫“bug案例分析”字段","bug回歸規(guī)范：

【是否關(guān)聯(lián)和優(yōu)化案例】

【回歸升級包名稱或時(shí)間(開發(fā)只回歸代碼級測試的自提bug)】

【回歸和關(guān)聯(lián)測試點(diǎn)測試結(jié)果】"

reopen,"1、reopen規(guī)范：

A、且“未回歸通過”是指Bug本身描述的缺陷沒有被解決，因修改而引起的其它缺陷不計(jì)入，當(dāng)出現(xiàn)此問題時(shí)，要找相應(yīng)開發(fā)人員進(jìn)行確認(rèn)，對于確實(shí)沒改好的才能reopen；如發(fā)散發(fā)現(xiàn)的bug不能reopen，另提交bug

B、對于修改其他BUG所引發(fā)的，則不能reopen，等待另外的問題解決之后再進(jìn)行回歸；

C、如存在reopen，測試版本經(jīng)理需要求開發(fā)版本經(jīng)理分析問題、追溯與改進(jìn)；","reopen規(guī)范：

表示開發(fā)認(rèn)為改好了,但測試發(fā)現(xiàn)沒有改好。

【何種情況下到此狀態(tài)】回歸測試不通過，或Closed狀態(tài)的bug發(fā)現(xiàn)并沒改好"

Rejected,"1、過程規(guī)范：

A、測試人員及時(shí)確認(rèn)是否可以reject，并備注原因，測試版本經(jīng)理填寫“Reject已確認(rèn)?”字段；如不認(rèn)同，可與測試版本經(jīng)理溝通；

B、沒有確定原因的rej問題不能被reject；","Rejected規(guī)范：

1.表示開發(fā)和測試都認(rèn)為這不是個(gè)問題,不需做任何改動(dòng)；

2.或者開發(fā)和測試都認(rèn)定這個(gè)bug和其它處于跟蹤流程中的bug現(xiàn)象和原因完全相同

3.注意事項(xiàng)和不能重現(xiàn)的問題不能被reject，注意事項(xiàng)也要提交bug，凡是產(chǎn)品問題和注意事項(xiàng)都要在24小時(shí)內(nèi)錄入缺陷庫

【何種情況下到此狀態(tài)】任何狀態(tài)下，認(rèn)為不是問題；任何狀態(tài)下，認(rèn)為和其它bug相同"

duplicate,"表示開發(fā)和測試都認(rèn)定，此bug和其它bug為不同現(xiàn)象、原因完全相同。（其中有一個(gè)bug要正常跟蹤直至Closed，Duplicate狀態(tài)的bug回歸后改為Clo