測試管理制度守則

1、測試管理制度II刖百本制度為北京首航財務(wù)管理顧問有限公司內(nèi)部使用的測試管理制度，僅用于公司內(nèi)部使用禁止外傳。本管理制度適用于測試組新員工入職培訓和測試組全體員工日常工作的執(zhí)行標準，是測試流程執(zhí)行工作的統(tǒng)一標準規(guī)范。達到對工作效率的掌控和監(jiān)督的作用，同時也可以規(guī)范各部門的交互合作流程，從而有效保證職、責、權(quán)的分明。所有項目執(zhí)行過程中， 項目經(jīng)理和開發(fā)人員 要發(fā)送郵件申請測試文檔，未申請的文檔不予提供。 所有的項目郵件 將作為工作中的重要信息保存 至項目封檔。測試組的每位成員有責任和義務(wù)履行所有的測試流程，也有責任保護測試流程和測試文檔申請流程。每位員工可以根據(jù)項目的個性需要對測試流程進行適當?shù)恼{(diào)

2、整，但是必須保證測試標準嚴格執(zhí)行，以保證項目的測試質(zhì)量。測試人員要在項目中經(jīng)常聯(lián)系需求和 開發(fā)人員，所以，要注意禮貌和標準用語的使用。郵箱使用 統(tǒng)一的簽名，日常交流中注意著裝、商務(wù)禮貌用語和職場禮儀，直接接觸客戶時談及的內(nèi)容以工作為主，不得泄漏公司機密、損害公司形象，注意體現(xiàn)技術(shù)服務(wù)的專業(yè)水準。每位測試人員負責的項目都要及時撰寫測試計劃，篩選測試用例等相關(guān)文檔，根據(jù)測試情況及時將缺陷錄入缺陷管理系統(tǒng)，指派給指定的研發(fā)人員。 同時對項目的BUG周期進行跟蹤管理。 定期整理項目的缺陷比例等數(shù)據(jù) 進行上報，對有價值的數(shù)據(jù)自動進行存檔，并更新文檔庫和用例庫。所有文檔規(guī)范模板見模板庫。所有申請表以 WO

3、R胳式上傳到SVN每個項目的參與測試人員每天需要及時確認需求是否有更新。對更新的需求部分需要調(diào)整測試用例。目的？?統(tǒng)一公司所有項目的軟件測試 標準流程；？-v . : I 支尸/?提供一套適合公司所有項目 的軟件測試 流程；規(guī)范統(tǒng)一的項目測試執(zhí)行標準 ；?范圍？?本規(guī)范適用于測試所有的JAVA開發(fā)的B/S架構(gòu)內(nèi)部使用的系統(tǒng)軟件 項目；？?本規(guī)范中集成測試、系統(tǒng)測試和性能測試適用于所有項目；測試計劃、用例、測試報告、缺陷報告等模板參見模板庫；第一章項目文檔和用例管理（一）項目文檔1、項目立項默認提供測試計劃、測試用例、測試過程管理 文檔、驗收報告和 測試報告五個文檔， 默認提交功能測試報告，有性

4、能測試的需求需要在申請測試文檔時注明。性能測試可提供性能測試計劃、性能測試用例、性能測試報告；2、如還需提供其他文檔請在測試文檔申請表詳細寫明，然后發(fā)送電子郵件到指定測試人員郵箱并抄送給測試組長，項目交付文檔以 申請郵件填寫的申請表內(nèi)容 為準；3、項目測試期間所有與客戶和研發(fā)人員的往來郵件都要抄送給直屬上級領(lǐng)導；4、每個項目結(jié)束要寫總結(jié)文檔要對項目的缺陷數(shù)量和比例進行統(tǒng)計，分析BUG產(chǎn)生原因，提出改進建議，統(tǒng)計不同BUG聽占比例，整理成圖表文檔發(fā)送給上級領(lǐng)導；5、每個季度編寫項目總結(jié)文檔，對項目的缺陷數(shù)量和比例進行統(tǒng)計，分析BUG產(chǎn)生原因，統(tǒng)計不同 BUG聽占比例，整理成圖表存檔并向上級領(lǐng)導提

5、交報告；l I1 11（二）項目用例-if /1、所有項目均可以根據(jù)項目實際 需求在通用用例庫選擇相應的用例 執(zhí)行測試，需要寫補充用例的要及時編 寫并錄入通用用例庫。需求不完善的 首先跟客戶確認需求、幫客戶設(shè)計需求，根據(jù)客戶需求制定執(zhí)行標準。必要時，根據(jù)行業(yè)通用標準、公司慣例完成 測試工作；2、所有用例需要100班行通過后才算通過；3、在項目中遇到新的測試用例要及時錄入通用用例庫以保證用例庫的更新和完善。所有的項目郵件將作為工作中的重要信息保存直至項目留存封擋之后。 刪除舊數(shù)據(jù)時需要發(fā)送郵件請示上級領(lǐng)導， 得到許可后方可進行 刪除； , . .4、項目結(jié)束整理項目的各項數(shù)據(jù)并按季度和年度提交上

6、級領(lǐng)導；（三）測試文檔申請和交付標準流程1、項目需求自交付之日起 3個工作日內(nèi)提交測試文檔申請表，該表可以在項目中期追加測試文檔申請，項目 起始時間和申請的相關(guān)文檔以申請表為準。其他形式的追加文檔一律安排到所有項目的測試工作完成之后提供； 2、項目工期提前或延期需提前 2周填寫項目延期通知單（表3）或項目工期提前通知單 （表4）。經(jīng)測試 人員回復郵件確認項目文檔 交付的日期，如提交超過一次則 按項目負責人最 近一次提交的申請單的日期為準。 同 時研發(fā)部項目組長需要給測試文檔的 交付預留至少1周的時間；SVN并告知更新文檔相關(guān)的研發(fā)人員,3、項目進行中客戶對需求的修改文檔都要第一時間上傳到版本管

7、理器以提高工作效率。需求修改時需要填寫“需求修改確認單”（表5）4、需要做性能測試的項目，需提前確認性能測試需求，需填寫性能測試申請單，并確認測試時間和地點，需提前5個工作日確認；5、確認時間少于5個工作日的一律自行調(diào)整項目交接時間，給測試工作和測試文檔撰寫爭取時間；6、如在項目后期需要追加測試文檔，需提前10個工作日提交申請表，無申請表一律不予提供；7、需要外派測試的需要提前 2個工作日申請，申請郵件中需注明工作地點、乘車路線信息、外派公司接待人聯(lián) 系方式、外派工位申請、協(xié)商好外派公司的行政管理部等相關(guān)部門，為外派的同事處理好工作銜接；8、測試文檔已郵件形式發(fā)送，每次都要抄送給上級領(lǐng)導和指定

8、關(guān)聯(lián)人；第二章測試執(zhí)行流程及標準、測試執(zhí)行標準流程（一）角色與職責1、角色與職責角色職責項目經(jīng)理協(xié)調(diào)軟件、硬件、人力資源、風險控制、項目進度和質(zhì)量等；測試經(jīng)理管理測試相關(guān)資源、分配測試工作、風險控制等，對測試工作進度把握和 質(zhì)量監(jiān)督。協(xié)調(diào)客戶需求和開發(fā)人員的合作；測試組長制定測試計劃、？編寫測試用例、執(zhí)行測試、提交缺陷、回歸測試、？編寫1測試分析報告、性能測試計劃、性能測試用例、性能測試報告、項目總結(jié)；測試工程師協(xié)助測試組長的工作、對負責的模塊用例進行篩選、確認BUG并提交至缺陷管理系統(tǒng)、指派對應的開發(fā)人員修復；測試員執(zhí)行負責模塊的測試用例，提交缺陷至缺陷管理系統(tǒng)；開發(fā)人員修改缺陷、開發(fā)人員修

9、改完缺陷后由測試人員進行回歸測試，測試通過則“關(guān)閉”缺陷，檢驗未通過，則轉(zhuǎn)給開發(fā)人員，繼續(xù)修改；？提交缺陷修改程序代碼；提供必要的測試數(shù)據(jù)；配置管理人員管理測試需要的資源，包括軟硬件環(huán)境，版本管理和缺陷跟蹤管理。建立 代他基線，配合進行配置檢查；2、測試范圍（根據(jù)項目實際選擇完成測試類型）系統(tǒng)集成后的功能性測試；？?？系統(tǒng)集成后的容錯性測試；？?？系統(tǒng)集成后的界面測試；？?？?？系統(tǒng)集成后的常用控件測試；？?？系統(tǒng)集成后的接口測試；？?？系統(tǒng)集成后的可用性測試；？?？系統(tǒng)集成后的完整性測試； 烏系統(tǒng)集成后的壓力測試；系統(tǒng)集成后的安全性測試；（，二 X 二尸3、進入測試條件項目概要設(shè)計通過評審；

10、單元測試通過；冒煙測試通過；4、退出條件缺陷基本修復完畢、系統(tǒng)穩(wěn)定;測試報告評審通過;項目上線，代碼基線化；線上測試通過；二、測試的準備工作(1)測試人員在項目的需求階段開始介入，首先仔細閱讀需求文檔，然后跟研發(fā)人員一同接受需求的業(yè)務(wù)培訓，參與需求評審、數(shù)據(jù)庫評審，從而更全面精準的了解業(yè)務(wù)流程，針對項目周期安排進行測試工作的計劃；(2)在“需求分析”期間著手編寫測試計劃，直到“概要設(shè)計”、“詳細設(shè)計”階段，將測試計劃有效的編寫完成。同時也篩選用例，將項目用例單獨整理成文當。對需要設(shè)計補充用例的模塊進行設(shè)計；(3)在軟件的“代碼編寫”期間，完成測試用例的編寫。測試計劃的時間規(guī)劃和工作安排要與項目

11、的整體 進度吻合。(4)安排的測試人員要與技術(shù)等級、工作量匹配，保證有效的工作進度，必要時采取加班方式增加工作量，為 項目完成降低可預見的更多風險；(5)監(jiān)測需求的變化及時調(diào)整測試用例；(6)性能測試指標及方案需要在項目撰寫測試計劃時預估性能測試工作量并預先安排工作時間，根據(jù)項目實際情況和客戶需求制定性能測試計劃和測試指標，編寫性能測試報告；三、測試執(zhí)行進程- I /.X 產(chǎn) J 尸 /(一)需求(1)參加立項會議，查看需求文檔，接受業(yè)務(wù)培訓詳細了解業(yè)務(wù)流程。我們是外包公司為客戶提供服務(wù)為主營業(yè)務(wù)。在接受客戶指定項目負責人提供的(以下簡稱客戶)直接的需求文檔，由研發(fā)部項目負責人先接受需求培訓，

12、然后組織相項目經(jīng)理、研發(fā)經(jīng)理、人員、開發(fā)人員、環(huán)境管理人 員、測試人員和其他相關(guān)人員進需求評審，確保達成一致意見。 對系統(tǒng)連接測試需求分析和集成測試需求分析進行評定，確保系統(tǒng)連接測試需求和系統(tǒng)集成測試需求通過評審。對于內(nèi)部測試需求分析中導出的內(nèi)部測試需求， 應由研發(fā)中心測試組組織相關(guān)業(yè)務(wù)人員、開發(fā)項目組進行評審，執(zhí)行統(tǒng)一標準，形成合作默契。所有評審文檔確 認后都要上傳到 SVN項目結(jié)束后也要隨時幫助客戶解決項目問題,體現(xiàn)在整個項目研發(fā)過程中與客戶進行需求變更的細節(jié)溝通, 人和創(chuàng)建員工的高素質(zhì)、高服務(wù)意識，維護公司的良好形象。另一種是第三方提供需求，除了等同客戶需求的工作之外，要特別注意：第三方

13、對需求的確認狀態(tài)和修改次數(shù)。不能簡單的、一味的、直接接受第三方的想法，必要時要求對方立即與客戶確認，做好需求的修改記錄。在 修改需求時與第三方的文件傳輸要每次都抄送上級和相關(guān)負責人，郵件正文中注明郵件目的、 傳輸文檔數(shù)據(jù)屬性和發(fā)送原因。所有評審文檔確認后都要上傳到SVN(2)單元測試開發(fā)人員完成代碼編寫后首先進行單元測試。其中，編寫單元測試計劃，設(shè)計單元測試用例、執(zhí)行單元測試過程、記錄單元測試缺陷、編寫單元測試報告等工作由白盒測試人員完成。根據(jù)項目組具體情況安排， 目前本部開發(fā)人員自行完成單元測試，而且不提供任何相關(guān)文檔給測試人員。(二)功能測試和性能測試指標(1)新項目的首次功能測試是從“冒

14、煙測試”開始。新項目交接到測試部，首先進行“冒煙測試”通過后進 行功能測試，如測試結(jié)果為：“不通過”將不予測試，打回重做。冒煙測試合格的項目基本的功能測試可以使用完整的流程，比如正常使用會員管理系統(tǒng)，可以進行會員注冊、登錄、會員信息修改、退出、管理員查詢、統(tǒng)計、凍結(jié)/刪除和修改會員信息等基本功能。期間沒有異常退出系統(tǒng)、掛機、報黃頁、安裝和卸載無異常等主要功能流程可以正常實現(xiàn)。也就是，被測試程序能完整實現(xiàn)基本功能 的流程，軟件基本功能正常，可以進行后續(xù)的正式測試工作。即為冒煙測試通過，反之則沒有通過，不予測試， 退回開發(fā)項目組負責人。升級版的項目也需要進行冒煙測試，在Web測試和負載測試中，冒煙

15、測試時間短，工作量也小。使用冒煙測試是為了在運行功能測試或壓力測試之前，確保一切都已配置正確并可按預期運行。(2)冒煙測試用例選擇標準 ？?1)新功能版本發(fā)布？?測試人員接到新版本后首先需要對新功能進行冒煙測試。冒煙測試主要驗證所提交的功能重點模塊是否按需 求開發(fā)完、是否進入測試階段、 是否可以按照正常測試用例執(zhí)行測試。選擇主要功能的正常用例做為冒煙測試執(zhí)行的用例，一般選擇測試用例中優(yōu)先級別低的用例；2)含有舊的BUG未修復的新功能版本?新功能開發(fā)完成后，如果依賴于某個功能模塊且該功能模塊中存在未修正的BUG則不接受新版本部署測試。選擇新功能正常測試用例和優(yōu)先級為“高”級別以上，并且已經(jīng)修復的

