CN104734920A - 对openflow交换机进行稳定性测试的方法及装置 - Google Patents

Abstract

本发明提供一种对openflow交换机进行稳定性测试的方法及装置，所述方法包括：采用测试平台对openflow交换机的稳定性进行测试；测试平台中预置config.py配置文件、RunTest.sh脚本文件、以及测试样例，修改config.py配置文件中的配置信息以连接待测试交换机；运行RunTest.sh脚本文件，自动加载测试样例；定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；保存并输出所述状态表单。本发明摆脱了对于Openflow交换机稳定性测试的重复人工劳动，降低人力投入，降低测试成本，提高测试效率；进一步的，使得对Openflow交换机稳定性的测试实现自动化、标准化，摆脱人为失误，测试准确率得以提高，同时，该方法及装置使Openflow交换机稳定性测试从底层执行迁移到注重上层用例设计，提供了一种新的设计思路。

Description

对openflow交换机进行稳定性测试的方法及装置

技术领域

本发明涉及网络通信领域，尤其涉及一种对openflow交换机进行稳定性测试的方法及装置。

背景技术

随着通信技术的发展，Openflow SDN作为一种新兴的网络技术发展迅猛，OpenFlow概念由美国斯坦福大学NickMcKe-own教授首先提出，是斯坦福大学CleanSlate计划资助的一个开放式协议标准，后成为GENI1计划的子项目。OpenFlow能为校园网络研究人员设计其创新网络提供真实的试验平台，目前OpenFlow技术的研究进展已经引起学术界和产业界的广泛关注，以开放软件模式的控制平面替代了传统的基于系统嵌入的控制平面，由软件驱动的中央控制结点来自动化控制整个网络，简化了网络的配置模式，增加了网络控制权的开放性，在某种程度上符合未来互联网的发展需求，进一步的，openflow交换机研发和更新的速率也在加快，然而，其系统稳定性对其发展非常重要，目前，对其系统稳定性的测试，大部分功能依赖于人工完成，故其稳定性测试效率偏低，且通过人力完成测试，其测试成本较高。

发明内容

本发明的目的在于提供一种对openflow交换机进行稳定性测试的方法及装置。

为实现上述目的之一，本发明一实施方式的所述方法包括：采用测试平台对openflow交换机的稳定性进行测试；

所述测试平台中预置config.py配置文件、RunTest.sh脚本文件、以及测试样例，

修改config.py配置文件中的配置信息以连接待测试交换机；

运行RunTest.sh脚本文件，自动加载测试样例；

定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；

保存并输出所述状态表单。

作为本发明的进一步改进，所述测试平台基于TCL语言进行编程设计或所述测试平台基于Python语言进行编程设计。

作为本发明的进一步改进，基于TCL语言进行编程设计的所述测试平台中集成CTPtelnet和Controller开源控制器；所述CTP和所述Controller开源控制器中均预置若干个测试样例；

基于Python语言进行编程设计的所述测试平台中集成telnetlib和ryu-manager开源控制器；所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

作为本发明的进一步改进，所述测试平台中设置多个APP，每个APP对应一个所述测试样例；每个APP被自动加载后，均在后台运行，当所述APP加载错误时，所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

作为本发明的进一步改进，每个所述APP均为多线程，且对应每个APP产生的状态表单自动保存在LOG文件中。

为实现上述目的之一，本发明一实施方式的对openflow交换机进行稳定性测试的装置

所述装置为测试平台，所述测试平台用于对openflow交换机的稳定性进行测试；

所述测试平台包括：

系统配置存储单元，用于存储config.py配置文件、RunTest.sh脚本文件、以及测试样例；

配置及检测单元，用于修改config.py配置文件中的配置信息以连接待测试交换机，运行RunTest.sh脚本文件，自动加载测试样例；

定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；

表单存储及输出单元，用于保存并输出所述状态表单。

作为本发明的进一步改进，所述测试平台基于TCL语言进行编程设计或所述测试平台基于Python语言进行编程设计。

作为本发明的进一步改进，基于TCL语言进行编程设计的所述测试平台中集成CTPtelnet和Controller开源控制器；

