測試執(zhí)行及BUG提交

如何執(zhí)行測試腳本并提交缺陷1測試執(zhí)行前提及注意事項2測試執(zhí)行過程中的問題3測試執(zhí)行過程及方法4測試執(zhí)行結(jié)束的條件一、如何執(zhí)行測試腳本什么是測試執(zhí)行？

測試執(zhí)行是執(zhí)行所有或部分選定的測試用例，并對結(jié)果進(jìn)行分析的過程。

預(yù)置條件>測試用例輸入>操作步驟>輸出測試執(zhí)行的前提進(jìn)入系統(tǒng)測試執(zhí)行的要求1.所有軟件實現(xiàn)基本完成。2.需求設(shè)計文檔均已批準(zhǔn)、定稿。3.測試計劃、用例設(shè)計已完成。測試環(huán)境已準(zhǔn)備好4.已經(jīng)通過BVT測試或Smoke測試，檢查主要功能是否能測試，表明該軟件具備一定的可靠性，可以開始正式的、全面的測試1、仔細(xì)檢查軟件測試環(huán)境是否搭建成功。2、注意測試用例中的前提條件和特殊規(guī)程說明。3、測試用例要執(zhí)行全部執(zhí)行，每條用例至少執(zhí)行一遍。測試執(zhí)行的注意事項4、執(zhí)行測試用例時，要詳細(xì)記錄軟件系統(tǒng)的實際輸入輸出。5、不要放過任何偶然想象。測試執(zhí)行的注意事項測試用例執(zhí)行過程中的問題1.軟件是否有缺陷2.填寫軟件缺陷報告3.確定造成這些缺陷的原因4.需求、設(shè)計是否有缺陷5.測試環(huán)境和測試部件是否有缺陷6.測試用例設(shè)計是否不合理測試用例執(zhí)行的方法一.測試用例的手動執(zhí)行根據(jù)測試用例的要求人工的進(jìn)行軟件操作，輸入數(shù)據(jù)，觀測輸出結(jié)果二.測試用例的自動執(zhí)行1、使用錄制回放工具2、使用通用腳本texttexttexttexttext1.根據(jù)測試的階段、任務(wù)，選擇執(zhí)行全部或部分測試用例2.任務(wù)分配：將測試用例分配給測試工程師3.執(zhí)行測試，記錄原始數(shù)據(jù)，報告發(fā)現(xiàn)的缺陷4.執(zhí)行某些測試用例時，如果需要先將被測對象置于某個特定的狀態(tài)，則應(yīng)保留測試環(huán)境、狀態(tài)測試執(zhí)行的過程5,解決測試中阻礙進(jìn)度的問題6,向管理層報告測試的進(jìn)度、發(fā)現(xiàn)的主要問題等等測試執(zhí)行的過程測試用例的狀態(tài)和生命周期

pass:執(zhí)行通過

fail:執(zhí)行失敗

Block（阻塞）:這個狀態(tài)就是該條用例在執(zhí)行時阻塞，沒法執(zhí)行

下去。測試執(zhí)行結(jié)果測試開始標(biāo)準(zhǔn)：1、測試計劃評審?fù)ㄟ^；

2、測試用例已編寫完成，并已通過評審；

3、存在已提交的可測試的系統(tǒng)；

4、測試環(huán)境已搭建完畢。測試停止標(biāo)準(zhǔn)：

1、近半數(shù)以上測試用例無法執(zhí)行；

2、測試環(huán)境與要求不符。

3、開發(fā)中需求頻繁變動測試開始執(zhí)行、停止執(zhí)行，結(jié)束執(zhí)行的條件測試結(jié)束標(biāo)準(zhǔn)：

1.達(dá)到了覆蓋率的要求例如：100%語句覆蓋90%用例場景覆蓋

2.指定的時間段內(nèi)沒有發(fā)現(xiàn)新的缺陷3,基于成本的考慮4,項目組達(dá)成一致5,因時間進(jìn)度、資源的限制必須結(jié)束測試執(zhí)行完就要提交測試執(zhí)行的結(jié)果，測試執(zhí)行的結(jié)果用每一個bug單表示，所以Bug是與測試用例對應(yīng)起來的。下面主要講下bug的有關(guān)問題1軟件缺陷的定義及分類2Bug的提交流程3Bug內(nèi)容的規(guī)范

4特殊bug問題的處理規(guī)范二.如何提交缺陷軟件缺陷

軟件缺陷（Defect），常常又被叫做[1]

Bug。所謂軟件缺陷，即為計算機(jī)軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標(biāo)準(zhǔn)的定義：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的錯誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。1.嚴(yán)重缺陷不能執(zhí)行正常工作功能或重要功能。使系統(tǒng)崩潰或資源嚴(yán)重不足例如：1.1、由于程序所引起的死機(jī)非法退出

1.2、死循環(huán)

1.3、數(shù)據(jù)庫發(fā)生死鎖

1.4、錯誤操作導(dǎo)致的程序中斷2.較嚴(yán)重缺陷嚴(yán)重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正。例如：2.1、功能不符

2.2、程序接口錯誤