16、BUG故為冒煙測試執(zhí)行的用例。？項目組成員可以用分配好的用戶名和密碼登錄缺陷管理系統(tǒng)實時查看缺陷情況。3) BUG修正版本發(fā)布？?選擇優(yōu)先級為“高”級別以上，并且已經(jīng)修復的BUG以及主要功能的正常測試用例做為冒煙測試執(zhí)行的用例。？項目組成員可以用分配好的用戶名和密碼登錄缺陷管理系統(tǒng)實時查看缺陷情況。(2)功能測試冒煙測試合格可以進行功能測試。項目可以正常運行完整的流程，而且系統(tǒng)沒有A級缺陷，并且能達到系統(tǒng)功能完整度總通過率不低于80%回歸測試BUG遺留不超過40%才可以進行下一輪測試。否則交由研發(fā)部將缺陷修復后重新進行測試。第二輪測 試，系統(tǒng)沒有 A級、B級和C級缺陷，并且用例通過率不低于 9

17、0%回歸測試BUG遺留不超過30%可以進行第 三輪測試。第三輪測試，系統(tǒng)沒有D級以上缺陷，同時用例通過率達到100%回歸測試BUG遺留不超過3%集成回歸測試時，如回歸測試全部通過，該項目測試通過，出具測試報告。此時可以著手開展性能測試的工作。首先要達到的普遍標準：1、通過冒煙測試后的項目才可以確認開始功能測試；2、確認兼容的系統(tǒng)、瀏覽器版本和環(huán)境等信息；3、準備測試機，搭建測試環(huán)境，保證環(huán)境正常有效；4、測試頁面上的：靜態(tài)頁面、動態(tài)獲取、色差、像素值、圖標、圖片、文字、符號、背景、鏈接、留白等是否 兼容；,l J 匚二5、將測試結(jié)果及時錄入缺陷管理系統(tǒng)，完成缺陷分配信息；6、完成缺陷分類、圖文