所述CTP和所述Controller开源控制器设置于所述系统配置存储单元中，且所述CTP和所述Controller开源控制器中均预置若干个测试样例；

基于Python语言进行编程设计的所述测试平台中集成telnetlib和ryu-manager开源控制器；

所述telnetlib和ryu-manager开源控制器设置于所述系统配置存储单元中，且所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

作为本发明的进一步改进，所述系统配置存储单元中设置多个APP，每个APP对应一个所述测试样例；所述配置及检测单元还用于使每个APP被自动加载，并将所述APP配置为均在后台运行，且当所述APP加载错误时，驱动所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

作为本发明的进一步改进，每个所述APP均为多线程，所述表单存储及输出单元用于将对应每个APP产生的状态表单自动保存在LOG文件中。

与现有技术相比，本发明的有益效果是：本发明的对openflow交换机进行稳定性测试的方法及装置，摆脱了对于Openflow交换机稳定性测试的重复人工劳动，降低人力投入，降低测试成本，提高测试效率；进一步的， 使得对Openflow交换机稳定性的测试实现自动化、标准化，摆脱人为失误，测试准确率得以提高，同时，该方法及装置使Openflow交换机稳定性测试从底层执行迁移到注重上层用例设计，为openflow交换机的测试方法及装置提供了一种新的设计思路。

附图说明

图1是本发明一实施方式中对openflow交换机进行稳定性测试的方法的流程图；

图2是本发明一实施方式中对openflow交换机进行稳定性测试的装置的模块图；

图3是本发明一实施方式中基于TCL语言进行编程设计的所述测试平台系统框架图；

图4是本发明一具体示例中config.py配置文件的样例示意图；

图5是本发明一具体示例中遍历config.py配置文件中的switchiplist过程的样例示意图；

图6是本发明另一实施方式中基于Python语言进行编程设计的所述测试平台的系统框架图；

图7是本发明一具体示例中基于Python语言进行编程设计的对应telnetlib的具体样例示意图；

图8是本发明一具体示例中基于Python语言进行编程设计的对应ryu-manager开源控制器的具体样例示意图。

具体实施方式

以下将结合附图所示的具体实施方式对本发明进行详细描述。但这些实施方式并不限制本发明，本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。

如图1所示，在本发明的一实施方式中，对openflow交换机进行稳定性测试的方法，所述方法包括：

采用测试平台对openflow交换机的稳定性进行测试；

该测试平台可对openflow交换机的稳定性进行测试，具体的，可包括对openflow交换机系统维度的测试，例如：对其硬件平台测试、软件平台测试、软件系统或软件特性测试、APP测试，以及管理相关的测试等。

进一步的，对应每个系统维度的测试，还分别包括不同的测试方法维度，例如：压力测试、异常测试、性能测试、交互测试、功能测试、随机测试等；

相应的，所述异常测试包括：操作异常、报文异常等测试；

所述性能测试包括：转发性能、规格性能、管理性能等测试；

所述功能测试包括：模拟正常/常用管理操作行为等测试；

所述随机测试包括：随机执行的正常/异常测试。

进一步的，每种测试方法维度均包括openflow交换机的管理特性测试和openflow交换机的软件特性测试。

为了完成上述对所述openflow交换机的稳定性进行测试，本实施方式中，所述方法进一步包括：构建所述测试平台。

本实施方式中，采用构建测试框架的形式构建所述测试平台，以下将详细介绍两种与所述测试平台对应的测试框架。

本发明一实施方式中，结合图3所示，所述测试框架满足模块化及扩展性的要求，并对各个待测试的所述openflow交换机集中式管理，采用调度执行的方式，进而降低操作和维护的工作量。

本实施方式中，所述测试平台基于TCL语言进行编程设计，所述测试平台中集成CTPtelnet和Controller开源控制器；所述CTP和所述Controller开源控制器中均预置若干个测试样例；

所述CTPtelnet通过脚本telnet到openflow交换机并通过CLI来增删配置；所述Controller开源控制器通过openflow协议来向openflow交换机进行增删流及获取状态等操作，所述CLI为命令行操作。

