【正文】 單元 /模塊的第一次提交測試到本編碼階段結束中間經過的所有的有關的測試行為和過程。 2． 適用范圍 本流程文件適用于公司開發(fā)軟件并需要測試服務的任何軟件開發(fā)項目組、軟件開發(fā)人員，以及任何測試人員。 開發(fā)文檔 開發(fā)人員提供給測試人員的開發(fā)文檔至少包括以下幾種：用戶需求，概要設計，詳細設計，用戶手冊等。如果是采用 B/S 結構的軟件，只需要在開發(fā)部的服務 器上建立一個可執(zhí)行包就可以了；在必要的情況下，也可同時在質量部服務器上建立可執(zhí)行包。 除了領導和超級用戶身份以外，對于其它身份登陸的用戶，系統(tǒng)具有自動提醒功能，既登陸后系統(tǒng)可以自動提醒用戶現在需要處理的一些工作。 ? 功能測試以公司下發(fā)的《質量部測試管理辦法》為測試依據。輔助測試系統(tǒng)中可供選擇的項有單元測試、集成測試、系統(tǒng)測試、安裝測試和發(fā)行測試等。但送測模塊的版本號由程序員自己填寫，而且必須填寫。 2）對每一個 BUG 的評級工作由測試員完成并由驗證人加以確認。 7． 對于確定已經修改成功的 BUG，測試員要將 BUG 的狀態(tài)置為“ CLOSE”；如果一張 BUG 單上的所有紀錄都已經 CLOSE，則測試人員可以將本 BUG 單的狀態(tài)置為 CLOSE，這樣此張BUG 單將退出測試流程，輔助測試系統(tǒng)提供選項可使 BUG 單再重新進入測試流程；此時測試員應當保存模塊的修訂版本， 并口頭通知開發(fā)人員。 開發(fā)階段與測試階段 測試階段對應于開發(fā)過程中的編碼階段，每一個相對獨立的編碼階段都可以形成一個測試階段，比如單元測試、集成測試等。 2. 集成測試 (Integrate testing) 相互關聯的一個子系統(tǒng)重的所有子模塊已開發(fā)完成，全部聯編后進行 測 試。 國標中有關 BUG 數量的描述 向用戶提交軟件進行驗收時，對于軟件中存在的 BUG 數量有如下的規(guī)定： 1． 程序中不存在未改的 A、 B 級 BUG； C 級 BUG 的數量每千行源代碼（ KLOC）中不超過 1 個； D、 E 級 BUG 的數量每千行源代碼（ KLOC）中不超過 2 個；對于隨機出現的 BUG 的數量也必須考慮。 ? 如果本 BUG 單已經 CLOSE，則由測試人員口頭通知程序員，否則重復以上的步驟。 4． 備注字段在開發(fā)人員向測試人員解釋自己的回答時由開發(fā)人員填寫，也可在測試人員向開發(fā)人員詳細解釋 BUG 描寫的時候填寫。 BUG 單的形式如下： Bug 單 項目名稱 被 測 模 塊 項目經理 送測版本 送測人 測試員 驗證人 收測日期 最后修改日期 修訂版本 BUG 描述 BUG類別 BUG 級別 BUG 處理 備注 1. BUG 單的填寫 在輔助測試系統(tǒng)中，一旦測試員接收了送測單，對應的 BUG 單會自動產生，因此在上面的 BUG 單中基本上測試員只需要填寫 BUG描述、 BUG 類別和 BUG 級別字段，而送測的程序員只需要填寫修訂版本和 BUG 處理就行了。 7． 測試重點是指開發(fā)人員或客戶在使用本模塊時，對本模塊在穩(wěn)定性，可靠性，易用性等任何本模塊應該滿足的一些要求，比如對于“酒樓收銀”模塊，數據計算的正確性是應該首先達到的最基本的要求。 送 測單的形式如下所示： 送 測 單 項目名稱 送測模塊 送測階段 項目經理 送測人 送測日期 版本號 工程文件路徑和名字 可執(zhí)行文件路徑和名字 軟 件 配 置 測試要求（重點）： 收測人 收測日期 送測單的填寫 其填寫規(guī)則約定如下： 1． 項目名稱、送測內容 、 送測人和送測日期等四個字段由送測人填寫。 ? 項目經理檢查送測單上的內容后，執(zhí)行確認工作，并將打包好的可執(zhí)行代碼發(fā)布到開發(fā)部服務器的 SourceSafe 中（如果是B/S 結構的軟件，要把可執(zhí)行代碼發(fā)布到 IIS 上），將相關的數據庫發(fā)布到質量部服務器上。 3． 子目錄“最終軟件”存放已經通過內部評審的軟件，如果軟件是分為幾個階段開發(fā)的，并且每個階段的產品都要發(fā)行給用戶，則測試員必須備份每個階段最終發(fā)行給用戶的產品。開發(fā)人員確認并修改 BUG 后，必須填入修改意見并將BUG 單返回給測試人員以驗證是否修改成功。 由于公司已經為質量管理部開發(fā)完成“輔助測試系統(tǒng) ”，因此本測試流程的制定就建立在輔助測試系統(tǒng)之上，如果輔助測試系統(tǒng)有了新的版本，質量部將根據其變化適當調整測試流程。開發(fā)人員應當在開發(fā)每階段完成后三天內就向測試人員傳送本階段 完成的開發(fā)文檔，以利于測試人員的工作。 在此系統(tǒng)的基礎之上，又采取用 Microsoft 來對開發(fā)文檔和軟件進行管理，從而減少了文檔傳遞失誤的機會，提高了測試自動化的程度，也降低了測試人員的工作量。所以，要求處于測試中的程序的相關人員，如項目經理、程序員、測試主管和測試員等，每天都必須在不同時段登陸本系統(tǒng)至少三次以上。測試人員應當嚴格按照管理辦法上的相關規(guī)定開展工作，并認真完成 BUG 紀錄的填寫。這里的階段由項目經理和測試員共同確定后，通知每一個程序員。 ? 項目經理確認所填信息都正確無誤，并且把可執(zhí)行文件在開發(fā)服務器上發(fā)布，數據庫文件同時發(fā)布到開發(fā)服務器和測試服務器上，對模塊進行簡單的試用之后，簽字送測。 BUG 按其嚴重性級別來評級，共分 A、 B、 C、 D、 E 五級（參見本文第 節(jié)表 1中的描述），在系統(tǒng)提供的列表框中選擇。 工作流程 ? 測試員在輔助測試系統(tǒng)的 BUG 單填寫模塊中，驗證程 序的版本號是否和 BUG 單上的送測版本號相同（如果不是第一次送測，這里應當對比修訂版本號）。編碼階段的劃分由開發(fā)組和項目經理負責，各階段的完成標志應當明確的告知測試組，以利于測試組在測試計劃中分階段的安排測試工作、設計測試用例和調配測試資源。 3. 確認測試 (Verification testing) 確認測試又稱有效性測試。如在系統(tǒng)實現的界面上，一些