【正文】 。當(dāng)不同的文檔使用人員對其內(nèi)容產(chǎn)生歧義時，都以這里保存的文檔作為仲裁依據(jù)。 輔助測試系統(tǒng) 輔助測試系統(tǒng) 是一個 B/S 系統(tǒng)，通過 IExplorer 訪問，建立在質(zhì)量部服務(wù)器上，由質(zhì)量部維護(hù)，使用人員通過在 IE 地址欄中輸入 賬號，否則無法使用。 除了領(lǐng)導(dǎo)和超級用戶身份以外，對于其它身份登陸的用戶，系統(tǒng)具有自動提醒功能，既登陸后系統(tǒng)可以自動提醒用戶現(xiàn)在需要處理的一些工作。 的服務(wù)器建立在開發(fā)部門的服務(wù)器上，由開發(fā)部門維護(hù)，測試人員對其數(shù)據(jù)庫的訪問由項目經(jīng)理控制。不同的測試人員只能對他 /她自己負(fù)責(zé)測試的部分具有讀的權(quán)利，對于其它項目的軟件產(chǎn)品和文檔，不具有訪問的權(quán)利。測試包括兩方面的內(nèi)容：一是代碼走查工作，其次是功能測試工作。 ? 功能測試以公司下發(fā)的《質(zhì)量部測試管理辦法》為測試依據(jù)。驗證完以后，測試主管將 BUG 單返回給程序員。在輔助測試系統(tǒng)中，已經(jīng)將送測單的填寫集成進(jìn)去了，這里給出送測單的主要元素及其填寫方法。在輔助測試系統(tǒng)中，項目名稱和模塊名稱由項目經(jīng)理加入，程序員在填寫送測單時只需要選擇就可以了；而送測人和送測日期兩個字段系統(tǒng)可以 根據(jù)用戶登陸信息自動添加。輔助測試系統(tǒng)中可供選擇的項有單元測試、集成測試、系統(tǒng)測試、安裝測試和發(fā)行測試等。工程文件路徑和名字是指送測的模塊在 SourceSafe 中的路徑和具體的模塊名字。 6． 軟件配置字段的填寫內(nèi)容有兩個，一是本模塊的相關(guān)設(shè)計文檔 的位置、源代碼的位置等；二是運(yùn)行本模塊需要的一些軟件設(shè)置，如環(huán)境參數(shù)設(shè)置、動態(tài)聯(lián)接庫版本等。 8． 收測人和收測日期字段由被指定測試本模塊的測試員填寫 。但送測模塊的版本號由程序員自己填寫，而且必須填寫。 ? 測試員確認(rèn)需要的文檔資料和程序，簽收后根據(jù)測試重點開始測試，并填寫 BUG 單。 BUG 單模塊也已經(jīng)集成到輔助測試系統(tǒng)當(dāng)中了，這里給出 BUG 單的主要元素及其填寫方法。 1）對發(fā)現(xiàn)的BUG 按測試發(fā)現(xiàn)的順序排序。 2）對每一個 BUG 的評級工作由測試員完成并由驗證人加以確認(rèn)。 3． BUG 處理一欄由開發(fā)人員填寫。一個 BUG 是否暫不修改必須由項目經(jīng)理審查并確認(rèn)。但必須更新 BUG 單上的“修訂版本”字段。 7． 對于確定已經(jīng)修改成功的 BUG，測試員要將 BUG 的狀態(tài)置為“ CLOSE”；如果一張 BUG 單上的所有紀(jì)錄都已經(jīng) CLOSE，則測試人員可以將本 BUG 單的狀態(tài)置為 CLOSE，這樣此張BUG 單將退出測試流程，輔助測試系統(tǒng)提供選項可使 BUG 單再重新進(jìn)入測試流程；此時測試員應(yīng)當(dāng)保存模塊的修訂版本， 并口頭通知開發(fā)人員。否則繼續(xù)下一步。 ? 程序員確認(rèn) BUG，并將處理意見填入 BUG紀(jì)錄的備 注字段中。 本階段的測試工作結(jié)束后，測試主管（或其指定人員）應(yīng)該提交一份本階段的測試報告。 開發(fā)階段與測試階段 測試階段對應(yīng)于開發(fā)過程中的編碼階段，每一個相對獨(dú)立的編碼階段都可以形成一個測試階段，比如單元測試、集成測試等。 測試組在測試時，重點測試本次送測新添加的模塊。 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)中實現(xiàn) 4）業(yè)務(wù)流程不正確 C 中等的 不正確的，但不會影響系統(tǒng)穩(wěn)定性的 1） 過程調(diào)用或其它腳本錯誤； 2） 打印錯誤或打印出來的結(jié)果與用戶的要求不一致 3） 系統(tǒng)刷新錯誤； 4） 產(chǎn)生錯誤結(jié)果，如計算結(jié)果錯誤等 5） 功能的實 現(xiàn)有問題。例如 ，如果程序的千行源代碼（ KLOC）的數(shù)量是 1000，即該程序有 1 000 000 行源程序，則與該程序相關(guān)的文字資料中允許的最大 BUG 數(shù)就是（ 1000/25+3=） 43 個。 2. 集成測試 (Integrate testing) 相互關(guān)聯(lián)的一個子系統(tǒng)重的所有子模塊已開發(fā)完成，全部聯(lián)編后進(jì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)行修改 。它的任務(wù)是驗證軟件的有效性，即驗證軟件 的功能和性能及其它特性是否與用戶的要求一致。實際的測試過程可能不會嚴(yán)格區(qū)分各個階段，寫在這里僅供參考。 國標(biāo)中有關(guān) BUG 數(shù)量的描述 向用戶提交軟件進(jìn)行驗收時，對于軟件中存在的 BUG 數(shù)量有如下的規(guī)定： 1． 程序中不存在未改的 A、 B 級 BUG； C 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 1 個； D、 E 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 2 個；對于隨機(jī)出現(xiàn)的 BUG 的數(shù)量也必須考慮。 BUG 的分類評級原則 BUG 的大小、嚴(yán)重性在不同的系統(tǒng)中相差很多，最嚴(yán)重的 BUG 會讓開發(fā)者立刻放下手中的其他事來改正它們。 待測模塊的組合與測試原則 開發(fā)組應(yīng)當(dāng)首先完成軟件的核心模塊，和軟件的主界面設(shè)計。