科技項目相關測試驗收方案設計

實用文案項目測試驗收方案1.1驗收流程在驗收階段，平臺系統所有應用系統將按照用戶和我公司都認可的《系統需求分析》，組織驗收小組，進行功能和性能的驗收測試。從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性及系統文檔、代碼、規范及注釋說明等方面組織全面驗收。驗收測試安排分為系統初驗和系統終驗。1.2初驗經過系統內部試運行，我公司對內部試運行期間發現的問題改正后，提出系統初驗書面申請。驗收標準將按照“需求說明書”和雙方認可的有關系統設計文檔所提的要求進行。用戶在收到我公司驗收申請后，盡快組織系統初驗。初驗前我公司提供全部的工程文檔和安裝測試報告，并提供初驗測試文檔，在用戶認可后進行初驗測試，初驗通過后，系統進入正式試運行期。我公司應解決試運行期間所反映出的問題，若系統達不到合同規定要求，試運行期將繼續順延，直到系統完善，但試運行期最長不得超過三個月。1.3試運行初驗合格后，經用戶同意，系統進入試運行階段，試運行周期不超過三個月。在試運行期間，我公司按用戶要求提供標準實用文案培訓和技術支持，保證用戶能夠正確理解和使用系統；我公司對試運行中出現的任何問題及用戶提出的修改意見將及時做出響應，并提交解決方案，在用戶確認后實施。試運行期間如出現重大故障，則試運行期從故障排除之日起重新計算。1.4終驗標準正式試運行期結束后，如系統無功能缺陷，能夠正常運行，在具備終驗條件下進行系統終驗，由我公司提出終驗書面申請，用戶在收到我公司驗收申請后，盡快組織系統終驗。成立項目全面驗收小組，由用戶、我公司以及外部專家等組成，對項目進行全面驗收。系統終驗前，我公司提交終驗測試標準和終驗測試計劃，內容包括：測試對象及應達到的測試指標、測試方法和測試條件、測試資料和數據，并以圖表說明每一測試對象或過程的功能輸入輸出測試進度。1.5終驗內容系統實用性：項目驗收最關鍵的指標，檢查系統是否符合當前業務的需要，特別是業務流的整體性和數據流的一致性，并前瞻性提供未來業務接口。系統穩定性：硬件環境的穩定性、軟件運行異常處理和正常運行情況。標準實用文案系統可維護性：含網絡系統管理與維護、服務器系統平臺管理與維護、操作系統管理與維護、應用系統軟件管理與維護、數據庫管理與維護以及數據庫備份、應用系統備份，災難事件處理與解決實施方案等。系統文檔：驗收文檔是否齊全、規范、準確、詳細，主要的文檔包括：需求分析報告，框架設計報告，數據庫物理及邏輯設計報告，詳細設計報告，編碼規范及技術選型報告，測試報告，系統部署和發布報告，集成方案，軟件用戶使用手冊，系統維護方案和操作文檔等。代碼規范及注釋說明：程序代碼編寫是否規范；注釋說明或代碼文檔是否詳細全面；接口定義是否符合局信息系統規劃一致性的要求。系統靈活性：系統是否方便客戶進行維護；系統是否在先進性的基礎上具備未來升級和可擴充性；是否利于系統平臺遷移和部署等。系統可操作性：界面是否友好性；是否實現傻瓜化操作和智能化數據檢索功能。系統安全性：是否有完善的安全機制保證系統的安全性，如軟件方面的安全防范（加密措施、相關認證、數據庫安全防范），硬件方面（防火墻、物理隔離和邏輯隔離）的安全設置。標準實用文案其他驗收標準：其他的與本系統相關的驗收標準。1.6終驗過程我公司按照項目驗收計劃完成驗收準備工作用戶代表運行驗收測試用例集，記錄運行結果如果發現沒有通過的驗收測試用例，則我公司立即解決問題用戶主持項目驗收會我公司向用戶報告項目實施結果用戶代表向用戶報告試運行結果用戶評議項目實施和試運行結果，起草和審定項目驗收報告。經中國疾病預防控制中心精神衛生中心確認系統終驗通過后，雙方簽署終驗證書。1.7終驗技術文檔資料我公司在軟件開發和系統集成中將嚴格按照國家軟件工程有關要求提供的文檔來提供，驗收的技術文檔至少包含以下內容：序 名稱 內容 提交時間號1 系統需求分析 描述用戶需求及分析 需求分析結結果(含用例圖,類圖 束等)標準實用文案2系統概要設計描述系統模型及系統概要設計結體系架構等初步設計束內容3系統詳細設計描述系統各個子模塊詳細設計結說明術的接口和詳細設計流束程4應用程序設計描述系統各程序模塊詳細設計結說明書的接口和實現流程束5數據庫詳細設描述數據庫物理規劃，詳細設計結計說明書數據表字段，存儲過程束設計內容6應用系統集成描述系統上線實施的開發過程實施說明詳細過程和步驟中，部件開發結束7系統測試大綱描述系統測試的詳細組裝測試結測試用例和測試方法束8系統測試報告描述系統測試的詳細系統測試結測試結果和分析束系統驗收報告描述軟件綜合評價，匯系統驗收完總所有軟件開發相關畢文檔系統用戶使用描述系統詳細使用說應用集成結標準實用文案手冊 明 束11 系統安裝維護 描述系統日常管理和 系統測試結管理手冊 維護的詳細內容 束1.8終驗報告驗收小組將在終驗結束后提交一份由專家簽名的驗收報告。驗收報告附平臺系統和整體系統測試結果報告，同時給出以下明確結論之一：1）通過驗收；2）基本通過驗收，要求在七天內完善后再次進行驗收；3）未通過驗收，要求在十天內改正后再次進行驗收；如再次驗收后仍然不能全部通過，用戶有權終止合同，并要求我公司承擔違約責任。驗收結束時,我公司將平臺系統相關產品說明書、系統安裝手冊、技術文檔、資料及安裝、測試、驗收報告等文檔匯集成冊交付用戶。2.1測試方法2.1單元測試單元測試目的單元測試的對象是軟件設計中的最小單元模塊。單元測試人員根據單元測試計劃對已完成的系統單元進行測試，確保已完成的系統單元符合相應部分系統詳細設計說明書所規定的要求。如果單元測試發現系統單元與其相應的詳細設計標準實用文案說明書不符，則此系統單元必須修改以最終符合說明書的規定。單元測試采用的方法、技術與內容單元測試主要采用白盒測試技術，用控制流覆蓋和數據流覆蓋等測試方法設計測試用例；主要測試內容包括單元功能測試、單元性能測試和異常處理測試等。單元測試流程單元測試流程分為單元測試設計、單元測試準備、單元測試實施和記錄、單元測試錯誤跟蹤。單元測試設計即單元測試用例設計，由系統設計人員在詳細設計的同時完成。單元測試準備為按照測試用例的要求，準備單元測試驅動數據和驅動模塊，由開發人員在開發過程中完成。單元測試實施和記錄由開發人員在編碼完成以后進行。單元測試問題跟蹤由開發人員和系統設計人員共同完成，根據引起問題的不同原因進行不同處理。如果測試問題為編碼錯誤，則由開發人員完成糾錯后重新測試。如果測試問題為設計階段引起的問題，則需要進行設計變更。通過單元測試的程序，進入配置管理系統。單元測試用例標準實用文案編程組組長組織、指導開發人員根據《系統設計說明書》，編寫所負責代碼設計模塊的《單元測試用例》，設計單元測試腳本。2.2代碼評審編程組組長組織人員進行代碼檢查。若所寫的代碼不符合編碼規范，即便已實現了系統功能，仍然認為不合格的，需要重寫。代碼檢查的意義保證代碼編寫的規范保證代碼編寫的過程不產生 BUG代碼檢查的依據檢查代碼是否有更新檢查存在問題是否有更新檢查存在問題是否已解決問題已解決，則填寫《代碼檢查記錄》2.3集成測試集成測試目的集成測試是指根據《系統概要設計》及《系統集成與開發詳細設計》，對系統的各單元進行組裝。把分離的系統單元組裝為完整的可執行的計算機軟件。集成測試的目的是檢查軟件單元部件是否能夠集成為一個整體，完成一定的功能，并找出單元測試中沒有發現的錯誤，包括數據定義有沒有重標準實用文案合與沖突，接口會不會產生錯誤，組合以后的模塊功能會不會互相影響，組合的系統是不是達到預期的效果等。集成測試采用的方法、技術和內容集成測試采用白盒測試和黑盒測試相結合的測試技術和漸增式的測試策略，用數據流等測試方法設計測試用例。主要測試內容包括單元之間的接口測試、全局數據結構測試等。集成測試流程集成測試包括集成測試設計、集成測試準備、集成測試實施和測試記錄、集成測試問題跟蹤和結束測試等階段。集成測試設計由測試組組長根據項目計劃和開發計劃編制《集成測試計劃》，設計《測試用例》。測試計劃和測試用例應當通過項目經理的審查。集成測試準備需要系統測試組組長建立獨立的測試環境。測試環境包括測試硬件環境、網絡、數據庫、應用服務器等以及測試對象(程序)的安裝和初始化工作。集成測試實施和測試記錄是由系統測試組組長組織人員按照測試計劃和測試用例要求進行測試，并且記錄測試過程和測試結果。集成測試問題跟蹤是在測試過程中發現的問題由系統測試組組長根據測試記錄提交測試問題報告，并由系統設計人員和開發人員解決每一個問題的過程。標準實用文案測試結束指測試問題報告中的問題解決后，進行回歸測試。當測試問題降低到一定程度并通過測試通過準則時，系統測試組組長提交測試總結報告結束測試。2.4功能測試功能測試包括兩大部分，一是包括基本業務功能、業務測試、接口測試和可用性測試等方面的功能測試，二是包括：安全性測試、故障恢復測試、數據庫測試、配置測試、安裝測試的產品化測試。驗收測試主要從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性方面進行測試。1）測試目標當國家重性精神疾病管理報表直報系統開發結束時，就要面臨著推廣使用的問題。在整個的軟件開發過程中，由于各種原因應用系統會有不完善的問題，這些問題會體現在開發后發布的軟件產品中，并在產品中極大的影響著產品的使用，對于用戶，這些缺陷阻礙著完成他們的既定目標和工作。所以我們要組織并執行測試，以降低軟件產品中存在的缺陷，保證產品的質量和可用性，測試工作的目標就是降低BUG率，從各個方面提高軟件產品的質量和可用性， 為用戶提供優質的國家重性精神疾病管理報表直報系統。計劃進度表和測試計劃對業務系統測試進行了時間和內容上的定義與約束。（2）測試流程標準實用文案下圖是功能測試的流程，概要描述了測試過程中所涉及的角色，測試階段，以及各階段不同角色需要完成的任務。業務測試流程在準備測試用例這一活動中，我們所執行的具體任務如圖所示，在確定具體的測試范圍及內容后，進行測試分類，并根據分類的結果確定需要設計的測試用例。每個測試用例的描述如圖中下半部分的描述。準備測試用例標準實用文案測試用例是測試工作中重要的指導性文件。 國家重性精神疾病管理報表直報系統的測試用例主要是按照測試類型做劃分，測試用例的輸入為《國家重性精神疾病管理報表直報系統測試需求》，測試需求的輸入是《系統需求規格說明書》 。在整個測試過程中，我們將用缺陷管理工具 BugBase 對測試大綱、測試用例、測試問題等進行管理，并可對問題進行統計。3）關鍵步驟輸入項目開發計劃業務需求說明、《系統需求規格說明》測試數據關鍵步驟定義測試需求與策略開發測試腳本和用例準備測試環境執行測試輸出測試計劃測試用例、腳本測試結果關鍵成功因素標準實用文案確定系統需求的可靠方法認可了整體測試計劃測試腳本開發與執行有足夠資源與時間支持測試腳本開發與執行的工具，包括適當的配置環境開發以業務過程驅動為基礎的測試腳本測試環境的可靠、及時（轉換）的測試數據所有業務系統和系統集成測試的全面執行獨立的質量保證測試和對所有測試活動的合格終止4）測試完成標準實現功能完全符合功能列表。所有的功能頁面均可達。TD上的問題得到妥善處理，不含有 A,B,C類問題。定義的測試項目完成。產品化測試的約束達成。（5）缺陷管理追蹤工具在上節描述中提到的TD，可以應用于測試的全過程，也可以用于管理各類評審的缺陷等。TD還提供一些模板，例如測試計劃、測試總結、測試大綱、測試問題卡，因此可以通過 BugBase 實現從測試計劃到總結的各測試活動管理。我們以需求說明書、軟件需求規格說明為輸入編寫測試大綱，對應測試大綱中的內容和測試需求編寫測試用例，測試標準實用文案人員可以根據測試大綱和用例執行測試，發現問題后，記錄在TD中，測試負責人通過查看缺陷問題列表將問題分配給對應的開發人員，開發人員通過查看問題列表修改問題，TD還提供了各種統計功能，例如根據問題的發現日期、問題等級、問題的分布、問題引入階段等進行統計，這些統計結果可用來進行分析和總結測試過程中使用 TD管理工具的益處在于：提高了測試的生產率工具自動進行統計和分析能夠將問題卡輸出到Excel文件中，便于與相關人員進行交流和確認。2.5性能測試性能測試總體流程與業務系統測試的流程基本相同。驗收測試主要從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性方面進行測試。性能測試的內容源于用戶對國家重性精神疾病管理報表直報系統的性能要求，此外就是針對國家重性精神疾病管理報表直報系統業務多、范圍廣、層次多、用戶量大的特點，對關鍵業務、關鍵流程進行性能測試。1）測試目標性能測試的目標是在整個系統或一個系統的特定組件上定義、建立和執行性能測試。驗證系統是否滿足中國疾病預標準實用文案防控制中心精神衛生中心的性能要求，如不能滿足，要進行相應的優化。2）測試流程根據國家重性精神疾病管理報表直報系統的性能要求，我們首先對性能測試進行策劃，確定性能測試的類別和測試方法。然后開發性能測試的用例，確定測試環境并準備就緒后執行性能測試，確定測試中的系統或組件的性能，并使用其結果決定性能是否可以被業務所接受。如果在測試中度量的性能特性證明是不能被接受的，我們可以通過對業務的改進、數據庫、應用服務器等進行調優，以提高性能質量，在進行系統調優前，我們同樣要進行調優的設計與分析。性能測試與應用和技術架構緊密相關并且兩者互相影響。性能測試類別與方法舉例測試類別測試方法導入大量數據到系統中，檢查單用戶大數據量測試操作時系統的性能表現，對于較慢的操作進行分析、查找原因直到最后修改多用戶并發操作用loadrunner模擬并發用戶操作，通過loadrunner及servertrace等工測試具進行問題查找和跟蹤標準實用文案不同帶寬下的測 用loadrunner 模擬不同帶寬進行測試 試疲勞測試 用loadrunner 模擬進行測試3）關鍵步驟輸入性能需求關鍵步驟定義性能測試策略設計性能測試腳本準備測試環境和性能測試數據性能測試執行輸出性能測試腳本性能測試報告關鍵成功因素性能測試的清晰的范圍定義。性能測試限制的識別作為性能質量工具和現實的專有技術可形性的風險評估，以定義和解釋性能測試。關于當前和未來業務量的質量信息的有效性，使能夠定義測試模擬速度和容量。標準實用文案自動化測試工具的有效性和使用它們的技術， 或用戶提供人工測試事務處理的有效性。性能測試能夠建立和運行的控制環境的有效性。（4）性能測試指標1、響應時間響應速度在用戶心理所能承受的范圍內。無論是客戶端還是管理端，當用戶登陸，進行任何操作的時候，系統應該及時進行反映，系統應能檢測出各種非正常情況，并及時提示用戶。功能名稱性能要求并發數支持100次/秒并發頁面加載頁面加載時間<5秒目錄樹加載目錄樹加載時間<5秒；數據列表加載數據列表加載時間<5秒；錄入數據檢查提錄入數據檢查提醒時間<2秒醒數據查詢簡單查詢處理時間<5秒；復雜查詢處理時間<15秒；數據統計簡單統計處理時間<5秒；復雜統計處理時間<15秒；數據上載/下載1M及以下文件上載/下載時間<20秒；10M及以下文件上載/下載時間<5分標準實用文案鐘；數據匯總 簡單匯總處理時間 <30秒鐘；復雜匯總處理時間 <3分鐘；2、可擴展性在設計上必須具有適應變化的能力， 當系統新增業務功能或現有業務改變時，應保證業務在整體框架不變的基礎上，業務變化造成的影響局部化。3、易用性所有的業務功能界面風格和操作流程一致， 業務表單做到所見即所得，錄入能夠完全通過鍵盤完成。4、可靠性系統應保證 7*24小時內不宕機，保證在正常情況下和極端情況下業務邏輯的正確性。5、可用性必須避免由于單點故障或系統升級而影響整個系統的正常運行。6、可維護性系統能夠簡單方便的修改和升級， 包含可度性、可修改性、可測試性等。7、可管理性和服務支持能力標準實用文案每個層次、每個構件都提供標準的管理接口。實現統一的、一致的日志功能。每個構件都提供應用架構總體設計規定的必要的標準外部接口。我們通過Loadruner等性能測試工具可以得到資源使用狀況、響應時間等結果，見下圖：資源使用情況（示例）響應時間（示例）2.6用戶測試標準實用文案為保證系統適合業務管理的功能要求，除了我公司組織測試外，還積極配合中國疾病預防控制中心精神衛生中心組織最終用戶對系統進行測試。1）用戶測試流程用戶測試流程如下：明確測試內容，其中包括功能、性能、可用性、安全性、兼容性、與其他系統集成確定測試范圍：確定業務情況類型是是非常重要的。每一種業務情況類型都對應一個實際商業業務。業務情況類型可以被表達成多種狀況（例如，簡單情況、或需要進行復雜處理的例外情況）。測試小組成員確定：由管理人員、業務人員、技術人員等組成，我方提供驗收測試過程中的技術支持。明確問題分類標準系統的功能通過功能測試進行驗證。在功能測試過程中發現的問題根據其嚴重程度進行分類。下表列出了功能測試問題的分類。功能測試問題嚴重程度分類嚴重程問題說明度A類：非 足以造成系統崩潰，造成文件不可靠或潛在的數據標準實用文案常嚴重 丟失性錯誤 造成非正常地返回操作系統 （系統崩潰或顯示系統錯誤信息）。Bug造成程序越或要求 Reboot 系統。造成缺乏關鍵的程序功能并無法逾越。由于設計問題，使系統存在嚴重隱患。Bug可能不會削弱系統，但將造成嚴重問題（如：嚴重的格式化錯誤等）。功能缺乏給用戶帶來極大不方便。B類：嚴 存在不明確或不完整的錯誤信息提示， 極大地影響重性錯 產品使用。誤 由于Bug的存在使產品其它部分不能測試。由于計算方法問題，使數據錯誤。由于設計原因，造成前后不一致，但問題可恢復。容錯性方面存在不足。由于精度問題造成數據不一致。這個Bug在將來是嚴重的，但比主要問題（MajorC類：一Problem）要輕。般性錯 Bug可以繞過，但將會很不方便或很難實現。誤 可以有一個比較簡單的繞過 Bug的解決方案。操作界面錯誤（包括數據窗口內列名定義、 含義是標準實用文案否一致）。打印內容、格式錯誤。簡單的輸入限制未放在前臺進行控制。刪除操作未給出提示。數據庫表中有過多的空字段。存在不明確或不完整的錯誤信息提示，但對產品使用影響較小。界面不規范。輔助說明描述不清楚。輸入輸出不規范。類：輕長操作未給用戶提示。微和建提示窗口文字未采用行業術語。議性錯可輸入區域和只讀區域沒有明顯的區分標志。誤對系統運行沒有影響，提出可以使系統從可移植性、兼容性、錯誤恢復能力和可維護性、易用性方面的意見明確功能測試標準功能測試標準測試標準測試成果驗收標準將測試結果與測試計劃和功新系統可執行不存在B及以能描述進行對照檢查，確定程序上級別的問題標準實用文案系統滿足功能描述的要求 功能描述接口描述操作手冊（2）用戶測試設計設計測試用例：確定每個功能的測試用例，明確系統輸入信息和期望的輸出結果。針對需求規格說明書的每一條測試內容，確定測試用例。每個測試用例包括測試條件（包括生成測試條件需要的測試數據類型）和期望的結果。每個測試用例都應該是唯一確定的（例如，賦一個數值）。設計測試大綱：依據測試范圍生成測試大綱。對每一種業務情況類型，生成盡可能多的測試用例來完善測試大綱。為了保證測試大綱包含所有的測試用例，將測試用例的條件映射為測試大綱是非常必要的。測試大綱中測試用例的順序安排是非常重要的，它應考慮多種方面的因素，主要考慮的因素是按照系統產生的數據，在測試大綱中安排測試用例的順序，使得一個測試的結果作為另一個測試前提。測試環境準備：為了預防出現問題，如數據損壞或對系統資源的爭用，需要建立一個獨立的測試環境。在進行測試之前，根據測試計劃中確定的時機建立一個獨立的測試環境。其準備工作包括：標準實用文案技術活動：如建立不同的服務器或在一臺服務器上建立多個數據庫實例，將相應的程序遷移到適當的程序庫中；準備活動：包括加載數據表，建立用戶訪問權限；建立版本控制程序，保證有效的控制對系統的修改；建立文檔控制程序，保證隨著系統的修改，有效地控制文檔的修改（如，培訓文檔、聯機幫助和用戶手冊）。3）用戶測試結果測試結束后，測試小組根據測試數據，制定并向驗收工作領導小組提交《用戶測試報告》。測試報告結果說明軟件滿足下列要求：在認可的外部設計文檔中表述的功能要求在認可的系統描述文檔中表述的非功能要求此外，測試報告中還包括對系統提出的改進意見。測試過程中產生的工作成果：《測試計劃》《測試方案》《測試需求分析》《功能測試用例》《業務測試案例》《測試報告》《各階段評審》標準實用文案《系統測試方案》《系統測試案例》《系統測試報告》《試運行測試報告》《工作周報月報》《評審文檔相關》《缺陷數據和分析》3.1文檔管理方案3.2管理承諾針對本項目提供詳細科學的文檔管理方案。項目文檔是項目執行的重要指標，完善的文檔管理可以規范項目執行人員的進度和任務，可以為用戶和用戶間搭建溝通的橋梁，可以為工作的進展鋪設階梯，還可以為系統的升級和維護提供依據。我公司鄭重承諾：我公司在系統初驗前向用戶提交完整的技術文檔，內容與所開發的系統相一致，并盡可能詳細。所提交的技術文檔為正式版本。我公司提供所開發系統的各項技術指標的測試報告、第三方軟件產品的用戶使用授權書。標準實用文案我公司提供技術文件包括但不限于系統需求規格說明書、系統設計方案（包括概要設計和詳細設計）、系統用戶手冊、系統維護手冊等。我公司提供詳細驗收文檔等。我公司對本項目的所有技術文件以及用戶提供的內部資料、技術文檔和信息予以保密。我公司嚴格遵守與用戶簽訂的保密協議，未經用戶書面許可，絕不以任何形式向第三方透露本標書以及本項目的任何內容。一旦因我公司的原因造成泄密，我公司承擔相應責任。3.3管理依據所有技術文檔內容滿足：GB8567《計算機軟件產品開發文件編制指南》GB/TI1457-89 《軟件工程術語》《軟件工程文檔管理辦法》《國家檔案管理標準匯編》《國家二級檔案管理標準》《國家重點項目檔案管理辦法》（檔發安【1997】15號）國家檔案局關于印發《科學技術研究檔案管理暫行規定》《中華人民共和國環境保護行業標準環境保護檔案管理數據采集規范》標準實用文案的要求。提供的文檔和資料均應以紙張和光盤為載體，文件格式為Word文檔或其他可視化、未加密的文件。涉及圖紙規格和質量符合ISO標準的A4標準格式。3.4管理工具在本項目中，利用VisualSourceSafe進行項目文檔管理，系統(軟件)項目開發進程中將提交的文檔進行收集管理。通常，文檔管理在項目開發中不是很受重視，當發現其重要性時，往往為時已晚。整個項目可能因此變得管理混亂，問題產生后無據可查。文檔管理對于一個項目的順利進行有著至關重要的作用，其關鍵性不容忽視。項目文檔管理涉及范圍廣泛，其內容會根據項目的不同而有所變化。首先要了解在本項目中文檔管理要遵循的行業標準。目前軟件系統開發提供了通用的管理規定和行業標準，它涉及文檔管理的整個生命周期。細分文檔的生命周期，一般包括：創建、審批、發布、修改、分發、簽收、追繳、歸檔、廢止與恢復這樣幾個環節。就目前軟件項目的開發情況來看， 電子文檔使用較紙質文檔更為方便、靈活、廣泛。對于電子文檔，我們管理其整個生命周期。VSS(VisualSourceSafe) 作為一種電子文檔管理工具給我們提供了完整的文檔管理功能，它覆蓋了文檔管理全生命周期各環節的管理要求。 VSS通過客戶端/服務器(C/S)標準實用文案架構收集整個項目組成員的各類文檔，通過管理員合理規劃管理，將電子文檔按目錄保存并同時提供給整個項目組的不同成員使用。3.5分類我公司承諾在整個項目的執行過程中，為方便用戶的維護和管理，并且為今后系統升級和維護提供可靠的依據，向