可进行多种应用协议测试的方法 本发明涉及数据传输及测试领域，特别涉及一种可进行多种应用协议和接口测试的测试方法。
通信协议的存在，其最主要的原因是为了保证两个通信实体能够发送、接收，并解释它们想要交换的信息。为了保证信息能够正确传输，通常需要对通信协议进行测试。目前，对于协议的测试基本上是用专用的测试程序进行相应的测试。例如，针对HTTP协议，就要开发专门的测试程序，测试应用是否符合HTTP地规范，数据包的结构是否符合要求等。同样，对于其他的协议如FTP、DNS、SMTP、POP3等，以及大量的自定义的应用协议的测试，都要开发各自专用的测试程序进行相应的测试。鉴于协议测试通常需要准备大量的数据，当前比较好的做法也就是针对某一种协议模拟产生大量数据，然后在测试程序中应用这些数据；其次是针对不同的协议采用不同的动态连接库(DLL)。
请参见图1、图2所示，分别为单一协议测试和使用DLL的几种协议测试的简单流程示意图。从中我们可以看出，单一协议测试的方法需要针对每种协议进行专门的测试程序开发编制，重复工作量相当大；使用DLL虽然可以适应有限的几种协议的测试，但是在本质上没有多大的改进。因此，对现有技术中的协议测试方法可归纳如下几点：
1)重复开发和重复劳动太多，使对测试程序的开发投入的人力太多，造成人力资源的浪费，同时，对测试人员的要求也太高。因为网络等的通讯程序通常是比较复杂的，这就要求程序员应较多的掌握系统调用，了解I/O的机制以及进程间通讯的机制，使得做测试程序的开发与做应用程序的开发处在同一水平线上。
2)程序的维护太困难。这是很显然的，因为测试程序太多，而且由于测试程序本身的特点，往往需要对程序或程序的配置进行频繁的修改，使得维护工作极其麻烦。
3)对数据的输入和输出的处理太隐蔽，不利于测试程序的使用。因为这样的专用程序往往是将处理流程写在程序的代码中的，这样，测试程序的使用者很难明确程序的功能，往往要同程序开发人员沟通，或仔细的阅读功能说明才能顺利使用。
再请参见图1、图2所示，从中我们还可以看出，虽然这些应用协议的类型是多种多样的，对这些协议进行测试需要开发相应的测试程序，但这些测试程序的结构和处理流程在很大程度上都是重复的，只有针对具体的协议数据处理部分才有所不同。
鉴于此及上述现有技术测试方法所存在的诸多不足，本发明的目的就在于提供一种可进行多种应用协议和接口测试的测试方法，其可去除大量应用协议测试程序中所反复重复的工作，简化测试方法，减少人员投入并使维护简单。
本发明一种可进行多种应用协议和接口测试的一种测试方法，是通过使用脚本语言来抽象、描述和执行不同应用协议测试中的不同部分--协议数据的组织和数据解释，使得针对不同应用协议和接口测试进行的程序编写变为通用的、简单的脚本语言描述文件的编写。
根据上述本发明技术方案，所述的使用脚本语言来粗象协议数据的组织和数据解释包括：分析协议的数据格式，将其粗象为字符型、整型、短整型、浮点型、双精度型及其他的数据类型；分析协议的数据动作，将其粗象为数据类型转换、同型数据合并、异型数据合并、同型数据分解、异型数据分解、数据类型比较、数据逻辑比较等操作。
根据上述本发明技术方案，所述的使用脚本语言来执行协议数据的组织和数据解释是通过一解释器实现的，包括在发送端将脚本文件中的描述解释成数据包，在接收端根据脚本文件的描述解释接收到的数据包。
上述的发送端解释器的解释过程可包含三个部分：
1)词法分析过程--对整个脚本文件进行浏览，检查每一个单词生成符号表；
2)语法分析过程--对脚本文件中的描述进行语法规则识别和匹配；
3)解释器的动作过程--在语法规则匹配之后将语句转换成堆栈机器语句。
上述的接收端解释器的解释过程包含四个部分：
1)接收协议的数据包；
2)从脚本文件中读取该协议所对应的测试脚本；
3)分析并执行该段测试脚本；
4)返回结果。
上述的解释器提供的接口是库函数。解释器封装后提供的接口至少包括：
1)协议描述(脚本缓冲，输出缓冲)
2)协议解释(输入缓冲，脚本缓冲，输出缓冲)。
根据上述本发明技术方案，所述的脚本语言为协议描述和解释语言(PDIL)，其语言特征至少包括：
1)支持多种的数据类型；
2)支持逻辑控制语句；
3)支持内嵌的函数；
4)支持字符和数值的运算；
5)支持输入读取和输出；
6)支持函数和过程的定义和使用。
本发明是通过将各种不同的应用协议测试程序中的不同部分--处理输入和输出的数据部分加以抽象、归纳和总结，使得对这些数据打包和解包的工作使用脚本语言来描述，脚本语言所描述的工作由解释器来完成。这样就可以让大量的测试程序中重复的工作得以去除，而不重复的部分可以通过该脚本语言来包容、描述和执行。大量的程序的处理变成了极其少的程序处理，原来复杂的程序编写变成了简单的脚本语言描述文件的编写。
本发明通过使用脚本语言来包容、描述和执行协议数据的组织和数据解释，使得大量复杂的应用协议的测试程序编写变成通用的、简单的脚本语言描述文件的编写。
下面结合附图及具体实施例对本发明再作进一步详细的说明。
图1是现有技术单一协议测试方法的简单流程示意图。
图2是现有技术几种协议测试方法的简单流程示意图。
图3为本发明的多种协议测试方法的简单流程示意图。
本发明是通过使用脚本语言来粗象、描述和执行不同应用协议测试中的不同部分--协议数据的组织和数据解释，使得针对不同应用协议和接口测试进行的程序编写变为通用的、简单的脚本语言描述文件的编写。这里，使用脚本语言来粗象协议数据的组织和数据解释是指：
分析协议的数据格式，将其粗象为字符型、整型、短整型、浮点型、双精度型及其他的数据类型；
分析协议的数据动作，将其粗象为数据类型转换、同型数据合并、异型数据合并、同型数据分解、异型数据分解、数据类型比较、数据逻辑比较等操作。
对这些粗象出来的元素进行归纳和总结，就可以得到本发明的协议描述和解释脚本语言(PDIL)，为了让这种脚本语言同其他的语言进行嵌合，我们采用一个解释器来执行PDIL脚本语言对协议数据的组织和数据解释的描述。因此，本发明的技术方案主要包含两方面的内容：
1)协议描述和解释脚本语言(PDIL)的特点和其语法描述。
2)解释器的工作原理。
下面以POP3协议为例，对该两个方面的内容分别进行阐述。
POP3协议是邮局协议，邮件代理程序如OUTLOOK按照该协议从邮件服务器中取得数据。以邮件客户端(CLIENT)同邮件服务器EXCHANGE SERVER之间最通常的交互过程为例，按照POP3协议，客户端同邮件服务器之间需要经过以下的通信过程：
客户端连接服务器，服务器应答：+OK Microsoft Exchange POP3 serverversion 5.5.2448.8 ready
客户端发送用户名：USER user-name
服务器应答：+OK
客户端发送：PASS password
服务器应答：+OK User successfully logged on
客户端发送：STAT //检查邮件数量和大小
服务器应答：+OK00
客户端发送：QUIT
服务器应答：+OK Microsoft Exchange POP3 server version 5.5.2448.8signing off
现在，用本发明的PDIL脚本语言来描述和解释以上的动作：
//数据定义
string command //保存命令
string comarg //保存命令参数
string sendbuffer //发送缓冲区
stirng recvbuffer //接收缓冲区
string result //结果
//*下面的内容是处理发送和接收用户名的USER操作
command＝“USER”
comarg＝“user-name”
//组织数据包
sendbuffer＝command+comarg
//调用系统函数发送该数据包
syseall(send(sendbuffer))
//调用系统函数接收该数据包
syscall(recv(recvbuffer))
//以下的动作分解接收到的数据包
result＝substr(recvbuffer，3) //
//检查接收到的数据的前三位，如果是+OK表示正常，否则有错，解释器返回，其中的substr是PDIL语言的内部函数，属于数据分解的类型。
if(result！＝“+ok){
print“user not exist”
exit
}
else print“user name is right”
……
按照这一段的代码的流程，对以上的PASS，STAT，QUIT等操作基本上是同样的处理，在STAT操作时会使用到INT的类型和类型转换函数ATOI。
总结以上实施例所述，PDIL语言至少应具备以下的特点：
1)支持多种的数据类型：整型，字符型，长整型，双精度型……
2)支持逻辑控制语句，IF和WHILE语句
3)支持内嵌的函数：主要是数学函数和字符串处理函数和格式转换函数
4)支持字符和数值的运算：支持关系运算和逻辑运算
5)支持输入读取和输出：READ，PRINT
6)支持函数和过程的定义和使用
语言的重点是在字符串的处理和数据格式的转换上
对PDIL的形式语法描述如下，需要说明的是该描述是基本的语法，并非是实际中完备的语法。
1)表达式
expression： 数字
| 字符串
| 变量
| 函数
| 过程
| 内部函数
| 表达式的结合
| ……；
2)语句 ： 表达式
| 函数声明
| 过程声明
| 输入输出语句
| 逻辑语句
| ……；
3)逻辑语句： 赋值语句
| IF语句
| WHILE语句
| 条件语句
| ……；
4)语句段 ： 赋值语句+结束符
| 定义+结束符
| 语句+结束符
| ……；
解释器的实现可归纳为如下三个部分：
1)词法分析过程-即符号表生成过程
2)语法分析过程-即语法规则识别过程
3)解释器的动作过程-即处理过程
词法分析过程为对整个脚本文件进行浏览，检查每一个单词做以下的几种判断：
1)是否结束
2)是否是数字
3)是否是字符串
4)是否是参数
5)是否是内部函数
6)是否是运算符
7)是否是保留字
对于以上的所有的种类，词法分析过程将其分别保留在符号表中的相应的位置里。符号表保存了整个脚本中所有的终结符或非终结符的信息，以供在语法的规则分析之中使用。
语法分析过程是对PDIL脚本文件中的描述进行语法匹配，在找到对应的语法规则后，进行相应的工作处理。这可以借助于现在许多现成的语法分析工具实现。
这里，解释器的动作处理过程是这三部分中工作量最大的部分，是在语法规则匹配之后将语句转换成堆栈机器语句。整个解释器主要的操作由三个栈组成：机器指令栈，数据栈，调用帧栈。
举例说明：X＝3*Y，该语句转化成堆栈机器语句后，指令栈中的指令如下表所示：常量压栈指令常量变量压栈指令变量计算指令计算变量压栈指令变量赋值指令出栈终止指令WHILE语句转化成堆栈机器语句后，堆栈中的指令如下表所示：WHILE指令WHILE语句体指针NEXT语句体指针条件表达指令…终止指令语句体…终止指令NEXT语句体…
针对于不同的语句，该堆栈有不同的机器指令存放。在语句的语法分析结束，堆栈机器语言形成后，开始进行的动作是堆栈机器指令的执行，执行主要是对数据栈进行操作。是通过调用解释器库函数进行。
堆栈机器执行包含以下的处理部分：
1)常数和变量的出入数据栈
2)IF和WHILE的控制流语句操作和出入数据栈
3)表达式的操作和出入数据栈
4)内部函数操作和出入数据栈
5)自定义函数和过程的操作和出入数据栈和出入调用帧栈。
一般的解释器的接口是标准输入，但是本解释器封装后的接口是库函数。作成库函数的目的是便于移植，另外程序用C语言开发可以在大量的平台上通用。
封装后提供两个重要的接口：
1)协议描述(脚本缓冲，输出缓冲)
1)协议解释(输入缓冲，脚本缓冲，输出缓冲)
协议描述函数读入PDIL脚本，然后解释该脚本，将解释后的脚本内容一个二进制的可以直接通过网络发送格式存放到缓冲区中，测试程序读出该缓冲即可。
协议解释函数读入输入缓冲一般是从网络上接收到的数据包，将该缓冲区用PDIL脚本进行解释，可以在解释的过程中将结果写入输出缓冲或者直接解释。
由以上实例的描述并对照现有测试程序开发模式所存在的问题，本发明的优点是相当明显的：
1)基本上没有重复的开发，在写好一个测试程序的框架之后就不用再修改，针对不同种类的协议只需要修改相应的脚本文件。
2)将复杂的程序编写简化为脚本文件编写，由于脚本文件只是针对数据组包和解释包，因此语法简明，对使用者水平要求降低，稍加培训即可顺利使用，大大减少了人员数量也降低了成本。
3)维护简单，只需要维护脚本文件，不需要维护程序。
4)使用简单明了，处理过程在脚本文件中描述，一目了然。
5)使用标准语言开发，提供函数，便于移植。
对比于专用程序，使用脚本语言的方法会降低性能，但是这些缺陷可以通过程序的并发设计和分布计算得到解决。
以上所述的仅为本发明的具体实施方案，并不构成对本发明保护范围的限定。本发明是通过使用脚本语言来包容、描述和执行协议数据的组织和数据解释，使得大量复杂的应用协议的测试程序编写变成通用的、简单的脚本语言文件编写。任何在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的权利要求保护范围之内。