軟件測試規(guī)章制度

年4月19日軟件測試規(guī)章制度文檔僅供參考，不當之處，請聯(lián)系改正。軟件測試規(guī)章制度【篇一：軟件測試管理流程與規(guī)范】軟件測試管理流程與規(guī)范前言目的：為統(tǒng)一軟件測試制度，更好的管理軟件測試，更好的配合軟件工程師軟件的下發(fā)，特制定。本標準的附錄記錄文檔是規(guī)范性文檔。本標準由萬捷科技有限公司top測試組提出，top測試組歸口。本標準起草部門：萬捷top測試組。本標準于4月7日發(fā)布。1、范圍本標準規(guī)定了軟件測試的流程。本標準規(guī)范了軟件測試的文檔。本標準適用于萬捷測試組。2、軟件測試的流程2.1軟件下發(fā)流程軟件方案→xxx公司top組軟件測試組組長軟件從發(fā)放到測試組進行測試為一個完整周期。一款軟件需測試由軟件方案方直接下發(fā)給萬捷top組測試組長，方案公司軟件負責人需填寫一份《軟件發(fā)布信息表～開發(fā)》才能下發(fā)至測試組，其表需詳細填寫機型、版本、改了些什么問題、測試時需注意的事項等，以便軟件能有效有質(zhì)的完成測試。（《軟件發(fā)布信息表1》請見附錄1）2.2軟件測試周期軟件從發(fā)放到測試組進行重點功能點檢需半天，全面測試需2天，專項測試需1天，（以上為人員充分情況下的理想狀態(tài)），在計劃時需作好時間的預留。3、萬捷測試組職責分配萬捷top測試組較成熟軟件試產(chǎn)軟件量產(chǎn)軟件萬捷top測試組負責較成熟軟件、試產(chǎn)軟件和量產(chǎn)軟件的測試，為避免發(fā)放到測試組的軟件有嚴重問題引起重復的無效測試，在軟件發(fā)放到萬捷之前軟件方案公司需自行進行測試，確認無嚴重問題再下發(fā)給萬捷top測試組進行測試。對于試產(chǎn)軟件某些功能未完善，某些bug由于時間問題未及時改進，須在軟件提交到測試組時，由軟件方案公司軟件負責人提交相關說明。每個外發(fā)出去的軟件版本都需經(jīng)過測試組測試確認合格；特別是量產(chǎn)軟件必須全面測試后才能外發(fā)出去。填寫〈軟件發(fā)布信息表2〉給各部門負責人簽字確認，再發(fā)出。（《軟件發(fā)布信息表2》請見附錄2）4、客戶反饋問題的反饋客戶反饋問題→高威爾客服服務部--→萬捷top測試組組長關于客戶反饋的軟件問題，由于客戶對于問題的描述不清晰或不全面或不是問題的問題直接提交到開發(fā)造成開發(fā)經(jīng)常要猜測問題復現(xiàn)路徑，對問題出現(xiàn)誤解，則須由測試組驗證確認后提交到軟件方案公司進行修改，不是問題/設計如此的也須由測試組回復一份報告給客服人員到客戶，以避免客戶再次反饋同樣的問題。5、軟件測試問題的反饋測試組對于每發(fā)布的一版軟件的測試結(jié)果必須詳細記錄在部門內(nèi)部buglist中或bug管理工具中，待測試完畢后整理，統(tǒng)一發(fā)出。若發(fā)現(xiàn)嚴重bug，可及時隨時反饋，發(fā)便bug能及時修改。測試結(jié)果（《軟件測試報告》請見附錄3軟件測試報告發(fā)送給方案公司項目接口人，由該接口人將此報告給相關的開發(fā)工程師，由軟件方案公司軟件開發(fā)工程師給出bug的修改建議，由萬捷科技top測試組長及軟件方案公司接口人共同跟進bug的解決進度。若有bug管理工具，則不需要以下步驟1。關于測試bug的整理與共享：(1)由測試組組長共享一目錄給部門項目相關負責人，格式為：buglist（項目名）buglist(2)測試組組長整理好各項目各版本的測試記錄。(3)各項目的每版軟件buglist...測試組組長要整理各種buglist，避免同一bug提交兩次；確保軟件方案公司同事，避免同一個已經(jīng)解決的bug出現(xiàn)兩次。對于某些新增功能的測試，由軟件方案公司相關開發(fā)人員或接口人與萬捷科技接口人共同出＊＊新功能測試指導給相關的測試人員；有必要時做＊＊新功能培訓。6、buglist的命名規(guī)則:buglist的優(yōu)先級由測試工程師確定,建議再加項其它，用以說明未考慮到的其它情況.關于bug的優(yōu)先級劃分請參照文檔〈軟件黑盒測試評估規(guī)范〉。（《軟件黑盒測試評估規(guī)范》請見附錄4）例：7、軟件測試工作的評估軟件測試不可能把所有的問題都發(fā)現(xiàn)出來只能最大程度上的減少問題的發(fā)生。對于軟件測試工作的評估如下：當外發(fā)的軟件有嚴重問題時，則記測試組一次工作失誤。當然，軟件方案公司開發(fā)人員也要對測試組負責，盡量避免使一些已經(jīng)解決的bug重復多次出現(xiàn)。8、量產(chǎn)版本的評估萬捷top測試組原則上量產(chǎn)軟件只有在經(jīng)過測試組測試且沒有a類嚴重問題后方能用于出貨軟件。在出貨任務緊急時，須由測試組、軟件開發(fā)、項目、銷售等相關部門評估同意后方能用做出貨軟件。9.軟件測試計劃的制定開發(fā)部門應提前制定測試計劃，但由于此計劃牽涉到項目部、客戶等多種軟件部不能決定的因素，根據(jù)實際情況，盡可能適當提前告之測試組相關軟件測試計劃。10、說明書的編寫每款機型的說明書由軟件方案公司相關人員編寫，萬捷top測試組進行審核及整理。客戶有關說明書問題的反饋由萬捷top測試組長跟進，并有效及時給予客戶回復。11、測試sim卡的使用測試sim卡由測試組長統(tǒng)一管理。需要充值時填寫“物品申構(gòu)單”，由公司進行充值。若公司不統(tǒng)一進行充值，購買充值卡時請索要發(fā)票，方便報銷。并在充值成功后記錄充值時間及卡內(nèi)余額。測試卡使用時請注意節(jié)約話費，避免不必要的開銷，嚴禁將測試卡作為測試工作以外的用途。暫定每張測試卡每次充值最高為人民幣一百元，可根據(jù)實際情況適當調(diào)整。12、手機測試的相關文檔12.1mtk平臺點檢表文檔：可作功能點檢。（《軟件發(fā)布點檢表》請見附錄5）12.2全面測試（mmi測試）文檔：可作手機全面測試文檔規(guī)范。（全面測試《mmi測試》文檔請見附錄6）12.3通話測試文檔：每版輸進行全面測試的軟件都得進行一次通話測試。（《通話測試》文檔請見附錄7）12.4通話專項測試文檔：每款機型至少要進行一次通話專項測試。（《通話專項測試規(guī)范文檔》請見附錄8）12.5lcd專項測試文檔：手機換屏后需進行l(wèi)cd專項測試。（《lcd專項》文檔請見附錄9）12.6flash-專項測試文檔：手機換flash后需進行flash專項測試。（《flash-專項測試》文檔請見附錄10）12.7重點功能測試文檔：作重點功能檢測。（《重點功能測試》文檔請見附錄11）13、附錄文檔（軟件測試的規(guī)范文檔），請見后續(xù)幾頁。附錄1：【篇二：軟件測試管理辦法】北京酷智科技有限公司軟件測試管理辦法（試行）1.職責劃分1.1測試組長1.參與軟件需求設計的評審及項目可行性分析，風險預估，測試資源的申請；2.編制軟件測試計劃、軟件測試用例，定期進行維護更新；7.與其它部門的協(xié)調(diào)和合作。1.2軟件測試工程師1.按照測試計劃進行測試用例的執(zhí)行，維護；2.測試記錄的整理，提交、驗證、關閉缺陷；3.跟蹤缺陷退回的問題，必須有詳細的原因分析我們才能夠進行缺陷退回缺陷的否決；4.完成性能與壓力測試。1.3質(zhì)量保證qa組1.對測試過程進行質(zhì)量監(jiān)督；2.保證項目按照正常的計劃執(zhí)行；3.并進行階段性的質(zhì)量評估。2.作業(yè)流程詳細規(guī)定了測試組在整個項目中各個階段的職責及相關測試輸出文檔：3.測試類型和策略按照當前的產(chǎn)品類型和規(guī)模，需要執(zhí)行的測試類型及策略如下：4.缺陷級別定義5.缺陷管理流程1.缺陷描述中要包括詳細、準確的操作步驟、預期結(jié)果、實際結(jié)果、測試環(huán)境。2.缺陷提交時在“實際結(jié)果”欄目中填寫測試數(shù)據(jù)、執(zhí)行結(jié)果內(nèi)容，盡量將缺陷的界面截圖作為附件上傳至對應的記錄。3.“否決缺陷”、“暫緩處理”此兩類缺陷要求在缺陷“注釋”中注明否決原因或后續(xù)處理方案。4.對“緊急”級別的缺陷，測試人員應進行隨時地檢查并驗證，及時修改對應缺陷的狀態(tài)。5.缺陷跟蹤遵循：誰發(fā)現(xiàn)誰跟蹤；開發(fā)管理組進行確認、分配缺陷；開發(fā)人員及時修改缺陷或反饋意見。6.開發(fā)管理組人員在自己無法及時分配缺陷的情況下要提前找到代理人員完成該工作，避免缺陷在此環(huán)節(jié)滯留。7.開發(fā)人員必須對缺陷進行及時修改，缺陷提交后，24小時內(nèi)必須進行處理。如果開發(fā)人員沒有及時修改缺陷，則將缺陷嚴重程度的等級升級（低級-中級，中級-高級，高級-緊急）。8.如果缺陷經(jīng)開發(fā)人員多次修改（修改次數(shù)2次），測試驗證后仍存在問題，則將缺陷的嚴重程度的等級升級（低級-中級，中級-高級，高級-緊急）。9.開發(fā)人員必須隨時查看qc中的缺陷狀態(tài)變化信息，每天最低查看次數(shù)不得少于5次。缺陷管理跟蹤流程如下：【篇三：軟件測試管理規(guī)范】軟件測試工作規(guī)范1目的??統(tǒng)一公司所有項目的軟件測試流程；??提供一套適合公司所有項目并可裁減的軟件測試工具；2范圍??本規(guī)范中單元測試適用于所有的java項目；??本規(guī)范中集成測試、系統(tǒng)測試和性能測試適用于所有項目。3測試階段與軟件開發(fā)階段的對應關系1過程描述1.1單元測試活動該活動包括以下環(huán)節(jié)：??編寫單元測試計劃；??設計單元測試用例；??執(zhí)行單元測試過程；??記錄單元測試缺陷；??編寫單元測試報告；1.1.1活動目的驗證軟件系統(tǒng)模塊內(nèi)功能、容錯、界面和報表測試和樁模塊、子模塊之間的接口測試。1.1.2角色與職責1.1.3測試范圍??單元模塊的功能性測試??單元模塊內(nèi)和模塊之間的接口測試??單元模塊的容錯性測試??單元模塊的界面測試??單元模塊內(nèi)的權限1.1.4進入條件已經(jīng)完成被測模塊的編碼工作1.1.5輸入《詳細設計說明書》1.1.6活動說明對于結(jié)構(gòu)化的編程語言，程序單元指程序中定義的函數(shù)或子程序。單元測試是指對函數(shù)或子程序所進行的測試。對于面向?qū)ο蟮木幊陶Z言，程序單元指特定的一個具體的類或相關的多個類。單元模塊之間的接口等。（1）開發(fā)人員依據(jù)詳細設計編寫單元測試計劃和和單元測試用例，《詳見junit使用說明》和《jprobe使用說明》，需詳細描述該用例的輸入、輸出和預期結(jié)果等相關內(nèi)容；（2）開發(fā)人員編寫程序代碼；（3）開發(fā)人員執(zhí)行單元測試用例，并記錄執(zhí)行結(jié)果；（4）開發(fā)人員執(zhí)行測試用例過程中發(fā)現(xiàn)的缺陷，必須提交到缺陷跟蹤工具中；（5）開發(fā)組長完成單元測試后，編寫單元測試分析報告，項目經(jīng)理審核《單元測試分析報告》。1.1.7輸出已經(jīng)過回歸測試、打標簽單元級的代碼《單元測試分析報告》1.1.8退出條件??被測代碼語句覆蓋率滿足單元測試計劃中制定的代碼覆蓋率要求；??測試用例執(zhí)行覆蓋率應達100%；??《單元測試分析報告》經(jīng)過評審；??a類缺陷、b類缺陷、c類缺陷為零，d類缺陷少于10％，e類缺陷少于15％。1.1.9工具與方法??java項目junit3.7以上版本：利用junit提供的組件測試代碼的功能邏輯；jprobe5.0以上版本：使用coverage組件檢查代碼覆蓋率。??工具使用參見《junit使用簡明手冊》，《jprobe使用簡明手冊》。1.2集成測試活動該活動包括以下環(huán)節(jié)：??編寫集成測試計劃；??設計集成測試用例；??執(zhí)行集成測試過程；??記錄集成測試缺陷；??編寫集成測試分析報告；1.2.1活動目的1.2.2角色與職責1.2.3測試范圍??系統(tǒng)集成后的功能性測試；??系統(tǒng)集成后的容錯性測試；??系統(tǒng)集成后的界面測試；??系統(tǒng)集成后的安全（權限）測試；??系統(tǒng)集成后的系統(tǒng)的內(nèi)部接口測試；??系統(tǒng)集成后的可用性測試；??系統(tǒng)集成后的數(shù)據(jù)完整性測試。1.2.4進入條件《概要設計說明書》經(jīng)過評審1.2.5輸入《概要設計說明書》1.2.6活動說明（1）測試組長制定《集成測試計劃》；（2）測試人員負責組織編寫集成測試用例，編寫測試腳本，編寫測試用例。（3）測試人員執(zhí)行測試用例。（4）測試過程中發(fā)現(xiàn)缺陷提交到缺陷跟蹤系統(tǒng)；（5）架構(gòu)師對缺陷進行評估并分發(fā)，若判斷是缺陷則指定相關開發(fā)人員進行修改；（6）開發(fā)人員修改完缺陷后，由測試人員進行回歸測試，測試經(jīng)過則缺陷關閉，檢驗未經(jīng)過，則轉(zhuǎn)給開發(fā)人員，繼續(xù)修改；（7）測試人員編寫集成測試分析報告。1.2.7輸出??已經(jīng)過回歸測試、打標簽系統(tǒng)級的代碼；??《集成測試分析報告》；??a類缺陷、b類缺陷、c類缺陷為零，d類缺陷少于5％，e類缺陷少于10％。1.2.8退出條件《集成測試分析報告》經(jīng)過評審代碼基線化1.2.9工具與方法因具體項目