IC卡测试

IC卡测试
IC卡因其快捷安全的独特魅力吸引了越来越多的专业领域用户，也有越来越多的银行加入或希望加入发行IC卡的行列。

许多银行选择发行磁条与芯片共存的复合型卡片。

复合IC卡在我国的银行卡市场，还算是尚在起步的新生事物，参考资料比较欠缺。

笔者有幸在IC卡发展早期成为IC卡系统开发项目组成员，并作为业务负责人负责提出系统业务需求，制定策划和组织了多次大规模的IC卡测试，经历了若干次IC 卡系统升级改造。

现将一些个人心得和经验进行总结，希望为正在为IC卡项目努力的同仁们提供一些借鉴。

测试环境搭建和案例的设计遵循如下的指导思想：覆盖所有的业务种类、涉及到每种业务的正常值、临界值及非正常值的综合测试系统处理业务峰值能力的检验、各子系统容错能力的验证、系统账务纠错管理功能的验证、系统安全性的考虑、特殊时间段及跨越24小时不间断运行的业务处理正确性的检验。

基本测试方法：本文所描述的测试是从业务的角度出发、基于业务应用层的综合测试，因此采用黑盒测试法，不验证系统内部的流程走向，而主要是通过设计尽可能完整的测试案例，从每个测试案例的响应结果和账务的状态结果来形成我们的测试报告。

一、测试准备
测试的目的就是要尽可能预先在实验室中发现问题，提前解决问题。

因此，为保证测试结果的可信度，搭建的测试环境应与生产环境尽量一致，覆盖所有的设备，根据IC卡的实际应用范围，搭建储蓄前台、后台、管理机、 ATM、POS 等设备的前置机、加密机等。

1、机具具体要求
（1）搭建储蓄前台。

以测试在储蓄网点进行的日常业务。

而为测试账务走向的正确性，应至少搭建3个以上储蓄所。

以测试本所交易、本地异所交易、异地交易（涉及跨地市资金清算和手续费收取）。

同时配备IC卡读写器、划卡器、密码键盘等。

（2）POS准备。

以测试在POS上进行的各类消费交易。

同储蓄前台原理，为测试账务走向应至少准备管理机构分属不同机构的3台以上POS。

同时因不同厂商的POS底层软件不尽相同，为检验交易处理的正确性，响应信息的正确性，应对在生产环境中使用到的每种类型 POS 都进行测试。

对于检查账务走向准确性的测试，程序多与后台记账程序有关，不涉及具体设备型号，不必分别进行。

根据实际应用，有特殊专业应用的POS，也在测试范围，如医院药店可用于医保区应用的POS，对于加油站等使用的有特殊输出要求的POS，以及用于公交车通过对电子钱包非接触式扣款应用的专用 POS等。

（3）ATM准备。

要求同POS。

（4）其他机具。

根据实际生产环境需要进行测试，如圈存机、CDM等。

（5）电话银行及网上银行等测试只是交易渠道不同，测试原则与网点测试相同，在此不作讨论，可同理进行。

2、卡片准备
本文假定测试范围为复合IC卡。

为检测账务走向、特殊业务控制等要求，一般至少准备本地分属两个不同储蓄所发的卡、异地分属两个不同储蓄所发的卡，并根据测试案例工作量大小准备卡片数量，应多准备测试卡以进行不同组合情况的测试。

另根据各系统实际开通功能的情况，准备跨行或跨地区的测试卡。

从IC卡测试成本考虑，最好能准备芯片可多次重写的专用测试卡（多为白板卡）。

3、IC卡密钥
IC卡测试与其他银行卡测试不同的是涉及到密钥的管理。

测试用卡应使用测试密钥，以保证生产安全。

二、测试管理
成功的测试工作，绝不仅仅是一两个人的个人努力成果，特别是对于大型项目，需要方方面面配合，项目组的每个技术和业务人员的通力合作。

测试成果是一个群体智力和汗水的共同结晶。

1、人员选择
（1）测试组织者
测试的组织者往往是测试成败的关键因素。

