集成測試是為了構建一個更大的系統或平台，這個系統的幾個部分通常是由不同的團隊或甚至不同的公司開發的，以前在做信息化的軟件開發時，面臨的集成測試通常是不同軟件子系統之間的集成測試，往往被這一階段的測試搞得人仰馬翻的，在從事了四年的視頻監控和GPS軟件開發之后，才知道，軟硬件系統之間的集成測試更加折磨人的脆弱的神經。雖然兩者本質上都是一樣，軟硬件系統集成實際上是嵌入式軟件系統和常規的PC軟件系統直接的集成。集成測試常常成為壓垮復雜項目的最后一根稻草。主要存在的問題如下：
1.嵌入式軟件開發團隊和常規的軟件開發團隊，風格差別很大，從開發語言和技術，到思考處理問題的方式都有很大區別。從一開始，如何保證兩個團隊之間的充分溝通並相互信任是個問題，團隊之間互相推諉，不擔當的情況常常發生；
2.系統集成必然基於同一個約定，如軟件接口，通信協議或規約，如果是第一次的合作開發，那么如何制定並保證接口和通信規約的穩定性，這個其實很難除非是我們都遵循成熟的國家標准或通用行業標准，如GPS通信協議JT/T808標准，否則研發初始自制的API和協議都是簡單甚至是弱智的，隨着軟件開發的深入，對於功能和需求理解的越來越透徹，接口和協議不斷的膨脹和變化，這種變化是那個團隊發起的，如何和另一個團隊進行協商，對於另外一個團隊是否可行，在嵌入式系統上增加一個功能和在后端平台上增加一個功能所面臨的的難度是一個天上一個地下，如何及時的固化到文檔中去，如何制定一個合理有效的協商機制，都是在項目初始要確定下來的。
3.兩個團隊往往是並行開發，因為同屬於一個大系統，所以有一個共同的項目計划和進度，大家在竭力完成自己的任務的時候，往往顧不得那邊的情況，在節點匯合的時候，大家都聲稱自己完成了計划上的任務，開始測試了，實際情況是大家根本沒有准備好，各自的單元測試和功能測試，進行的非常不充分，而留給雙方共同的集成測試時間又非常的樂觀。沒有充分測試過的子系統在進行集成測試的時候，必然會暴露大量的問題，雖然這顯得集成測試很必要，但是這些問題暴露的有點晚了，再返工修改，Rework的工作量很大，進度更加吃緊，而且有些問題本來可以避免掉，無須拿到成本昂貴的集成測試上進行。
4.集成測試並不意味着測試更充分或者覆蓋面加大，我們拿到一個硬件系統，並不能像軟件一樣可以隨心所欲的制造出一個有效用例來並且進行大量重復使用，例如要測試一個GPS軟件的超速報警的功能，那測試用例設計時，必須要創造出一個車輛超速的動作環境，並觸發終端報警上傳到軟件平台，這樣一個用例還需要能夠供測試人員反復調用。其他還有很多復雜的測試，如視頻監控功能等測試。
5.壓力不夠。由於測試環境的搭建，都是基本單一的軟硬件對測，再加上硬件測試環境搭建的成本和復雜性，難以模擬出真實大規模業務並發的環境，造成壓力測試不夠，很多都是測試人員騙領導，走走過場，真實的問題往往最后在上線后，接入大規模業務時出現。
如何能夠做好軟硬件集成測試呢?
1.多個開發團隊要選擇一些邏輯清晰有擔當、能溝通的人來充當聯絡人，這個雖然有點滑稽，但是在出問題的時候，起的作用很大，沒有邏輯，不敢擔當的人，總是死咬着一句話，"我這邊沒問題"。出了問題不可怕，為什么要推諉老是找借口呢? 耽誤其他團隊時間，浪費口舌。
2.及早Mock, 模擬測試可以讓我們在單元測試階段，就可以進行便利的接口調用，保證我們的測試路徑和測試面的充分覆蓋，只不過硬件的Mock難度比較大，有一定的開發工作量。例如在GPS軟件開發的時候，我們需要開發一個完整的GPS模擬終端，模擬GPS終端的數據發送和接收各種指令並進行應答的行為。很多人不用模擬終端，是因為開發一個完整808協議的模擬終端，實現錄音、拍照、參數設置、媒體檢索等Mock功能，沒有一兩個月搞不定。硬件測試的時候，也需要不斷的檢測自己的硬件發送的數據或指令是否正確，也需要Mock一個后端服務器來進行檢驗。
3.集成測試的用例設計起來，往往貫穿終端、無線網絡、服務器軟件、PC客戶端軟件，是一個復雜的流程測試，所以對於用例設計的是否充分，需要花點時間進行評審和討論理解。這種測試用例，應當及早設計，成為照亮各個開發團隊行進道路的航標。
4.充分估計測試的工作量，上面說到測試用例的設計，如果認真設計用例，這個測試的工作量其實很大。不要為了項目計划而壓縮集成測試的周期。
總之，不要埋地雷，沒有僥幸，問題總是會出現的，何不讓它出現的早一點，代價小一點。
GPS部標監控平台的功能設計(二)-部標808模擬終端功能列表：
1.完整實現了808協議的全部命令，包括媒體檢索、錄音、拍照、區域設置、行車記錄儀等命令；
2.日志記錄，分為原始報文記錄，下發命令和應答跟蹤記錄等詳細記錄；
3.應答數據入庫，GPS數據入庫，便於查詢和跟蹤。
4.轉發服務，可以轉發到其他平台進行跟蹤；
5.在線連接監控；
6.GPS數據分析，油量、里程、停車、報警入庫。