本实施方式中，对所述openflow交换机的操作全部依赖于CTPtelnet执行，具体的，通过CTP telnet到openflow交换机以支持依赖于CLI的交换机配置；通过CTP telnet控制Controller开源控制器通过openflow协议操作openflow交换机，如此，可以使该测试平台基于Tcl语言开发，其继承性和可维护性更高需要操作Ixia时也比较方便。

进一步的，本实施方式中，所述Controller开源控制器的选择有多种，可以选择opendaylight，本实施方式中，为了增强其扩展性，优选Controller开源控制器为ryu，使其支持of10和of13，进而增强器扩展性，并且社区活跃度较高，满足设计的配置需求。

本实施方式中，该测试平台在设计过程中，预置config.py配置文件、RunTest.sh脚本文件、以及测试样例。

本发明中，所有对openflow交换机的稳定性进行测试的相关配置均保存在config.py配置文件中，在对openflow交换机的稳定性进行测试之前，通过修改config.py配置文件中的配置信息以连接待测试交换机；结合图4所示，本实施方式中，config.py配置文件中有一条配置命令为：“switchiplist=[]”，对其进行修改后，可将openflow交换机连入所述测试平台，本示例中，在将openflow交换机接入测试平台之前，获取openflow交换机的IP地址，并将该IP地址添加到config.py配置文件中，如图4所示， config.py配置文件中的“switchiplist=[]”被修改为“switchiplist=[“10.10.33.191”“10.10.33.192” “10.10.33.193”“10.10.33.194”“10.10.33.195”“10.10.33.196”“10.10.33.197”“10.10.33.199”]”后，IP地址为上述内容的openflow交换机便自动接入所述测试平台中，本示例中，该测试平台接入8台openflow交换机，并将该8台openflow交换机同时进行测试，当然，接入测试平台的openflow交换机的数量，可以根据实际需要任意调整，在此不做详细赘述。

进一步的，本实施方式中，所述方法还包括：运行RunTest.sh脚本文件，自动加载测试样例。

本实施方式中，所述测试平台中设置多个APP，每个APP对应一个所述测试样例；为了使该测试平台更趋近于智能化，每个APP在设计阶段均会对其属性进行相应的设置，本实施方式中，将所述APP的属性设置为必选或可选，在运行RunTest.sh脚本文件时，若所述APP的属性为必选，则对该APP自动加载，例如：initdevice.py等，若所述APP的属性为可选，则可通过人工等辅助方式选择性加载，例如：lacp.py等。

进一步的，本示例中，可以选择分两个文件夹保存所述APP，一个文件夹保存必选类APP，一个文件夹保存可选类APP。通常情况下，压力测试，异常测试，随机测试，功能测试，交互测试等，为每个openflow交换机必选测试项目，故将上述测试对应的APP存储到必选类文件夹下，在启动测试脚本后，默认加载执行，而性能测试，例如：转发性能测试、规格性能测试、管理性能测试等通常为可选类APP，故将该类APP保存在可选类文件夹 ，并在需要时，加载相应的APP，在此不再继续赘述。另外，本实施方式中，所有的APP划分为两大类，一类是对应CTPtelnet设置的系统管理类APP，一类是对应Controller开源控制器设置的特性类APP，且每个APP在用户需求变更时，可以自行扩展、修改，本实施方式中，每个app均对应一个openflow交换机的交互消息，由于Controller开源控制器为ryu，故，所述特性类APP分为of10和of13两种。

进一步的，每个APP被自动加载后，均在后台运行，当所述APP加载错误时，所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

所述APP加载错误的情况例如：所述APP自身错误、timeout、设备重启等。

进一步的，每个所述APP均为多线程，以保证在测试过程中，每个App均可以同时并行操作多台openflow交换机。

本示例，结合图5所示，每次运行RunTest.sh脚本文件，自动遍历config.py配置文件中的“switchiplist=[]”，且所述APP对每个openflow交换机单独起一个线程来操作。

进一步的，定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；保存并输出所述状态表单，完成对openflow交换机的稳定性测试。

