【導(dǎo)讀】合、送測單和BUG單的填寫、測試循環(huán)的結(jié)束等部分。則等也在本流程文件中有相關(guān)的描述。試工作，而且還要進(jìn)行白盒測試中的“代碼走查”工作。

　　

【正文】 測試工作的總結(jié)等。 測試報告提交后，項(xiàng)目經(jīng)理、開發(fā)部門經(jīng)理、質(zhì)量部經(jīng)理以及公司的技術(shù)委員會將審閱或簽字確認(rèn)，并將成為軟件是否可發(fā)行的參考資料之一。 9 . 備注 以下內(nèi)容屬于流程之中的一些原則和測試工作中的一些做法，寫在這里供開發(fā)人員參考。 開發(fā)階段與測試階段 測試階段對應(yīng)于開發(fā)過程中的編碼階段，每一個相對獨(dú)立的編碼階段都可以形成一個測試階段，比如單元測試、集成測試等。編碼階段的劃分由開發(fā)組和項(xiàng)目經(jīng)理負(fù)責(zé)，各階段的完成標(biāo)志應(yīng)當(dāng)明確的告知測試組，以利于測試組在測試計劃中分階段的安排測試工作、設(shè)計測試用例和調(diào)配測試資源。 待測模塊的組合與測試原則 開發(fā)組應(yīng)當(dāng)首先完成軟件的核心模塊，和軟件的主界面設(shè)計。每一次軟件送測時，把已完成并通過開發(fā)組內(nèi)部測試的模塊聯(lián)編入核心模塊中送測，已經(jīng)通過測試的模塊不應(yīng)當(dāng)被取出。 測試組在測試時，重點(diǎn)測試本次送測新添加的模塊。對于已測試過的模塊，可以酌情加以發(fā)揮性的測試，但在所有的測試階段之后，每個模塊至少保證測試過兩遍以上。 BUG 的分類評級原則 BUG 的大小、嚴(yán)重性在不同的系統(tǒng)中相差很多，最嚴(yán)重的 BUG 會讓開發(fā)者立刻放下手中的其他事來改正它們。不太嚴(yán)重的則是在時間和資源允許的情況 下才去理會它們。 BUG 按其嚴(yán)重性可以分為以下幾類： 表 1 按嚴(yán)重性劃分 BUG 嚴(yán)重等級 描 述 A 極嚴(yán)重 1）可能有災(zāi)難性的后果或是會出人命的 2) 故意留有程序后門 B 嚴(yán)重 產(chǎn)生錯誤的結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定的問題 1）造成數(shù)據(jù)庫不穩(wěn)定的錯誤； 2）系統(tǒng) 崩潰 ，無法繼續(xù)操作 3）列在說明中的需求未在最終系統(tǒng)中實(shí)現(xiàn) 4）業(yè)務(wù)流程不正確 C 中等的 不正確的，但不會影響系統(tǒng)穩(wěn)定性的 1） 過程調(diào)用或其它腳本錯誤； 2） 打印錯誤或打印出來的結(jié)果與用戶的要求不一致 3） 系統(tǒng)刷新錯誤； 4） 產(chǎn)生錯誤結(jié)果，如計算結(jié)果錯誤等 5） 功能的實(shí) 現(xiàn)有問題。如在系統(tǒng)實(shí)現(xiàn)的界面上，一些可接受輸入的控件點(diǎn)擊后無作用；對數(shù)據(jù)庫的操作不能正確實(shí)現(xiàn) 6） 編碼時數(shù)據(jù)類型、長度定義錯誤的； 7） 對用戶的使用有操作順序上的限制 8） 雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時間受到影響 D 一般性的 不正確的，但是沒有特別損害的輸出，或者使系統(tǒng)使用起來不太方便的錯誤 1）系統(tǒng)的提示語不明確，不簡明 2）滾動條無效 3）可編輯區(qū)和不可編輯區(qū)不明顯， 4）光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯誤； 5）對庫記錄指針，方向鍵無效時沒有變灰 6）界面不一致，或界面不正確 E 輕微的 1）日期或 時間初始值錯誤（起止日期、時間沒有限定） 2）按鈕或標(biāo)簽上有拼寫錯誤的單詞、不正確的大小寫 除了按嚴(yán)重性來分類， BUG 還可以按技術(shù)種類分為以下幾類： 表 2 按技術(shù)種類劃分 BUG 類 別 描 述 功能性錯誤 列在說明中的需求沒有在最終系統(tǒng)中達(dá)到 系統(tǒng)錯誤 存在或產(chǎn)生于所開發(fā)的系統(tǒng)之外的軟硬件錯誤 邏輯錯誤 程序運(yùn)行起來不像要求的樣子 用戶界面錯誤 字段和控件標(biāo)號不一致，功能提供的不一致等 數(shù)據(jù)錯誤 訪問數(shù)據(jù)庫時出錯 編碼錯誤 源代碼中存在的語法錯誤 測試錯誤 測試者誤操作卻認(rèn)為發(fā)現(xiàn)了 問題 在執(zhí)行本規(guī)定時， BUG 的評級原則按表 1 中的描述進(jìn)行。 國標(biāo)中有關(guān) BUG 數(shù)量的描述 向用戶提交軟件進(jìn)行驗(yàn)收時，對于軟件中存在的 BUG 數(shù)量有如下的規(guī)定： 1． 程序中不存在未改的 A、 B 級 BUG； C 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 1 個； D、 E 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 2 個；對于隨機(jī)出現(xiàn)的 BUG 的數(shù)量也必須考慮。 2． 在交付給用戶的文檔資料中，允許存在的 BUG 數(shù)量按以下方法計算：用程序的千行源代碼（ KLOC）數(shù)量除以25，所得數(shù)加上 3即為文檔中允許存在的最大 BUG 數(shù)量。例如 ，如果程序的千行源代碼（ KLOC）的數(shù)量是 1000，即該程序有 1 000 000 行源程序，則與該程序相關(guān)的文字資料中允許的最大 BUG 數(shù)就是（ 1000/25+3=） 43 個。 測試階段的劃分 本節(jié)的詳細(xì)描述可在公司文檔《軟件測試文檔編制規(guī)范》中找到。實(shí)際的測試過程可能不會嚴(yán)格區(qū)分各個階段，寫在這里僅供參考。 1. 單元測試 (Unit testing) 將開發(fā)成功的各個子模塊單獨(dú)測試。 2. 集成測試 (Integrate testing) 相互關(guān)聯(lián)的一個子系統(tǒng)重的所有子模塊已開發(fā)完成，全部聯(lián)編后進(jìn)行 測 試。 3. 確認(rèn)測試 (Verification testing) 確認(rèn)測試又稱有效性測試。它的任務(wù)是驗(yàn)證軟件的有效性，即驗(yàn)證軟件 的功能和性能及其它特性是否與用戶的要求一致。 4. 系統(tǒng)測試 (System testing) 安裝測試、恢復(fù)測試、安全測試、運(yùn)行測試、操作手冊測試等任何用戶需要打交道的東西。 修 改 紀(jì) 錄 表 編 號 GL/ZL— N002 版 本 擬 制 日 期 20xx/8/4 審 批 日 期 修改人 修改日 期 修改章節(jié) 簡要描述 20xx/11/21 版本 第 ， ， ，和 節(jié) 減輕測試人員文檔工作量，重新命名共享目錄，簡化 BUG 和送測單的填寫，細(xì)化 BUG 評級分類規(guī)定 20xx/3/14 版本 第 5， 6， 7 章 調(diào)整測試流程 20xx/07/13 版本 全文 結(jié)合輔助測試系統(tǒng) 對測試流程進(jìn)行修改