（3）测试人员

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

　　因此，我们从以下方面要求测试人员：

　　第一，不仅仅是个简单的操作员。首先人员必须对业务和操作都非常熟悉，这是对测试人员的基本要求。因为测试就是一个预见问题和发现问题的过程。试想一个对业务和操作都不熟悉的人，他自己都无法确定自己的操作和系统结果是正确的，又如何能判断错误是他的误操作造成的或是程序错误的结果呢。

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

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

　　2、测试内容分配

　　在一个大型的测试中，一般需多个测试人员共同参与。IC卡因其特殊性， 不同交易有不同处理方式，甚至使用的密钥都不同。我们在测试内容的分配中尽量做到合作中分工明确。比如，按交易类型分配给不同的测试人员负责测试，这样可以多个交易同时进行，可以考核各人的测试情况，也避免重复劳动。但在分工的同时，尽量考虑每一项功能或交易由两人（或以上）负责，避免一个交易只通过一个人检查和操作，有一定程度个人判断的局限。

　　3、测试记录

　　良好而忠实的测试记录是提供给包括验收者在内的第三方验证和分析的最原始资料。要求记录详尽，各要素齐全。建议最好设计成表格形式，一目了然。比如测试具体交易，则需分栏记录交易引起变动的各个相关要素测试前后的状态和记录，如交易前后卡的相关卡号、状态、余额、利息积数等信息，所进行测试的交易种类、交易金额，交易完成后系统输出记录、出错信息，是否成功的结论等。IC卡的测试记录在包括系统各要素的同时，要增加对卡片相关要素（如芯片余额等）的记录。测试人员必须根据实际测试情况忠实填写。测试输出的单据和资料也作为测试重要资料保存。

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

　　4、测试信息反馈

　　在测试过程中要建立良好的信息反馈和沟通机制。测试人员发现问题要及时与技术人员沟通要求修改。不能解决的问题要向上反映，不能造成问题悬空和脱节。项目管理人员要及时掌握项目进度情况和测试情况，对业务和技术的交叉环节进行疏导解决。

　　5、讨论会和

　　IC卡是个新产品，在测试过程中，总会出现新问题或是与设计有矛盾或冲突的地方。 有些问题还需其他业务部门定夺。项目组的业务技术人员，包括分管项目的领导，定期地召开讨论会和（遇到紧急情况可随时要求召开），互通项目的进展情况，对测试中遇到的问题共同讨论分析，群策群力寻求最佳方案。要求对项目组不能决定的问题及时提交相关部门，及时解决。

　　6、程序的版本控制

　　程序的版本控制更多的是个技术问题。一个大系统，一般是多人同时开发的。 版本控制不佳时会出现前面已测试通过的功能，又出现错误。或是已经解决的问题又再次出现，这不仅使得测试得重新进行，影响进度，而且因为在实际中大量的测试难以全盘重复进行时，上线后的潜在问题是难以估量的。因此程序的版本控制管理问题是值得项目组全员重视的。

　　三、测试步骤原则

　　一个初建的系统，其功能往往是繁杂的，而IC卡因其本身功能的多样性，交易处理的复杂性，使得测试更为繁琐。对于一个新手，可能会觉得每一项功能都需要测试验证，千头万绪，无从下手，测试起来这也不行那也不对，更会觉得失去了继续测试的信心。笔者根据经验，总结了几个测试原则，试图把握测试的脉络，组织测试做到思路清晰，没有大的疏漏。

　　1、先进行功能性测试再进行系统测试

　　这一条基本上是测试工作的定理，当然也适用于IC卡测试中。特别是在进行比较大型的测试时，一般会先进行功能测试（或称单元测试）。这个阶段目的在于检测针对系统的单项功能是否正确，往往是最耗时的阶段。案例设计对同一功能或交易的各种可能发生的正常或异常情况，各种边缘、临界情况进行测试，保证系统处理结果的正确性。我们对IC卡的功能测试方法是根据系统菜单功能的选项逐个进行，无一遗漏。对交易的测试则按各交易种类逐个进行测试。对以交易码处理不同类型交易的系统，则需对每个交易码进行测试，保证万无一失。