1、如何執(zhí)行測試腳本并提交缺陷1測試執(zhí)行前提及注意事項測試執(zhí)行前提及注意事項2測試執(zhí)行過程中的問題測試執(zhí)行過程中的問題3測試執(zhí)行過程及方法測試執(zhí)行過程及方法4測試執(zhí)行結(jié)束的條件測試執(zhí)行結(jié)束的條件一、如何執(zhí)行測試腳本一、如何執(zhí)行測試腳本什么是測試執(zhí)行？什么是測試執(zhí)行？ 測試執(zhí)行是執(zhí)行所有或部分選定的測試用例，并對結(jié)果進行分析的過程。 預置條件預置條件 測試用例輸入測試用例輸入 操作步驟操作步驟 輸出輸出測試執(zhí)行的前提測試執(zhí)行的前提進入系統(tǒng)測試執(zhí)行的要求1.所有軟件實現(xiàn)基本完成。2.需求設計文檔均已批準、定稿。3.測試計劃、用例設計已完成。測試環(huán)境已準備好4.已經(jīng)通過BVT測試或Smoke測試，檢查主

2、要功能是否能測試，表明該軟件具備一定的可靠性，可以開始正式的、全面的測試1、仔細檢查軟件測試環(huán)境是否搭建成功。2、注意測試用例中的前提條件和特殊規(guī)程說明。3、測試用例要執(zhí)行全部執(zhí)行，每條用例至少執(zhí)行一遍。測試執(zhí)行的注意事項測試執(zhí)行的注意事項4、執(zhí)行測試用例時，要詳細記錄軟件系統(tǒng)的實際輸入輸出。5、不要放過任何偶然想象。測試執(zhí)行的注意事項測試執(zhí)行的注意事項測試用例執(zhí)行過程中的問題測試用例執(zhí)行過程中的問題1.軟件是否有缺陷 2.填寫軟件缺陷報告 3.確定造成這些缺陷的原因4.需求、設計是否有缺陷 5.測試環(huán)境和測試部件是否有缺陷 6.測試用例設計是否不合理 測試用例執(zhí)行的方法測試用例執(zhí)行的方法一.

3、 .測試用例的手動執(zhí)行 根據(jù)測試用例的要求人工的進行軟件操作，輸入數(shù)據(jù)，觀測輸出結(jié)果二.測試用例的自動執(zhí)行1、使用錄制回放工具2、使用通用腳本texttexttexttexttext1.根據(jù)測試的階段、任務，選擇執(zhí)行全部或部分測試用例2.任務分配：將測試用例分配給測試工程師3.執(zhí)行測試，記錄原始數(shù)據(jù)，報告發(fā)現(xiàn)的缺陷4.執(zhí)行某些測試用例時，如果需要先將被測對象置于某個特定的狀態(tài)，則應保留測試環(huán)境、狀態(tài)測試執(zhí)行的過程測試執(zhí)行的過程5,解決測試中阻礙進度的問題6,向管理層報告測試的進度、發(fā)現(xiàn)的主要問題等等測試執(zhí)行的過程測試執(zhí)行的過程測試用例的狀態(tài)和生命周期 pass:執(zhí)行通過 fail:執(zhí)行失敗 B

4、lock（阻塞）:這個狀態(tài)就是該條用例在執(zhí)行時阻塞，沒法執(zhí)行 下去。測試執(zhí)行結(jié)果測試開始標準：1、測試計劃評審通過； 2、測試用例已編寫完成，并已通過評審； 3、存在已提交的可測試的系統(tǒng)； 4、測試環(huán)境已搭建完畢。測試停止標準： 1、近半數(shù)以上測試用例無法執(zhí)行； 2、測試環(huán)境與要求不符。 3、開發(fā)中需求頻繁變動測試開始執(zhí)行、停止執(zhí)行，結(jié)束執(zhí)行的條件測試開始執(zhí)行、停止執(zhí)行，結(jié)束執(zhí)行的條件測試結(jié)束標準： 1.達到了覆蓋率的要求 例如： 100%語句覆蓋 90%用例場景覆蓋 2.指定的時間段內(nèi)沒有發(fā)現(xiàn)新的缺陷 3,基于成本的考慮 4,項目組達成一致 5,因時間進度、資源的限制必須結(jié)束 測試執(zhí)行完就要

