1. 如何驗證軟體的數字簽名
下載安裝PDF閱讀器 Acrobat Reader
安裝好後用該閱讀器打開PDF文檔，此時可以看到數字簽名的提示框。，黑色（藍色）代表已經驗證過的數字簽名，是可信有效的。
綠色代表未驗證但有效的數字簽名。
紅色表示數字簽名無效（可能是文檔被篡改，也可能是數字證書過期，具體會有提示）
黃色表示數字證書不被Adobe公司信任。（可能是軟體沒有更新合作商。也可能是該證書是簽名人自己製作的，而不是由第三方可信機構頒發的）有些簽名證書由於提前集成在微軟發布的Windows各類系統中，但卻沒有集成在Adobe公司的各類軟體中，所以必須調用Windows集成後才會起作用，否則也可能看到是黃色提示。
那麼預先集成在Windows中的證書怎麼被調用，點擊Adobe Acrobat Reader 軟體的「編輯」——「首選項」
點擊「簽名」——「驗證~更多」
勾選 「Windows集成」中的兩個復選框即可。重新打開文檔，看看如果還是黃色，那就說明這個證書不被信任，請聯系簽名人進行核實。
2. 關於軟體測試：結合測試時需要驗證資料庫數據嗎
你的想法是正確的。不需要再去驗證了。我以前沒考慮過這事。希望高級專業人員給您詳細的解答。
3. 軟體開發資料庫如何進行測試
比如：數據冗餘，功能和性能方面存在的問題已經嚴重影響應用軟體的使用。軟體測試人員往往重視對軟體功能和編碼的測試，而忽略對軟體性能，特別是資料庫訪問並發測試。因為，他們固有的思想中認為資料庫設計存在問題對系統性能影響不大，或從根本上忽略了資料庫在軟體開發中的地位，直到出現了問題，才想到對資料庫的測試，但往往也是僅僅通過對編碼的測試工作中捎帶對資料庫進行一定的測試，這遠遠是不夠的。目前，中鐵網上訂票系統在大用戶同時在線訂票中系統頻頻癱瘓，就是最好的佐證。 所以，在應用軟體的測試工作中，應該將資料庫作為一個獨立的部分進行充分的測試，這樣才可以得到應用軟體所需要的性能優化的資料庫。那麼，應該對哪些內容進行測試，如何進行測試呢？ 2、資料庫設計的測試 資料庫是應用的基礎，其性能直接影響應用軟體的性能。為了使資料庫具有較好的性能，需要對資料庫中的表進行規范化設計。規范化的範式可分為第一範式、第二範式、第三範式、BCNF範式、第四範式和第五範式。一般來說，邏輯資料庫設計應滿足第三範式的要求，這是因為滿足第三範式的表結構容易維護，且基本滿足實際應用的要求。因此，實際應用中一般都按照第三範式的標准進行規范化。但是，規范化也有缺點：由於將一個表拆分成為多個表，在查詢時需要多表連接，降低了查詢速度。故資料庫設計的測試包括前期需求分析產生資料庫邏輯模型和後期業務系統開發中的測試兩部分（這里指的是後者），我在這里稱為實體測試。 資料庫是由若乾的實體組成的，包括（表，視圖，存儲過程等），資料庫最基本的測試就是實體測試，通過對這些實體的測試，可以發現資料庫實體設計得是否充分，是否有遺漏，每個實體的內容是否全面，擴展性如何。 實體測試，可以用來發現應用軟體在功能上存在的不足，也可以發現數據冗餘的問題。經過測試，測試人員對有異議的問題要及時和資料庫的設計人員進行溝通解決。 3、數據一致性測試 在進行實體測試後，應進一步檢查下面的內容以保障數據的一致性： 3.1 表的主鍵測試根據應用系統的實際需求，對每個表的主鍵進行測試，驗證是否存在記錄不唯一的情況，如果有，則要重新設置主鍵，使表中記錄唯一。 3.2 表之間主外鍵關系的測試資料庫中主外鍵欄位在名稱，數據類型，欄位長度上的一致性測試。 3.3 級聯表，刪除主表數據後，相應從報表數據應同時刪除的問題例如學生表和學生成績表，學生數據已經刪除，成績表中相應學生的成績記錄應同時刪除。 3.4 存儲過程和觸發器的測試存儲過程可以人工執行，但觸發器不能人工處理，所以在對存儲過程和觸發器執行的過程中針對SQL SERVER2005及以上版本可以使用Microsoft SQL Server Profiler性能測試工具進行測試。 Microsoft SQL Server Profiler 是 SQL 跟蹤的圖形用戶界面，用於監視資料庫引擎或 Analysis Services 的實例。測試人員可以捕獲有關每個事件的數據並將其保存到文件或表中供以後分析。例如：可以對生產環境進行監視，了解哪些存儲過程由於執行速度太慢影響了性能。 4、資料庫的容量測試 隨著資料庫系統的使用，數據量在飛速增長，如何在使用前對數據容量的增長情況進行初步估算，為最終用戶提供參考，這在資料庫使用和維護過程中，是非常重要的。可以通過對資料庫設計中基本表的數據大小，和每天數據表的數據產生量進行初步估算。 記錄數據量=各個欄位所佔位元組數的總和表的數據量=記錄數據量*記錄數資料庫大小=各表數據量的總和 當然，資料庫的大小不僅僅只是基本表的大小，還有系統表，視圖，存儲過程等其它實體所佔的容量，但最基本的數據是表的數據。另外，資料庫的容量還包括資料庫日誌文件的容量，一般應預留資料庫文件的2倍左右。 5、資料庫的性能測試 應用軟體除了功能外，很重要的一部分就是軟體的性能，而對於資料庫系統，資料庫性能的好壞會直接影響應用軟體的性能，這部分的測試，一般手工測試就顯得無能為力了，這時就要藉助自動化的測試軟體，例如：DataFactory，DataFactory是一種強大的數據產生器，它允許開發人員和測試人員很容易產生百萬行有意義的正確的測試資料庫，該工具支持DB2、Oracle、Sybase、SQL Server資料庫。這樣，就可以模擬出應用軟體長期使用後，海量數據存儲的資料庫的性能狀況。從而盡早發現問題，進行資料庫性能的優化。 這里要注意，進行性能測試的時候，一定要注意測試環境的一致性，包括：操作系統、應用軟體的版本以及硬體的配置等，而且在進行資料庫方面的測試的時候一定要注意資料庫的記錄數、配置等要一致，只有在相同條件下進行測試，才可以對結果進行比較。否則無法和用戶對軟體的性能的觀點達成一致。 6、資料庫的壓力測試 說起測試，我們首先想到的就是軟體正確性的測試，即常說的功能測試。軟體功能正確僅是軟體質量合格指標之一。在實際開發中，還有其它的非功能因素也起著決定性的因素，例如軟體的響應速度。影響軟體響應速度的因素有很多，有些是因為演算法不夠高效；還有些可能受用戶並發數的影響。 在眾多類型的軟體測試中，壓力測試正是以軟體響應速度為測試目標，尤其是針對在較短時間內大量並發用戶的訪問時，軟體的抗壓能力。但壓力測試往往是手工難以測試的，必須藉助自動化測試工具。常用的壓力測試有：Web測試、資料庫測試等。 資料庫在大多數軟體項目中是不可缺少的，對於它進行壓力測試是為了找出資料庫對象是否可以有效地承受來自多個用戶的並發訪問。這些對象主要是：索引、觸發器、存儲過程和鎖。通過對SQL語句和存儲過程的測試，自動化的壓力測試工具可以間接的反應資料庫對象是否需要優化。 這些自動化的測試工具很多，各有特點，基於Java的項目可以使用JMeter，.Net項目可以採用.Net集成開發環境中提供的測試方案。 7、結束語 總之，在應用系統的測試中，把資料庫應當作為獨立的系統來測試，這無疑會為應用軟體的質量增加可靠的保障，同時還必須結合應用軟體進行集成測試，只有二者有機結合起來，才能最大限度的發揮資料庫和應用軟體的功能。
4. 集成測試 VS 系統測試
集成測試位於產品研發流程的開發階段，所謂的集成就是為不斷開發功能並將功能集成到系統中，最後完成整改系統的開發過程。
實際中，即為開發者按照計劃，完成本build計劃要集成到系統的功能開發後，需要通過單元測試來測試功能的正確性，測試通過後，開發者將功能集成起來，構成系統（這個過程也叫聯調）。構成完成之後的測試，就是集成測試。
在實際工作中，時常有下列情況發生：每個模塊都能獨立工作，但這些模塊集成在一起後就不能正常工作，主要原因是模塊在相互調用的時候，介面引入了許多新問題，如一個模塊對另一個模塊造成了不應有的影響或數據經過介面時丟失；幾個子功能組合起來不能實現主功能；單個模塊可以接受的誤差，組裝起來之後，則達到了不可接受的程度。因此有必要在單元測試完成之後進行一次集成測試。
集成測試主要是測試軟體單元的組合是否正常工作以及與其他組的模塊能否集成起來工作，最後還要測試構成系統的所有模塊組合是否能正常工作，其主要測試參考標準是《軟體概要設計規格說明書》，任何不符合該說明的程序模塊行為都需要記錄上報。
集成測試是單元測試的邏輯擴展。其中單元測試是為了測試新開發的功能和模塊是否符合設計，是白盒測試，使用內部介面進行測試。而集成測試相當於驗證新合入的功能能否在系統中被正確裝配起來，是黑盒測試。也是系統級的測試，應該使用系統提供給用戶的輸入介面來進行測試，使用提供給用戶的輸出介面來判斷介面的正確性。其主要測試內容包括：
• 使用黑盒測試方法來確認新合入的功能是否正確
• 驗證功能集成後系統功能的正確性（功能是我們想要的那個功能）
• 確認原來的系統功能沒有被新合入的功能破壞。
進行集成測試的准入條件為第一個集成計劃中的功能開發完成，並完成了單元測試，第一個集成計劃中的功能集成完成，並可測（開發需要提供基於用戶的輸入輸出介面，而不是內部的函數介面）。其出口規則為系統需要集成的功能已經全部開放、集成完成。計劃執行的用例全部完成，缺陷分析的結果符合預期。
進行集成測試的准入條件為第一個集成計劃中的功能開發完成，並完成了單元測試，第一個集成計劃中的功能集成完成，並可測（開發需要提供基於用戶的輸入輸出介面，而不是內部的函數介面）。其出口規則為系統需要集成的功能已經全部開放、集成完成。計劃執行的用例全部完成，缺陷分析的結果符合預期。
集成測試是灰色地帶，做好該測試需要遵循一些原則：
• 所有公共介面都要被測試到
• 關鍵模塊都必須進行充分測試
• 介面發生修改時，涉及的相關介面必須再測試
• 模塊與介面的劃分，應理清
由於集成測試主要是測試軟體的結構問題，測試建立在模塊的介面上，所以多採用黑盒測試技術，適當輔以白盒測試技術。具體測試內容應包括以下幾個方面：
功能測試：程序單元或模塊之間的介面測試（數據在通過介面時是否會出現丟失、關聯模塊間正確傳輸數據、介面的可靠性）、程序功能測試（組合後是否滿足設計需求）、模塊間影響（一個模塊是否對另一個模塊產生不利影響）
可靠性測試
易用性測試
性能測試
由於集成測試是驗證組成軟體系統各模塊正確的介面和交互作用。執行集成測試應遵循如下的方法：
• 首先，確認組成一個完整系統的模塊之間的關系
• 理清模塊之間的交互和通信要求
• 構造測試數據
• 使用所謂的增量式測試方法，即依次將模塊加入到系統，並測試新合並後的系統，這個過程以一個邏輯或功能順序重復進行，直至所有模塊被功能集成進來形成完整的系統為止。
一種增量式測試方法為從頂向下逐步集成和逐步測試。即模塊集成的順序是首先集成主控模塊，然後按照軟體控制層次結構向下集成，從屬於主控模塊的模塊按深度優先策略或廣度優先測試逐步集成到結構中去，如
採用深度優先策略是首先將模塊M1,M2,M5和M8集成在一起，然後考慮集成中間的M3和M7，最後集成右邊的M4。廣度優先策略是集成沿著水平方向，首先集成M2,M3,M4，再將M5,M6,M7集成在一起，最後集成最底層的M8。做集成測試過程由以下3個步驟完成：
1. 將主控模塊作為測試驅動器，把對主控模塊進行單元測試時引入的被調用模擬子模塊用實際模塊替代。
2. 依據所選用的模塊集成策略，下層被調用的模擬子模塊一次一個地被替換為真正的模塊。
3. 在每個模塊被集成時，都必須進行測試，重復2步驟，直到整個結構被集成完成。
集成測試主要還是針對功能的基礎，在集成測試中還沒有對其他非功能方面的質量進行驗證，即只通過集成測試無法對系統進行全面的測試，這時系統測試時就非常有必要，在系統測試中需要測試的內容包括：
• 從系統角度來驗證測試功能的正確性
• 從系統角度來驗證各種非功能的質量的正確性
這是因為集成測試只關注新開發的功能，容易忽視對系統其他反應的判斷，而且隨著功能的不斷集成，系統的復雜性急劇膨脹，要考慮將和功能相關的所有組合都驗證完（作為計算機系統的一個重要組成部分，與計算機硬體、外設、某些支撐軟體的系統等其他系統元素組合在一起所進行的測試，以驗證軟體系統的正確性和性能是否滿足需求分析的要求）。
軟體開發過程中，開發人員通常需要將軟體的需求文檔轉化為軟體的概要設計文檔。在該文檔中通常會指明各個模塊間的介面。集成測試就是為了驗證各個模塊間的介面關系。單元測試階段，測試人員主要工作是對軟體詳細設計文檔的驗證；系統測試階段，測試人員主要是對產品需求規格說明書進行驗證（驗證軟體功能與用戶要求的一致性）。
系統測試完全是黑盒測試，不需要考慮組件模塊間的實現細節，主要根據需求分析時確定的標准檢驗軟體是否滿足功能、行為、性能和系統協調性等方面的要求。
系統測試的對象不僅僅是需要測試的軟體系統，還包括所依賴的硬體、外設甚至是某些數據、支撐軟體等，因此需要將系統中的軟體和各種依賴的資源結合起來，在實際運行環境下進行測試，為充分運行系統，系統測試階段應包含以下幾個測試項：
功能測試：測試產品的各項功能的正確性，以及驗證產品的各項功能是否與產品需求規格說明書描述的一致。
性能測試：測試產品各項性能是否達標
壓力測試：在一定負荷的長期使用環境下，測試系統的可靠穩定性
兼容性測試：兼容性描述
安裝測試：指測試軟體在各種軟硬體環境組合下是否能正常的進行安裝、卸載。包括在取消安裝時回滾操作是否徹底、安裝過程中出現異常（斷電、系統崩潰），待到系統重啟之後軟體產品是否可以重新安裝。
安全測試：檢查系統對非法侵入行為的防範能力，就是設置以下企圖突破系統安全保密措施的測試用例，檢查系統是否有安全漏洞。
因為系統測試的主要目標是樹立軟體系統將通過驗收測試的信心，因此系統測試所用的數據必須盡可能像真實數據一樣在復雜性、精度和數據量盡可能地和實際數據相當。
5. 關於集成測試，我想了解一下
集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的介面。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有 集成測試
進程。 集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。 集成測試是在單元測試的基礎上，測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那麼集成測試的效果將會受到很大影響，並且會大幅增加軟體單元代碼糾錯的代價。 集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。集成測試採用的方法是測試軟體單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最後，還要測試構成系統的所有模塊組合能否正常工作。集成測試所持的主要標準是《軟體概要設計規格說明》，任何不符合該說明的程序模塊行為都應該加以記載並上報。 所有的軟體項目都不能擺脫系統集成這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟體單元做起，軟體單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中 集成測試
，幾乎不存在軟體單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。 集成測試的必要性還在於一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種情況下，集成測試的意義還在於它能間接地驗證概要設計是否具有可行性。
方法
集成測試應該考慮以下問題： 1、在把各個模塊連接起來的時候，穿越模塊介面的數據是否會丟失； 2、各個子功能組合起來，能否達到預期要求的父功能； 3、一個模塊的功能是否會對另一個模塊的功能產生不利的影響； 4、全局數據結構是否有問題； 5、單個模塊的誤差積累起來，是否會放大，從而達到不 集成測試
可接受的程度。 因此，單元測試後，有必要進行集成測試，發現並排除在模塊連接中可能發生的上述問題，最終構成要求的軟體子系統或系統。對子系統，集成測試也叫部件測試。 任何合理地組織集成測試，即選擇什麼方式把模塊組裝起來形成一個可運行的系統,直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。
實施
集成測試是一種正規測試過程，必須精心計劃，並與單元測試的完成時間協調起來。在制定測試計劃時，應考慮如下因素： 1、是採用何種系統組裝方法來進行組裝測試； 2、組裝測試過程中連接各個模塊的順序； 3、模塊代碼編制和測試進度是否與組裝測試的順序一致 4、測試過程中是否需要專門的硬體設備； 解決了上述問題之後，就可以列出各個模塊的編制、測 集成測試
試計劃表，標明每個模塊單元測試完成的日期、首次集成測試的日期、集成測試全部完成的日期、以及需要的測試用例和所期望的測試結果。 在缺少軟體測試所需要的硬體設備時，應檢查該硬體的交付日期是否與集成測試計劃一致。例如，若測試需要數字化儀和繪圖儀，則相應測試應安排在這些設備能夠投入使用之時，並需要為硬體的安裝和交付使用保留一段時間，以留下時間餘量。此外，在測試計劃中需要考慮測試所需軟體（驅動模塊、樁模塊、測試用例生成程序等）的准備情況。
完成標准
怎樣判定集成測試過程完成了, 可按以下幾個方面檢查: 1、成功地執行了測試計劃中規定的所有集成測試； 2、修正了所發現的錯誤； 3、測試結果通過了專門小組的評審。 集成測試應由專門的測試小組來進行，測試小組由有經驗的系統設計人員和程序員組成。整個測試活動要在評審人員出席的情況下進行。 在完成預定的組裝測試工作之後，測試小組應負責對測試結果進行整理、分析，形成測試報告。測試報告中要記錄實際的測試結果、在測試中發現的問題、解決這些問題的方法以及解決之後再次測試的結果。此外還應提出目前不能解決、還需要管理人員和開發人員注意的一些問題，提供測試評審和最終決策，以提出處理意見。
目的
是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。它所測試的內容包括單元間的介面以及集成後的功能。使用黑盒測試方法測試集成的功能。並且對以前的集成進行回歸測試。
綜述
集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基於使用的集成測試等。在此，筆者將重點討論其中一些經實踐檢驗和一些證實有效的集成測試方案。
自頂向下集成測試
自頂向下集成（Top-Down Integration）方式是一個遞增的組裝軟體結構的方法。從主控模塊（主程序）開始沿控制層向下移動，把模塊一一組合起來。分兩種方法： 第一：先深度：按照結構，用一條主控制路徑將所有模塊組合起來； 第二：先寬度：逐層組合所有下屬模塊，在每一層水平地 集成測試
沿著移動。 組裝過程分以下五個步驟： 步驟一：用主控模塊作為測試驅動程序，其直接下屬模塊用承接模塊來代替； 步驟二：根據所選擇的集成測試法（先深度或先寬度），每次用實際模塊代替下屬的承接模塊 步驟三：在組合每個實際模塊時都要進行測試； 步驟四：完成一組測試後再用一個實際模塊代替另一個承接模塊； 步驟五：可以進行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。
自底向上集成測試
自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程序模塊結構中最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝的，對於一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經完成組裝並經過測試，所以不再需要編制樁模塊（一種能模擬真實模塊，給待測模塊提供調用介面或數據的測試用軟體模塊）。自底向上集成測試的步驟大致如下: 步驟一: 按照概要設計規格說明，明確有哪些被測模塊。在熟悉被測模塊性質的基礎上對被測模塊進行分層，在同一層次上的測試可以並行進行，然後排出測試活動的先後關系，制定測試進度計劃。圖2給出了自底向上的集成測試過程中各測試活動的拓撲關系。利用圖論的相關知識，可以排出各活動之間的時間序列關系，處於同一層次的測試活動可以同時進行，而不會相互影響。 步驟二: 在步驟一的基礎上，按時間線序關系，將軟體單元集成為模塊，並測試在集成過程中出現的問題。這里，可能需要測試人員開發一些驅動模塊來驅動集成活動中形成的被測模塊。對於比較大的模塊，可以先將其中的某幾個軟體單元集成為子模塊，然後再集成為一個較大的模塊。 步驟三: 將各軟體模塊集成為子系統（或分系統）。檢測各自子系統是否能正常工作。同樣，可能需要測試人員開發少量的驅動模塊來驅動被測子系統。 步驟四: 將各子系統集成為最終用戶系統，測試是否存在各分系統能否在最終用戶系統中正常工作。 方案點評: 自底向上的集成測試方案是工程實踐中最常用的測試方法。相關技術也較為成熟。它的優點很明顯: 管理方便、測試人員能較好地鎖定軟體故障所在位置。但它對於某些開發模式不適用，如使用XP開發方法，它會要求測試人員在全部軟體單元實現之前完成核心軟體部件的集成測試。盡管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。
核心系統先行集成測試
核心系統先行集成測試法的思想是先對核心軟體部件進行集成測試，在測試通過的基礎上再按各外圍軟體部件的重要程度逐個集成到核心系統中。每次加入一個外圍軟體部件都產生一個產品基線，直至最後形成穩定的軟體產品。核心系統先行集成測試法對應的集成過程是一個逐漸趨於閉合的螺旋形曲線，代表產品逐步定型的過程。其步驟如下: 步驟一: 對核心系統中的每個模塊進行單獨的、充分的測試，必要時使用驅動模塊和樁模塊; 步驟二: 對於核心系統中的所有模塊一次性集合到被測系統中，解決集成中出現的各類問題。在核心系統規模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統的各組成模塊。 步驟三: 按照各外圍軟體部件的重要程度以及模塊間的相互制約關系，擬定外圍軟體部件集成到核心系統中的順序方案。方案經評審以後，即可進行外圍軟體部件的集成。 步驟四: 在外圍軟體部件添加到核心系統以前，外圍軟體部件應先完成內部的模塊級集成測試。 步驟五: 按順序不斷加入外圍軟體部件，排除外圍軟體部件集成中出現的問題，形成最終的用戶系統。 方案點評: 該集成測試方法對於快速軟體開發很有效果，適合較復雜系統的集成測試，能保證一些重要的功能和服務的實現。缺點是採用此法的系統一般應能明確區分核心軟體部件和外圍軟體部件，核心軟體部件應具有較高的耦合度，外圍軟體部件內部也應具有較高的耦合度，但各外圍軟體部件之間應具有較低的耦合度。
高頻集成測試
高頻集成測試是指同步於軟體開發過程，每隔一段時間對開發團隊的現有代碼進行一次集成測試。如某些自動化集成測試工具能實現每日深夜對開發團隊的現有代碼進行一次集成測試，然後將測試結果發到各開發人員的電子郵箱中。該集成測試方法頻繁地將新代碼加入到一個已經穩定的基線中，以免集成故障難以發現，同時控制可能出現的基線偏差。使用高頻集成測試需要具備一定的條件: 可以持續獲得一個穩定的增量，並且該增量內部已被驗證沒有問題; 大部分有意義的功能增加可以在一個相對穩定的時間間隔（如每個工作日）內獲得; 測試包和代碼的開發工作必須是並行進行的，並且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本; 必須藉助於使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數頻繁，顯然，人工的方法是不勝任的。 高頻集成測試一般採用如下步驟來完成: 步驟一: 選擇集成測試自動化工具。如很多Java項目採用Junit+Ant方案來實現集成測試的自動化，也有一些商業集成測試工具可供選擇。 步驟二: 設置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。 步驟三: 測試人員和開發人員負責編寫對應程序代碼的測試腳本。 步驟四: 設置自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，並將測試報告匯報給開發人員和測試人員。 步驟五: 測試人員監督代碼開發人員及時關閉不合格項。 按照步驟三至步驟五不斷循環，直至形成最終軟體產品。 方案點評: 該測試方案能在開發過程中及時發現代碼錯誤，能直觀地看到開發團隊的有效工程進度。在此方案中，開發維護源代碼與開發維護軟體測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在於測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。 以上我們介紹了幾種常見的集成測試方案，一般來講，在現代復雜軟體項目集成測試過程中，通常採用核心系統先行集成測試和高頻集成測試相結合的方式進行，自底向上的集成測試方案在採用傳統瀑布式開發模式的軟體項目集成過程中較為常見。讀者應該結合項目的實際工程環境及各測試方案適用的范圍進行合理的選型。
6. 信息技術安全2)如何驗證數據完整性
一種驗證系統數據完整性的方法，包括步驟： 從所述系統數據生成加密密鑰， 使用散列函數從所述加密密鑰生成檢驗數據，和 通過比較生成的檢驗數據和所述檢驗數據的可信任版本來驗證所 述系統數據完整性。