要求能精通业务，同时对技术流程有一定了解，起到技术和业务的桥梁作用。

负责整个测试工作的规划，设计测试方案，制定测试范围、测试方式，做出分工，明确测试步骤，对问题能快速做出决断。

（2）技术员
我们在多次的项目中也深刻体会到：一个优秀的系统决不是靠测试测出来的。

编程质量至关重要。

我们很幸运合作过一些优秀的技术员，他们是编程高手，同时对业务流程非常熟悉，善于和勤于思考，发现了问题就深究到底。

同时，他们会不时将程序设计思路与业务人员沟通，帮助制定测试范围，减小黑盒测试的局限性。

这样的素质都是人员选择的关键。

（3）测试人员
在实际的测试工作中，有时因人员紧张或其他原因，只要能满足派出人员参加测试就不错了，测试人员在进入项目组后再进行速成培训，会事倍功半，而测试的质量也难以保证的。

因此，我们从以下方面要求测试人员：
第一，不仅仅是个简单的操作员。

首先人员必须对业务和操作都非常熟悉，这是对测试人员的基本要求。

因为测试就是一个预见问题和发现问题的过程。

试想一个对业务和操作都不熟悉的人，他自己都无法确定自己的操作和系统结果是正确的，又如何能判断错误是他的误操作造成的或是程序错误的结果呢。

第二，测试人员不应只是针对案例简单操作，而应根据案例的范围，根据自己平时工作经验，尽可能的随时加入设想可能发生的情况。

第三，作为问题的第一面对者的测试人员，要求具有良好的判断和反映问题的能力。

要求一定的书面表达能力，不要求文采，但要求问题描述简短而清晰，忠实地记录出错情况，从他的问题报告可以让技术及组织者或第三方明白问题所在，而不是长篇大论不知所云，或只是简单而笼统地说不行。

2、测试内容分配
在一个大型的测试中，一般需多个测试人员共同参与。

IC卡因其特殊性，不同交易有不同处理方式，甚至使用的密钥都不同。

我们在测试内容的分配中尽量做到合作中分工明确。

比如，按交易类型分配给不同的测试人员负责测试，这样可以多个交易同时进行，可以考核各人的测试情况，也避免重复劳动。

但在分工的同时，尽量考虑每一项功能或交易由两人（或以上）负责，避免一个交易只通过一个人检查和操作，有一定程度个人判断的局限。

3、测试记录
良好而忠实的测试记录是提供给包括验收者在内的第三方验证和分析的最原始资料。

要求记录详尽，各要素齐全。

建议最好设计成表格形式，一目了然。

比如测试具体交易，则需分栏记录交易引起变动的各个相关要素测试前后的状态和记录，如交易前后卡的相关卡号、状态、余额、利息积数等信息，所进行测试的交易种类、交易金额，交易完成后系统输出记录、出错信息，是否成功的结论等。

IC卡的测试记录在包括系统各要素的同时，要增加对卡片相关要素（如芯片余额等）的记录。

测试人员必须根据实际测试情况忠实填写。

测试输出的单据和资料也作为测试重要资料保存。

我们同时设计IC卡测试问题报告单，内容包括测试人员发现问题的描述、时间、技术员分析错误的原因、是否修改程序、是否要求重新测试、再测试结果、相关负责的人员签署等，可以详尽记录出现和解决的问题，方便备查，并为项目完成时提交测试报告，提供验收人员参考分析作为第一手的资料。

4、测试信息反馈
在测试过程中要建立良好的信息反馈和沟通机制。

测试人员发现问题要及时与技术人员沟通要求修改。

不能解决的问题要向上反映，不能造成问题悬空和脱节。

项目管理人员要及时掌握项目进度情况和测试情况，对业务和技术的交叉环节进行疏导解决。

5、讨论会和
IC卡是个新产品，在测试过程中，总会出现新问题或是与设计有矛盾或冲突的地方。

有些问题还需其他业务部门定夺。

项目组的业务技术人员，包括分管项目的领导，定期地召开讨论会和（遇到紧急情况可随时要求召开），互通项目的进展情况，对测试中遇到的问题共同讨论分析，群策群力寻求最佳方案。