18、并茂的直觀描述BUG使用語言簡潔準確，內(nèi)容較復雜時使用排序方式描述，如1, 2, 3.;7、測試JS腳本和其他插件是否對系統(tǒng)和環(huán)境兼容，基本的彈出窗口是否正常，記錄同上；8、及時查看缺陷信息，對已經(jīng)修復的缺陷及時回歸，完成集成回歸測試；9、界面測試：多窗體、單窗體以及資源管理器風格；其次，參考測試標準文檔：-：- IX、三/1、界面測試執(zhí)行標準；2、常用基本控件測試用例；3、通用用例庫4、測試方案5、測試計劃 6、測試評審表7、缺陷報告8、缺陷統(tǒng)計9、測試過程管理10、測試報告11、驗收報告12、項目操作手冊13、性能測試需求申請單_ | 夕 I14、性能測試用例 TOC o 1-5 h z

19、r 1 115、性能測試報告117- - . (3)軟件性能測試中的性能指標和實施方法 x1 一 q :各種軟件在系統(tǒng)實施過程中， 需要滿足客戶的一些特殊要求。 如果軟件系統(tǒng)沒有經(jīng)過測試和優(yōu)化， 軟件系統(tǒng) 將無法滿足用戶的需求，還會給軟件在實際應用中帶來很大的風險。性能測試是整個軟件測試中一個重要方面，能測試軟件的穩(wěn)定性和承受較大數(shù)據(jù)量時系統(tǒng)的運行能力。(，二 X 二尸性能測試目的是驗證軟件系統(tǒng)是否能夠達到用戶提出的性能指標，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的 。性能測試工程師技能要求：熟悉軟件測試基本理論；掌握軟件測試常用方法；熟悉一門編程語言；？熟悉一種數(shù)據(jù)

20、庫管理系統(tǒng)； ？熟悉 Web服務(wù)器，如IIS、Apache等；？?？熟悉常見網(wǎng)絡(luò)協(xié)議，如 Http ; ?掌握性能測試理論;熟練使用一種性能測試工具；實際工作中需要的其他技能（性能調(diào)優(yōu)除外）；包括以下幾個方面：1、評估系統(tǒng)的能力，測試中得到的負荷和響應時間數(shù)據(jù)可以被用于驗證所計劃的模型的能力，并幫助作出決策。2、識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄弱的地方。3、系統(tǒng)調(diào)優(yōu)：重復運行測試，驗證調(diào)整系統(tǒng)的活動得到了預期的結(jié)果，從而改進性能。檢測軟件中的問題：長時間的測試執(zhí)行可導致程序發(fā)生由于內(nèi)存泄露引起的失敗，揭示程序中的隱含的問題或沖突。4、驗證

21、穩(wěn)定性、可靠性：在一個生產(chǎn)負荷下執(zhí)行測試一定的時間是評估系統(tǒng)穩(wěn)定性和可靠性是否滿足要求的唯一方法。定義：性能測試類型包括負載測試，強度測試，容量測試等。 I -負載測試：負載測試是一種性能測試指數(shù)據(jù)在超負荷環(huán)境中運行，程序是否能夠承擔。r 1 1強度測試： 強度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運行情況。容量測試：確定系統(tǒng)可處理同時在線的最大用戶數(shù)觀察指標：性能測試主要是通過自動化測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加

22、時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不ll .I能接收的性能點來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。軟件方面？?1、響應時間?反映系統(tǒng)處理效率指標 ？?響應時間是從開始到完成某項工作所需時間的度量。在客戶/服務(wù)器環(huán)境中，通常是從客戶方測量響應時間。響應時間通常隨負載的增加而增加。？?2、吞吐量？?反映系統(tǒng)處理能力指標 ？?吞吐量是單位時間內(nèi)完成工作的度量，在客戶/服務(wù)器環(huán)境中通常是從服務(wù)器方進行評估。隨著負載的增加，吞吐量往往增長到一個峰值后，然后下降，隊列變長。在如客戶/服務(wù)器這樣的端到端系統(tǒng)中，吞吐量依賴于每個部件的運行。系統(tǒng)中最慢的點決定了整個系統(tǒng)的吞吐率

23、。通常稱此慢點為瓶頸。？日訪問量？常用頁面最大并發(fā)數(shù)：分為廣義并發(fā)和狹義并發(fā)，沒有特定標明一般指廣義并發(fā)?？梢酝ㄋ桌斫鉃?，在同一個時間點有一批用戶在使用某一功能。當然，同時也有另外一批用戶在使用其他功能。同時在線人數(shù)：在某一時間段有登錄操作的用戶，有上傳、下載、支付款項、頁面瀏覽等的所有用戶人數(shù)。也可 以按照session的個數(shù)來決定。？響應時間：從發(fā)出請求到服務(wù)器響應返回到請求頁面的時間。4、資源利用：率反映系統(tǒng)能耗指標5、創(chuàng)建測試場景、執(zhí)行場景，根據(jù)“測試腳本”，得到“測試腳本運行結(jié)果”。測試實施人員根據(jù)“測試腳本運行結(jié)果”，寫出性能測試報告。第三章缺陷級別和缺陷狀態(tài)定義 J J冏*1 I

24、（一）缺陷級別定義A級不能完全滿足系統(tǒng)要求，基本功能未完全實現(xiàn)；或者危及人身安全。系統(tǒng)崩潰或掛起等導致系統(tǒng)不能繼續(xù)運行。？包括以下各種錯誤：？ I 17號 1 I、產(chǎn)、尸 ” /.由于程序所引起的死機，非法退出？.死循環(huán)？.數(shù)據(jù)庫發(fā)生死鎖？.因錯誤操作導致的程序中斷？.重大功能錯誤？.與數(shù)據(jù)庫連接錯誤？.數(shù)據(jù)通訊錯誤B級嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有更正辦法（重新安裝或重新啟 動該軟件不屬于更正辦法）。使系統(tǒng)不穩(wěn)定、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結(jié)果，或部分 功能無法執(zhí)行，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。？包括以下各種錯誤：？.程序接口錯誤？.因錯誤操作迫使程序中

25、斷第，I-.= 二二一J f ，I F ；.?系統(tǒng)可被執(zhí)行，但操作功能無法執(zhí)行（含指令）？.?單項操作功能可被執(zhí)行，但在此功能中某些功能（含指令參數(shù)的使用）無法被執(zhí)行（對系統(tǒng)非致命的）？.?在功能項的某些項目（選項）使用無效（對系統(tǒng)非致命的）？6.業(yè)務(wù)流程不正確？（，二 X 二尸.功能實現(xiàn)不完整，如刪除時沒有考慮數(shù)據(jù)關(guān)聯(lián) ？.功能的實現(xiàn)不正確，如在系統(tǒng)實現(xiàn)的界面上，一些可接受輸入的控件點擊后無作用；對數(shù)據(jù)庫的操作不能正確實現(xiàn)？.？報表格式以及打印內(nèi)容錯誤（行列不完整，數(shù)據(jù)顯示不在所對應的行列等導致數(shù) 據(jù)顯示結(jié)果不正確的錯誤）C級嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法（重新安裝

26、或重新啟動該軟件不屬于更正辦法）。系統(tǒng)性能或響應時間變慢、產(chǎn)生錯誤的中間結(jié)果 但不影響最終結(jié)果等影響有限的問題。？包括以下各種錯誤：？ TOC o 1-5 h z .操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）？.打印內(nèi)容、格式錯誤（只影響報表的格式或外觀，不影響數(shù)據(jù)顯示結(jié)果的錯誤）.簡單的輸入限制未放在前臺進行控制？.刪除操作未給出提示？.雖然正確性不受影響，但系統(tǒng)性能和響應時間受到影響？/ I.不能定位焦點或定位有誤，影響功能實現(xiàn) ？ J，5* $ * 產(chǎn), f yX1Z J： 一.方？.？顯示不正確但輸出正確？.？增刪改查功能，在本界面不能實現(xiàn)，但在另一界面可以補充實現(xiàn)。D級使操

27、作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。界面拼寫 |X、式尸 ” /錯誤或用戶使用不方便等小問題或需要完善的問題。包括以下各種錯誤：.界面不規(guī)范.輔助說明描述不清楚.輸入輸出不規(guī)范.長時間操作未給用戶提示？.提示窗口文字未采用行業(yè)術(shù)語？.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志.必填項與非必填項應加以區(qū)別？.滾動條無效？.鍵盤支持不好，如在可輸入多行的字段中，不支持回車換行；或?qū)ο嗤?？段，在不同界面支持不同的快捷方式?界面不能及時刷新，影響功能實現(xiàn)。E級測試過程中站在用戶角度提出一些易用性，人性化等更利于系統(tǒng)優(yōu)化的建議。.?光標跳轉(zhuǎn)設(shè)置不好，鼠標（光標）定位錯誤.? 一些建議