5、提交測試執(zhí)行的結(jié)果，測試執(zhí)行的結(jié)果用每一個bug單表示，所以Bug是與測試用例對應起來的。下面主要講下bug的有關(guān)問題1軟件缺陷的定義及分類軟件缺陷的定義及分類2BugBug的提交流程的提交流程3BugBug內(nèi)容的規(guī)范內(nèi)容的規(guī)范 4特殊特殊bugbug問題的處理規(guī)范問題的處理規(guī)范二二. .如何提交缺陷如何提交缺陷軟件缺陷軟件缺陷 軟件缺陷（Defect），常常又被叫做1Bug。所謂軟件缺陷，即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義：從產(chǎn)品內(nèi)部看，缺陷是

6、軟件產(chǎn)品開發(fā)或維護過程中存在的錯誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。1. 1.嚴重缺陷嚴重缺陷 不能執(zhí)行正常工作功能或重要功能。使系統(tǒng)崩潰或資源嚴重不足例如：1.1、由于程序所引起的死機非法退出 1.2、死循環(huán) 1.3、數(shù)據(jù)庫發(fā)生死鎖 1.4、錯誤操作導致的程序中斷2. 2.較嚴重缺陷較嚴重缺陷 嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正。例如：2.1、功能不符 2.2、程序接口錯誤 2.3、數(shù)據(jù)流錯誤 2.4、輕微數(shù)據(jù)計算錯誤BugBug的分類的分類3.3.一般性缺陷一般性缺陷 嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法 3.1

7、、界面錯誤 3.2、打印格式錯誤 3.3、刪除操作未給出提示 3.4、數(shù)據(jù)輸入沒有邊界值限定或不合理4 4、較小缺陷、較小缺陷 使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作或功能實現(xiàn)。例如：1、輔助說明描述不清楚 2、顯示格式不規(guī)范 3、系統(tǒng)處理未優(yōu)化 4、長時間操作未給用戶進度提示 5、提示窗口文字未采用行業(yè)術(shù)語BugBug的分類的分類1 1、概要、概要 測試人員在概要輸入時，首先要明確是外網(wǎng)還是內(nèi)網(wǎng)發(fā)生的問題，然后再對問題進行簡單的描述。在描述中，需說明在什么模塊出現(xiàn)了什么樣的錯誤。 比較規(guī)范的概要輸入如：外網(wǎng)-委托方新增聯(lián)系人時對固定電話的校驗錯誤 不規(guī)范的概要輸入如：外網(wǎng)固定電話校驗錯

8、誤 或 委托方新增聯(lián)系人時對固定電話的校驗錯誤。2、缺陷發(fā)現(xiàn)版本、缺陷發(fā)現(xiàn)版本 測試人員在選擇缺陷發(fā)現(xiàn)版本時，應選擇正在測試的版本3、狀態(tài)狀態(tài) Bug流程狀態(tài)請參照Bug提交流程說明。4 4、模塊名稱，發(fā)現(xiàn)者，缺陷發(fā)現(xiàn)日期、模塊名稱，發(fā)現(xiàn)者，缺陷發(fā)現(xiàn)日期 測試人員在提交Bug時，應選擇Bug出現(xiàn)的模塊。發(fā)現(xiàn)者和發(fā)現(xiàn)日期。BugBug內(nèi)容的規(guī)范內(nèi)容的規(guī)范 5 5、嚴重程度、嚴重程度 測試人員在提交Bug時，需明確Bug的嚴重程度，嚴重程度的已在前面的bug 分類中做了詳細介紹。6、缺陷描述缺陷描述 測試人員在缺陷描述中，應包括以下幾點的描述： 1）Bug出現(xiàn)的模塊 2）進行了哪些操作，如新增某條

9、數(shù)據(jù)或修改某條數(shù)據(jù)。注意的是，在描述中，需明確測試數(shù)據(jù)，有利于研發(fā)人員快速尋找錯誤原因。 3）Bug現(xiàn)象的描述，應清楚地描述Bug出現(xiàn)的現(xiàn)象，不得含糊不清。 4）如已找到Bug出現(xiàn)的原因，也應在描述中進行說明。 5）可根據(jù)測試人員對需求的理解，填寫認為正確的修改意見。BugBug內(nèi)容的規(guī)范內(nèi)容的規(guī)范 7 7、可重現(xiàn)性、可重現(xiàn)性 測試的偶然性，即首次執(zhí)行會出現(xiàn)Bug,再次執(zhí)行時，該Bug消失。8 8、關(guān)閉版本、關(guān)閉版本 測試人員在回測過程中，如Bug已經(jīng)不存在，在關(guān)閉此Bug時，需選擇當前回測的版本號。9 9、關(guān)閉日期、關(guān)閉日期 測試人員在回測過程中，如Bug已經(jīng)不存在，在關(guān)閉此Bug時，需選擇

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