智能卡软件测试方法

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

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

　　在一块具有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）系统集成

　　由于智能卡只能和一大型系统在一起工作，不同的系统部件就必须在此阶段归并在一起。结果是所有部分 的完整的和无差错的结合，形成整个系统的终文档。

　　5）操作

　　软件开发过程的阶段只能修改分配给被发行的卡的一些通用参数，大规模的软件改编与修改，在此阶 段已经是不可能了。

　　在未来，采用语言（例如Java），实现既方便而又快捷地对智能卡编程，将有可能除采用传统瀑布模型之外也可采用“进化的”过程模型。在进化模型中，设计、技术规格和编码与测试，甚至于 系统集成阶段的一部分都将随着不断改进的结果而反复数次。其目的是在技术规格的生成和详尽的功能化原 型的工作上，以尽可能小的花费代价迅速地达到的方案。

　　长期以来，一个众所周知的事实是在所有类型的项目中，特别是软件的开发上纠正一个差错的成本随着项 目的进展而增加。就像在瀑布模型中所表示的那样，这一事实决定项目的第1阶段的适当的时间与人工的开 销数量。如果设计不完整或者技术规格是错误的，补救问题的成本在项目的后继阶段中按指数增加，如图2 所示。

图2 作为发现错误的时间函数（纠正错误的成本费用）

　　2．测试过程和测试策略

　　今天，对用于软件测试的所有方法与过程要有所了解已是不可能的了。仅少量已经证实了的方法对智能卡 程序的测试才是必需的，这是采用汇编语言编程的好处之一，我们可以利用数十项经验和大量的出版物，它 们都和汇编语言软件测试这一论题有关。顺便说明，软件测试总是意味着企图去发现程序中的错误，而不是 证明程序是正确的。

　　所有的测试方法可被分为静态型和动态型的，在静态方法中，采用不同的方法或是人工的或是自动的来分 析并评估程序代码，两种常用的静态测试法将简短说明如下。

　　1）采用软件工具静态评估程序

　　这包括了采用静态技术分析程序代码的不同特性，可分析的特性包括下列各项。

　　·代码行数LOC（Lines。f oode）；

　　·注解行数；

　　·注解量和程序代码量之比；

　　·程序代码结构；

　　·函数数；

　　·嵌套深度；

　　·“死”码。

　　2）审查

　　由一组评审员对程序模块进行分析和评估，有时把这种方法称为“代码走查（codewalkthrough）或“代 码检查”（code inspection）。

　　和静态方法相反，动态程序分析技术在其工作时测试程序，或是人工的或用计算机辅助等两种基本手段， 也可以使二者混合进行。

　　3）黑箱测试

　　黑箱测试是基于如下的观念，即执行测试的机构对被测程序的内部处理、功能和机制一无所知。这也就是说，只能按照技术规格中的规定检验输人和输出数据彼此之间的关系。一个二维测试区的黑 箱测试向量图示于3图中，实际测试中不乏多维空间的事例，从而可知黑箱测试的难度和复杂性。

图3 黑箱测试的二维测试向量之例（用等效类的方法它规定了一个指定的测试区域，对于更复杂的测试 ，测试向量能轻易地具有lO或更多的维数，
受到可用于测试的时间限制，测试区域必须适当予以限制）

　　对智能卡操作系统来说黑箱测试是标准的，它们也用于终端和计算机系统的安全模块。然而，它经常被错 误地假定这种测试也能发现软件中的差错之外的特洛伊木马或类似的隐患的存在。这一假定经常用来作为不 需要进行比较费时而又昂贵的程序代码分析的论点。的确，它可以检查出一些简单的、不复杂的或者是那些 因不留神而编入到系统中的陷门。一个有经验的程序员能轻而易举地建立起永远不会被黑箱测试检查出来的 访问途径。这可用一简例来说明，它并不是作为特洛伊木马的模型，因为长久以来已人所共知了，而是强调 对代码检查在安全分析中的必要性的认识。

　　几乎所有的智能卡操作系统都包括有一条产生与发布随机数的命令（GET CHALLENGE）。此命令可被修改为 只有它发送的前8字节的数是真正由伪随机数发生器产生的，每一后继的“随机”数可取自EEPROM的某8字节 与前一随机数的X0R之值，于是一个简单的外部程序就可用来读出整个存储器的内容，包括全部密钥。顺便 说说，这是在智能卡中应用隐匿器的很好例证。

