系统测试一般在功能测试已完成，系统对各单个功能处理正确的基础上，模拟实际工作中可能进行的日常工作全面设计测试案例，尽可能包括各系统功能和交易类型。检查系统处理日常业务的能力，数据报表的衔接，一致性检查等功能。重点交易种类在大而全，但对每种具体交易一般只进行正确的操作，非正常操作和临界情况一般不是此阶段测试重点。

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

　　2、先进行正常情况交易测试，再进行非正常情况交易的测试

　　在进行功能测试时，我们采用先进行对正常情况下各交易的正确性测试，再测试其他非正常情况。正常情况的测试是指，对一个交易或功能，完全按正确的要求和步骤操作，输入正确而常规的要素，检查系统的输出结果各要素或流程是否正确。之所以这样安排，是因为对于一个从未进行过测试的初建的IC卡系统，我们对它的功能和处理结果基本一无所知，先对各个功能进行常规测试可以先保证各交易是基本能做的，保证了系统处理流程和框架是正确的，在这基础上，再设计各交易预见的各种情况进行测试，从测试进度控制和问题解决的难易程度上，要处理得从容一些。否则，某些交易各种情况的测试均已完成，却又发现另外某个交易连处理流程都是错的，再做修改，此时对项目组的信心会有打击，同时做大改动是否会影响前面已通过的测试也未可知。

　　3、先测试以磁条发起进行的交易，再测试以芯片发起进行的交易

　　这项原则我们主要是针对IC复合卡的测试而言，在没有可重复写芯片的测试卡而使用真实卡片进行测试时，从节约测试卡成本的角度考虑的。一般来说，以磁条发起进行的交易都是联机交易，交易是以完成修改

　　系统后台的数据库相关信息为目的，不涉及对芯片的读写，不会改变芯片的信息。换句话说，以磁条发起进行的交易测试完成后发现结果错误需重新进行测试，只需恢复后台的数据库即可，不需更换测试卡。而以芯片发起进行的交易，交易完成多已改写芯片的信息，当发生测试结果错误时，不能简单恢复后台数据库重来，特别一些如销户、卡收回等不可逆的交易，测试完成则卡片不能重复使用，如果不讲究策略，测试的卡片成本是非常巨大的。

　　4、在进行最后的系统测试之前，必须针对账务正确性进行测试

　　IC卡的交易是新交易，又有多个分区，有其特殊性，如圈存，圈提等均与普通存取款不同，分录都是新设计的。新交易完成后，账务的处理是否正确，借贷关系记录正确是否，交易流程结束后清算到所属分行、支行、储蓄所的资金是否正确？这些问题也不容忽视，任何遗漏都会带来资金的风险。我们的经验是在各功能测试完成后，对各项涉及资金的交易进行通测，重点检查系统分录的正确性，账务走向和资金清算的正确性，再进行系统集成测试。

　　四、测试案例设计要点

　　美国《测试流程管理》一书的作者Rex　Black 在该书的简介部分也提到当他自己最初作为测试工程师和测试项目管理者时，也曾经以为：测试能会有多难？测试只不过想象可能会出现什么问题，然后试着验证这些问题罢了。而他很快发现：想象可能会出现的问题，并试着验证这些问题，实际上是非常困难的。这涉及到测试案例的设计，如何在试验室中想象系统在日后的实际应用会出现的问题，这不仅需要丰富的经验，还需一定的条理，否则测试会漫无边际，缺乏头绪。案例设计针对各种不同具体交易会有不同的具体设计。由于篇幅的限制，本文试图根据笔者的经验，总结一些必须测试的要点，围绕这些要点进行测试案例设计，尽量避免大的遗漏。

　　1、正常情况测试

　　在上文测试步骤原则中已提到这类测试是测试的基础。保证系统对输入正常值的正确处理。测试时除检查系统结果外，对各项输入要素系统是否有必要的纠错限制，界面是否合理，提示和响应信息是否正确也同时检查。

　　2、黑卡的交易测试

　　黑名单卡是指一切卡状态不正常的卡，包括各种原因造成的黑卡。如挂失、冻结、止付、收回等原因，已上了系统黑名单的卡。检查系统是否能正确进行拒绝交易的处理，输出的信息是否正确。另一方面，也同时检查撤销黑名单的卡是否能正常交易等，以保证银行资金的安全。

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