【正文】 模 塊 項目經(jīng)理 送測版本 送測人 測試員 驗證人 收測日期 最后修改日期 修訂版本 BUG 描述 BUG類別 BUG 級別 BUG 處理 備注 1. BUG 單的填寫 在輔助測試系統(tǒng)中，一旦測試員接收了送測單，對應的 BUG 單會自動產(chǎn)生，因此在上面的 BUG 單中基本上測試員只需要填寫 BUG描述、 BUG 類別和 BUG 級別字段，而送測的程序員只需要填寫修訂版本和 BUG 處理就行了。對于問題和建議，它 們的級別應當選擇為“未定義”。 4． 備注字段在開發(fā)人員向測試人員解釋自己的回答時由開發(fā)人員填寫，也可在測試人員向開發(fā)人員詳細解釋 BUG 描寫的時候填寫。不相同就把 BUG 單打回給程序員。 ? 如果本 BUG 單已經(jīng) CLOSE，則由測試人員口頭通知程序員，否則重復以上的步驟。 待測模塊的組合與測試原則 開發(fā)組應當首先完成軟件的核心模塊，和軟件的主界面設計。 國標中有關 BUG 數(shù)量的描述 向用戶提交軟件進行驗收時，對于軟件中存在的 BUG 數(shù)量有如下的規(guī)定： 1． 程序中不存在未改的 A、 B 級 BUG； C 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 1 個； D、 E 級 BUG 的數(shù)量每千行源代碼（ KLOC）中不超過 2 個；對于隨機出現(xiàn)的 BUG 的數(shù)量也必須考慮。它的任務是驗證軟件的有效性，即驗證軟件 的功能和性能及其它特性是否與用戶的要求一致。 2. 集成測試 (Integrate testing) 相互關聯(lián)的一個子系統(tǒng)重的所有子模塊已開發(fā)完成，全部聯(lián)編后進行 測 試。 BUG 按其嚴重性可以分為以下幾類： 表 1 按嚴重性劃分 BUG 嚴重等級 描 述 A 極嚴重 1）可能有災難性的后果或是會出人命的 2) 故意留有程序后門 B 嚴重 產(chǎn)生錯誤的結果，導致系統(tǒng)不穩(wěn)定的問題 1）造成數(shù)據(jù)庫不穩(wěn)定的錯誤； 2）系統(tǒng) 崩潰 ，無法繼續(xù)操作 3）列在說明中的需求未在最終系統(tǒng)中實現(xiàn) 4）業(yè)務流程不正確 C 中等的 不正確的，但不會影響系統(tǒng)穩(wěn)定性的 1） 過程調(diào)用或其它腳本錯誤； 2） 打印錯誤或打印出來的結果與用戶的要求不一致 3） 系統(tǒng)刷新錯誤； 4） 產(chǎn)生錯誤結果，如計算結果錯誤等 5） 功能的實 現(xiàn)有問題。 開發(fā)階段與測試階段 測試階段對應于開發(fā)過程中的編碼階段，每一個相對獨立的編碼階段都可以形成一個測試階段，比如單元測試、集成測試等。 ? 程序員確認 BUG，并將處理意見填入 BUG紀錄的備 注字段中。 7． 對于確定已經(jīng)修改成功的 BUG，測試員要將 BUG 的狀態(tài)置為“ CLOSE”；如果一張 BUG 單上的所有紀錄都已經(jīng) CLOSE，則測試人員可以將本 BUG 單的狀態(tài)置為 CLOSE，這樣此張BUG 單將退出測試流程，輔助測試系統(tǒng)提供選項可使 BUG 單再重新進入測試流程；此時測試員應當保存模塊的修訂版本， 并口頭通知開發(fā)人員。一個 BUG 是否暫不修改必須由項目經(jīng)理審查并確認。 2）對每一個 BUG 的評級工作由測試員完成并由驗證人加以確認。 BUG 單模塊也已經(jīng)集成到輔助測試系統(tǒng)當中了，這里給出 BUG 單的主要元素及其填寫方法。但送測模塊的版本號由程序員自己填寫，而且必須填寫。 6． 軟件配置字段的填寫內(nèi)容有兩個，一是本模塊的相關設計文檔 的位置、源代碼的位置等；二是運行本模塊需要的一些軟件設置，如環(huán)境參數(shù)設置、動態(tài)聯(lián)接庫版本等。輔助測試系統(tǒng)中可供選擇的項有單元測試、集成測試、系統(tǒng)測試、安裝測試和發(fā)行測試等。在輔助測試系統(tǒng)中，已經(jīng)將送測單的填寫集成進去了，這里給出送測單的主要元素及其填寫方法。 ? 功能測試以公司下發(fā)的《質(zhì)量部測試管理辦法》為測試依據(jù)。不同的測試人員只能對他 /她自己負責測試的部分具有讀的權利，對于其它項目的軟件產(chǎn)品和文檔，不具有訪問的權利。 除了領導和超級用戶身份以外，對于其它身份登陸的用戶，系統(tǒng)具有自動提醒功能，既登陸后系統(tǒng)可以自動提醒用戶現(xiàn)在需要處理的一些工作。當不同的文檔使用人員對其內(nèi)容產(chǎn)生歧義時，都以這里保存的文檔作為仲裁依據(jù)。如果是采用 B/S 結構的軟件，只需要在開發(fā)部的服務 器上建立一個可執(zhí)行包就可以了；在必要的情況下，也可同時在質(zhì)量部服務器上建立可執(zhí)行包。送測單必須有送測重點，以利于測試人員工作。 開發(fā)文檔 開發(fā)人員提供給測試人員的開發(fā)文檔至少包括以下幾種：用戶需求，概要設計，詳細設計，用戶手冊等。 鑒于公司的技術要求，目前質(zhì)量部的測試人員不僅要完成黑盒測試工作，而且還要進行白盒測試中的“代碼走查”工作。 2． 適用范圍 本流程文件適用于公司開發(fā)軟件并需要測試服務的任何軟件開發(fā)項目組、軟件開發(fā)人員，以及任何測試人員。測試文檔由測試人員編寫并維護，也屬于開發(fā)文檔的一部分。 測試循環(huán) 測試循環(huán)是指從軟件單元 /模塊的第一次提交測試到本編碼階段結束中間經(jīng)過的所有的有關的測試行為和過程。 共享目錄在項目開始階段由測試小組的負責人在質(zhì)量部專用的測試服務器上建立，并由測試負責人在整個項目期間進行維護。 輔助工具的使用 輔助工具目前有兩個：輔助測試系統(tǒng) 和 Microsoft 。開發(fā)人員使用 可以保證所有人員包括測試人員看到的是同一個版本的文檔，從而避免理解上的偏差。 ? 測試人員接受送測單后，從 SourceSafe 中獲得程序代碼，開始測試。 ? 測試人員測試完成后，測試主管必須對 BUG 單執(zhí)行“驗證”過程，即檢驗 BUG 單上描寫的 BUG 是否都是正確的。送測內(nèi)容指的是本次送測的程序模塊。 4． “工程文件路徑和名字”和“可執(zhí)行文件路徑和名字”兩個字段由程序員填寫，項目經(jīng)理必須檢查確認這兩個字段所填寫的信息是否都是準確無誤的。測試重點由送測人和項目經(jīng)理共同確定，并由送測人填寫。 ? 測試員在輔助測試系統(tǒng)的“送測單接收