听起来虽然明确，然而仍有一条必须事先讲清，测试程序并不意味着去系统搜索错误，而是实现一具有发 现被测程序中有无错误的测试过程，测试并不是去排错，因为测试是由测试者而不是软件开发者进行的。

　　就像我们一再强调的那样，智能卡微控制器软件和其他软件比起来并无巨大差别，然而，它们有着自己特 殊的特性，这一点可用对一个典型操作系统的某些通用技术规格所考虑的有关因素来说明。

　　在一块具有16kb rom和8kb eeprom的普通的芯片中，软件大约要占20kb的存储量，留下4kb eeprom由所有 的应用使用。目前，软件通常用汇编语言编程，在我们的例子中大约有30 000行程序代码的数量，大约有2 000次转移，如果以每页60行印刷，大概要填满500张纸，即使是一个有经验的程序员也需要用9个月的时间 来产生⒛kb的汇编代码。

　　这个数字例子清楚的说明智能卡操作系统还是比较复杂的。除此之外，这一软件必须在把安全作为一个几 乎独占的因素的领域中使用。这就是说，在软件开发时或其后的仅有的一些少量的自行测试不能满足错误水 平很低的要求。相反，需要有适当的测试策略。

　　就像在其他领域，对智能卡来说也倾向于远离汇编语言编程而使用高级编程语言。c语言，它比较接近硬 件水平，对智能卡来说正日益增多其应用。在最近几年中，面向对象的java语言也正变得同样重要了。对超 过30kb代码的大型智能卡操作系统高级编程语言的应用是必须的，不仅是为了减少实现时间9也是由于可减 少错误数量。

　　这一点可解释如下，几乎对于所有的编程语言来说，可以认为源程序代码每行的错误数接近于相同。由于 高级语言的功能水平明显地高于汇编语言，这就意味着执行代码的错误密度降低了同样的数量。

　　例如，如果我们假设程序代码实际上一律为每100行有1.5个错误。而且我们还进一步假设在经过可以做到 的努力之后，仅有全部错误的一半可以找到。则一测试过的程序在每100行程序代码中将仍有0.75个错误。 对于java，源代码行数与机器代码（字节码）的关系大约为1比6，这就是说，一行lava代码粗略地相当于6 行机器代码。如果我们假定所有其他条件都是相同的，而编译处理基本上不出现错误，则由于使用较强有力 的语言将使程序中的错误数量减少至1/6。即使在实践中实际值达不到1/6，这仍旧是使用强有力的编程语言 的原因。

　　1，智能卡软件测试

　　在开始制定测试策略之前必须首先考虑智能卡软件的生命周期，可以采用w．w．royce所建议的瀑布型生 存周期模型。自1970年发表以来已经有多种形式为众所周知，它对于掩膜编程的智能卡操作系统很合适。然 而，由于此模型是为用于pc机的大型机软件项目设计的，我们将采用一个简化的特别适合于智能卡的版本。

　　图1所示的五个阶段通常是按顺序执行的，无论如何，对一个问题会遇到在某个阶段上必须返回一个或多个阶段的可能。应当尽可能地避免这种情况，因为每次反复都以时间和金钱为代价。

图1 用于生产智能卡软件的简化的瀑布型生存周期模型（各个步骤可看做是活动安排，也可当做是时间区间 ）

　　为了满足经济需要，诸如时间和市场以及缩短软件开发时间，经常需要在某种程度上使各阶段相重叠，而 不是严格地按序列执行。采用被称之为并行化工程的方法，部分软件应尽早划分为单独的模块，这些模块可 并行投人到瀑布中去。于是，对于智能卡软件来说在系统集成之时就只包含有一个数据传输协议，至于对同 一应用的加密算法则仍有待规定。

　　1）设计

　　设计阶段包括了对目的基本界定和以形式化的方式来编制需求文件。它们规定了要开发的智能卡软件必须 满足的所有需求，在设计阶段也考虑到以初步设计的形式生成出建议方案。简言之，这一阶段规定了完成后 的软件要做些什么。

　　2）技术规格

　　随着设计之后进人第2阶段，将确定软件如何去完成它的任务。因此，必须形成不以阐述为前提的严格技术 规格，而是完整规定了在设计阶段产生的需求的一个可能的方案。最好是形式化构造的技术规格，因为这样 能使软件的特性、功能和处理都得到清楚而不含糊的定义。以伪代码写成的技术规格可以用计算机程序来检 测其相容性并免除错误，因而最适用于此目的。在计算机辅助软件工程（case）环境中，这样的技术规格可 直接用来生成源代源码和测试程序。有时它们被称之为“可执行技术规格”，意即所产生的技术规格的形式 可由计算机解释并进一步处理。

　　3）编码和测试

　　一旦技术规格被完成并接受，就可以形成汇编器或c编程的流程图。接着就是编程和相关的测试，这一阶段 的成果就是完成编程并测试过的智能卡操作系统。

　　4）系统集成

　　由于智能卡只能和一大型系统在一起工作，不同的系统部件就必须在此阶段归并