要求对项目组不能决定的问题及时提交相关部门，及时解决。

6、程序的版本控制
程序的版本控制更多的是个技术问题。

一个大系统，一般是多人同时开发的。

版本控制不佳时会出现前面已测试通过的功能，又出现错误。

或是已经解决的问题又再次出现，这不仅使得测试得重新进行，影响进度，而且因为在实际中大量的测试难以全盘重复进行时，上线后的潜在问题是难以估量的。

因此程序的版本控制管理问题是值得项目组全员重视的。

三、测试步骤原则
一个初建的系统，其功能往往是繁杂的，而IC卡因其本身功能的多样性，交易处理的复杂性，使得测试更为繁琐。

对于一个新手，可能会觉得每一项功能都需要测试验证，千头万绪，无从下手，测试起来这也不行那也不对，更会觉得失去了继续测试的信心。

笔者根据经验，总结了几个测试原则，试图把握测试的脉络，组织测试做到思路清晰，没有大的疏漏。

1、先进行功能性测试再进行系统测试
这一条基本上是测试工作的定理，当然也适用于IC卡测试中。

特别是在进行比较大型的测试时，一般会先进行功能测试（或称单元测试）。

这个阶段目的在于检测针对系统的单项功能是否正确，往往是最耗时的阶段。

案例设计对同一功能或交易的各种可能发生的正常或异常情况，各种边缘、临界情况进行测试，保证系统处理结果的正确性。

我们对IC卡的功能测试方法是根据系统菜单功能的选项逐个进行，无一遗漏。

对交易的测试则按各交易种类逐个进行测试。

对以交易码处理不同类型交易的系统，则需对每个交易码进行测试，保证万无一失。

系统测试一般在功能测试已完成，系统对各单个功能处理正确的基础上，模拟实际工作中可能进行的日常工作全面设计测试案例，尽可能包括各系统功能和交易类型。

检查系统处理日常业务的能力，数据报表的衔接，一致性检查等功能。

重点交易种类在大而全，但对每种具体交易一般只进行正确的操作，非正常操作和临界情况一般不是此阶段测试重点。

对于程序设计和改动较少的小规模测试，可以考虑直接在系统测试中一并设计功能测试各种可能情况，将单元测试和系统测试合一。

2、先进行正常情况交易测试，再进行非正常情况交易的测试
在进行功能测试时，我们采用先进行对正常情况下各交易的正确性测试，再测试其他非正常情况。

正常情况的测试是指，对一个交易或功能，完全按正确的要求和步骤操作，输入正确而常规的要素，检查系统的输出结果各要素或流程是否正确。

之所以这样安排，是因为对于一个从未进行过测试的初建的IC卡系统，我们对它的功能和处理结果基本一无所知，先对各个功能进行常规测试可以先保证各交易是基本能做的，保证了系统处理流程和框架是正确的，在这基础上，再设计各交易预见的各种情况进行测试，从测试进度控制和问题解决的难易程度上，要处理得从容一些。

否则，某些交易各种情况的测试均已完成，却又发现另外某个交易连处理流程都是错的，再做修改，此时对项目组的信心会有打击，同时做大改动是否会影响前面已通过的测试也未可知。

3、先测试以磁条发起进行的交易，再测试以芯片发起进行的交易
这项原则我们主要是针对IC复合卡的测试而言，在没有可重复写芯片的测试卡而使用真实卡片进行测试时，从节约测试卡成本的角度考虑的。

一般来说，以磁条发起进行的交易都是联机交易，交易是以完成修改
系统后台的数据库相关信息为目的，不涉及对芯片的读写，不会改变芯片的信息。

换句话说，以磁条发起进行的交易测试完成后发现结果错误需重新进行测试，只需恢复后台的数据库即可，不需更换测试卡。

而以芯片发起进行的交易，交易完成多已改写芯片的信息，当发生测试结果错误时，不能简单恢复后台数据库重来，特别一些如销户、卡收回等不可逆的交易，测试完成则卡片不能重复使用，如果不讲究策略，测试的卡片成本是非常巨大的。

