軟件測試規(guī)章制度_第1頁
軟件測試規(guī)章制度_第2頁
軟件測試規(guī)章制度_第3頁
軟件測試規(guī)章制度_第4頁
軟件測試規(guī)章制度_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

軟件測試規(guī)章制度LT軟件測試規(guī)章制度【篇一:軟件測試管理流程與規(guī)范】軟件測試管理流程與規(guī)范前言目的:為統(tǒng)一軟件測試制度,更好的管理軟件測試,更好的配合軟件工程師軟件的下發(fā),特制定。本標(biāo)準(zhǔn)的附錄記錄文檔是規(guī)范性文檔。本標(biāo)準(zhǔn)由萬捷科技有限公司top測試組提出,top測試組歸口。本

標(biāo)準(zhǔn)起草部門:萬捷top測試組。本標(biāo)準(zhǔn)于2009年4月7日發(fā)布。1、范I本標(biāo)準(zhǔn)規(guī)定了軟件測試的流程。本標(biāo)準(zhǔn)規(guī)范了軟件測試的文檔。本標(biāo)準(zhǔn)適用于萬捷測試組。2、軟件測試的流程2.1軟件下發(fā)流程軟件方案——xxx公司top組軟件測試組組長軟件從發(fā)放到測試組進行測試為一個完整周期。一款軟件需測試由軟件方案方直接下發(fā)給萬捷top組測試組長,方案公司軟件負(fù)責(zé)人需填寫一份《軟件發(fā)布信息表?開發(fā)》才能下發(fā)至測試組,其表需詳細(xì)填寫機型、版本、改了些什么問題、測試時需注意的事項等,以便軟件能有效有質(zhì)的完成測試。(《軟件發(fā)布信息表1》請見附錄1)2.2軟件測試周期軟件從發(fā)放到測試組進行重點功能點檢需半天,全面測試需2天,專項測試需1天,(以上為人員充足情況下的理想狀態(tài)),在計劃時需作好時間的預(yù)留。3、 萬捷測試組職責(zé)分配萬捷top測試組較成熟軟件試產(chǎn)軟件量產(chǎn)軟件萬捷top測試組負(fù)責(zé)較成熟軟件、試產(chǎn)軟件和量產(chǎn)軟件的測試,為避免發(fā)放到測試組的軟件有嚴(yán)重問題引起反復(fù)的無效測試,在軟件發(fā)放到萬捷之前軟件方案公司需自行進行測試,確認(rèn)無嚴(yán)重問題再下發(fā)給萬捷top測試組進行測試。對于試產(chǎn)軟件某些功能未完善,某些bug由于時間問題未及時改善,須在軟件提交到測試組時,由軟件方案公司軟件負(fù)責(zé)人提交相關(guān)說明。每個外發(fā)出去的軟件版本都需經(jīng)過測試組測試確認(rèn)合格;特別是量產(chǎn)軟件必須全面測試后才能外發(fā)出去。填寫〈軟件發(fā)布信息表2〉給各部門負(fù)責(zé)人簽字確認(rèn),再發(fā)出。(《軟件發(fā)布信息表2》請見附錄2)4、 客戶反饋問題的反饋客戶反饋問題——高威爾客服服務(wù)部--—萬捷top測試組組長關(guān)于客戶反饋的軟件問題,由于客戶對于問題的描述不清晰或不全面或不是問題的問題直接提交到開發(fā)造成開發(fā)經(jīng)常要猜測問題復(fù)現(xiàn)路徑,對問題出現(xiàn)誤解,則須由測試組驗證確認(rèn)后提交到軟件方案公司進行修改,不是問題/設(shè)計如此的也須由測試組回復(fù)一份報告給客服人員到客戶,以避免客戶再次反饋同樣的問題。5、軟件測試問題的反饋測試組對于每發(fā)布的一版軟件的測試結(jié)果必須詳細(xì)記錄在部門內(nèi)部buglist中或bug管理工具中,待測試完畢后整理,統(tǒng)一發(fā)出。若發(fā)現(xiàn)嚴(yán)重bug,可及時隨時反饋,發(fā)便bug能及時修改。測試結(jié)果(《軟件測試報告》請見附錄3軟件測試報告發(fā)送給方案公司項目接口人,由該接口人將此報告給相關(guān)的開發(fā)工程師,由軟件方案公司軟件開發(fā)工程師給出bug的修改建議,由萬捷科技top測試組長及軟件方案公司接口人共同跟進bug的解決進度。若有bug管理工具,則不需要以下步驟1。關(guān)于測試bug的整理與共享:(1) 由測試組組長共享一目錄給部門項目相關(guān)負(fù)責(zé)人,格式為:buglist(項目名)buglist(2) 測試組組長整理好各項目各版本的測試記錄。⑶各項目的每版軟件buglist...測試組組長要整理各種buglist,避免同一bug提交兩次;確保軟件方案公司同事,避免同一個已經(jīng)解決的bug出現(xiàn)兩次。對于某些新增功能的測試,由軟件方案公司相關(guān)開發(fā)人員或接口人與萬捷科技接口人共同出**新功能測試指導(dǎo)給相關(guān)的測試人員;有必要時做大大新功能培訓(xùn)。6、buglist的命名規(guī)則:buglist的優(yōu)先級由測試工程師確定,建議再加項其它,用以說明未考慮到的其它情況.關(guān)于bug的優(yōu)先級劃分請參照文檔〈軟件黑盒測試評估規(guī)范〉。(《軟件黑盒測試評估規(guī)范》請見附錄4)例:7、軟件測試工作的評估軟件測試不可能把所有的問題都發(fā)現(xiàn)出來只能最大程度上的減少問題的發(fā)生。對于軟件測試工作的評估如下:當(dāng)外發(fā)的軟件有嚴(yán)重問題時,則記測試組一次工作失誤。當(dāng)然,軟件方案公司開發(fā)人員也要對測試組負(fù)責(zé),盡量避免使一些已經(jīng)解決的bug重復(fù)多次出現(xiàn)。8、量產(chǎn)版本的評估萬捷top測試組原則上量產(chǎn)軟件只有在通過測試組測試且沒有a類嚴(yán)重問題后方能用于出貨軟件。在出貨任務(wù)緊急時,須由測試組、軟件開發(fā)、項目、銷售等相關(guān)部門評估同意后方能用做出貨軟件。9.軟件測試計劃的制定開發(fā)部門應(yīng)提前制定測試計劃,但由于此計劃牽涉到項目部、客戶等多種軟件部不能決定的因素,根據(jù)實際情況,盡可能適當(dāng)提前告之測試組相關(guān)軟件測試計劃。10、說明書的編寫每款機型的說明書由軟件方案公司相關(guān)人員編寫,萬捷top測試組進行審核及整理??蛻粲嘘P(guān)說明書問題的反饋由萬捷top測試組長跟進,并有效及時給予客戶回復(fù)。11、測試sim卡的使用測試sim卡由測試組長統(tǒng)一管理。需要充值時填寫“物品申構(gòu)單”,由公司進行充值。若公司不統(tǒng)一進行充值,購買充值卡時請索要發(fā)票,方便報銷。并

在充值成功后記錄充值時間及卡內(nèi)余額。測試卡使用時請注意節(jié)約話費,避免不必要的開銷,嚴(yán)禁將測試卡作為測試工作以外的用途。暫定每張測試卡每次充值最高為人民幣一百元,可根據(jù)實際情況適當(dāng)調(diào)整。12、 手機測試的相關(guān)文檔12?1mtk平臺點檢表文檔:可作功能點檢。(《軟件發(fā)布點檢表》請見附錄5)12.2全面測試(mmi測試)文檔:可作手機全面測試文檔規(guī)范。(全面測試《mmi測試》文檔請見附錄6)12.3通話測試文檔:每版輸進行全面測試的軟件都得進行一次通話測試。(《通話測試》文檔請見附錄7)12.4通話專項測試文檔:每款機型至少要進行一次通話專項測試。(《通話專項測試規(guī)范文檔》請見附錄8)12.5lcd專項測試文檔:手機換屏后需進行l(wèi)ed專項測試。(《led專項》文檔請見附錄9)12.6flash-專項測試文檔:手機換flash后需進行flash專項測試。(《flash-專項測試》文檔請見附錄10)12.7重點功能測試文檔:作重點功能檢測。(《重點功能測試》文檔請見附錄11)13、 附錄文檔(軟件測試的規(guī)范文檔),請見后續(xù)幾頁。附錄1:【篇二:軟件測試管理辦法】北京酷智科技有限公司軟件測試管理辦法(試行)職責(zé)劃分1.1測試組長參與軟件需求設(shè)計的評審及項目可行性分析,風(fēng)險預(yù)估,測試資源的申請;編制軟件測試計劃、軟件測試用例,定期進行維護更新;與其他部門的協(xié)調(diào)和合作。1.2軟件測試工程師1.按照測試計劃進行測試用例的執(zhí)行,維護;2.測試記錄的整理,提交、驗證、關(guān)閉缺陷;跟蹤缺陷退回的問題,必須有詳細(xì)的原因分析我們才可以進行缺陷退回缺陷的否決;4.完成性能與壓力測試。1.3質(zhì)量保證qa組對測試過程進行質(zhì)量監(jiān)督;2.保證項目按照正常的計劃執(zhí)行;3.并進行階段性的質(zhì)量評估。作業(yè)流程詳細(xì)規(guī)定了測試組在整個項目中各個階段的職責(zé)及相關(guān)測試輸出文檔:3.測試類型和策略按照目前的產(chǎn)品類型和規(guī)模,需要執(zhí)行的測試類型及策略如下:缺陷級別定義缺陷管理流程缺陷描述中要包括詳細(xì)、準(zhǔn)確的操作步驟、預(yù)期結(jié)果、實際結(jié)果、測試環(huán)境。缺陷提交時在“實際結(jié)果”欄目中填寫測試數(shù)據(jù)、執(zhí)行結(jié)果內(nèi)容,盡量將缺陷的界面截圖作為附件上傳至對應(yīng)的記錄。3.“否決缺陷”、“暫緩處理”此兩類缺陷要求在缺陷“注釋”中注明否決原因或后續(xù)處理方案。4.對“緊急”級別的缺陷,測試人員應(yīng)進行隨時地檢查并驗證,及時修改對應(yīng)缺陷的狀態(tài)。5.缺陷跟蹤遵循:誰發(fā)現(xiàn)誰跟蹤;開發(fā)管理組進行確認(rèn)、分配缺陷;開發(fā)人員及時修改缺陷或反饋意見。6.開發(fā)管理組人員在自己無法及時分配缺陷的情況下要提前找到代理人員完成該工作,避免缺陷在此環(huán)節(jié)滯留。7.開發(fā)人員必須對缺陷進行及時修改,缺陷提交后,24小時內(nèi)必須進行處理。如果開發(fā)人員沒有及時修改缺陷,則將缺陷嚴(yán)重程度的等級升級(低級-中級,中級-高級,高級-緊急)。如果缺陷經(jīng)開發(fā)人員多次修改(修改次數(shù)2次),測試驗證后仍存在問題,則將缺陷的嚴(yán)重程度的等級升級(低級-中級,中級-高級,高級-緊急)。9.開發(fā)人員必須隨時查看qc中的缺陷狀態(tài)變化信息,每天最低查看次數(shù)不得少于5次。缺陷管理跟蹤流程如下:【篇三:軟件測試管理規(guī)范】軟件測試工作規(guī)范1目的??統(tǒng)一公司所有項目的軟件測試流程;??提供一套適合公司所有項目并可裁減的軟件測試工具;2范圍??本規(guī)范中單元測試適用于所有的java項目;??本規(guī)范中集成測試、系統(tǒng)測試和性能測試適用于所有項目。3測試階段與軟件開發(fā)階段的對應(yīng)關(guān)系1過程描述1.1單元測試活動該活動包括以下環(huán)節(jié):??編寫單元測試計劃;??設(shè)計單元測試用例;??執(zhí)行單元測試過程;??記錄單元測試缺陷;??編寫單元測試報告;1.1.1活動目的驗證軟件系統(tǒng)模塊內(nèi)功能、容錯、界面和報表測試和樁模塊、子模塊之間的接口測試。1.1.2角色與職責(zé)1.1.3測試范圍??單元模塊的功能性測試??單元模塊內(nèi)和模塊之間的接口測試??單元模塊的容錯性測試??單元模塊的界面測試??單元模塊內(nèi)的權(quán)限1.1.4進入條件已經(jīng)完成被測模塊的編碼工作1.1.5輸入《詳細(xì)設(shè)計說明書》1.1.6活動說明對于結(jié)構(gòu)化的編程語言,程序單元指程序中定義的函數(shù)或子程序。單元測試是指對函數(shù)或子程序所進行的測試。對于面向?qū)ο蟮木幊陶Z言,程序單元指特定的一個具體的類或相關(guān)的多個類。單元模塊之間的接口等。(1) 開發(fā)人員依據(jù)詳細(xì)設(shè)計編寫單元測試計劃和和單元測試用例,《詳見junit使用說明》和《jprobe使用說明》,需詳細(xì)描述該用例的輸入、輸出和預(yù)期結(jié)果等相關(guān)內(nèi)容;(2) 開發(fā)人員編寫程序代碼;(3) 開發(fā)人員執(zhí)行單元測試用例,并記錄執(zhí)行結(jié)果;(4) 開發(fā)人員執(zhí)行測試用例過程中發(fā)現(xiàn)的缺陷,必須提交到缺陷跟蹤工具中;(5) 開發(fā)組長完成單元測試后,編寫單元測試分析報告,項目經(jīng)理審核《單元測試分析報告》。1.1.7輸出已通過回歸測試、打標(biāo)簽單元級的代碼《單元測試分析報告》1.1.8退出條件??被測代碼語句覆蓋率滿足單元測試計劃中制定的代碼覆蓋率要求;??測試用例執(zhí)行覆蓋率應(yīng)達100%;??《單元測試分析報告》通過評審;??a類缺陷、b類缺陷、c類缺陷為零,d類缺陷少于10%,e類缺陷少于15%。1.1.9工具與方法??java項目junit3.7以上版本:利用junit提供的組件測試代碼的功能邏輯;jprobe5.0以上版本:使用coverage組件檢查代碼覆蓋率。??工具使用參見《junit使用簡明手冊》,《jprobe使用簡明手冊》。1.2集成測試活動該活動包括以下環(huán)節(jié):??編寫集成測試計劃;??設(shè)計集成測試用例;??執(zhí)行集成測試過程;??記錄集成測試缺陷;??編寫集成測試分析報告;1.2.1活動目的1.2.2角色與職責(zé)1.2.3測試范圍??系統(tǒng)集成后的功能性測試;??系統(tǒng)集成后的容錯性測試;??系統(tǒng)集成后的界面測試;??系統(tǒng)集成后的安全(權(quán)限)測試;??系統(tǒng)集成后的系統(tǒng)的內(nèi)部接口測試;??系統(tǒng)集成后的可用性測試;??系統(tǒng)集成后的數(shù)據(jù)完整性測試。1.2.4進入條件《概要設(shè)計說明書》通過評審1.2.5輸入《概要設(shè)計說明書》1.2.6活動說明(1) 測試組長制定《集成測試計劃》;(2) 測試人員負(fù)責(zé)組織編寫集成測試用例,編寫測試腳本,編寫測試用例。(3) 測試人員執(zhí)行測試用例。(4) 測試過程中發(fā)現(xiàn)缺陷提交到缺陷跟蹤系統(tǒng);(5) 架構(gòu)師對缺陷進行評估并分發(fā),若判斷是缺陷則指定相關(guān)開發(fā)人員進行修改;(6) 開發(fā)人員修改完缺陷后,由測試人員進行回歸測試,測試通過則缺陷關(guān)閉,檢驗未通過,則轉(zhuǎn)給開發(fā)人員,繼續(xù)修改;(7) 測試人員編寫集成測試分析報告。1.2.7輸出??已通過回歸測試、打標(biāo)簽系統(tǒng)級的代碼;??《集成測試分析報告》;??a類缺陷、b類缺陷、c類缺陷為零,d類缺陷少于5%,e類缺陷少于10%。1.2.8退出條件《集成測試分析報告》通過評

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論