it基礎(chǔ)-軟件測(cè)試工作流程(參考版)
2025-07-17 20:05本頁(yè)面
【正文】 修 改 紀(jì) 錄 表 編 號(hào) GL/ZL— N002 版 本 擬 制 日 期 20xx/8/4 審 批 日 期 修改人 修改日 期 修改章節(jié) 簡(jiǎn)要描述 20xx/11/21 版本 第 ， ， ，和 節(jié) 減輕測(cè)試人員文檔工作量，重新命名共享目錄，簡(jiǎn)化 BUG 和送測(cè)單的填寫，細(xì)化 BUG 評(píng)級(jí)分類規(guī)定 20xx/3/14 版本 第 5， 6， 7 章 調(diào)整測(cè)試流程 20xx/07/13 版本 全文 結(jié)合輔助測(cè)試系統(tǒng) 對(duì)測(cè)試流程進(jìn)行修改 。它的任務(wù)是驗(yàn)證軟件的有效性，即驗(yàn)證軟件 的功能和性能及其它特性是否與用戶的要求一致。 2. 集成測(cè)試 (Integrate testing) 相互關(guān)聯(lián)的一個(gè)子系統(tǒng)重的所有子模塊已開(kāi)發(fā)完成，全部聯(lián)編后進(jìn)行 測(cè) 試。實(shí)際的測(cè)試過(guò)程可能不會(huì)嚴(yán)格區(qū)分各個(gè)階段，寫在這里僅供參考。例如 ，如果程序的千行源代碼（ KLOC）的數(shù)量是 1000，即該程序有 1 000 000 行源程序，則與該程序相關(guān)的文字資料中允許的最大 BUG 數(shù)就是（ 1000/25+3=） 43 個(gè)。 國(guó)標(biāo)中有關(guān) BUG 數(shù)量的描述 向用戶提交軟件進(jìn)行驗(yàn)收時(shí)，對(duì)于軟件中存在的 BUG 數(shù)量有如下的規(guī)定： 1． 程序中不存在未改的 A、 B 級(jí) BUG； C 級(jí) BUG 的數(shù)量每千行源代碼（ KLOC）中不超過(guò) 1 個(gè)； D、 E 級(jí) BUG 的數(shù)量每千行源代碼（ KLOC）中不超過(guò) 2 個(gè)；對(duì)于隨機(jī)出現(xiàn)的 BUG 的數(shù)量也必須考慮。 BUG 按其嚴(yán)重性可以分為以下幾類： 表 1 按嚴(yán)重性劃分 BUG 嚴(yán)重等級(jí) 描 述 A 極嚴(yán)重 1）可能有災(zāi)難性的后果或是會(huì)出人命的 2) 故意留有程序后門 B 嚴(yán)重 產(chǎn)生錯(cuò)誤的結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定的問(wèn)題 1）造成數(shù)據(jù)庫(kù)不穩(wěn)定的錯(cuò)誤； 2）系統(tǒng) 崩潰 ，無(wú)法繼續(xù)操作 3）列在說(shuō)明中的需求未在最終系統(tǒng)中實(shí)現(xiàn) 4）業(yè)務(wù)流程不正確 C 中等的 不正確的，但不會(huì)影響系統(tǒng)穩(wěn)定性的 1） 過(guò)程調(diào)用或其它腳本錯(cuò)誤； 2） 打印錯(cuò)誤或打印出來(lái)的結(jié)果與用戶的要求不一致 3） 系統(tǒng)刷新錯(cuò)誤； 4） 產(chǎn)生錯(cuò)誤結(jié)果，如計(jì)算結(jié)果錯(cuò)誤等 5） 功能的實(shí) 現(xiàn)有問(wèn)題。 BUG 的分類評(píng)級(jí)原則 BUG 的大小、嚴(yán)重性在不同的系統(tǒng)中相差很多，最嚴(yán)重的 BUG 會(huì)讓開(kāi)發(fā)者立刻放下手中的其他事來(lái)改正它們。 測(cè)試組在測(cè)試時(shí)，重點(diǎn)測(cè)試本次送測(cè)新添加的模塊。 待測(cè)模塊的組合與測(cè)試原則 開(kāi)發(fā)組應(yīng)當(dāng)首先完成軟件的核心模塊，和軟件的主界面設(shè)計(jì)。 開(kāi)發(fā)階段與測(cè)試階段 測(cè)試階段對(duì)應(yīng)于開(kāi)發(fā)過(guò)程中的編碼階段，每一個(gè)相對(duì)獨(dú)立的編碼階段都可以形成一個(gè)測(cè)試階段，比如單元測(cè)試、集成測(cè)試等。 測(cè)試報(bào)告提交后，項(xiàng)目經(jīng)理、開(kāi)發(fā)部門經(jīng)理、質(zhì)量部經(jīng)理以及公司的技術(shù)委員會(huì)將審閱或簽字確認(rèn)，并將成為軟件是否可發(fā)行的參考資料之一。 本階段的測(cè)試工作結(jié)束后，測(cè)試主管（或其指定人員）應(yīng)該提交一份本階段的測(cè)試報(bào)告。 ? 如果本 BUG 單已經(jīng) CLOSE，則由測(cè)試人員口頭通知程序員，否則重復(fù)以上的步驟。 ? 程序員確認(rèn) BUG，并將處理意見(jiàn)填入 BUG紀(jì)錄的備 注字段中。 ? 測(cè)試員根據(jù)測(cè)試用例做測(cè)試，將發(fā)現(xiàn)的 BUG 現(xiàn)象填入對(duì)應(yīng)的BUG 單中 。否則繼續(xù)下一步。不相同就把 BUG 單打回給程序員。 7． 對(duì)于確定已經(jīng)修改成功的 BUG，測(cè)試員要將 BUG 的狀態(tài)置為“ CLOSE”；如果一張 BUG 單上的所有紀(jì)錄都已經(jīng) CLOSE，則測(cè)試人員可以將本 BUG 單的狀態(tài)置為 CLOSE，這樣此張BUG 單將退出測(cè)試流程，輔助測(cè)試系統(tǒng)提供選項(xiàng)可使 BUG 單再重新進(jìn)入測(cè)試流程；此時(shí)測(cè)試員應(yīng)當(dāng)保存模塊的修訂版本， 并口頭通知開(kāi)發(fā)人員。如果是，則測(cè)試員驗(yàn)證是否按照處理方法的描述解決了所有問(wèn)題；否則將BUG 單再次返回給程序員。但必須更新 BUG 單上的“修訂版本”字段。 4． 備注字段在開(kāi)發(fā)人員向測(cè)試人員解釋自己的回答時(shí)由開(kāi)發(fā)人員填寫，也可在測(cè)試人員向開(kāi)發(fā)人員詳細(xì)解釋 BUG 描寫的時(shí)候填寫。一個(gè) BUG 是否暫不修改必須由項(xiàng)目經(jīng)理審查并確認(rèn)。對(duì) BUG 和問(wèn)題的回答有三種方式：一是“已修改”； 二是“暫不修改”；三是“不存在 ”。 3． BUG 處理一欄由開(kāi)發(fā)人員填寫。對(duì)于問(wèn)題和建議，它 們的級(jí)別應(yīng)當(dāng)選擇為“未定義”。 2）對(duì)每一個(gè) BUG 的評(píng)級(jí)工作由測(cè)試員完成并由驗(yàn)證人加以確認(rèn)。 BUG 和問(wèn)題的描述中，操作步驟和 BUG 現(xiàn)象用“ =〉”加以區(qū)分，“ =〉”以前是重復(fù)本問(wèn)題的步驟，以后是測(cè)試員認(rèn)為不對(duì)的地方。 1）對(duì)發(fā)現(xiàn)的BUG 按測(cè)試發(fā)現(xiàn)的順序排序。 BUG 單的形式如下： Bug 單 項(xiàng)目名稱 被 測(cè) 模 塊 項(xiàng)目經(jīng)理 送測(cè)版本 送測(cè)人 測(cè)試員 驗(yàn)證人 收測(cè)日期 最后修改日期 修訂版本 BUG 描述 BUG類別 BUG 級(jí)別 BUG 處理 備注 1. BUG 單的填寫 在輔助測(cè)試系統(tǒng)中，一旦測(cè)試員接收了送測(cè)單，對(duì)應(yīng)的 BUG 單會(huì)自動(dòng)產(chǎn)生，因此在上面的 BUG 單中基本上測(cè)試員只需要填寫 BUG描述、 BUG 類別和 BUG 級(jí)別字段，而送測(cè)的程序員只需要填寫修訂版本和 BUG 處理就行了。 BUG 單模塊也已經(jīng)集成到輔助測(cè)試系統(tǒng)當(dāng)中了，這里給出 BUG 單的主要元素及其填寫方法。 7 ． BUG 單 每一個(gè)送測(cè)單將對(duì)應(yīng)的產(chǎn)生一個(gè) BUG 單。 ? 測(cè)試員確認(rèn)需要的文檔資料和程序，簽收后
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1