信息安全方案安全原則我司安全方案設計遵循以下原則：*以滿足《網絡安全等級保護基本要求》(GB/T22239-2019)、《數據安全能力成熟度模型》（報批稿）和《政務信息共享數據安全技術要求》（送審稿）等數據安全合規要求為目標，協同大數據資源平臺各子系統落實關鍵合規要求并進行安全相關功能完善。實現多租戶隔離，包括租戶間的用戶隔離和數據隔離。實現基于角色和用戶組的訪問控制，在功能權限和數據權限兩個維度進行權限控制，功能權限控制應細化到頁面級別，數據權限控制應細化到行級，實現系統管理員、審計管理員和安全管理員三權分立，實現權限有效期設定并對授權范圍外操作嘗試進行告警。對接集成門戶和開放門戶實現統一身份鑒別和權限管理，做到統一設立、統一注銷、統一鑒別、統一授權和集中審計。實現基于場景觸發的多因素認證，對敏感數據或重要模塊的操作觸發復合采用兩種或兩種以上的鑒別技術進行身份認。對所有用戶操作記錄日志，包括業務操作日志和授權日志。業務操作日志內容至少包括：時間、操作賬號、租戶標識、訪問IP、操作對象、操作內容、操作結果；授權日志內容至少包括：時間、操作賬號、租戶標識、訪問IP、操作對象、操作內容、操作結果、授權對象、授權角色；日志應不包含敏感信息或對敏感信息進行脫敏處理。使用TLS協議，保證重要數據在傳輸過程中信息的保密性和一致性，采用校驗技術或密碼技術保證重要數據在存儲過程中的完整性，包括但不限于鑒別數據、重要業務數據和重要個人信息。對系統重要業務數據進行本地備份，在大數據中心提供異地備份環境支持前提下，支持對重要業務數據的異地實時備份。確保鑒別信息所在的存儲空間被釋放或重新分配前得到完全清除，敏感數據的存儲空間被釋放或重新分配前得到完全清除。對外接口的調用日志，日志內容包括：調用賬號、IP、調用時間、調用接口信息、調用結果。*對接統一身份認證管理鑒權中心系統，實現身份認證并支持金庫模式授權，保證系統的安全性。對接數據授權管理模塊，實現對數據的訪問權限、訪問數據用戶的身份認證，保證數據的安全性。對接脫敏服務模塊，保證脫敏規則的統一管理，實現對敏感數據的脫敏，保證數據的安全性。對接安全審計系統（接數據庫審計、應用授權審計、用戶權限審計、數據訪問權限審計、系統日志審計），將系統的日志分類后統一提供給安全審計系統進行日志分析審計。對接密鑰加密管理，實現數據的加解密、數據庫信息的加解密，保證數據的安全性。對接數字簽名系統，實現敏感網頁的網頁水印和數據傳輸中的數字簽名。安全服務安全集成服務按要求對服務內容進行安全建設并對落地效果進行檢查確保對《網絡安全等級保護基本要求》(GB/T22239-2019)三級要求、《數據安全能力成熟度模型》和《政務信息共享數據安全技術要求》等數據安全合規要求的符合性。安全評估服務在系統部署前，對各子系統源代碼開展源代碼安全審計；在系統部署后、發布前分別對各子系統開展主機漏洞掃描、應用漏洞掃描、安全基線檢查；在發布前對系統互聯網和政務外網邊界組織應用漏洞掃描和安全滲透測試；對上述檢測所發現的安全脆弱性和風險，提出具體的安全加固建議，并在系統完成必要的安全加固后組織安全驗證。等保測評支持服務配合相關等級保護測評方開展等級保護三級要求測評。安全措施網絡通訊安全系統服務器統一安置在政府授權機房，互聯網服務器已具備一定的非正常使用的防范能力（DoS阻塞、操作系統漏洞、病毒隔離），局域網的服務器（數據庫服務器和備份服務器）與互聯網實現單向物理隔離，外部無法訪問；安全準入通過身份認證和安全策略檢查的方式，對未通過身份認證或不符合安全策略的用戶終端進行網絡隔離，并幫助終端進行安全修復，以達到防范不安全網絡用戶終端給安全網絡帶來安全威脅的目的。對系統進行安全審計審計范圍覆蓋到服務器和重要客戶端上的每個操作系統用戶和數據庫用戶；審計內容包括重要用戶行為、系統資源的異常使用和重要系統命令的使用等系統內重要的安全相關事件。審計包括事件的日期、事件、類型、主體標識、客體標識和結果等。保護審計記錄，避免受到未預期的刪除、修改或覆蓋等。漏洞掃描。定期對服務器進行漏洞掃描，服務器操作系統及數據庫操作系統根據系統安全策略，采取適當方式進行安全補丁升級。建立用戶認證對登錄用戶進行身份鑒別和標識，對口令長度和復雜性設置要求，密碼強度要求至少八位，必須是數字與字母組合；用戶連續3次登錄失敗，則限制24小時之內，不能登錄，防止暴力破解。或者聯系管理員解鎖；建立登錄日志：記錄用戶登錄系統的用戶、時間、IP地址、登錄結果；建立操作日志：記錄主要業務模塊的操作日志，包括增加、修改、刪除等關鍵性操作。項目信息數據安全項目信息數據是本系統的核心，信息的安全很重要，需要采取必要的管理和技術措施加以保護，建立完整的項目信息字段更新日志，注冊和登錄常用較強密碼和驗證級別。采用加密或其他保護措施實現鑒別信息存儲保密性，對用戶口令采用MDF加密；對通信過程中的敏感信息字段，采用HTTPS等加密傳輸方式進行加密。檢測鑒別信息或重要業務數據在傳輸過程中的完整性是否受到破壞，并采取完整性保護措施。對數據庫進行定時備份，可以將員工誤操作，機器掉電，病毒攻擊，系統崩潰等人為或其它意外情況造成的損失減少到最低;將兩臺服務器通過批處理文件將系統備份做雙機冷盤，避免因一臺服務器故障導致數據丟失;服務器采用Raid5磁盤陣列，防止因一塊硬盤物理損壞導致數據丟失。對應用程序也采取相應的定期備份措施。數據交換安全因為是局域網上的應用作為網絡鏈接的發起方，外網無法主動連接到本系統在辦公網和局域網內的設備，但是在交換數據字段或數據包時進行編碼處理，以保證傳輸的準確性和安全性。操作系統安全措施服務器系統安全操作系統安全控制策略主要是利用用戶識別和認證、存取控制和監控審查機制增強保密性。采用各種軟硬件備份機制來增加系統的可靠性。在一定規模的網絡環境中，沒有對網絡和系統的集中管理，安全性的實施和管理幾乎是不可能的。因此，需要利用服務器操作系統的集中域管理、目錄服務功能等，來集中管理用戶的認證和對資源的授權。總之，我們要充分開發服務器操作系統的安全功能，并對其薄弱環節進行分析，自行開發或引進新軟件增強其安全控制能力。客戶機系統安全客戶機的操作系統多屬單用戶操作系統，安全控制保密能力較弱，可以采用的管理手段和技術措施有：加強用戶責任意識，例如在短暫的離開計算機操縱臺之前先退出網絡退出系統或鍵盤鎖定，等等；設置系統登錄口令，設置屏幕保護口令，認真保存存儲介質和打印輸出。系統邊界防護系統通過防火墻接入互聯網，因此在作邊界防護時不僅需要考慮系統與互聯網的邊界防護，還要充分考慮各部門之間的邊界防護。在方案中將采用防火墻技術做系統與互聯網的邊界防護，系統內部的業務部門將采用VLAN技術做邊界防護。防病毒系統設計在一個網絡計算環境中，病毒一般是通過磁盤、網絡、電子郵件或Internet下載進行傳播。網與Internet連通后，病毒的防范應該更加重視。病毒防范策略主要包括：1、管理方面：建立防病毒體制和規章制度，實行嚴格的用機機制，嚴格控制軟件介質的來源和去向，實行安全的備份制度，實施網絡防病毒策略。2、在技術上加強預防措施：使用可靠度高的、通過國家安全處室和機要處室認可的防病毒軟件產品，并建立相應的及時更新殺毒引擎和病毒特征庫的制度。因此，網絡防病毒解決方案主要從以下幾個方面考慮：1、杜絕通過磁盤、可移動磁盤、光盤等物理介質對服務器和普通工作站的病毒感染；2、對電子郵件的病毒防護，對有可能隨電子郵件傳播的病毒進行攔截；3、嚴格控制使用調制解調器等通訊連接設備進行收發文件，從內部網外部將病毒引入；4、對內部網站進行控制，防止HTTP和FTP等流量的病毒防護。整體備份機制本項目各應用子系統每天將產生大量數據，這些數據也必須進行備份。更為重要的是，萬一其中的某一應用系統因突發故障導致數據丟失或失效時，需要能夠用事先生成的備份數據將系統恢復到故障前的狀態，從而在盡可能短的時間內恢復系統應用，保證業務繼續運行，使損失和風險降低到最低。為了保證應用系統的數據資源不因發生意外情況而受到損失，可以采用以下幾種防范和恢復措施。1．手工備份：系統管理員定期對數據進行手工備份。2．周期性自動備份：可利用數據庫自動備份功能，配置數據的周期性自動備份，備份介質可以是備份數據庫、備份文件和磁帶等。3．服務器備份：在應用服務器和數據庫服務器分離的條件下，兩臺服務器可以相互進行備份。4．在發生硬件故障的情況下，能夠迅速而可靠的恢復數據庫結構及其內容，數據至少保留最近7天的完整數據；5．通過建立事務處理機制，在事務處理失敗的情況下，能夠保證數據庫恢復到確定狀態；6．針對系統中各類數據的互動，建立完整的數據審核機制，確保系統中的所有數據的正確性、合法性；7．數據不受非法、越權、越級操作侵犯，系統自動保留關鍵數據的變更歷史。應用和管理安全許多信息泄漏事件往往是系統設計缺陷、管理不善、內部網絡造成的，而非通過技術上的惡意攻擊：1．權限分配管理、對項目信息、評審信息進行分級管理，需要保護的信息提高安全級別和信息編碼，屏蔽信息共享。對已完成或不需要保護項目降低項目信息級別，實現信息共享。實現數據訪問的權限控制。采用權限控制表可為每個用戶、角色、組設置對每個目錄的數據訪問和應用權限。系統權限管理員由專人擔任，對于重要數據的訪問權限分配和可能具有危害性的操作權限分配一般需經過雙人審批授權環節。2．特別加強對查詢、統計、匯總和報表等數據集合功能的權限分配和管理。3．通過權限控制，自動拒絕越權、違規操作。4．對可能導致不可逆轉結果的操作采用二次提示確認機制。5．對各種原因導致的異常退出提供數據安全保障。6．提供重要操作失誤后的自動回滾機制。程序代碼安全在編寫程序代碼時做的編碼規范，做到無SQL注入、跨站腳本、緩沖區溢出等高風險漏洞，部署安裝經國家認可的惡意代碼防治產品，制定病毒防范策略。定期更新惡意代碼特征庫，及時升級軟件版本，定期進行惡意代碼查殺。