本示例中，所述运行状态包括：openflow交换机的CPU、内存使用情况，流表调取情况、packet-in/out功能，ovs-vswitchd及flash是否正常等。

进一步的，还可以选择状态表单的输出方式，例如：将生成的状态表单以邮件等形式发送给用户，或以报警的方式提醒用户，当然，在实际应用过程中，状态表单还可以选择性的发送给用户，例如：在状态表单的产生过程中，对所述状态表单做初步确认，若该状态表单的内容对openflow交换机的稳定性测试不产生影响，则取消对其进行输出，若该状态表单的内容对openflow交换机的稳定性测试产生影响，则将其进行输出。

另外，本示例中，在测试平台中可选择设置一个存储文件夹，例如：LOG文件夹，每个APP的运行过程中，生成的状态表单均会自动保存在LOG文件夹中，并在需要时，主动调取该LOG文件夹中的状态表单，查看测试过程的历史记录，进而查看及分析测试过程。

本发明另一实施方式中，结合图6所示，所述测试平台基于Python语言进行编程设计，所述测试平台中集成telnetlib和ryu-manager开源控制器；所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

本实施方式与上述实施方式大致相同，区别在于编程设计的语言不同，本实施方式中，所述telnetlib相当于上一实施方式中的CTPtelnet，ryu-manager开源控制器相当于上一实施方式中的Controller开源控制器，其功能近似。本实施方式中，该测试平台在设计过程中，同样预置config.py配置文件、RunTest.sh脚本文件、以及测试样例等，结合图7、图8所示，图7对应telnetlib，图8对应ryu-manager开源控制器，例如：“config.py”设置在telnetlib下，其表示config.py配置文件，“flowprocessing.pv”设置于ryu-manager开源控制器下，其表示openflow交换机的稳定性测试过程中，对其流表调取情况进行测试的特性类APP，图7中出现的“bond.py”“config.py” “config.pyc”“ftp.py” “gretunnel.py”“initdevice.py”“lacp.py”“lacp.py~”“log”“of10”“of13”“RunTestsh”“RunTestsh~”“telnat.py”“tytp.py”“tools”，图8中出现的“echorequest.py” “echorequest.py~”“echorequest.pyc”“flowprocessing.pv”“flowprocessing.pvc”“of13.log”“packetout.py”“packetout.py~”“packetout.pyc”“tablerequestpy”“~”“tablerequestpyc”表示的内容不再具体赘述。

上述内容中所述的该实施方式相较于上一实施方式，测试环境较方案一更简洁，并且架构上更为简单直接明了；Python语言的脚本效率本身就比Tcl语言高，同时因其还可以支持多线程，效率得到进一步的提高；进一步的，Python这种面向对象的脚本语言，还提供了很多功能全面的标准库。

结合图2所示，在本发明的一实施方式中，对openflow交换机进行稳定性测试的装置，所述装置为测试平台10，本实施方式中，测试平台10用于对openflow交换机的稳定性进行测试。

测试平台10包括：系统配置存储单元100、配置及检测单元200、表单存储及输出单元300。

采用测试平台10对openflow交换机的稳定性进行测试；

该测试平台10可对openflow交换机的系统维度进行测试，例如：对其硬件平台测试、软件平台测试、软件系统或软件特性测试、APP测试，以及管理相关的测试等。

进一步的，对应每个系统维度的测试，还分别包括不同的测试方法维度，例如：压力测试、异常测试、性能测试、交互测试、功能测试、随机测试等；

相应的，所述异常测试包括：操作异常、报文异常等测试；

所述性能测试包括：转发性能、规格性能、管理性能等测试；

所述功能测试包括：模拟正常/常用管理操作行为等测试；

所述随机测试包括：随机执行的正常/异常测试。

进一步的，每种测试方法维度均包括openflow交换机的管理特性测试和openflow交换机的软件特性测试。

为了完成上述对所述openflow交换机的稳定性进行测试，本实施方式中，构建所述测试平台10。本实施方式中，采用构建测试框架的形式构建测试平台10，以下将详细介绍两种与所述测试平台对应的测试框架。

