第三方模擬測試環境的搭建

摘要： 應用軟件與第三方實時通訊時，由于開發進度以及通訊條件的限制，需要模擬第三方的通訊程序，以利測試和維護。本文就此發表自己的一些觀點。
　　關鍵詞：中間業務 模擬測試環境 server daemon、client daemon
　　近年來我一直從事中間業務軟件的開發與維護，所謂中間業務，就是銀行作為中間人、代理人的角色幫客戶和第三方委托單位辦理的一些業務，比如各種話費代收、保險費代繳、水費代收等等。開發中間業務軟件，難點在于銀行方要與第三方（電信局等委托單位，以下簡稱第三方）實時交換數據，而銀行與第三方的軟件開發往往不是同一個軟件公司承擔，從而導致需求分析、接口定義的不一致性、復雜性，并且雙方技術力量的不同經常導致開發進度的不一致，我行為保證開發進度以及軟件質量，往往需要為第三方搭建一個模擬測試環境。以下是我在組建模擬測試環境的實踐中總結的一些經驗和方法。
　　模擬環境要能夠較為全面地模擬出第三方系統所能夠實現的功能，從總體上來說，所有的交易可劃分為兩大塊：由我方發起的交易和由對方發起的交易；為此在模擬機上要建立相應的模擬server 程序和模擬client 程序，server程序接收我方發起的交易而client程序發起對方的交易；
　　模擬環境一般只模擬到對方的前置機一級，因為我方與對方系統要交換的只有請求報文和響應報文，至于各自系統中對每筆交易的帳務處理和流程對對方都是透明的。當然模擬環境也必須模擬到前置機一級，否則請求報文還沒送到對方就被返回，根本沒有測試到我方相關的通訊子程序，實際聯調的時候還須先解決通訊中可能存在的問題，就沒有起到模擬第三方的作用了。
　　雙方通訊采用標準的tcp/ip協議，報文交換則可有幾種不同的方法，我們采用的主要有ISO8583國際標準包協議和自定義字符串方式兩種，建議在對方允許的情況下盡量采用ISO8583包格式，既可減少通訊量又可利用統一的打包、解包函數。聯系前面提到的server 和client 服務，則模擬前置機上可能用到的程序共有以下四個：采用ISO8583報文交換的server程序 和client程序 ，以及采用自定義字符串方式交換報文的server程序和client 程序。當然，針對某個特定的委托單位只會用到其中的一對程序。一般來說，server 程序要常駐內存，它接收請求然后返回模擬的響應報文，因為沒有實際的第三方數據庫可供檢索和處理，server程序只能簡單地根據不同的請求類型返回相對固定的響應數據，例如，對所有的用戶的話費查詢，server程序只能返回同樣的話費余額和明細，當然，不同類型的請求報文返回的響應報文還是不一樣的。如果時間充裕，還可以把server的功能做得盡可能完善：對接收到的請求報文格式作合法性檢查，對每一種交易都可以有成功與失敗兩種返回結果，甚至考慮每一種交易的可能的自動沖正報文，等等；client 程序則做成一般的執行程序，每向我方前置機發起一個交易后即退出運行。client 程序應能模擬第三方發起的每種交易，并接收相應的返回。client 程序還應模擬第三方的可能的錯誤報文，以檢驗我方通訊程序能否正常處理。
　　在確定了通訊協議和報文交換格式之后，對每一個交易，還存在一個長聯接和短聯接的問題：發起方發起請求后是一直保持原來的聯接等待對方的響應呢還是立即斷鏈，等對方取得響應報文后由對方重新建立新的聯接？若采用前一種實現方法則稱為長聯接，實現起來較為簡單，且可靠性較高，比較適合于業務量較小且對方業務處理延遲較小的單位和場合，長聯接的缺點是不能緩沖請求報文與響應報文，當交易高峰期很多請求差不多同時到達的時候會拒絕一些請求，從而影響到業務的辦理。短聯接則不同，一般短聯接都會在內存中建立兩個消息隊列，一個存放所有到達的請求報文，另一個存放所有收到的響應報文；對應每一個消息對列，有一個daemon 進程（即常駐后臺運行的程序）專門處理其中的每一個報文，這樣就把發起請求后等待響應報文的時間去掉了（這部分時間包括對方業務處理的時間和返回的傳送時間，一般占整個交易時間的80%以上），請求daemon只管不停的把請求隊列中的請求報文發出去，不需要等待任何一個響應報文的返回，而響應daemon 則專門處理收到的響應報文；這里要特別注意的是，由于業務處理系統的并發處理機制，發出去的請求報文順序與接收到的響應報文順序不一定相同，因而要確定一種請求報文與響應報文之間的連接方式，一般考慮用報文中某個唯一字段如主機流水號來建立兩者之間的一一對應，以免造?quot;張冠李戴"，即把后一個交易的響應報文作為前一個交易的響應返回給前臺；當然短聯接也有其缺點：對消息隊列的管理不當有可能導致響應報文嚴重超時，例如第三方數據庫down下來了，把所有的請求報文緩沖起來，等幾分鐘或幾十分鐘后數據庫恢復正常，再對緩沖的請求報文進行處理，事實上此時的處理已經無效，因為發起請求的前端早就對此筆交易作超時處理，不需要它的返回報文了。
　　下面簡單介紹一下以socket編程的server程序和client 程序的一般處理流程：
server端：
1、通過socket（）函數向系統申請一個套接字；
　　一般用法： socket(AF_INET , SOCK_STREAM , 0 ) ;
　　其中AF_INET SOCK_STREAM 為系統定義的常量，指明了所需套接字的用途。
2、調用 bind（）函數為該次通訊定義一個偵聽端口號
3、調用 listen（）函數偵聽可能的請求
4、組織循環，處理收到的每一筆請求：
4、1 用aclearcase/" target="_blank" >ccept（）函數建立交換數據的通道；
4、2 用read（）函數讀取請求報文
4、3 根據請求報文進行業務處理，形成響應報文
4、4 調用write（）函數返回響應報文
4、5 調用close（）函數關掉套接字
client端：
1、通過socket（）函數向系統申請一個套接字；
2、調用 connect（）函數與server 端建立連接
3、調用 write（） 函數發出請求報文
4、調用 read（）函數讀取響應報文
5、調用 close（）函數關掉套接字
　　總之，第三方模擬測試環境的建立不僅有效的減少了合作雙方的摩擦，提高了我方應用系統的開發進度，而且極大的方便了整個應用系統的聯調，并且在系統運行、維護、優化等過程中也發揮了巨大的作用。

原文轉自：http://www.anti-gravitydesign.com