2.3、數(shù)據(jù)流錯誤

2.4、輕微數(shù)據(jù)計算錯誤Bug的分類3.一般性缺陷嚴(yán)重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法

3.1、界面錯誤

3.2、打印格式錯誤

3.3、刪除操作未給出提示

3.4、數(shù)據(jù)輸入沒有邊界值限定或不合理4、較小缺陷使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作或功能實現(xiàn)。例如：1、輔助說明描述不清楚

2、顯示格式不規(guī)范

3、系統(tǒng)處理未優(yōu)化

4、長時間操作未給用戶進(jìn)度提示．5、提示窗口文字未采用行業(yè)術(shù)語Bug的分類1、概要測試人員在概要輸入時，首先要明確是外網(wǎng)還是內(nèi)網(wǎng)發(fā)生的問題，然后再對問題進(jìn)行簡單的描述。在描述中，需說明在什么模塊出現(xiàn)了什么樣的錯誤。比較規(guī)范的概要輸入如：外網(wǎng)--委托方新增聯(lián)系人時對固定電話的校驗錯誤不規(guī)范的概要輸入如：外網(wǎng)—固定電話校驗錯誤或委托方新增聯(lián)系人時對固定電話的校驗錯誤。2、缺陷發(fā)現(xiàn)版本測試人員在選擇缺陷發(fā)現(xiàn)版本時，應(yīng)選擇正在測試的版本3、狀態(tài)

Bug流程狀態(tài)請參照Bug提交流程說明。4、模塊名稱，發(fā)現(xiàn)者，缺陷發(fā)現(xiàn)日期測試人員在提交Bug時，應(yīng)選擇Bug出現(xiàn)的模塊。發(fā)現(xiàn)者和發(fā)現(xiàn)日期。Bug內(nèi)容的規(guī)范

5、嚴(yán)重程度測試人員在提交Bug時，需明確Bug的嚴(yán)重程度，嚴(yán)重程度的已在前面的bug分類中做了詳細(xì)介紹。6、缺陷描述測試人員在缺陷描述中，應(yīng)包括以下幾點的描述：

1）Bug出現(xiàn)的模塊

2）進(jìn)行了哪些操作，如新增某條數(shù)據(jù)或修改某條數(shù)據(jù)。注意的是，在描述中，需明確測試數(shù)據(jù)，有利于研發(fā)人員快速尋找錯誤原因。

3）Bug現(xiàn)象的描述，應(yīng)清楚地描述Bug出現(xiàn)的現(xiàn)象，不得含糊不清。4）如已找到Bug出現(xiàn)的原因，也應(yīng)在描述中進(jìn)行說明。5）可根據(jù)測試人員對需求的理解，填寫認(rèn)為正確的修改意見。Bug內(nèi)容的規(guī)范

7、可重現(xiàn)性

測試的偶然性，即首次執(zhí)行會出現(xiàn)Bug,再次執(zhí)行時，該Bug消失。8、關(guān)閉版本測試人員在回測過程中，如Bug已經(jīng)不存在，在關(guān)閉此Bug時，需選擇當(dāng)前回測的版本號。9、關(guān)閉日期測試人員在回測過程中，如Bug已經(jīng)不存在，在關(guān)閉此Bug時，需選擇當(dāng)前回測通過。Bug內(nèi)容的規(guī)范

Bug內(nèi)容的規(guī)范

缺陷提交流程1、測試員提交缺陷單給測試組長（此時狀態(tài)為new）。2、測試組長確認(rèn)缺陷存在并符合需求時將其提交給研發(fā)組負(fù)責(zé)人（此時需將狀態(tài)改變?yōu)閛pen），如果缺陷不存在或不符合需求，則關(guān)閉此缺陷（此時需將狀態(tài)改變?yōu)閏losed）。3、研發(fā)組負(fù)責(zé)人收到此缺陷后，分配給其它組員進(jìn)行修改。如分配給其它組員，則無須修改狀態(tài)，如自行修改，則須修改其狀態(tài)（此時可選擇的狀態(tài)有fixed、rejected）。（需說明預(yù)計缺陷關(guān)閉版本和預(yù)計修改時限）4．研發(fā)其它組員收到研發(fā)組負(fù)責(zé)人轉(zhuǎn)交過來的缺陷后，則須修改其狀態(tài)（此時可選擇的狀態(tài)有fixed、rejected），然后返還給研發(fā)組負(fù)責(zé)人。）6．測試組長將其問題返還給測試人員進(jìn)行回測（在此過程中，測試組長是不用改變狀態(tài)的）。7、測試人員在回測過程中，根據(jù)回測結(jié)果修改其狀態(tài)（此時可選擇的狀態(tài)有closed、reopen）。5、研發(fā)組負(fù)責(zé)人再將其問題返還給測試組長。（在此過程中，研發(fā)組負(fù)責(zé)人是不用改變狀態(tài)的）。@對于不處理的Bug（即狀態(tài)為rejected的Bug），測試人員可根據(jù)以下三種情況作處理：1，如研發(fā)人員明確不修改時，測試人員可以根據(jù)