4、在进行最后的系统测试之前，必须针对账务正确性进行测试
IC卡的交易是新交易，又有多个分区，有其特殊性，如圈存，圈提等均与普通存取款不同，分录都是新设计的。

新交易完成后，账务的处理是否正确，借贷关系记录正确是否，交易流程结束后清算到所属分行、支行、储蓄所的资金是否正确？这些问题也不容忽视，任何遗漏都会带来资金的风险。

我们的经验是在各功能测试完成后，
对各项涉及资金的交易进行通测，重点检查系统分录的正确性，账务走向和资金清算的正确性，再进行系统集成测试。

四、测试案例设计要点
美国《测试流程管理》一书的作者Rex Black 在该书的简介部分也提到当他自己最初作为测试工程师和测试项目管理者时，也曾经以为：测试能会有多难？测试只不过想象可能会出现什么问题，然后试着验证这些问题罢了。

而他很快发现：想象可能会出现的问题，并试着验证这些问题，实际上是非常困难的。

这涉及到测试案例的设计，如何在试验室中想象系统在日后的实际应用会出现的问题，这不仅需要丰富的经验，还需一定的条理，否则测试会漫无边际，缺乏头绪。

案例设计针对各种不同具体交易会有不同的具体设计。

由于篇幅的限制，本文试图根据笔者的经验，总结一些必须测试的要点，围绕这些要点进行测试案例设计，尽量避免大的遗漏。

1、正常情况测试
在上文测试步骤原则中已提到这类测试是测试的基础。

保证系统对输入正常值的正确处理。

测试时除检查系统结果外，对各项输入要素系统是否有必要的纠错限制，界面是否合理，提示和响应信息是否正确也同时检查。

2、黑卡的交易测试
黑名单卡是指一切卡状态不正常的卡，包括各种原因造成的黑卡。

如挂失、冻结、止付、收回等原因，已上了系统黑名单的卡。

检查系统是否能正确进行拒绝交易的处理，输出的信息是否正确。

另一方面，也同时检查撤销黑名单的卡是否能正常交易等，以保证银行资金的安全。

另外，对于IC卡脱机交易的特殊性，需对受理IC卡的POS测试黑名单下传的功能，检查下传的黑名单记录是否完整，POS进入一个新的交易日是否会提示签到更新黑名单等。

3、超限额交易测试
IC卡设计有多个分区，因此有多个分区余额，针对各个分区进行超出账户余额（对具体要求不同可能是可用余额，如对可透支卡或部分金额冻结的卡）的各类型交易测试，检查系统是否在交易时对账户余额进行正确控制，杜绝程序错误而使账户发生透支的可能。

是一项必不可少的测试内容。

4、密码控制的测试
在以密码进行个人身份识别交易时，系统是否可以正确判断并通过正确的密码校验。

检查有无不应出现的不输入或输入错误密码也可通过交易的情况。

5、撤销交易的测试
撤销交易一般是在交易完成后需要取消这笔交易。

一般是进行一笔与原交易性质相同但金额为负数的交易进行反向冲销。

这种情况中在实际工作中也是经常使用的。

测试时除检查撤销交易完成后账户各项要素是否正确外，还需特别注意系统对撤销交易的操作有无基本的操作员权限的控制，有无对需撤销的交易进行必要检验，对惟一性的控制，如既不可对未存在的交易进行测试，也不能对已进行撤销的交易重复撤销。

6、冲正交易的测试
系统良好的冲正处理可以较大程度的减少错账的可能。

卡类业务中许多前后台数据不一致的单边账有很大的原因是冲正处理不佳造成的。

此类测试专门针对系统的冲正处理。

如在交易个要素输入完成后，操作员选择放弃交易，或是交易进行过程中，人为拔断电源的制造交易中断的情况，检测系统处理情况，有无在前台已显示成功而后台却失败的情况。

对于芯片的交易更要测试有无对芯片的读写已完成，而后台数据却不一致的情况。