28、性問題。（二）缺陷狀態(tài)定義（，二 X 二尸OK 測試結(jié)果無差異 I 產(chǎn)， X % y J /NOK測試結(jié)果大部分正確NG 測試結(jié)果有較大的錯誤NT:由于各種原因本次無法測試redmine缺陷狀態(tài)：新建：新發(fā)現(xiàn)的 BU的待解決；進行中：正在修復中； 已解決：已經(jīng)修改過的 BUGW寺返測;BUG反饋：經(jīng)開發(fā)人員、需求人員和測試人員等一致同意不需要修復的已關(guān)閉：由于各種原因不再需要進行任何操作的BUG重新打開：根據(jù)實際情況需要，將修復過的BU加次打開，重新進行 修改和測試；復測通過：開發(fā)修改后經(jīng)測試人員測試通過 ；已投產(chǎn)：已經(jīng)更新到生產(chǎn)環(huán)境，即：已上線；(三)BUGM理原則當變更BUG犬態(tài)時，開發(fā)、

29、測t人員需要確認 bug表單。(1)測試人員處理原則？*r IJ 二一7*?提交BUGf主動與開發(fā)人員溝通，需要以辦公管理軟件、即時通訊工具或郵件通知r 1BUG ?BUG苗述需要盡量做到清晰、易懂，對于可以重現(xiàn)的BUGFF發(fā)人員能夠按照描述步驟重廳 ,現(xiàn)BUG測試執(zhí)行中發(fā)現(xiàn)BUGM接寫入缺陷管理系統(tǒng)的BUGW表中，描述BUG寸要將BUG殳 現(xiàn)步驟描述清楚，還需提供測試數(shù)據(jù)、系統(tǒng)日志、截圖等有助于開發(fā)人員分析、解決BUG勺相關(guān)數(shù)據(jù)；？填報BUGlg者轉(zhuǎn)2他人BU費否需要Email通知根據(jù)不同項目決定，但是所有轉(zhuǎn)給 產(chǎn)品人員的BUG勻需要同步發(fā)送Email通知，并保留發(fā)送記錄以備日后查詢；？(2

30、)開發(fā)人員處理原則？.?開發(fā)人員去除一個BUG必須修改缺陷管理系統(tǒng)中的缺陷狀態(tài)，方便進行回歸測試；？.?對于標記為“可重現(xiàn)”的 BUG開發(fā)人員必須按BUG述步驟自己重現(xiàn)BUG必 要時請測試人員配合重現(xiàn)；.?開發(fā)、測試人員將一個BUG專給他人之，必須發(fā)郵件給接受人和測試人員進行說 明，接受人回復同意交接才可繼續(xù)；.?Bug的優(yōu)先級別遵循測試人員的設(shè)定；？ TOC o 1-5 h z .?任彳51 BUGTB不應該被刪除，但可以被置為“拒絕修改”或“關(guān)閉” ；？ I - -z f r IJ - 7 - -，.?開發(fā)人員修復一個BUGB需要在缺陷報告中詳細描述BUGT生的原因及修復的文 1 I 1件