本发明一实施方式中，结合图3所示，所述测试框架满足模块化及扩展性的要求，并对各个待测试的所述openflow交换机集中式管理，采用调度执行的方式，进而降低操作和维护的工作量。

本实施方式中，测试平台10基于TCL语言进行编程设计，测试平台10包括系统配置存储单元100，系统配置存储单元100中集成CTPtelnet和Controller开源控制器；所述CTP和所述Controller开源控制器中均预置若干个测试样例；

所述CTPtelnet通过脚本telnet到openflow交换机并通过CLI来增删配置；所述Controller开源控制器通过openflow协议来向openflow交换机进行增删流及获取状态等操作，所述CLI为命令行操作。

本实施方式中，对所述openflow交换机的操作全部依赖于CTPtelnet执行，具体的，通过CTP telnet到openflow交换机以支持依赖于CLI的交换机配置；通过CTP telnet控制Controller开源控制器通过openflow协议操作openflow交换机，如此，可以使该测试平台基于Tcl语言开发，其继承性和可维护性更高需要操作Ixia时也比较方便。

进一步的，本实施方式中，所述Controller开源控制器的选择有多种，可以选择opendaylight，本实施方式中，为了增强其扩展性，优选Controller开源控制器为ryu，使其支持of10和of13，进而增强器扩展性，并且社区活跃度较高，满足设计的配置需求。

本实施方式中，该测试平台在设计过程中，配置存储单元100具体用于存储config.py配置文件、RunTest.sh脚本文件、以及测试样例等。

本发明中，所有对openflow交换机的稳定性进行测试的相关配置均保存在config.py配置文件中，在对openflow交换机的稳定性进行测试之前，通过配置及检测单元200修改config.py配置文件中的配置信息以连接待测试交换机；结合图4所示，本实施方式中，config.py配置文件中有一条配置命令为：“switchiplist=[]”，配置及检测单元200对其进行修改后，可将openflow交换机连入所述测试平台，本示例中，在将openflow交换机接入测试平台之前，配置及检测单元200获取openflow交换机的IP地址，并将该IP地址添加到config.py配置文件中后，本示例中，如图4所示，config.py配置文件中的“switchiplist=[]”被配置及检测单元200修改为“switchiplist=[“10.10.33.191” “10.10.33.192”“10.10.33.193”“10.10.33.194”“10.10.33.195”“10.10.33.196”“10.10.33.197”“10.10.33.199”]”后，IP地址为上述内容的openflow交换机便自动接入所述测试平台中，本示例中，该测试平台接入8台openflow交换机，并将该8台openflow交换机同时进行测试，当然，接入测试平台的openflow交换机的数量，可以根据实际需要任意调整，在此不做详细赘述。

进一步的，本实施方式中，配置及检测单元200还用于运行RunTest.sh脚本文件，自动加载测试样例。

本实施方式中，所述测试平台中设置多个APP，每个APP对应一个所述测试样例；为了使该测试平台更趋近于智能化，每个APP在设计阶段均会对其属性进行相应的设置，本实施方式中，将所述APP的属性设置为必选或可选，在运行RunTest.sh脚本文件时，若所述APP的属性为必选，则对该APP自动加载，例如：initdevice.py等，若所述APP的属性为可选，则可通过人工等辅助方式选择性加载，例如：lacp.py等。

进一步的，本示例中，可以选择分两个文件夹保存所述APP，一个文件夹保存必选类APP，一个文件夹保存可选类APP。通常情况下，压力测试，异常测试，随机测试，功能测试，交互测试等，为每个openflow交换机必选测试项目，故将上述测试对应的APP存储到必选类文件夹下，在启动测试脚本后，默认加载执行，而性能测试，例如：转发性能测试、规格性能测试、管理性能测试等通常为可选类APP，故将该类APP保存在可选类文件夹 ，并在需要时，加载相应的APP，在此不再继续赘述。另外，本实施方式中，所有的APP划分为两大类，一类是对应CTPtelnet设置的系统管理类APP，一类是对应Controller开源控制器设置的特性类APP，且每个APP在用户需求变更时，可以自行扩展、修改，本实施方式中，每个app均对应一个openflow交换机的交互消息，由于Controller开源控制器为ryu，故，所述特性类APP分为of10和of13两种。

