引 言
隨著智慧卡在金融、電信、移動通信、醫療保險、付費電視等領域應用的迅速增長，其可靠性要求越來越高，而針對智慧卡模塊的測試已經成為必不可少的質量保證手段。自動化測試不需要人工幹預，能提高測試效率，受到更多重視和應用。在發展自動化測試的過程中，一個高效的自動化測試平臺是其基本保障。根據智慧卡的應用現狀和市場需求，本設計用TCL語言和C語言聯合編程的方法，以PC／SC為編程接口，實現了智慧卡的測試平臺，能夠對智慧卡進行質量和性能的測試。
1 測試系統結構
具有測試功能的系統結構如圖1所示。測試系統一般由測試平臺、讀／寫器和智慧卡三個部分組成。測試平臺運行測試腳本，並對從智慧卡返回的結果進行處理。智慧卡內部有被測程序，響應測試平臺發來的命令，返回測試數據。讀／寫器提供測試平臺和智慧卡的接口。這裡的研究重點是測試平臺。
2 測試平臺的設計思路
測試平臺軟體由兩個部分組成，即界面程序和通信軟體程序，如圖2所示。界面程序提供一個友好的圖形畫面，接受用戶指令，如腳本輸入，按鈕響應等。界面將用戶的任務轉換為內部指令，然後由通信軟體程序具體實施，而通信軟體程序負責與USB讀卡器通信。下面分別介紹界面程序和通信軟體程序的實現原理。
圖2是測試平臺的軟體結構。
圖３界面程序
2．1 界面程序
界面程序分為三層，頂層為腳本層，用於支持ATP語言。ATP並不是一種全新的語言，是從TCL語言口 擴展而來，針對ATP開闢的命令集，它包括TCL基本命令和應用程式相關的擴展命令。TCL基本指令的使用方法可以參考文獻[1，2]，擴展命令是TCL專門針對智慧卡的測試而擴展的。
中間層是根據應用需求而擴展的TCI 解釋器，它包含TCI 標準庫和與底層接口程序有關的TCL擴展庫。ATP的基本部分由TCL語言解釋器調用TCL標準庫來執行；ATP的擴展部分由擴展的TCL解釋器調用TCL擴展庫執行。
頂層和中間層說明了TCI 即是一種腳本語言也是一個解釋器。底層是接口程序，提供與通信軟體程序的接口，負責發送命令和返回狀態。
圖4顯示了TCI 與應用程式的調用關係。
TCL的標準命令 是TCL自帶的，而與應用程式相關的特殊命令需要用C代碼去擴展，下面詳細介紹如何擴展TCL命令。使用TCL之前，應用程式必須首先創建TCL解釋器創建標準的命令解釋器，然後可以調用Tcl—CreateCommand過程使用用戶自定義命令來擴展解釋器，它的原型是：
Tcl—CreateCom mand (interp，cmdName，proc，cli—entData，deleteProc)其中：interp為創建的解釋器；cmdName為創建的命令名字；proc為與命令相對應的函數；clientData為一個字長的值，通常指向一個專用數據結構；deleteProc為註銷命令的函數名，如果其為空，則在註銷命令前不調用任何函數。調用Tcl—CreateCommand時，擴展命令name就會和name—tcl聯繫起來；執行name命令時，會進入n am e— tcl函數處理name命令。
創建完程序自定義命令後，應用程式進入死循環，等到命令後就傳遞給解釋器。調用Tcl—Eval(interp，script)，通過script的內容知道命令的類型後，選擇在相應的過程函數中進行計算。
通信軟體程序的執行就是在過程函數裡面被調用，這樣就實現了界面程序與通信軟體程序的接口。
2．2 通信軟體程序
通信軟體程序遵循PC／SC規範 。PC／SC規範是由PC／SC工作組提出的。PC／SC工作組是一個主要由智慧卡廠商和計算機廠商組成的委員會，主要成員有微軟、蘋果、雅斯拓、金普斯、英飛凌、菲利普等。PC／SC規範是一個基於Windows平臺的標準用戶接口(API)。它獨立於硬體設備，使得應用程式的開發人員不必考慮由於硬體改變而引起的應用程式變更，從而降低了軟體開發成本。
PC／SC規範包含大量Scard為前綴的API，可以在winscard．h中找到其原型。應用程式需要包含win—scard．1ib，所有函數的正常返回值都是SCARD—S—SUCCESS，在這些函數中常用的只有幾個。與智慧卡的訪問流程如下：
(1)初始化函數中調用SCardEstablishContext，建立資源管理器的上下文，獲得設備的連接句柄，若返回SCARD— S— SUCCESS，則調用成功；調用ScardLis—tReaders獲得系統中安裝的讀卡器列表，調用成功則獲取聯機的讀卡器名字。
(2)在響應函數中調用ScardConnect與卡片建立連接，此時能與卡片通信。
(3)與卡片連接後通過調用SCardTransmit來發送命令，得到由卡片返回的數據。
(4)卡片處於連接狀態時，可以調用SCardRecon—nect函數使卡片復位。
(5)完成了與卡片的命令發收後，調用SCardDis—connect函數斷開與智慧卡的連接。
項目已經實現以上功能的編程接口，而且利用類的方法進行了封裝。
3 測試平臺的使用
3．1 測試流程
腳本的制定還是使用人工方式，測試人員通過測試平臺完成測試。自動化測試不需要人工幹預，縮短了測試時間。因而測試過程採用人工測試和自動化測試相結合的方法進行。
用戶可以編寫測試腳本，快速發送測試命令和收集測試數據，可以單次執行或者循環執行，當滿足終止條件時，腳本執行結束，生成測試報告。圖5為測試流程圖。
3．2 功能測試
測試平臺能夠以APDU為基本單元完成針對智慧卡的功能測試，下面分別對其進行介紹。
3．2．1 測試基本單元
測試平臺與智慧卡通信的基本單元是APDUL9 。應用層以APDU為單位進行有序的數據交換，應用層交換的每一步都以命令應答對組成。APDU 的命令應答對由以下部分組成：
命令APDU 包含一個必備的四字節頭(CLA，INS，P1，P2)和可選的命令體(Lc，Data，Le)。命令頭為命令的編碼，Lc為體內數據(data)長度，Data為發送的數據，Le為應答APDU數據欄位的最大字節數。應答APDU 由可選長度體和兩字節狀態字SW1一SW2組成。其中，體內的字節數由命令APDU 的Le指出。Data為卡片接受命令APDU 後返回的數據。尾部狀態字指出卡的處理狀態。其中，61xx和9000為正常處理，6lxx的含義SW2指出仍然有效的應答字節數，9000代表正常處理。
3．2．2 單元測試
圖5 測試流程圖
同樣，智慧卡內部程序也是以APDU為單位實現的，因此單元測試的對象就是APDU。發送一個APDU給智慧卡，通過智慧卡內部程序執行完後返回狀態字，判斷執行結果的正確與否。命令之間存在著相互依賴關係，因此命令之間通常要相互配合才能完成測試任務。
3．2．3 集成測試
集成測試主要是通過命令之問有序地執行完成智慧卡的功能測試，根據不同的測試需要可以對測試腳本進行分類，例如FLASH 的讀／寫，加密模塊的測試等。按照需要整理好相應的測試腳本後就可以在測試平臺上運行，通過腳本與智慧卡程序的互測，達到測試目的。測試平臺支持自動化測試，所以可以在測試平臺上不間斷地執行測試腳本，測試人員不需要實時跟蹤，只需要關心最後的測試結果，通過測試結果可以發現問題，解決問題。
4 結 語
該系統已經通過測試，並且得到初步驗證。由於針對智慧卡的測試項很多，通常需要多種測試工具的軟體和硬體設備交互使用，測試人員要熟悉各種軟體工具，相應地降低了工作效率。如果能將各種工具軟體集成在一起，形成一個多功能的測試平臺，支持多種通信接口的讀卡器，支持多種腳本格式，那麼這將是下一步的工作重點。
1