从开始就应了解到程序测试只能证明差错的存在，而不是它们不存在，这一点很重要。假定只有所存在的 差错的大约一半被真正找到了，则可以断言在这个达到一般水平的程序中仍包含着一定数量的弱点。

　　在实践中，对于汇编语言的编程经常假定在测试后其差错率为每100行代码有0.7个错。如果我们以前述的 30 000行程序代码作为智能卡操作系统的代表（作为一种评价我们从这个数字中减去2/3）可以算出仍有70 个差错存在于一个完全测试过并发布了的操作系统之中。虽然，它们的绝大多数永远不会出现在完全正确的 情况中，但一个差错已足以绕过系统中的所有安全壁垒了。对这一事实保持关切是非常有用的，它可以作为 失去研究测试技术的因素。

　　当然，测试有其本质的限制，特别是商业的项目，因研究项目不同，可以利用的时间以及可以付出的最大 代价都是强力的限制因素。此外，随着程序中存在的错误的数量减少，测试变得越来越困难而且苛刻。对最 后几个少量错误的搜索必须终止在某点上，因为可以花费在它上面的时间和资源是根本的限制，参见图1。

　　当软件的一个新版本发行时，可在第1瞬间就假定其中总是包含着少量差错。因而，这里还存在着对操作 时发现的错误进行分析与消除它们的机会。有趣地是，差错数目的减少不会无限期地延续下去。相反，可以 看到大约在第2版时一般就达到了最小值。通常接着又会增

图1 作为剩余的差错数的函数的差错搜索成本

　　加，这种转向仅仅是因为所需的校正都是基于最初的技术规格和程序代码之故。经过一段时间后，它可能有 很大的改变，常常会校正一个差错就增加了一个或更多个差错。结果导致如图2所示之曲线。经过数次修改 版本后，显然更合理地是完全从头开始，这比继续在过时的技术规格的基础上重复地更正程序代码要好。或 许，对所有的技术领域来说，这一点都是正确的。图3则表明了在一程序中残存差错数和已发现的差错数之 间的经验关系。

图2 程序中的差错数量对版本号的经验依赖关系

图3 在程序中残存差错数和已发现差错数之间的依存关系（经验确定）

　　根据ieee 1008标准（软件单元测试标准），动态测试可区分为三个测试级别。其中第1级为基本测试级， 在这一级里测试了必需的基本功能和成功执行单独的命令；第2级为能力测试，它包括着边界值和不能成功 的执行；第3级为性能（behavior）测试，在其中把命令相互组合起来测试。

　　1，测试过程

　　测试一个新的操作系统和测试一项新的应用是有重大区别的。当测试智能卡操作系统时，整个的程序代码 必须对广泛变化的应用案例进行测试。这样就需要大量不同的测试。对于新应用，如已知仅由一个df和数个 bf组成，则测试减少到了和应用中规定的附加数据量和认证以及鉴别方法相匹配的数量。

　　如果必须测试一新的操作系统，通常产生几个就像某些典型的真正的应用那样的测试应用，然后以能说明 问题的方式对“典型”应用形成等效类别，以构成要相继执行的单独测试的基础。

　　下述测试智能卡新操作系统的方法在数年的期间内已经确立于大量的项目中。测试总是从数据传输功能开 始，因为它们是所有进一步活动的基础。接着，测试所有可用的命令。若是包括有一项应用，下一阶段就是 文件测试，如果所有这些测试都完成了，则开始固定处理的测试。

　　当前只有少量的国际标准规定了智能卡操作系统应用测试的构造与执行。一项欧洲标准（en 1292）规定了 对atr和t＝1传输协议的少量测试。对gsm卡的操作系统和应用的比较广泛的测试则规定在gsm 11.17规范之 中。图4为对智能卡通信传输测试的屏幕显示。

图4 在实体和逻辑水平上验证终端和智能卡之间通信的屏幕显示（版权 lntegn［lntegri］）

　　为了提供一个总览，下面给出了按照常规序列对可能的测试的选择。这个表并不自认为是完善的，它仅仅 是用作详细说明的一个例子而已。列举的测试的目的在于测试新操作系统的必要的基本参数，包括一个或多 个应用。

　　2．数据传输测试

　　·atr（奇偶错检测，若是t=0时的符号重复，atr的结构与内容）；

　　·pts（pts的结构和内容）；

　　·在051第2层上的数据传输（开始、数据和停止位、分隔符、约定）；

　　·t=0传输协议（奇偶错检测和符号重复、各种子程序）；

　　·t=1传输协议（cwt、bwt、bot、再同步、差错机制、各种子程序）；

图5