进一步的，配置及检测单元还用于使每个APP被自动加载，并将所述APP配置为均在后台运行，且当所述APP加载错误时，驱动所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

所述APP加载错误的情况例如：所述APP自身错误、timeout、设备重启等。

进一步的，每个所述APP均为多线程，以保证在测试过程中，每个App均可以同时并行操作多台openflow交换机。

本实施方式中，结合图5所示，配置及检测单元200每次运行RunTest.sh脚本文件，自动遍历config.py配置文件中的“switchiplist=[]”，且所述APP对每个openflow交换机单独起一个线程来操作。

进一步的，表单存储及输出单元300定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；保存并输出所述状态表单，完成对openflow交换机的稳定性测试。

本示例中，所述运行状态包括：openflow交换机的CPU、内存使用情况，流表调取情况、packet-in/out功能，ovs-vswitchd及flash是否正常等。

进一步的，表单存储及输出单元300还可以选择状态表单的输出方式，例如：将生成的状态表单以邮件等形式发送给用户，或以报警的方式提醒用户，当然，在实际应用过程中，状态表单还可以选择性的发送给用户，例如：在状态表单的产生过程中，对所述状态表单做初步确认，若该状态表单的内容对openflow交换机的稳定性测试不产生影响，则取消对其进行输出，若该状态表单的内容对openflow交换机的稳定性测试产生影响，则将其进行输出。

另外，本示例中，在测试平台中可选择设置一个存储文件夹，例如：LOG文件夹，每个APP的运行过程中，生成的状态表单均会自动保存在LOG文件夹中，并在需要时，主动调取该LOG文件夹中的状态表单，查看测试过程的历史记录，进而查看及分析测试过程。

本发明另一实施方式中，结合图6所示，测试平台10基于Python语言进行编程设计，测试平台10包括系统配置存储单元100，系统配置存储单元100中集成telnetlib和ryu-manager开源控制器；所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

本示例中，统配置存储单元100、配置及检测单元200、表单存储及输出单元300与上一实时方式中出现的相应单元作用相同，在此不做详细赘述。区别在于编程设计的语言不同，本实施方式中，所述telnetlib相当于上一实施方式中的CTPtelnet，ryu-manager开源控制器相当于上一实施方式中的Controller开源控制器，其功能近似。本实施方式中，该测试平台在设计过程中，统配置存储单元100同样预置config.py配置文件、RunTest.sh脚本文件、以及测试样例等，结合图7、图8所示，图7对应telnetlib，图8对应ryu-manager开源控制器，例如：“config.py”设置在telnetlib下，其表示config.py配置文件，“flowprocessing.pv”设置于ryu-manager开源控制器下，其表示openflow交换机的稳定性测试过程中，对其流表调取情况进行测试的特性类APP，图7中出现的“bond.py”“config.py”“config.pyc”“ftp.py”“gretunnel.py” “initdevice.py”“lacp.py”“lacp.py~”“log”“of10”“of13”“RunTestsh”“RunTestsh~”“telnat.py”“tytp.py”“tools”，图8中出现的“echorequest.py”“echorequest.py~” “echorequest.pyc”“flowprocessing.pv”“flowprocessing.pvc”“of13.log”“packetout.py”“packetout.py~”“packetout.pyc”“tablerequestpy”“~”“tablerequestpyc”表示的内容不再具体赘述。

上述内容中所述的该实施方式相较于上一实施方式，测试环境较方案一更简洁，并且架构上更为简单直接明了；Python语言的脚本效率本身就比Tcl语言高，同时因其还可以支持多线程，效率得到进一步的提高；进一步的，Python这种面向对象的脚本语言，还提供了很多功能全面的标准库。