項目組織方案項目組織項目人力資源管理機制項目實施過程中人力資源管理是項目管理中一項十分重要工作，項目實施成功主要依靠公司整體的實力，依靠組織的制度與紀律。我司質量體系中具有一套完善的項目管理規范，本項目實施將通過執行這些規范來保證有效的項目人力資源管理：項目組每個員工都已經按照公司培訓制度接受管理規范的培訓，從而保證項目人員具備合格的知識技能來完成其工作；通過項目質量量化管理機制（根據缺陷率進行考核），考核及獎懲制度激勵員工追求上進、努力工作；項目組每個員工填寫日報，提高項目實施過程的透明度；項目人員的工作成果定期組織審核與評審，以保證項目每一項實施工作的正確性；項目人員所有的工作成果納入到配置管理庫中，以保證項目實施工作的完整性；項目人員所有工作都必須按照“文檔交付”章節提交文件，以保證項目實施工作可追溯性及可跟蹤性；項目組成員必須必須按照“項目會議制度”章節執行溝通規范，以保證交流的效率及有效性，充分體現項目人員每個個人的尊嚴與價值；項目人員組織結構一套健全有效的組織和領導機構是貫徹工程意圖和順利進行工程實施的重要條件和保證。在工程規劃之初，首要的是提出并組建起適于本項工程實施和管理的全套組織和領導機構。從實施和管理的職責看這套組織應是完整配套的，從人員構成素質看這套組織應是精練高效的。建議甲方公司和我司共同成立項目組，采用項目領導小組下的各方項目經理負責制，并明確規范所屬下級各組的職責及組間協調關系。為工程驗收，設置了直屬項目領導小組之下的多方方共同組成的驗收小組。這種結構是在多個大型工程項目中采用，并被驗證為行之有效的工程組織方案。建議項目組織結構圖如下所示：圖組織架構圖機構中人員構成與職責項目領導小組由招標方與我公司的相關領導組成，主要負責提供行政業務上的保證（為項目的前期調研和后期的需求變更確認，以及項目的實施等各項工作的順利開展，提供人力、物力、財力上的保證），負責項目實施過程中的重大事件的決策，根據項目過程中的進度、質量、技術、資源、風險等實行宏觀監控等。項目組會定期向管理領導小組匯報項目進度。一、項目領導小組工作職責1、審核批準項目的總體方案、實施計劃、把握需求，控制進程；2、項目團隊總體管理；協調各方面關系；3、負責項目實施過程中的重大事件的決策；4、根據項目過程中的進度、質量、技術、資源、風險等實行宏觀監控；5、協調參與項目的各級業務單位與我公司雙方關系；6、重大項目變更的決策；7、對項目的執行、質量進行監督和調控。二、項目經理職責1、與用戶討論并確定最終項目范圍和實施方法；2、負責制訂具體的項目計劃，包括培訓計劃；3、把握項目各方面的進程；4、指導業務流程重組和項目變更；5、檢查及調控項目實施范圍；6、向公司匯報項目狀況，提出建議及改進措施；7、負責項目階段質量。需求工作組項目需求工作小組成員由我公司的項目經理負責。工作職責：明確項目需求，提出需求分析，完成項目概要設計。質量監控組我公司配備有專門的質量監督經理，負責質量管理，按制定的標準及控制手段執行進度管理，風險管理和變更管理。評審軟件工程活動、審計軟件產品、將結果通知項目組成員及相關經理。軟件質量保證人員的主要工作目標是保證軟件過程質量。通過質量管理團隊的建立，將一些優秀的軟件工程化開發經驗用一套合理、規范的制度沉淀固化下來，使項目的成功不再成為一種偶然。項目實施組項目實施是本次項目建設的重點，我公司將針對本項目建設的要求，派出專業的實施隊伍，進行全面的系統的安裝、部署。工作職責：1、對項目實施按項目實施計劃提供實施支持；2、協助項目經理定義項目的范圍及目標；3、參與討論、制定項目計劃；4、按項目實施計劃提供系統功能培訓；5、制訂指導系統詳細實施計劃和進度方案；6、制訂數據轉換格式和方案；7、進行系統的客戶化；8、負責系統安裝、提供設備選型參數；9、對系統整體性能提出意見；10、根據以往的實施經驗提供實施風險及防范方面的建議。軟件開發組項目開發小組成員由我公司的開發部經理帶隊負責。工作職責：1、軟件開發組負責相關交互程序與軟件的編碼開發，包括高級程序員、程序員等。軟件開發組組長是一位資深的技術人員，對系統設計、系統開發、客戶業務及系統和開發工具有深入的了解。2、美工組負責項目的平面美術設計、FLASH動畫設計，負責完成項目中各種平面效果圖的設計。3、測試組負責制定測試計劃，進行單元測試、集成測試和性能測試，并撰寫測試文檔和測試報告。4、用戶文檔撰寫人員負責撰寫相應的用戶手冊和系統管理員手冊。售后服務支持組本項目需要一支高效率，結構合理、經驗豐富的項目服務隊伍來完成，提供優質的項目服務。考慮到項目的延續性，服務團隊在項目實施開始即與項目實施及開發人員共同參與項目的實施工作。項目服務組組長由一人擔任，負責項目服務人員的協調，對外的接口，工作的分配、總結，包括：1、數據庫維護人員，負責數據庫的相關維護工作；2、應用系統維護人員，應用系統的相關維護工作；3、開發人員，負責系統上線后的二次開發工作；工作職責：1、在該項目實施結束后，我公司將從公司內部抽調相關網絡技術人員及軟件開發人員，負責本項目相關軟件的日常維護、升級以及軟件應用的二次開發工作。2、培訓教師負責面向決策層、管理層、應用層、系統維護層人員提供培訓。3、售后服務人員負責系統維護以及相關技術支持工作。4、系統集成人員提供系統集成方面的技術支持。過程管理實施流程瀑布模型迭代模型A迭代模型B項目啟動階段需求分析階段需求規格階段設計階段開發階段測試階段試運行階段驗收階段項目維護階段項目質量及保證措施質量管理體系標準本項目實施應采用先進的質量管理模式和科學的質量管理體系和流程，并根據項目自身特點選用合適的質量控制規程。目前，主要采用ISO9001質量標準和軟件成熟度模型（CMM）兩種控制規程。針對本項目，公司將采用ISO9001質量體系標準，在項目實施的過程中嚴格執行質量標準。質量控制過程本項目中，由項目經理制訂質量控制計劃，項目質量控制組進行審核。審核方面包括：質量控制措施是否足夠、各個成員的質量責任是否明確合理，測試方法是否適用。質量評定計劃為了加強項目質量管理和界定產品質量標準，本公司將制訂適應于項目的檢查驗收規定和質量評定標準，確保工程質量。本項目中，應實行兩級檢查、兩級驗收制度。一級檢查、二級檢查和一級驗收由本公司實施小組組織完成；二級驗收由用戶組織實施。各級檢查驗收嚴格按項目實施中制訂的相應的檢查驗收規定和質量評定標準執行。對實施和驗收過程中出現的重大技術問題，將上報用戶協調處理，對一般質量問題的處理應予以書面記錄。質量管理措施在項目實施過程中還將采取如下措施保障項目實施質量：（1）在項目實施前后對網絡性能進行評估。（2）在系統部署完成后要在實際環境中進行網絡連通性測試、安全策略驗證和應用系統測試。（3）配合應用系統做好壓力測試，根據壓力測試結果調整系統配置。（4）項目實施后要進行一定時間的試運行，在試運行期間要重點監控網絡環境的運行情況、安全策略的驗證和業務應用系統運行情況，若出現的問題要及時查找原因并加以修正。（5）在試點實施過程中驗證方案的可行性和正確性。軟件質量控制階段性評審軟件質量保證過程包括對軟件過程質量控制和軟件產品質量控制。我公司在本系統項目組織中，由質量控制組負責質量控制和管理，采用軟件度量過程采集信息對軟件過程和軟件產品的質量進行管理。對軟件過程質量的控制通過量化并提取軟件過程信息實現對軟件過程的目標管理，量化的主要內容包括：產品質量、項目進度和資源占用。軟件過程控制一般采用軟件開發過程的節點控制的方法。軟件開發過程的節點控制是提高軟件開發的計劃性和成功經驗的可重復應用的重要支持手段。我公司在開發本系統的過程中，將充分利用該方法，確保本系統的高質、準時完成。在本系統的開發過程中，把涉及軟件開發、應用的人員分為甲方、乙方，甲方代表各種層次的軟件系統的用戶，乙方代表軟件開發商中各組織、各層次人員。軟件系統的最終成功基于甲乙雙方對軟件開發過程的共同控制與管理，甲方側重“需求”與“監督”職能，乙方側重“供求”與“控制”職能。甲乙雙方實現職能的基礎是軟件開發過程的可視性，即從甲乙雙方角度得到軟件開發過程的可見性。如下圖所示：圖（a）表示一個對甲乙雙方可見性極差的過程，甲方給出需求后，經過乙方的開發過程得到的是最終結果，甲方對軟件開發過程沒法參與。乙方中只有具體的開發人員了解局部的軟件過程，高層管理人員沒法得到開發過程中具體的過程狀態信息，不能根據過程狀態做出決策。圖（b）表示一個對甲乙雙方可見性較好的軟件過程，在軟件開發過程的特定階段設置階段控制點（也稱為里程碑），甲乙雙方依據階段成果，從各自的角度提出過程改善與修改意見，控制軟件系統生產的質量、開發過程的效率及項目資源消費。測試測試是確保本系統質量的重要手段，不經過認真測試的系統是不能被用于生產的。雖然，對各階段的文檔的審核也可認為是測試，但本項目所指的測試是指對應用軟件的測試。做好測試是測試組的責任，測試組是與開發組相互獨立的兩組，且需要相當的技術和經驗，對業務的理解要十分透徹。為保證測試的效率和質量需要主意以下幾點：1．建立高效合理的測試流程，包括：建立盡量模擬真實環境的業務數據模型（即運行業務的初始環境）；對測試案例的設計要有深度和廣度；特別在系統測試和驗收測試階段，安排好項目組的全體人員的任務和責任；做好測試階段文檔和源程序的版本控制；做好測試中發現的BUGS的記錄及存檔工作；對發現的任何BUGS都要做好原因分析并記錄歸檔；做好回歸測試；防止對程序的修改而引起的其他問題。軟件測試是一個過程，涉及到軟件生命周期的各個階段。下圖描述了軟件測試過程模型：測試過程是與開發過程并行的，軟件測試的實施過程是與改錯過程既是交錯的、同時又是并行進行的。在集成測試階段中，測試一般應當由獨立的軟件測試人員來實施。這種方法一方面可以有效地壓縮測試的總周期，但更重要的是可以避免開發者自身的思維局限，更加客觀全面地進行有效的測試。程序開發必須在開發服務器上運行，并經過同行測試才能放置到生產服務器上。如果測試必須要在生產環境中進行，則必須報告項目經理，并經過同意后，才可以在生產環境中進行測試。所有必要的測試通過后，報項目經理批準后，開發的程序才能正式通知用戶可以使用。項目風險管理風險定義軟件開發過程中，由于存在的各種不確定因素，給項目開發不可避免地帶來風險。產生風險主要可能有以下幾個方面：產品規模風險：項目風險是直接與產品規模成正比的。商業影響風險：常見的因素包括項目開發后交付給用戶的文檔量或質出現問題，或者由于產品缺陷造成成本的上升等等。需求變化的風險：客戶有不同的需求，但是同時由于在項目開發初期，客戶本身對自己的需求存在一定的模糊，導致開發過程中客戶需求的變化，這些都會給項目開發帶來風險。過程風險：如果項目的工作量，項目開發所需要的資源量不足，勢必會造成項目的延期，給項目帶來風險。同時項目的過程控制不能按照計劃有效進行，也是一種風險。技術風險：如果在項目的需求中要求使用新的技術、設計或測試方法，而新技術、新方法本身就具有一定風險。開發環境風險：由于本項目在很大程度上需要異地進行，網絡問題就會給項目帶來風險。在開發過程中，軟件工具完備性，設備是否能夠按時到位，同樣會帶來風險。為了緩解項目開發過程中的風險，首先我們將對項目中可能出現的風險進行風險評估，建立風險表；其次項目管理還將建立一個策略來降低人員流動，隨著項目的進展，對引起風險的因素進行動態監控，隨時發現和糾正可能出現的風險。具體的策略有：在項目開始之前，認真規劃整個項目的目標與項目的范圍，仔細做好客戶需求的調研工作。加強項目開發的質量保證與質量控制。定期召開項目工作會議，及時了解項目的進展以及出現的問題。在制定工作計劃前，充分考慮可變因素，提出解決建議。風險管理風險管理能力是體現一個公司項目管理能力的重要方面。具有良好的項目風險管理能力的公司很少出現項目失敗的情況。結合公司的實際情況，制定了一趟行之有效的風險管理過程。風險管理的過程圖，如圖。風險管理的主要活動如下：風險識別項目經理從項目立項及合同談判階段開始定期組織相關人員（包括項目組成員、QA代表、必要時包括用戶代表、部門經理等），通過“頭腦風暴”的會議模式識別盡可能多的項目風險。這種風險識別的活動應該一直持續到項目結束為止。項目風險的主要類型列在《風險檢查表》中，相關人員在識別風險過程中可以參考其羅列的風險，判斷這些風險是否在本項目中存在。項目的規劃和執行過程中針對風險管理的流程主要有以下這些：風險鑒別項目經理定期分析風險列表中列出的風險，估計風險發生的可能性，以及風險的影響程度。風險發生的可能性可分為0%、20%、40%、60%、80%、100%六個程度，其中100%表示風險已經發生。風險的影響程度代表風險的嚴重性，以風險一旦發生，造成項目組工作量的增加程度為衡量，單位是人天。風險的優先度指標代表風險的重要程度，它的計算公式為：風險發生的可能性×風險影響程度。同時評估其對項目可能造成的影響，并由項目經理進行確認，必要時上報項目管理委員會。風險分析根據風險對項目的影響程度進行分類，以確定如何管理這些識別出的風險。風險分類包括確認風險發生的可能性（極小、較低、中、較高、很高），以及如果風險發生了所引起后果的嚴重性（輕微、較小、中、高、很高）。風險評估根據以下基于影響程度的評估標準對風險進行分類：輕微：此類風險能夠安全地避免較低：將影響降低到最小程度，或只需采取簡單的應急措施中：應將影響降低到最小程度，并采取簡單的應急措施較高：此級別及之上的風險必須有防范計劃和規避/應急計劃很高：此級別及之上的風險應當有一個單獨的“風險行動計劃”，很可能需要單獨進行管理極高：這些風險將需要大量工作對其進行管理，如果可能的話應盡可能完全避免其發生以上分類作為決定如何對本項目中的風險進行管理的基礎。項目經理組織項目成員、QA代表定期評審列在《風險列表記錄單》上的風險，了解風險的狀況以及風險降低計劃和風險補救計劃的執行狀況，討論應對風險所需的資源和需要進一步采取的行動。如果風險可能性或影響程度發生了變化，或者發現了新的項目風險，或者項目本身發生了重大變化（重大變化包括新增的項目特性，系統目標平臺變化，項目成員發生非計劃的重大變化），則需要重新按定義的風險管理過程進行風險分析、計劃、跟蹤執行。風險計劃由項目組中了解風險的人，如項目經理或專家組，作為負責人并制定風險行動計劃以明確對策：避免：停止進行引起此風險的動作或活動移交：將風險分攤給其它方或與更有能力處理這一風險的人合作解決保留/接受：接受風險，期望它不發生，或設想風險負責人能夠處理其后果降低發生的可能性/防范：采取如更多的關注、QA程序、監督、培訓等方法降低影響后果/減緩：改變設計方案以減輕影響，制定風險防范計劃等如果風險對策所需資源超出項目組自身控制能力，由項目管理委員會負責資源調配。當風險的優先度指標超過項目整體計劃工作量的5%時，項目經理必須為這個風險制定降低風險計劃以及風險補救計劃。降低風險計劃指的是在風險發生之前，如何采取行動來降低風險的可能性以及風險的影響程度。風險補救計劃則是指一旦風險發生，如何采取行動，對風險發生造成的影響進行補救。風險跟蹤與控制風險將會在項目期間持續發生，存在的風險也將會發生變化。因此我們將在項目中采用有規律的風險鑒別、分析和管理流程：如每周的狀態跟蹤會中將回顧項目風險、計劃風險對策和監督風險對策的執行。更新風險記錄表和風險管理計劃中相應的風險狀態。由項目經理負責風險對策的跟蹤工作，并向項目管理委員會匯報。重大風險（如影響度為高或極高的風險）的管理流程，需要有項目總監的參與以有效控制風險，并做出最終決策。根據項目執行的不同階段調整風險清單項目經理對已經制定降低風險計劃的風險，安排人員執行降低風險的計劃。對于已經發生的風險，則進行風險補救計劃。優先度值越高的風險越先被處理。項目經理應該跟蹤風險計劃的執行狀況，并將計劃的執行過程記錄于《風險列表記錄單》。對于已經執行的風險降低計劃，要分析計劃的執行對風險可能性以及風險影響程度的影響，是否達到預期的效果；對執行的風險補救計劃，要分析補救計劃是否減少了風險的發生對項目的影響，以及減少的程度。風險計劃所有的執行過程，以及執行結果，再計劃和再跟蹤的過程，都需要記錄在《風險列表記錄單》中。項目文檔項目技術文檔我司提供的書面技術資料能確保系統正常運行所需的管理、運營及維護有關的全套文件。技術文件應該全面、完整、詳細。提供的技術文件至少包括：－系統說明文件；－技術手冊(安裝、測試、操作、維護、故障排除等)；－項目文檔，包括：(1) 軟件需求說明書(2) 系統總體設計說明書(3) 應用軟件功能清單我司承諾中標后提供全套技術文件紙介質3套以及電子文件1套。設備開通后，如發生軟件升級及設備升級、擴展等有關情況，我司向最終用戶提出申請。項目管理文檔針對本項目，我司提供包括但不限于以下管理文檔：項目啟動會議紀要；項目進度計劃表；項目日報；項目周報；項目需求確認郵件；項目質量管理；項目流程管理文檔；項目報告；……