31、；Cj- - 一一/口 J(3)無效BUGt義？1.?產(chǎn)品定義不明確：如刪除了某會員后該會員登錄系統(tǒng)后是什么狀態(tài)沒有定義，而 由此產(chǎn)生的BUGIU可以選才!此項；？-r.：- IX、三/.產(chǎn)品遺留的BUG如某個項目的升級版本出現(xiàn) BUG經(jīng)查是原版本已知的BUG ?.測試人員誤操作：包括但不限于：測試人員需求理解錯誤、測試環(huán)境中毒、測試 人員技較差、測試人員重復提交已經(jīng)存在的BU摩引起的BUG.需求在報BUG1后發(fā)生了變化導致BUGE效；?BUCT生原因定義？.產(chǎn)品定義不明確，對操作的邏輯定義不完善;產(chǎn)品原有BUG如：某個項目的升級版本出現(xiàn) BUG經(jīng)查是原版本已知的BUGIU可以選擇此項；.粗心

32、大意、單元測試不足、對程序設(shè)計語言不熟悉、軟件設(shè)計缺陷、未遵從編碼 規(guī)范、需求理解錯誤、業(yè)務(wù)知識缺乏？；.由其他BUI起，如：調(diào)用了一段彳t碼，該段代碼存在 BUG則選擇此項)？.相關(guān)系統(tǒng)不兼容引起的BUG.無效BUG如：由于測試人員操作有誤或者由于測試環(huán)境出現(xiàn)問題產(chǎn)生的BUG則選擇 11 1測試退出準則？ “一?新產(chǎn)品測試退出準則？.?所有功能均符合用戶需求并已經(jīng)通過確認；？(，二 X 二尸.？BUG趨勢出現(xiàn)明顯收斂狀態(tài)達到兩個版本以上。明顯收斂的定義：當前測試版本發(fā)現(xiàn)的BUG占此項目總BUGt的033%根據(jù)項目規(guī)模大小不同可以在這個范圍內(nèi)選擇，但最大不能超過3% ？.？測試退出前完成一次執(zhí)

33、行全部測試用例的回歸測試。對優(yōu)先級別為“高”BUG回歸；？.？測試退出前一個版本的測試定為“穩(wěn)定期”，在此期間無優(yōu)先級別為A級、B級的BU第在；？.測試退出前測試經(jīng)理主導召開最后一次 BUG?Review所有與會人需要簽字確認是 否可以退出測試；(6)升級版本測試退出準則？.?完全滿足新產(chǎn)品測試退出準則；.系統(tǒng)當前線上運行版本中的功能、性能未出現(xiàn)新的BUG;(7)Patch (修復BUG版本測試退出準則？.?需要修復的BUGB經(jīng)修復；？.?系統(tǒng)原有版本(指當前線上運行版本)中的功能、性能未出現(xiàn)新的BUG ?.?測試退出前完成一次執(zhí)行全部測試用例的回歸測試及優(yōu)先級別為“高”的BUG0歸；？注：測

34、試退出前測試經(jīng)理主導召開最后一次BUG?Review所有與會人需要簽字確認是否可以退出測試；(，二 X 二尸(8)測試執(zhí)行期間版本發(fā)布原則？開發(fā)人員處理的所有BUG勻需要輸入bug列表，修正的BUG需要說明問題發(fā)生的原 因及如何解決，解決后是否對其他相關(guān)模塊有影響；其他狀態(tài)的 BUG均需要說明理 由。？1)新功能版本發(fā)布？按正常發(fā)布版本流程發(fā)布測試版本。接到新版本測試人員要對新功能進行冒煙測試，主要驗證所提交的功能點是否按需求完成，能否執(zhí)行測試用例。冒煙測試過程中如出現(xiàn)重大BUG阻礙下一步測試，則冒煙測試不通過，不接受測試。待開發(fā)人員進行修復后再部署版本進行測試。？冒煙測試中執(zhí)行的測試用例只標

35、示“運行”狀態(tài)，不報BUG執(zhí)行過程中測試用例如果執(zhí)行失敗則關(guān)聯(lián)BUG ?2)新功能版本+ BUG修正版本發(fā)布？新功能開發(fā)完成后，如果依賴于某個功能模塊且該功能模塊中存在“未修復”的BUG則不接受新版本部署測試。3) BUG修正版本發(fā)布？廠人7 一一，二 TOC o 1-5 h z 測試執(zhí)行過程中，在測試人員進行了第一輪測試后，開發(fā)人員需要對BUGt行修改， r 1 ,原則上修改BUG達到以下標準后才能發(fā)布第二輪測試版本，如遇緊急情況另行處L7- -JJ.，理。?.高優(yōu)先級Bug修復要求？.力爭目標：對優(yōu)先級大于等于 C級的BUGS要全部修復；？ - I /.x X、yJ/.最低目標：對優(yōu)先級大于等于 C級的BUG果不能全部修復，則影響到下一步執(zhí) 行測試的BUC須全部修復；并對不能修復的 BUG合予說明。？.低優(yōu)先級Bug修復要求？：對優(yōu)先級小于C級的BUGS要彳復80% ?對于不修改或 者拒絕的BUGS行說明；不修改的BUGT要項目經(jīng)理將其置為“ Later”狀態(tài)。？.除以上情況外“緊急發(fā)布情況”需要開發(fā)