综上所述，本发明的对openflow交换机进行稳定性测试的方法及装置，摆脱了对于Openflow交换机稳定性测试的重复人工劳动，降低人力投入，降低测试成本，提高测试效率；进一步的， 使得对Openflow交换机稳定性的测试实现自动化、标准化，摆脱人为失误，测试准确率得以提高，同时，该方法及装置使Openflow交换机稳定性测试从底层执行迁移到注重上层用例设计，为openflow交换机的测试方法及装置提供了一种新的设计思路。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助通用硬件平台的方式来实现。

以上所描述的装置实施方式仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件是逻辑模块，即可以位于芯片逻辑中的一个模块中，或者也可以分布到芯片内的多个数据处理模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请可用于众多通用或专用的通信芯片中。例如：交换芯片、路由器芯片，服务器芯片等等。

应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施方式中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

Claims (10)

1.一种对openflow交换机进行稳定性测试的方法，其特征在于，所述方法包括：

采用测试平台对openflow交换机的稳定性进行测试；

所述测试平台中预置config.py配置文件、RunTest.sh脚本文件、以及测试样例；

修改config.py配置文件中的配置信息以连接待测试交换机；

运行RunTest.sh脚本文件，自动加载测试样例；

定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；

保存并输出所述状态表单。

2.根据权利要求1所述的对openflow交换机进行稳定性测试的方法，其特征在于，所述测试平台基于TCL语言进行编程设计或所述测试平台基于Python语言进行编程设计。

3.根据权利要求2所述的对openflow交换机进行稳定性测试的方法，其特征在于，

基于TCL语言进行编程设计的所述测试平台中集成CTPtelnet和Controller开源控制器；所述CTP和所述Controller开源控制器中均预置若干个测试样例；

基于Python语言进行编程设计的所述测试平台中集成telnetlib和ryu-manager开源控制器；所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

4.根据权利要求3所述的对openflow交换机进行稳定性测试的方法，其特征在于，

所述测试平台中设置多个APP，每个APP对应一个所述测试样例；每个APP被自动加载后，均在后台运行，当所述APP加载错误时，所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

5.根据权利要求4所述的对openflow交换机进行稳定性测试的方法，其特征在于，

每个所述APP均为多线程，且对应每个APP产生的状态表单自动保存在LOG文件中。

6.一种对openflow交换机进行稳定性测试的装置，其特征在于，所述装置为测试平台，所述测试平台用于对openflow交换机的稳定性进行测试；

所述测试平台包括：

系统配置存储单元，用于存储config.py配置文件、RunTest.sh脚本文件、以及测试样例；

配置及检测单元，用于修改config.py配置文件中的配置信息以连接待测试交换机，运行RunTest.sh脚本文件，自动加载测试样例；

定时检测openflow交换机的运行状态，并将其运行状态生成状态表单；

表单存储及输出单元，用于保存并输出所述状态表单。

7.根据权利要求6所述的对openflow交换机进行稳定性测试的装置，其特征在于，

所述测试平台基于TCL语言进行编程设计或所述测试平台基于Python语言进行编程设计。

8.根据权利要求7所述的对openflow交换机进行稳定性测试的装置，其特征在于，

基于TCL语言进行编程设计的所述测试平台中集成CTPtelnet和Controller开源控制器；

所述CTP和所述Controller开源控制器设置于所述系统配置存储单元中，且所述CTP和所述Controller开源控制器中均预置若干个测试样例；

基于Python语言进行编程设计的所述测试平台中集成telnetlib和ryu-manager开源控制器；

所述telnetlib和ryu-manager开源控制器设置于所述系统配置存储单元中，且所述telnetlib和ryu-manager开源控制器中均预置若干个测试样例。

9.根据权利要求8所述的对openflow交换机进行稳定性测试的装置，其特征在于，

所述系统配置存储单元中设置多个APP，每个APP对应一个所述测试样例；所述配置及检测单元还用于使每个APP被自动加载，并将所述APP配置为均在后台运行，且当所述APP加载错误时，驱动所述APP自动重启，直至对openflow交换机的稳定性测试完成或借助人工使其停止。

10.根据权利要求9所述的对openflow交换机进行稳定性测试的装置，其特征在于，

每个所述APP均为多线程，所述表单存储及输出单元用于将对应每个APP产生的状态表单自动保存在LOG文件中。