項目實施方案項目實施原則1．用戶方項目小組的成員，爭取參與項目的全過程用戶方成立領導親自掛帥的項目小組，在調研、設計、編碼、安裝調試、測試、培訓、運行、驗收、售后服務等項目的各個階段，配合系統開發方的工作，一方面可以培訓自己的技術維護隊伍，為系統的使用保駕護航；另一方面，在開發過程中，協調用戶方和開發方的關系，保證項目的順利進行，及時發現問題，并對項目進度和質量進行監督。此外，我公司在項目實施過程中承擔如下職責：按招標方的要求，我方負責開展詳細全面的需求調研工作，進行需求分析并形成需求說明書由招標方確認。負責指導所提供的應用軟件現場安裝、調測和開通。除了負責自己應用軟件系統的互通，還將配合招標方保證能與其它應用系統之間的互通。向招標方提交測試內容、方法和測試計劃。測試計劃和測試內容由我方擬定，經招標方確認。我方確保技術建議以及所提供的應用軟件的完整性和可用性，保證應用軟件能夠投入正常運行。若出現由于我方提供的應用軟件不滿足要求或其所提供的技術支持和服務不全面而導致系統功能無法實現或不能完全實現，由我方負全部責任。提供系統裝調試時所需的工程設計資料,我方有責任在保證安全和質量的前提下提供技術服務,包括技術咨詢等。在系統調試期間,招標方有權派出技術人員參加,我方有義務對其進行指導。在系統試運行期間，根據需要我方有責任派技術人員到現場指導維護工作。在系統和設備擴容及軟件升級時，我方派技術人員到場指導。2．采用“兩手抓”的方針，一手抓開發、一手抓使用對于軟件項目，之所以稱為一個工程，很大程度上是因為軟件項目的建設，除了技術因素外，還有很多的非技術因素需要考慮，并且必須被得到重視。衡量一個軟件項目是否成功，很大程度上不是看這個軟件項目采用了多么先進的技術，而是軟件對用戶來說是否實用，是否能夠幫助用戶解決許多預期的問題。國內很多軟件項目的失敗，很大程度上是使用抓得不夠。建議在項目的試運行過程中，在抓系統維護的同時，也要狠抓系統的使用，開發方和用戶方齊心協力幫助業務人員從原來的手工處理轉到計算機輔助處理上來，在業務人員適應計算機輔助業務處理的過程中，盡可能早發現系統中存在的問題，從而最大可能地使系統保質保量的按時完成。3．數據同程序同等重要該系統的建設，數據位于首要的地位，程序的編寫完成，僅僅意味著系統完成了一半，數據的收集、整理、錄入，對系統的建設來說同等重要。在項目實施過程中，一定要重視系統中數據的錄入工作，充分估計數據處理的難度，在系統建設之初，就將數據工作提到議事日程上來，安排相應的資金、時間等，將數據工作落到實處，只有這樣才能爭取系統早日達到實用化。項目實施策略由于本項目實施的范圍廣、工作量較大，因此需要良好的實施策略保障實施的順利進行。考慮到本系統的建設是一個逐漸深入，滾動發展的過程，同時也是一個不斷完善的過程，項目組綜合各方面的因素考慮，擬采用“原型法”來進行本項目的實施。具體策略措施主要包括以下幾個方面：1、統一規劃，分步實施。項目實施采用統一規劃，分步實施的策略，明確項目每一個階段的實施范圍，保障本系統建設高效、有序地實施。在項目實施過程中，將提交詳細的項目實施計劃列表，以及實施時間表，按照需求調研論證、軟件開發設計、安裝、培訓、調試、初驗、試運行、終驗等各步驟有序地實施。2、版本控制，統一系統。我們將采用嚴格的版本控制方法，統一本項目的系統版本。3、分層實施策略。信息化系統的建設，不是簡單的信息化技術改造和提升，更重要的是它意味著對內部與外部的業務梳理和整合。項目建設分三層：一是認識問題，二是操作問題，三是工程和技術問題。其中認識問題其中包括系統的目標、價值、意義、時機、重要性、利弊等方面，也就是項目組成員在許多問題上要達成一些基本的共識；操作問題包括如何做好系統和如何運行好系統，包括管理，規劃，投資，標準，組織，階段性，評價，系統結構，運營，規范制度和環境等等；工程和技術問題包括這個具體是指項目實施和方案問題，包括軟硬件，安全，認證，人員培訓等。項目管理機制項目進度控制項目實施工期我司承諾根據之前建設內容，分階段制定合理的時間進度，并且根據招標方要求進行調整和細化，在項目規定期限內保證系統上線。我司承諾中標通知書發出之日起，90日內完成本項目要求的所有系統需求開發、測試及部署上線，包括系統間接口開發和聯調、遺留系統存量數據割接方案的評審，具備整體功能上線條件。項目實施計劃表由于本項目規劃的內容較多，立足于實際情況，本項目采用總體規劃、分步實施、穩步推進原則，盡可能充分利用現有資源，節約投資，具體階段劃分如下：序號里程碑主要工作內容開始時間完成時間1需求調研與確認了解業務含義和業務流程，與業務部門確認需求和業務實現方式T0（天）T0+20（天）2項目開發針對用戶需求進行開發T0+21（天）T0+55（天）3系統測試、聯調、試運行系統測試、現場部署和聯調及試運行T0+55（天）T0+89（天）4系統上線系統上線T0+90（天）T0+90（天）T0為中標通知書發出之日起。項目人員控制針對本項目人員投入，我司承諾如下：1.在項目實施期間，如果招標方認為系統供應商人員配置不能達到完成項目所需的要求，有權要求系統我司在5天內（包含節假日）按照招標方要求增加或調換項目組成員。2.我司配備包括但不僅限于數據治理相關技術經驗豐富、熟悉各類數據治理產品的中高級人員的長時間的駐場服務，對于駐場團隊的具體要求如下：我司為本期項目單獨建立管理組織，配置核心管理團隊24人（且為本單位在職員工）；承諾建立至少100人規模的服務團隊，提供7x24小時的駐場服務；項目經理具有相關管理資質（信息系統項目管理師以及高級工程師證書）團隊成員包含熟悉ITIL運維流程的團隊成員不少于5人，具備專業技術能力的高級工程師至少2人。我司已在在方案中提供對于本項目詳細的人員配置清單（見.6.2）。團隊組織機構、團隊人員配備、團隊人員資質見6章節。項目質量控制在項目實施全過程中，招標方及招標方授權的第三方有對工程質量進行監督控制的職責和權利，我司將按照項目管理要求進行嚴格的質量控制，并制定詳細合理的溝通計劃，至少包括周報、月報和項目例會，確保買賣雙方能及時了解所需的信息。項目后勤保障我司根據項目實施需要配備獨立、安全的辦公場所供駐場及工程實施人員使用。并有獨立的人力資源調配流程、財務流程制度等以應對項目實施過程中的風險因素。我司已在在方案中闡述相關制度及風險應對措施（詳見5.4項目風險管理）。項目培訓培訓計劃對于任何一個項目的實施，人員素質都是非常重要的一個因素。因此從項目實施之初就應該同時開始進行各種水平和層次的培訓。需要通過授課培訓讓大家增加知識并改變以往的工作習慣和工作方式。參與實施的項目組人員應當學習IT方面的知識，并了解項目實施計劃，以便更好地配合。對于使用系統的最終用戶，要學習新系統的工作過程和操作程序，并進行模擬實踐，已使他們充分了解和支持新系統，更好地適應新系統的工作。通過使用計算機來節省人力早已不是計算機應用的目標，它追求的目標在于以更有效的新方式實現對業務全過程的管理。因此在實施的過程中，必須通過教育和培訓使從高層領導到廣大員工都充分理解項目，并期待通過它來獲益，項目的實施才能夠最終成功。我們將在本工程項目的培訓工作中，積極實現以下目標：用戶方的使用操作或管理員全面了解本工程的產品配置情況、系統結構、系統功能；用戶方的使用操作或管理員掌握各子系統的操作、使用方法；用戶方的管理員能夠相當程度的維護各子系統；管理員能夠熟練地進行常規功能設置、參數設置，以便于運行當中的優化從而滿足實際業務不斷變化的需求。在簽定合同起的一個月時間內，向用戶提交一份培訓的詳細計劃及每一課程的大綱，包括培訓項目、人數、時間、地點等具體內容；授課方式、教員職稱與資歷，課程的詳細內容在培訓前10天提供。培訓方式我方將編制并實施必要的培訓課程，負責對用戶指定的培訓人員進行技術培訓，使有關人員了解這套系統，我們擬從本項目建設合同生效之日(或用戶指定)起對客戶有關人員進行系統培訓，培訓的對象分高級和初級兩級進行。接受高級培訓的人員為高級管理人員、高級技術人員，重點了解系統的構成、運行、管理；接受初級技術培訓人員為技術員和操作、維護人員。1、講解階段由我方的系統培訓工程師向用戶指定的培訓人員講解整個系統的組成、工作原理和主要功能等。2、實際操作階段領會系統基本構成后，在我方系統工程師的講解和指導下，帶領用戶指定的受訓人員進行實際操作。3、答疑階段在上述兩階段的培訓完成后，由我方的系統培訓工程師解答培訓人員提出的相關問題。（此階段的活動也可能在前兩個階段的培訓過程中發生）相關人員的培訓：1.系統維護人員（工程師/程序員/具體實際操作人員）：能較深入地了解各軟件的工作原理、系統組成等其他相關技術要求，能全面地掌握該軟件，并能指導其他技術人員的維護工作。2.業務操作人員（相關管理人員/業務人員）：掌握軟件的詳盡的工作原理、操作使用、一般維護、常見故障排除等一系列的專業培訓。培訓課程和時間1、應用軟件系統管理：針對系統管理員和系統維護員在應用軟件投入運行前進行的系統管理培訓。培訓內容為系統管理一般知識和組織機構、業務流程、系統參數等的管理以及超級用戶等管理工具的使用以及管理日志的利用等。教材為我公司提供的《系統管理員操作手冊》。應用軟件系統管理培訓安排在系統開發測試結束，進入實施階段前。2、應用軟件系統操作：為領導和普通用戶進行的應用軟件使用培訓，培訓內容包括計算機基礎知識、應用軟件的基本操作。教材為我公司提交給客戶的《用戶操作手冊》。應用軟件操作培訓安排在系統實施結束，進入試運行前。培訓時間和培訓地點由雙方協商后確定。培訓承諾人員培訓是平臺實施成功的關鍵。為了充分發揮系統的效益，系統供應商應根據產品系列的劃分，安排相應的技術培訓。針對本項目培訓，我司做出如下承諾：我司負責提供所開發應用功能軟件的原理、性能、操作使用方法、安裝調測、維護管理、排除故障及軟件結構、定制和升級等各個方面培訓，系統供應商應給出詳細的培訓計劃和課程安排，并提供全套教材。本期合同包含15個人的初始培訓（指平臺搭建及上線過程中對整體解決方案的培訓），以及后續每年5人（項目驗收后的第2~5年）的進階培訓；我司將詳細開列各種培訓費用。如對合同中確定的培訓地點、時間等項目系統供應商提出變更，應提出書面通知，并承擔變更中發生的全部費用。培訓地點、時間由雙方商定。系統開通運行后，我司根據招標方的需要不定期免費對招標方新入職人員進行相關的培訓（原則上一年二次）。運營人員經過培訓后，能熟練使用系統軟件，及時排除大部分的系統故障。系統管理員經過培訓后，能熟練掌握系統軟件的使用，熟悉系統整體結構，能夠閱讀軟件源程序，分析系統故障，管理系統設備，掌握系統內部和外部接口，具備系統管理和系統擴建、升級的能力，承擔全面的技術管理工作。系統安裝及調試針對本項目的安裝及調試，我司承諾如下： （1）我司負責系統集成，調測（包括硬件及軟件）及開通； （2）系統測試將由我司提供調測方案，經招標方確認后，在我司的督導指導下進行。我司提供測試方案并通過書面形式向招標方報告測試進展（包括遇到的實際問題）以及所有的工程文檔；在系統調測完成后必須經現場人員書面確認，否則不予驗收。 （3）在安裝工作開始前，我司提供安裝技術資料和相關的規范。我司將提供詳細的條款、測試方法、測試目標和系統測試的必需儀器，并經招標方確認。在經過系統測試后，我司認為系統的質量和穩定性達到要求時，向招標方提供匯總的測試記錄。系統測試測試原則（1）系統測試的條款應與技術規范書一致，測試范圍應以本技術規范書為基礎，測試指標應以技術規范書及認可的答復為標準。基于以上要求，系統供應商應提供測試條件，方法和過程的草案，談判以后，最終測試文件由雙方共同擬定。測試內容應至少包括：軟件性能測試軟件功能測試網絡功能測試安全性測試大負荷測試其它測試等（2）系統測試由系統供應商督導人員及招標方人員配合進行；（3）如果系統測試沒有滿足測試文件的要求，要重新進行系統測試。（4）系統供應商需提交工程測試驗收標準，《測試驗收》文檔需要盡量細化，需要經過大數據中心確認。測試目的和任務軟件測試的目的是采用技術的手段，根據預定的目標，按照一定的規則和過程，檢測和發現軟件中存在的各種問題、缺陷和錯誤。軟件測試是檢驗和保證軟件產品的正確性與可靠性的一種基本方法。任何軟件產品都必須經過必要的測試過程并經確認后才能付諸使用。為了保證測試的完整性和全面性，原則上測試活動應由開發者以外的人員設計和進行。測試完成以后應及時作好總結并提呈測試報告。測試所用到的工具及產生的所有說明、數據等文檔資料必須作為項目開發的基本文檔妥善保存。測試的階段測試是一項復雜的軟件質量保證技術，由不同的人在軟件開發的不同階段，針對不同的目標采用不同的技術手段來進行。根據軟件測試的要求、范圍和目的的不同，測試過程一般可分為下列三個階段：單元測試(UnitTest)集成測試(IntegrationTest)驗收測試(AcceptanceTest,FAT)測試內容功能測試1、劃分等價類把所有可能的數據輸入劃分為若干部分，然后從每一部分選擇少數具有代表性的數據作為測試用例。（1）有效等價類合理，有意義的輸入數據構成的集合，檢驗程序是否實現規格說明預先規定的功能和性能。（2）無效等價類不合理，無意義的輸入數據構成的集合，檢驗程序的容錯能力。邊界值分析大量的錯誤發生在輸入或輸出的邊界上，而不是某個范圍的內部。語句覆蓋設計若干個測試用例，運行所測程序，使得每一可執行語句至少執行一次，語句覆蓋是最弱的邏輯覆蓋在準則。判定覆蓋設計若干測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次，即判斷的真假值都能滿足。條件覆蓋設計若干測試用例，運行被測程序，要使判斷中的每個條件的可能取值至少滿足一次。路徑覆蓋覆蓋所有可能的路徑。功能測試的方法(1)頁面鏈接檢查，每一個鏈接是否有對應的界面(2)相關性檢查，刪除/增加一項會不會對其他項產生影響，如果產生影響，是否正確(3)檢查按鈕功能是否正確(4)字符串長度檢查，輸入超出需求所說明的字符串長度的內容，看系統是否檢查，會不會出錯。(5)字符類型檢查(6)標點符號檢查(7)中文字符處理，亂碼或出錯(8)檢查帶出信息的完整性，在查看信息和update信息時,查看所填寫的信息是不是全部帶出,帶出信息和添加的是否一致。(9)信息重復，在一些需要命名，且名字唯一的信息輸入重復的名字或ID，看系統有沒有處理，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，看系統是否處理。(10)檢查刪除功能，在一些可刪除多個的地方，不選任何內容按刪除按鈕看系統如何處理(11)選擇一個或多個時又如何處理(12)檢查添加修改是否一致，檢查添加和修改信息的要求是否一致,例如添加要求必填的項,修改也應該必填;添加規定為整型的項,修改也必須為整型.(13)檢查修改重名，修改時把不能重名的項改為已存在的內容，看會否處理，報錯，同時看會否報和自己重名的錯。(14)重復提交表單，一條已成功提交的記錄，back后在提交，看系統是否進行處理。(15)檢查多次處理back鍵的情況(16)Search檢查:在有search功能的地方輸入系統存在和不存在的內容，看結果是否正確；(17)如果可以輸入多個search條件，同時可以添加合理和不合理的條件，看系統是否處理正確。(18)輸入信息的位置，輸入信息時，光標的位置(19)上傳和下載文件的檢查，上傳下載的功能是否實現，上傳文件是否能打開，上傳文件的格式規定，系統是否有解釋信息。(20)必填項檢查，必填項是否有提示信息(21)快捷鍵檢查，是否支持常用快捷鍵檢查(22)回車鍵檢查，在輸入結束后直接按回車鍵，看系統處理如何，會否報錯。2．界面測試的常用方法界面測試要遵循的規則：1）易用性，按鈕名稱通俗易懂，望文知意。（1）完成相同或相近功能的按鈕，要用Frame框起來，常用按鈕要有快捷鍵（2）完成同一功能或任務的元素要集中放置，減少鼠標的移動距離（3）按功能將界面劃分區域塊，并要有功能說明和標題（4）界面要支持鍵盤自動瀏覽按鈕功能，Tab，回車鍵等（5）界面上首先要輸入的和重要信息的控件在Tab順序中應當靠前,位置也應放在窗口上較醒目的位置。（6）同一界面上的控件數最好不要超過10個，多于10個時可以考慮使用分頁界面顯示。（7）分頁界面要支持在頁面間的快捷切換，常用組合快捷鍵Ctrl+Tab（8）默認按鈕要支持Enter及選操作，即按Enter后自動執行默認按鈕對應操作。（9）可寫控件檢測到非法輸入后應給出說明并能自動獲得焦點（10）Tab鍵的順序與控件排列順序要一直，目前流行總體從上到下，同時行間從左到右的方式。（11）復選框和選項框按選擇幾率的高底而先后排列。（12）復選框和選項框要有默認選項，并支持Tab選擇。（13）選項數相同時多用選項框而不用下拉列表框。（14）界面空間較小時使用下拉框而不用選項框。（15）選項數較少時使用選項框，相反使用下拉列表框。（16）專業性強的軟件要使用相關的專業術語，通用性界面則提倡使用通用性詞眼。2）規范性，通常界面設計都按Windows界面的規范來設計（1）常用菜單要有命令快捷方式（2）完成相同或相近功能的菜單用橫線隔開放在同一位置。（3）菜單前的圖標能直觀的代表要完成的操作。（4）菜單深度一般要求最多控制在三層以內（5）工具欄要求可以根據用戶的要求自己選擇定制。（6）相同或相近功能的工具欄放在一起。（7）工具欄中的每一個按鈕要有及時提示信息。（8）一條工具欄的長度最長不能超出屏幕寬度。（9）工具欄的圖標能直觀的代表要完成的操作。（10）系統常用的工具欄設置默認放置位置（11）工具欄太多時可以考慮使用工具箱。（12）工具箱要具有可增減性，由用戶自己根據需求定制。（13）工具箱的默認總寬度不要超過屏幕寬度的1/5。（14）狀態條要能顯示用戶切實需要的信息，常用的有：目前的操作、系統狀態、用戶位置、用戶信息、提示信息、錯誤信息等，如果某一操作需要的時間較長，還應該顯示進度條和進程提示。（15）滾動條的長度要根據顯示信息的長度或寬度能及時變換，以利于用戶了解顯示信息的位置和百分比。（16）狀態條的高度以放置五好字為宜，滾動條的寬度比狀態條的略窄。（17）菜單和工具條要有清楚的界限;菜單要求凸出顯示，這樣在移走工具條時仍有立體感（18）菜單和狀態條中通常使用5號字體。工具條一般比菜單要寬，但不要寬的太多，否則看起來很不協調。（19）右鍵快捷菜單采用與菜單相同的準則。3）獨特性（1）安裝界面上應有單位介紹或產品介紹，并有自己的圖標。（2）主界面，最好是大多數界面上要有公司圖標。（3）登錄界面上要有本產品的標志，同時包含公司圖標。（4）幫助菜單的“關于”中應有版權和產品信息（5）公司的系列產品要保持一直的界面風格，如背景色、字體、菜單排列方式、圖標、安裝過程、按鈕用語等應該大體一致。4）安全性（1）最重要的是排除可能會使應用非正常中止的錯誤。（2）應當注意盡可能避免用戶無意錄入無效的數據（3）采用相關控件限制用戶輸入值的種類。（4）當用戶作出選擇的可能性只有兩個時,可以采用單選框。（5）當選擇的可能再多一些時,可以采用復選框,每一種選擇都是有效的,用戶不可能輸入任何一種無效的選擇。（6）當選項特別多時，可以采用列表框，下拉式列表框。（7）在一個應用系統中,開發者應當避免用戶作出未經授權或沒有意義的操作（8）對可能引起致命錯誤或系統出錯的輸入字符或動作要加限制或屏蔽。（9）對可能發生嚴重后果的操作要有補救措施。通過補救措施用戶可以回到原來的正確狀態。（10）對一些特殊符號的輸入、與系統使用的符號相沖突的字符等進行判斷并阻止用戶輸入該字符。（11）對錯誤操作最好支持可逆性處理，如取消系列操作。（12）在輸入有效性字符之前應該阻止用戶進行只有輸入之后才可進行的操作。（13）對可能造成等待時間較長的操作應該提供取消功能。（14）特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/還有空格。（15）與系統采用的保留字符沖突的要加以限制。（16）在讀入用戶所輸入的信息時，根據需要選擇是否去掉前后空格。（17）有些讀入數據庫的字段不支持中間有空格，但用戶切實需要輸入中間空格，這時要在程序中加以處理。性能測試1、負載測試負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？Web應用系統能否處理大量用戶對同一個頁面的請求？負載測試應該安排在Web系統發布以后，放在Internet上接受負載測試。2、前端連接測試用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。以上需要關注的前端性能指標，主要包含以下三個指標：加載時間指標a.TimetoFirstImpression表示從用戶在瀏覽器鍵入URL按下回車鍵一刻開始，到頁面開始有反應（用戶可以在頁面中看見一點點內容）為止。直觀信號就是網頁開始顯示title。b.TimetoonLoadEvent表示從頁面開始顯示內容，到瀏覽器開始觸發OnLoad函數（開始執行js）這一時間段。只有當初始的文本和所引用的對象加載完成，瀏覽器才開始觸發OnLoad函數c.TimetoFullyLoaded表示從上一時間段末到整個網頁完全加載完成（所有OnLoad函數以及相關的動態資源加載完成）。資源情況指標網頁由初始的html文本中嵌入圖片以及通過XHR或者修改dom樹動態加載的內容組成，css負責樣式，js負責行為。a.TotalNumberofRequests包括html網頁請求，css、js資源下載及其它網絡請求。優化的目標之一是要盡量減少請求數。b.TotalNumberofHTTP300s/400s/500s表示返回狀態為300（重定向）、400（客戶端錯誤）、500（服務器端錯誤）的http請求。盡量避免這些請求，以提高頁面load的時間。造成這些狀態的原因經常是服務器的實施、配置和部署問題。c.TotalSizeofWebSite構成網頁元素總的大小。圖片或者js庫的增加都會對下載時間造成重要的影響。d.TotalSizeofImages/CSS/JSimage、css、js在網頁元素大小中占主要比例。e.TotalNumberofXHR(XMLHttpRequest)Requests通過js異步從服務器端獲得數據的請求數。一些js框架提供了跟服務器端的更新機器，就是XHR請求。通過配置可以減少XHR請求的數目。網絡連接指標瀏覽器底層的網絡連接對資源的下載速度有很大影響。資源的下載過程分為很多階段。下面介紹這些階段以及瀏覽器、網絡、請求如何影響這些階段的時間。a.DNSTimedns查詢的時間。網頁請求會產生一次尋找該網頁資源所在主機的dns查詢。在同個域名進行網頁切換不會造成新的dns查詢。b.ConnectTime指瀏覽器和服務器之間建立tcp/ip連接的時間，對于ssl連接包括握手的時間。網絡連接過慢、使用ssl、使用短連接而非常連接都是造成connecttime較多的原因。c.ServerTime指收到請求后服務器邏輯處理的時間，d.TransferTime這一指標與瀏覽器和服務器之間的連接速度相一致，通過減小傳輸內容或使用cdn來降低TransferTime。e.WaitTime等待時間和同一個域中服務資源的數量直接相關。每個域的瀏覽器的物理網絡的限制，導致資源等待可用的連接。減少資源的數量，或將資源散布在不同的域，能將這一時間降低。平均等待時間的大小更能反映等待時間是否需要注意。f.NumberofDomains/SingleResourceDomains部署網站資源的域主機數量是很重要的，因為它影響的DNS，連接和等待時間。專門用戶資源下載的域是必要的，他將直接減少等待時間。應避免單一的資源域，否則將為dns查詢以及資源下載付出昂貴的代價。穩定性測試壓力測試壓力測試主要是為了獲取系統在較大壓力狀況下的性能表現而設計并實現的，壓力測試主要是獲取系統的性能瓶頸和系統的最大吞吐率。1、壓力測試概述壓力測試是針對系統在應對密集整轉的壓力下業務處理能力的測試，檢驗系統的吞吐率；針對主要業務功能、報表統計進行，檢查在日間應用高峰時期，并發用戶數較多的時候的處理能力等等。2、測試目的壓力測試的目的就是檢驗系統的最大吞吐量，檢驗現行的業務系統在各種壓力交易量下的運行狀況，檢驗系統地運行瓶頸，獲取系統的處理能力等等。3、測試方法及測試用例對系統進行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，跟蹤記錄服務器端的運行情況和返回給客戶端的運行結果。針對每個測試用例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進行，查看服務器端在客戶端的連接數量變化過程中對應的處理能力，以更好的定位系統在達到多少并發或壓力下我們的系統出現了不穩定。4、測試指標及期望在本次性能測試中，各類測試指標包括測試中應該達到的某些性能指標，這些性能指標均是來自應用系統設計開發時遵循的業務需求，當某個測試的某一類指標已經超出了業務需求的要求范圍，則測試已經達到目的，即可終止壓力測試。5、應用軟件級別的測試指標 CPU的利用率小于40% 內存占用小于80% Processorqueuelength小于2 Responsetime小于1s 吞吐量throughtput大于90% 業務執行的平均響應時間（期望值：<15s） 不同并發用戶數的狀況下的記錄上述值網絡級別的測試指標 吞吐量：單位時間內網絡傳輸數據量 沖突率：在以太網上監測到的每秒沖突數操作系統級別的測試指標 進程/線程交換率：進程和線程之間每秒交換次數 CPU利用率：即CPU占用率（％） 系統CPU利用率：系統的CPU占用率（％） 用戶CPU利用率：用戶模式下的CPU占用率（％） 磁盤交換率：磁盤交換速率 中斷速率：CPU每秒處理的中斷數數據庫級別的測試指標 數據庫I/O的流量大小 數據庫鎖資源的使用數量 數據庫的并發連接數：客戶端的最大連接數測試數據準備根據測試系統的硬件條件，選擇滿負荷的壓力，在系統的資源使用基本維持在90%左右的狀況下，測試天威寬帶業務管理系統的處理能力。數據準備工作包括：測試數據庫需具備與真實環境成一定比例或基本一致的數據運行狀況記錄記錄可擴展性測試中的測試結果及其系統的運行狀況。除了記錄測試指標以外，應該結合測試實時記錄系統各個層次的資源和參數。主要包括： 硬件環境資源 服務器操作系統參數 網絡相關參數 數據庫相關參數：具體數據庫參數有所不同，結合各個數據庫獨有的特點記錄容錯測試時鐘中斷測試概念時鐘源中斷測試是指通過模擬時鐘信號中斷來測試時鐘源中斷對系統的影響的測試過程。測試目的測試時鐘源中斷對系統的影響，檢查系統對時鐘源中斷的處理過程是否符合要求。故障產生原因（1）、外部時鐘源中斷（2）、相關模塊故障故障可能產生的后果（1）、誤碼（2）、業務中斷測試步驟（1）、啟動系統，加入一定的業務量。（2）、在系統正常運行時，切斷時鐘信號線或模擬失效使時鐘信號中斷。（3）、觀察系統的狀態測試的期望結果系統能檢測到時鐘源中斷所影響的范圍并上報故障，同時對于重要業務，能及時倒換到備用設備上去。當時鐘源恢復正常后，系統也能恢復到故障前的正常狀態。資源丟失測試[概念]資源丟失是指資源沒有正在被使用，也不在對應的資源管理程序中，即該資源已經不受控了。[測試目的]資源丟失測試的目的是驗證在發生資源丟失故障時軟件是否能從故障中恢復過來，在故障恢復過程中是否還引入了其它的故障。[故障產生原因]（1）、重入（2）、申請出來的資源使用后沒有釋放（3）、在某些路徑下資源沒有釋放[故障可能產生的后果]（1）、復位（2）、輸出錯誤（3）、軟件內部狀態錯誤（4）、業務無法完成或業務性能降低[測試時的故障產生方法]把資源申請出來后不釋放。[測試步驟]（1）、申請一個資源（2）、經過一段時間后，檢查軟件是否能發現出現資源丟失，觀察軟件是否采取了什么恢復措施，該措施是否有效。（3）、重復申請一批資源出來，不釋放，過一段時間后，檢查軟件是否能發現出現資源丟失故障，故障軟件是否采取了相應的措施，以及該措施是否有效。[測試的期望結果]對于一般系統，要求在資源耗盡以后能復位，這時要注意耗盡型資源和非耗盡型資源的差異，復位條件的檢測要特殊設計。對于系統，要求能恢復資源丟失造成的影響，并且不影響業務的正常運作。故障測試內存過載測試[概念]當一個計算機系統的內存占用率為80%~100%時，視為內存過載。[測試目的]內存過載測試主要是測試系統在內存即將用完的時候，系統運行的可靠性。[故障產生原因]（1）大流量沖擊（2）內存丟失（3）算法缺陷，需要占用大量內存[故障可能產生的后果]（1）復位（2）空轉（3）系統內部數據狀態不一致，即發送消息的模塊和接收消息的模塊狀態不一致。[測試時的故障產生方法]采用內存丟失的辦法實現內存過載。[測試步驟]（1）丟失空閑內存，使內存占用率達到80%，運行一段時間，觀察系統的運行狀態。（2）在前面的基礎上再丟失10%的內存，運行一段時間，觀察系統的運行狀態。（3）把剩余的所有內存全部申請出來丟掉，觀察系統的運行情況。[測試的期望結果]對于一般系統，內存過載時能自動降低業務處理量，如果持續時間過長，復位單板。對于系統，要求能區分是大流量沖擊還是內存丟失造成的內存過載，如果是大流量沖擊造成的過載，應能自動降低業務處理量，如果是內存丟失造成的過載，應能復位單板，但對業務不造成影響。CPU過載測試[概念]當一個計算機系統的CPU占用率達到80%~100%時，稱為CPU過載。[測試目的]CPU過載測試主要是測試系統在高CPU占用率狀態下系統的可靠性情況。[故障產生原因]（1）大流量沖擊（2）算法效率低下，例如在等待某些事件時沒有交出CPU權限[故障可能產生的后果]（1）對實時事件響應不及時（2）影響提供業務的能力[測試時的故障產生方法]創建一個任務，用循環的方式強制消耗掉一部分CPU資源，循環次數可以動態調整，通過調整循環次數可以調整CPU占用率。[測試步驟]（1）創建一個最高優先級的CPU過載測試任務，調整循環次數，使CPU過載，觀察系統的運行情況。（2）降低過載測試任務的優先級，使原來優先級較高的任務可以正常運行，優先級較低的任務受到影響，運行一段時間，觀察系統的運行情況。（3）重復步驟2，使各優先級的任務均受到過過載干擾。[測試的期望結果]CPU過載時應能自動啟動流控，降低業務流量，同時，系統運行的各種業務不應出錯，輸入輸出的各類消息順序保持不變。安全性測試1、SQL注入漏洞檢測SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵后的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟件。檢測的目的是為預防SQL注入漏洞攻擊，而對于SQL注入漏洞攻擊后的檢測，主要是針對審計日志的查看，SQL注入漏洞攻擊成功后，會在WebService和數據庫的審計日志中留下“痕跡”。檢測方法如下：（1）動態SQL檢查動態的SQL語句是一個進行數據庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用于存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，數據庫仍然存在SQL注入漏洞攻擊的危險。（2）有效性校驗如果一個輸入框只可能包括數字，那么要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字符，那就需要設置字符串檢查功能。確保應用程序要檢查以下字符：分號、等號、破折號、括號以及SQL關鍵字。（3）數據表檢查使用SQL注入漏洞攻擊工具軟件進行SQL注入漏洞攻擊后，都會在數據庫中生成一些臨時表。通過查看數據庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。（4）審計日志檢查在Web服務器中如果啟用了審計日志功能，則WebService審計日志會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件（存在SQL注入點的動態網頁），審計日志文件會急劇增加，通過查看審計日志文件的大小以及審計日志文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件；另外還可以通過查看數據庫審計日志，查詢某個時間段是否有非法的插入、修改、刪除操作。（5）其他SQL注入漏洞攻擊成功后，入侵者往往會添加特權用戶（如：administrator、root、sa等）、開放非法的遠程服務以及安裝木馬后門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。SQL注入攻擊源于英文“SQLInjectionAttack”。微軟技術中心從兩個方面對SQL注入攻擊進行了描述：一是腳本注入式的攻擊；二是惡意用戶輸入用來影響被執行的SQL腳本。StephenKost對這種攻擊形式的描述是“從一個數據庫獲得未經授權的訪問和直接檢索”。SQL注入就其本質而言，是利用SQL語法，對應用程序中的漏洞的攻擊。當攻擊者能夠操縱數據，在應用程序中插入一些SQL語句時，SQL注入攻擊就發生了。理論上，這種攻擊對于所有基于SQL語言標準的數據庫軟件都是有效的，包括MSSQLServer，Oracle，DB2，Sybase，MySQL等。特別是現在一些AQL注入攻擊工具的出現，使得Web應用更易遭到SQL注入攻擊。原始的手工測試不適用于大型Web應用程序，可使用N-Stealth、WebInspect、WiktoWebScarab、Nikto等工具進行掃描，測試系統是否存在SQL注入的安全漏洞。為防止SQL注入，程序員編寫代碼時，要對客戶端和服務端進行兩級檢查。檢查數據類型、數據長度和敏感字符的合法性。客戶端檢查可減少網絡流量，降低服務器負荷，將一般誤操作、低等級攻擊與高等級攻擊行為區分開來。對于繞開客戶端檢查的攻擊，提交的數據被直接發往服務端，服務端檢查到的提交異常基本可以認定為惡意攻擊行為所致，就應中止提交信息的處理，進行攻擊備案，并對客戶端給出出錯或警告提示。另外，在構造查詢時，應根據用戶輸入的內容設置參數值來創建參數化查詢，從而避免SQL注入及由此帶來的安全問題。2、表單漏洞檢測⑴表單數據提交測試。對表單數據提交的測試，主要檢查程序中是否對表單所提交數據的完整性、正確性進行了驗證（如果在頁面部分進行驗證的話），如：查詢條件輸入一些特殊字符，比如“--”，“‘，，’”，““”等會使查詢的SQL語句出錯檢查程序中是否屏蔽了表單提交的html語句、VBScript和Jscript等客戶端腳本語句檢查是否會出現“腳本利用”問題檢查程序是否對表單域長度進行了真正的限制檢查是否存在重復提交數據的問題檢查這些驗證是否在服務器端進行對表單提交數據的測試，可以采用手工和編寫可重復使用的腳本代碼相結合的方法，進行邊界值測試、等價類測試，以及異常類測試。編寫的腳本代碼可以在測試、回歸測試時運行。若在測試中發現數據完整性、正確性驗證只是在客戶端進行，應在服務器端增加對表單提交數據的驗證，防止出現本地提交表單的漏洞。⑵本地提交表單的漏洞測試。本地提交表單的漏洞容易受到參數篡改的攻擊。這類測試可用手工的方式進行。對于如下用戶注冊頁面：Cookie欺騙監測如果系統使用了cookie，就要對cookie的使用情況進行檢測。檢查Cookies在生存期內能否正常工作而且對這些信息是否加密，是否按預定的時間進行保存，是否存在cookie可被偽造提交的問題，刷新對Cookie有什么影響及過期處理等。用戶身份驗證檢測測試有效和無效的用戶名和密碼，測試是否大小寫敏感，是否有最大字符數的限制規則等。測試重試次數的限制，如果登錄失敗的次數超過允許值，應用程序將會做出何種反應（譬如拒絕此IP地址在短時間內的登錄）。測試是否可以利用歷史登錄信息或以前的URL來繞開登錄程序。測試執行添加、刪除、修改等動作中是否需要登錄操作，退出系統之后的操作是否仍可繼續等。測試用戶密碼是否符合指定要求（字符、長度），如果不符合，對有什么影響，新用戶自己修改密碼后，創建時分配的密碼是否會失效。測試用戶賬戶過期后，是否完全、正確的刪除其信息或使其失效。是否存在不驗證而直接進入Web應用系統的問題，是否存在不登錄就可查看非會員頁面和權限問題。用戶身份驗證測試一般使用手工和測試工具相結法的方法，若在測試中發現問題，應及時修改代碼，使用加密碼算法對密碼加密，采用Session對象進行登錄驗證。文件操作漏洞檢測測試系統是否允許上傳腳本文件、可執行文件等有可能給系統帶來危害的文件。若有下載功能，可供下載的文件是否與系統的程序分別存放，是否存在數據庫文件、包含文件和頁面文件下載的可能。文件操作漏洞測試一般使用手工測試的方法，若發現問題，應及時修改代碼并將可供