2 、 BUG 的跟蹤
A) 對自己發現的 BUG 已解決和未解決的問題進行跟蹤。
B) 對新版本中仍未解決的問題應另外作 BUG 記錄，并可注明“遺留問題”。
3 、測試任務分工
明確每人的測試重點，文件的保存位置，提交 BUG 的方式，所有的 BUG 由測試組長匯總后提交給項目組。
2.4.4. 測試組工作流
1. 項目組 PM 提交測試程序;
要求：包含所有工程文件和執行文件(第一次要求是項目組經過預測試的可運行程序)
2. 測試人員驗收;
3. 測試人員將所有文件打進一個包;
4. 提交給項目配置庫;
5. 測試執行
說明：測試人員按《測試任務分工》、《業務依賴關系》及相關的《需求文檔》 執行測試
6. 填寫《測試記錄》與《 BUG 列表》
要求：《測試記錄》在測試過程中按照要求即時、詳盡的填寫;《 BUG 列表》每天測試完成后按要求填寫
7. 將《測試記錄》與《測試 BUG 列表》提交測試組長(不長于 2 天提交一次);
說明：測試人員不長于 2 天完成一輪測試
8. 測試組長統計測試情況并及時將 BUG 列表提交項目組 PM
9. 項目組及時更改程序并跟蹤記錄 BUG 的解決情況;
要求：項目組不長于 2 天的時間，提交一次軟件新版本(以日期定義版本)給測試小組進行測試。新版本軟件提交到配置庫并及時通知測試組
2.5. 常規問題
2.5.1. 程序人員自測不嚴
程序人員在有測試人員的情況下，對于編碼后的程序常不行全面的測試后就會拋給測試小組進行測試，使測試小組承擔過多的責任，解決方式：程序人員進行單元測試，提供單元測試記錄，加強程序嚴謹性;在一定(一天或兩天)時間程序進行代碼暫時封凍，程序員進行互測，使其了解自己編的程序到底如何或給項目領導進行演示，破壞其自我優越感。
2.5.2. 數據約束的合理性是桌前檢查第一步
數據是否是約定條件范圍內;對于越界處理是否正常;默認、空白、 null 值、零值的處理是否正常。
3. 軟件的測試標準
對于軟件的測試從以下幾個方面考慮：
1. 用戶需求的完整性：
是否根據用戶所要求的業務流程，進行了相應的具體系統的實現。
2. 文檔的完整性：
是否已經完成合同及約定所明確的所有的文檔。
3. 通過測試(含準確性測試)
測試的第一步，測試系統能做什么工作。
4. 條件覆蓋測試
測試的第二步，測試系統多方面考慮進行的如何。通過一定的測試數據明確是否進行了足夠的條件覆蓋，使系統達到足夠的質量。
5. 數據約束的合理性：
數據是否是約定條件范圍內;對于越界處理是否正常;默認、空白、 null 值、零值的處理是否正常。
6. 狀態控制
進行系統和功能在不同狀態下的處理，如數據庫關機，客戶機開機是否可以正常。
7. 軟件常規性能及其它：
軟件所需的操作環境及易使用性，可移植性、兼容性、錯誤恢復能力和可維護性等等是否為用戶認可。
對于測試的結果有兩種可能，一種可能是各種方面(主要是功能和性能指標)滿足軟件需求說明的要求，用戶接受系統;另一種可能是軟件不滿足軟件需求說明的要求，用戶無法接受。對于這個階段才發現的嚴重錯誤(一般指重要的業務邏輯)一般很難在預定的時間改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。
關于作者：
王輝，具有八年的編程及系統管理經驗，所使用的語言為 C 和 Java 編程語言。目前在深圳一家公司做項目經理，使用 C 和 ORACLE 數據庫開發應用系統�？赏ㄟ^ ddxxkk@21cn.com 聯系。
4. 附錄
4.1. 測試計劃大綱
摘自 計算機軟件產品開發文件編制指南 GB 8567-88
這里所說的測試，主要是指整個程序系統的組裝測試和確認測試。本文件的編制是為了提供一個對該軟件的測試計劃，包括對每項測試活動的內容、進度安排、設計考慮、測試數據的整理方法及評價準則。具體的內容要求如下：
17 . 1 引言
17 . 1 . 1 編寫目的
17 . 1 . 2 背景
17 . 1 . 3 定義
17 . 1 . 4 參考資料
17 . 2 計劃
17 . 2 . 1 軟件說明
17 . 2 . 2 測試內容
17 . 2 . 3 測試 1 (標識符)
17 . 2 . 3 . 1 進度安排
17 . 2 . 3 . 2 條件
17 . 2 . 3 . 3 測試資料
17 . 2 . 3 . 4 測試培訓
17 . 2 . 4 測試 2 (標識符)
......
17 . 3 測試設計說明
17 . 3 . 1 測試 l (標識符)
17 . 3 . 1 . 1 控制
17 . 3 . 1 . 2 輸入
17 . 3 . 1 . 3 輸出
17 . 3 . 1 . 4 過程
17 . 3 . 2 測試 2 (標識符)
.......
17 . 4 評價準則
17 . 4 . 1 范圍
17 . 4 . 2 數據整理
17 . 4 . 3 尺度
4.2. BUG 列表必要內容
包括錯誤程序名稱及版本，錯誤主題，錯誤嚴重級別，測試過程描述，測試人，測試時間，修改結果，修改人，修改時間。
對于錯誤嚴重級別的分類說明如下：
· 嚴重錯誤：導致系統無法實現功能目標，使測試無法繼續進行。主要包括：程序不能起動、程序非正常終止、程序死機、關鍵需求未實現、嚴重的數值計算錯誤、安全性錯誤、文檔與軟件嚴重不符。
· 中等錯誤：導致系統無法正常實現功能目標，但知道如何通過其它途徑來避免錯誤發生。主要包括：程序非正常終止但可避免、系統邊界值錯誤、非關鍵需求理解錯誤、系統文檔錯誤。
· 輕微錯誤：導致用戶 / 操作員使用不方便，但不影響系統功能目標的實現。主要包括：查詢報告格式錯誤、用戶界面不很友好、顯示格式錯誤、輕微的數值計算錯誤、系統處理未優化、系統文檔存在輕微錯誤等。
· 建議：使系統更加完善的建設性意見等。
4.3. 常用名詞定義
白盒測試 ：如果已知產品的內部活動方式，可以測試它的內部活動是否都符合設計要求，這種方法叫白盒測試，檢查軟件的內部邏輯結構，是以仔細檢查過程的細節為基礎，通過提供一組指定條件和循環的測試用例，對穿過軟件的邏輯路徑進行測試，可以在不同點檢查程序的狀態，以確定實際狀態與預期狀態是否一致。
黑盒測試 ：著眼于軟件的外部特性，而不考慮軟件的內部邏輯結構。指在軟件的接口上進行測試，即看它能否滿足功能要求，輸入能否被正確地接收，并正確的輸出結果，以及能否保持外部信息(如數據文件)的完整性等等。
單元測試(模塊測試) ：相當于分調，即逐個模塊考察，是以詳細設計描述為指南，對重要的控制路徑進行測試，用以發現錯誤。使用白盒子測試法。
集成測試(組裝測試或聯合測試) ：相當于聯調，主要是考察模塊間的接口和各模塊間的聯系
確認測試(有效性測試) ：是驗證軟件的功能和性能及其它特點是否與用戶的要求一致。功能與用戶的需求是否一致。使用黑盒測試。
系統測試(系統聯調) ：是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行(使用)環境下，對計算機系統進行一系列的組裝測試和確認測試。
驗收測試： 由用戶實施，通過所謂黑盒子測試，來證實軟件功能與描述的需求是否一致
回歸測試 ：重復以前進行過的部分或全部測試
恢復測試： 是一種系統測試，它以不同的方式強使軟件出現故障，用來嚴整軟件能否恰當地完成恢復
安全性測試： 就是試圖去驗證建立在系統內的預防機制，以防止來自非正常的侵入。
強度測試： 實在要求一個非常數量、頻率或容量資源方式下運行一個系統。它實際上是一種叫做敏感性測試技術
性能測試 ：就是測試軟件在給組裝進系統的環境下運行時的性能。性能測試應覆蓋測試過程的每一步
測試用例： 一組最有可能發現某個錯誤或某類錯誤的測試數據
4.4. 關于α、β測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有最終用戶才能發現的問題。
α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品(稱為α版本)進行測試，試圖發現錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件產品稱為β版本。緊隨其后的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發公司再對β版本進行改錯和完善。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
