引 言
随着智能卡在金融、电信、移动通信、医疗保险、付费电视等领域应用的迅速增长，其可靠性要求越来越高，而针对智能卡模块的测试已经成为必不可少的质量保证手段。自动化测试不需要人工干预，能提高测试效率，受到更多重视和应用。在发展自动化测试的过程中，一个高效的自动化测试平台是其基本保障。根据智能卡的应用现状和市场需求，本设计用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 结 语
该系统已经通过测试，并且得到初步验证。由于针对智能卡的测试项很多，通常需要多种测试工具的软件和硬件设备交互使用，测试人员要熟悉各种软件工具，相应地降低了工作效率。如果能将各种工具软件集成在一起，形成一个多功能的测试平台，支持多种通信接口的读卡器，支持多种脚本格式，那么这将是下一步的工作重点。