7、脱机交易批上送测试
IC卡可在POS（或其他专用设备）进行脱机交易。

对此类交易要求进行批上送将交易纪录上传到主机，再进行批量入账处理。

此时，需测试上送到主机的交易纪录是否正确，是否有数据包丢失的情况。

后台批量入账有无问题。

可否多次批上送，对批次号的处理是否正确，进入新的工作日是否有做批上送提示等。

8、交易峰值测试
对于受理IC卡脱机交易的POS，一般都有受理交易笔数的最大值（峰值），超过了这个数值将无法进行交易，需设计测试POS是否会提示或有必要措施强制在峰值前进行批上送，避免交易超过峰值POS无法处理。

9、压力测试
实验室的测试一般人员有限，测试的交易量有限，而在日后实际生产环境中却是有大量的操作员，不同的交易渠道在同时进行交易，那么系统处理的情况如何还需确认。

可通过程序模拟在短时内发起大量交易检查系统的处理情况，但IC卡因其有交易读写芯片的特殊性，只能模拟后台的交易处理，要模拟读写芯片的全过程比较困难。

10、特殊时间点的测试
为保证系统处理的连贯性和数据的一致性，需选择日终、月末、季末、年末、结息日、系统进入新日期的临界点等，为时间点进行测试，检查结果的正确性。

11、其他测试
另外，还需根据管理需要和实际情况进行其他的测试，如界面设计和各步骤的安全控制、交易流程的特殊要求等。

五、测试结果检查
以上介绍了如何测试以及测试的内容。

但对于测试人员来说，从哪些方面检查测试结果呢？笔者总结以下几个必须检查的要点以便测试人员确认结果。

1、输出信息检查
结果检查的基础是核对从银行业务员，终端客户的操作界面反馈的输出信息是否正确，是否如实返回系统的处理结果，错误提示是否正确合理。

操作流程控制及步骤是否正确等。

从操作员和客户的角度分别判断系统输出信息处理是否正确。

2、后台数据库检查
对于某项功能或交易，在交易完成后势必会相应修改后台相关数据库的相应要素。

在交易前后，测试人员必须检查并认真记录相关信息，并判断系统处理的正确性。

如检查一笔交易处理是否正确，则必须检查相关的卡分户信息中卡状态，利息积数，相应IC卡分区的余额，上次发生日等是否正确，是否正确记入当日交易流水账，日终是否正确记入明细账等。

3、芯片检查
根据IC的特性，在对IC的测试还需检查IC卡的芯片相关信息。

如在交易前后记录和检查IC卡芯片分区余额，IC卡明细，对某些特殊情况是否正确做出灰卡记录，保证系统对IC卡交易后的芯片的处理结果是正确的。

4、输出单据检查
对于交易处理完成后，系统输出打印的各类单据，报表，凭证，测试人员也需按照管理规定审核打印的要素是否齐全，数据输出是否正确。

对于提供给客户的单据，更要求精确无歧义。

5、账务检查
在测试步骤原则中已提到账务检查的重要性。

在测试时必须检查系统对交易的账务处理是否正确合理，各分户账、总账记录是否正确，数据一致性检查，总分平衡，数据连续性是否正确。

6、其他检查
另外，还需根据具体不同具体情况和特殊要求进行必要检查。

六、测试的局限性
测试归根结底仍只能是在试验室中模拟真实环境而试图发现问题。

无法在试验室中百分之分地预见所有可能发生的问题，其与真实环境存在或多或少的差异几乎难以避免。

而IC卡又因其在交易时必须读写芯片的特殊性，使得实验室测试更具局限性。

对于大交易量的压力测试几乎无法进行，如在其他测试中常规设计的做法：在系统正式切换上线前在各网点进行追账的测试以更全面的检验系统处理正确性，对IC卡实际难以实行。

所以在正式切换前需设有试运行阶段和上线后的密切跟踪期，这段时间至关重要，业务人员和技术人员必须随时观测，及时发现问题，解决问题，减少和避免差错和疏漏，使系统平稳运行。