項目結束后，需要對項目中使用的資源進行整理，并將不使用的資源進行釋放。
硬件資源：PC機、服務器、磁盤空間、交換機等
網絡資源：IP地址
3.3 測試數據的獲取和處理
功能測試的數據獲取主要有三個方式
1) “造”數據：針對正常業務，異常情況，邊界情況等構建測試數據，不僅僅包括最基本的基礎數據，比如：用戶、權限、配置、基礎編碼、原數據等，還包括系統的業務數據;
2) “導”數據：把已經在生產環境中運行的數據或老版本中的數據導出，在此基礎上進行數據的整理后加工為測試數據;
3) “積累”數據：使用現實的業務流程將現有的非電子化業務數據手工錄入系統，在驗證業務的同時也完成了測試數據的積累，即邊測試邊積累數據。但是這種情況積累的數據往往有一定局限性，因為已經發生的業務數據基本是正確的、一致的，而且可能缺少某些特定業務的數據(不常發生的分支業務)。這樣就需要根據對測試需求的分析，追加新的測試數據，以便能完整覆蓋業務類型。
性能測試使用的數據和功能測試有一定的區別，準備測試數據的側重點不同，性能測試使用的數據不用考慮如何去校驗功能。性能測試數據要注意以下幾點：
1) 測試數據的唯一問題
性能測試往往使用自動化測試工具進行測試，會使用相同的腳步反復的運行來進行測試，所以在測試過程中一定要注意腳本中參數的重復問題，設計測試數據時要考慮并發用戶數以及每個用戶可能迭代的次數，避免因測試數據數量不夠而使用重復數據，最終導致測試失敗。
2) 測試數據的清理問題
性能測試往往會向系統中增加大量的數據，增加的數據量足以達到影響系統性能的程度(例如：數據庫表中有100條數據和表中有100W條數據的響應時間一定是不同的)，所以必須及時的對增加的測試數據進行清理，以保證測試環境的公平性，進而保證測試結果的真實性。
3) 測試數據數量和容量(大小)問題
性能測試往往要使用“大”數據量來進行測試，“大”數據量不僅僅指數量的多少，還要考慮到數據容量的大小。例如：發布文章的測試，不僅要滿足發布文章數量的要求，還要考慮到文章內容的大小，也就是說不僅要考慮發布10W個1K大小的文章的性能還要考慮發布10W個10M大小的文章的性能。
4) 測試數據隨意性問題
測試數據忌隨意性，隨意輸入指定長度的字符串，雖然滿足測試執行的要求，但是對后續工作會產生很多不良影響，例如：無法保證數據的唯一性，隨意的輸入數據有幾率產生重復數據;收集的測試結果開發人員不易分析，性能測試中的開發人員可能需要分析內存的Dump文件，隨意輸入的、沒有規則的字符串不利于開發人員對dump文件的分析。
四. 如何開展性能測試
測試前期的準備工作紛繁復雜，做好測試準備工作，已是完成了測試工作的一大半，但要產生一份具有說服力的測試報告，還應正確把握測試的強度，保持測試的一致性，提高測試的精度。
判斷軟件的好壞，要看軟件解決實際應用的能力，只有在一定的測試強度下，才能測試出各種軟件資源的消耗率，軟件運行的速度，軟件的穩定性。通過對比在不同的測試強度下，不同軟件每一個功能模塊解決實際問題的能力和軟件運行的效率，我們才可能判斷出不同軟件的每一個模塊的強弱，甚至于整個軟件的優劣。
性能測試開始后，所有參數的輸入都應遵循統一的標準，無論是哪一個環節，哪怕是一點點偏差，都應立即糾正，絕不能心存僥幸。要特別注意外部環境對測試結果的影響，如果在整個測試過程中，外部環境不一致，如網速、機器內存使用率不一樣，就有可能導致測試結果與實際情況有出入。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
