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