　　用黑箱测试无法断定隐蔽在这条命令后面的特洛伊木马，即使是对随机数的统计分析也检测不到任何对通 常的伪随机数的明显的偏离，识别这种被操纵的程序的惟一方法是检查操作系统的全部代码。可用例子说明 在许多可能的选项之中只有一项用于改变一条正常的命令以便获取存储器的内容，因为只有程序代码很少的 几行对此改变是需要的。反击这种陷门的惟一有效方法是完整地审查源代码。

　　4）白箱测试

　　白箱测试通常被叫作“玻璃盒测试”，由此可清楚地说明了它的概念。所有内部数据结构和处理都是已知 的，而且是完全可理解的。有关的程序文档被用来设计并产生测试，但技术规格丿总是惟一的典据。数十年 来，程序流程图是所有汇编语言用来编写程序的方言，而它们通常形成了在对软件的白箱测试评估内部功能 的基础。

　　由于准确的程序处理是已知的，测试者需要去测试通过软件的所有可能的路径。有几种方法来做到这一点。其中之一是语句的覆盖，其程序的每条指令都至少执行。这使得它非常易于发现程 序中包含的死代码（这是永远不会用到的代码）。然而，对于保障所期待的功能性的存在，它就是太软弱的 测试了。对此的较好方法是决策覆盖，它包括了通过程序代码的所有决定在每个可能的变化上至少。参 见图4。

图4 在一程序流程图中可能的处理路径数目的举例

　　（用语句覆盖和决策覆盖测试）

　　在动态测试时，为了能够识别这些内部的程序处理，就有必要或是对所涉及的智能卡微控制器使用复杂的 仿真器，或是把被测程序“仪表化”。在仪表化的程序中，在每条跳转指令，分枝指令和函数调用之前都正 好插人有特殊的程序代码。在程序运转时，这些代码搜集位置和参数信息，一个分析程序可用来对这些信息 进行统计和图形两方面的评估，遗憾的是，附加的程序代码改变了程序的时间关系。在坏的情况下，它甚 至能改变程序的行为，在采用此方法时，这是必须考虑的。

　　决策覆盖准则的一个扩充是经过程序决定的所有可能的组合，每次一个组合，这就覆盖了所有可能的处理 路径。然而，可用于测试的有间就意味着这种可能性仅仅对于只有数百字节编码的很小的程序才可行。 即使是有1 000字节数量级的程序，测试所有可能的组合也不能在合理的时间κ度内实现。

　　表1以概要的形式在一典型的智能卡命令解释器的基础上说明了这一点。这个程序模块的功能是凭借类别 和指令字节来识别位于卡输人缓冲器中的命令，然后去检查P1、P2，Lc和Le诸参数，对于此子程序的程序代 码的大小大约是200字节，它包含有18个分枝，可能的输出值由5个回送代码以及对26个不同的命令处理的调 用组成。

　　两个另外的路径覆盖准则：输入覆盖和输出覆盖用于测试智能卡操作系统，其目的是产生所有可能的输入 和输出值，输出值经常被限制为可使用的回送代码，否则变化量将太大了。

　　由于可能的输人值的数日也会迅速地达到巨大数值从而使测试变得不实际，由于大量的输入值或所需的时 间数量，通常采用等效类别。这样就把可能输入值的巨大数量减少到较小的数目，从而可以在合理的时间量 内进行测试。等效类别是在决策范围每一边的选择的边界情况下形成的，同时还在范围的中间取一值。

　　表1 在白箱测试中不同覆盖方法的可能测试事例的数垦（本例中使用了一个200字节的智能卡命令解释器，平均处理时间为300ms，包括数据传输，用来计算测试持续时间）

　　例如，若智能卡命令解释器允许的Pl字节数的范围为20～50，则将用19，20，50和51各值作为形成等效类别的边界值，而35（例如）作为中问范围之值。这组值检验了程序的基本的查询条件。在此测试之后，就可以较高的可信水平认为已经正确地实现了参数范围的检查。

　　特别是对于汇编语言编程，当规定等效类别时，遗憾地是必需把目标硬件的特征估计在内。例如，在形成等效类别时，所有可能引起处理器中上溢或下溢的算术操作（由于运算单元的8位或16位结构之故）都必须考虑在内。只有这样，才有可能确信下溢或上溢均已在程序中得到了正确的处理。

　　5）灰箱测试

　　灰箱测试是黑箱与白箱测试的混合产物。对于这种测试，软件的某些部分，诸如内部程序处理是已知的。灰箱测试主要用于智能卡的集成阶段，因为在各个部件的交互中它可以既快速而又有效地检出并纠正错误。当然，需要从密钥管理设施取得适用的测试密钥（它是公开的）。一旦集成测试的这一部分结束后，其结果可用真正的密钥（生命密钥）进行核查。

　　欢迎转载，信息来源维库电子市场网（www.dzsc.com）